2017-04-12 17 views
5

मैं सर्वर लॉग पर गोपनीय जानकारी लॉग इन करने वाले लोगों के बारे में बहुत चिंतित हूं। मैंने उत्पादन में सर्वर लॉग देखा है। कुछ डेवलपर्स गलती से सुरक्षा जानकारी पासवर्ड, clientid, clientSecret आदि जैसे प्रवेश कर रहे हैं से संबंधितलॉगिंग सुरक्षा पर चेतावनी दें

वहाँ कोई तरीका है, ग्रहण प्लगइन या किसी उपकरण की तरह, डेवलपर्स चेतावनी देने के लिए, जबकि उनके कोड लिखने?

`ex : log.info("usernam = " + username + "password = " + password) ;` // 
Warn that confidential info is getting logged. 

मैं कुछ शोध किया है ... मैं sonarLint और FindBug

जैसे उपकरणों को देखा है, लेकिन उन प्लगइन्स मेरी समस्या का समाधान करने में असमर्थ हैं।

+2

इस तरह की चीजें टूल्स द्वारा 100% हल नहीं की जा सकती हैं, भले ही आप स्थिर कोड विश्लेषण करते हैं, यह केवल तभी काम करता है जब आपके लॉग इन वेरिएबल नाम या जानकारी ग्रंथों में वास्तव में "उपयोगकर्ता" या "पासवर्ड" जैसे सबस्ट्रिंग होते हैं। यदि वे नहीं करते हैं, तो आप इसका पता नहीं लगा सकते हैं। क्या आपने कभी इस हास्यास्पद चीज़ के बारे में सुना है जिसे कोड समीक्षा कहा जाता है? मैंने सुना है कि यह सहायक है। – kriegaex

उत्तर

7

सोनारलिंट नियम S2068: Credentials should not be hard-coded प्रदान करता है, जो हार्ड-कोड किए गए प्रमाण-पत्रों के उपयोग को लक्षित करता है, और यह आपके द्वारा प्राप्त की जा रही चीज़ों के करीब लगता है, हालांकि यह आपकी आवश्यकताओं के लिए पर्याप्त नहीं हो सकता है।

जैसा कि अन्य उत्तरों में बताया गया है, हालांकि, इस तरह के सुरक्षा छेद की पहचान अंततः कठिन हो सकती है और मजबूत कोड समीक्षा जोखिम को कम करने के लिए निश्चित रूप से एक अच्छा कदम है।

अब, अगर आप वास्तव में वालों के उपयोगों के बारे में डर लगता है, पहले से ही संभावित मुद्दों जानता है, और क्या डेटा प्रकट कर सकता है, मैं SonarQube के लिए अपने स्वयं के जावा कस्टम नियम लिखने के लिए सुझाव है।

कस्टम नियम सोनारलिंट द्वारा समर्थित हैं और कस्टम प्लगइन युक्त एक सोनाक्यूब सर्वर पर तैनात किए जाने के बाद एंटरप्राइज़ स्तर पर लागू किया जा सकता है। यह समाधान आपको स्पष्ट रूप से परिभाषित करने की अनुमति देगा कि आप क्या लक्षित करना चाहते हैं, और अपनी आवश्यकताओं और उद्यम विनिर्देशों के आधार पर नियम को सुदृढ़ करें। इस तरह के नियम लिखना कठिन नहीं है और निम्नलिखित ट्यूटोरियल में दस्तावेज किया गया है: Custom rules for Java

3

सुरक्षा छेद कैसे दिखाई दे सकते हैं इसके कई अलग-अलग तरीके हैं। ब्राउज़र कंसोल पर डेटा लॉगिंग उनमें से केवल एक है।

और मेरे ज्ञान के लिए, कोई ऐसा उपकरण नहीं है जो स्वचालित रूप से उन सुरक्षा समस्याओं का पता लगा सके। किसी पृष्ठ पर निजी उपयोगकर्ता जानकारी का पर्दाफाश न करने के लिए प्रोग्रामर की ज़िम्मेदारी है।

इस मामले में सलाह है: कभी ब्राउज़र कंसोल के लिए पासवर्ड (विशेष रूप से एन्क्रिप्ट नहीं किए गए हैं) के लिए लॉग इन! इसके बजाय, डेटाबेस में अपने पासवर्ड को एल्गोरिदम के साथ एन्क्रिप्ट करें जिसे डिक्रिप्ट नहीं किया जा सकता है।

+2

'एन्क्रिप्ट' द्वारा आप शायद 'हैश' मतलब था। लेकिन किसी को सावधान रहना होगा, पासवर्ड हैशिंग के लिए कई सामान्य हैश एल्गोरिदम उचित नहीं हैं (अब)। आपको आधुनिक हैश फ़ंक्शंस का उपयोग करना चाहिए, जैसे उदा। bcrypt। लेकिन पासवर्ड कैसे संग्रहीत किए जाते हैं, इस मामले में वास्तव में प्रासंगिक नहीं है, क्योंकि किसी बिंदु पर उपयोगकर्ताओं को सादे टेक्स्ट में अपने पासवर्ड दर्ज करना पड़ता है। कुछ ढांचे को आसानी से पहुंचने और पासवर्ड को लॉग इन करने में कठिनाई हो सकती है। – Kapep

+1

हां, मेरा मतलब है 'हैश'। मैंने विशिष्ट एल्गोरिदम पर सलाह देने से बचना, क्योंकि, जैसा कि आप कहते हैं, औपचारिक रूप से सुरक्षित रूप से माना जाने वाला कई एल्गोरिदम अब और नहीं हैं (और यह इस प्रश्न के विषय से बाहर है)। –

0

क्या आपको कंट्रास्ट टूल का प्रयास करना चाहिए। यह अच्छा है और हम लंबे समय से इसका इस्तेमाल कर रहे हैं।

यह सब अद्यतन OWASP शीर्ष 10 मुद्दों का ख्याल रखता है।

एंटरप्राइज़ अनुप्रयोगों में सुरक्षा छेद खोजने के लिए काफी अच्छा है।

उनका समर्थन भी अच्छा है।

0

एक और दृष्टिकोण है कि कुछ-बताएं कहानी रुझान देखकर एक कस्टम लॉग appender बनाने के लिए है (उदाहरण के लिए "पासवर्ड" और "पासवर्ड" की तरह काम करता है) और संदेश obliterates, या कोई त्रुटि फेंकता है।

हालांकि, यह खतरनाक हो सकता है। यदि बुरे लोग जानते थे कि आप ऐसा कर रहे थे, तो वे अपने ट्रैक को कवर करने या यहां तक ​​कि अपने सर्वर को क्रैश करने के लिए इसका फायदा उठाने का प्रयास कर सकते हैं।

1

मैं इस पर कुछ आउट ऑफ़ द बॉक्स समाधान के लिए अपनी सांस नहीं पकड़ूंगा।अपने स्वयं के लॉगिंग से परे, आपको अपनी निर्भरताओं द्वारा किए गए लॉगिंग के बारे में भी चिंतित होना होगा। उस ने कहा, आपके पास काम करने के लिए दो क्षेत्र हैं: लॉग में क्या होता है और किसके पास लॉग तक पहुंच है।

जहां तक ​​लॉग में जाता है, इस समस्या का मुकाबला करने के लिए आपके सर्वोत्तम उपकरण शिक्षा और सहयोग (उपर्युक्त कोड समीक्षा सहित) हैं। लॉगिंग के लिए गैर-कार्यात्मक आवश्यकताओं की एक सूची लिखने के साथ शुरू करें जिसमें सुरक्षा शामिल है जो लॉग इन करें और लॉग कैसे करें (मार्कर, स्तर, संवेदनशील पैरामीटर इत्यादि) को संबोधित करता है। मैं इस सूची को परिभाषित करने के लिए सहकर्मियों के साथ काम करने की सलाह देता हूं, इसलिए "हमें वास्तव में कुछ करने की ज़रूरत है" के बजाय "रवि के लॉगिंग क्रूसेड" के रूप में जाना जाने वाला नहीं है।

एक बार उस सूची को परिभाषित करने के बाद और आप अपने सहयोगी और/या प्रबंधन के खरीद-इन प्राप्त कर लेते हैं, तो आप उन कार्यान्वयन लॉगिंग के लिए रैपर लिख सकते हैं जो आपके द्वारा एकत्र की गई गैर-कार्यात्मक लॉगिंग आवश्यकताओं की सूची का समर्थन करते हैं। यदि संवेदनशील पैरामीटर को लॉग इन करना वास्तव में जरूरी है, तो मूल खाते द्वारा बाद में पुनर्प्राप्ति के लिए पैरामीटर को असम्बद्ध रूप से एन्क्रिप्टेड करने का एक तरीका प्रदान करें: जैसे फ़ाइल में संग्रहीत एन्क्रिप्शन कुंजी केवल रूट/कंटेनर द्वारा पहुंचा जा सकता है। प्रबंधन के लिए, आपको मूल्य प्रस्ताव लिखने में कुछ समय बिताना पड़ सकता है कि आपकी पहल आपकी कंपनी के लिए मूल्यवान क्यों है।

जो भी आपके एसएलडीसी को परिभाषित करता है उसके साथ अगला काम - सुनिश्चित करें कि आपके एसडीएलसी में परिवर्तन बाहरी रूप से संप्रेषित है। क्या उन्हें आपकी कंपनी के लिए 1 आइटम के साथ कार्यान्वित करने के लिए एक सुरक्षित कोडिंग चेकलिस्ट बनाएं जो कहती है: सभी लॉगिंग OurCompanySecureLogger का उपयोग करके लागू की गई है। अब आप पहल को लागू करने पर काम करना शुरू कर सकते हैं। मैं निर्माण सर्वर पर एक चेक लिखने की अनुशंसा करता हूं जो निर्भरताओं को देखता है और बिल्ड को विफल करता है अगर उसे log4j, slf4j, logback, आदि के लिए सीधे संदर्भ मिलता है

समस्या के दूसरे भाग के बारे में, अपनी SysOps टीम के साथ काम करें कर्तव्यों के अलगाव के नियमों को परिभाषित करें। यही है, सॉफ़्टवेयर इंजीनियरों को उन सर्वरों तक पहुंच नहीं होनी चाहिए जहां लॉगिंग की जा रही है। यदि आप इस धारणा का समर्थन करने के लिए इस बिंदु पर पर्याप्त रूप से पर्याप्त कर्मचारी नहीं हैं, तो आपको रचनात्मक होना पड़ सकता है।

संबंधित मुद्दे