प्रत्येक प्रोग्रामर को सुरक्षा के बारे में क्या पता होना चाहिए? [बन्द है]

427

मैं एक आईटी स्टूडेंट हूं और अब यूनिवर्सिटी में 3 साल का हूं। अब तक हम सामान्य (प्रोग्रामिंग, एल्गोरिदम, कंप्यूटर वास्तुकला, गणित, आदि) में कंप्यूटर से संबंधित कई विषयों का अध्ययन कर रहे हैं।

मुझे पूरा यकीन है कि कोई भी सुरक्षा के बारे में हर बात नहीं सीख सकता है, लेकिन यकीन है कि प्रत्येक प्रोग्रामर या आईटी छात्र को "न्यूनतम" ज्ञान होना चाहिए और मेरे बारे में यह जानना चाहिए कि यह न्यूनतम ज्ञान क्या है?

क्या आप कुछ ई-पुस्तकें या पाठ्यक्रम सुझा सकते हैं या कुछ भी इस सड़क से शुरू करने में मदद कर सकते हैं?

security 
— एमएच
स्रोत
6
काफी के समान stackoverflow.com/questions/325862/...
— थॉमस
118
नियम # 1: कभी भी उपयोगकर्ता के इनपुट पर भरोसा न करें। यहां तक ​​कि अगर यह आपकी दादी नहीं है
— एंथनी फोर्लोनी
2
..और इस सूत्र में भी बहुत अच्छी जानकारी है - stackoverflow.com/questions/72394/…
— श्रीपति कृष्णन
मेरा सवाल केवल प्रोग्रामर और उनकी गलतियों के बारे में नहीं है, आईटी और कंप्यूटर विज्ञान के छात्रों के बारे में भी है
— मोहम्मद अलहमौद
1
अपने त्रुटि संदेश देखें। जब आप उपयोगकर्ता के अनुकूल होना चाहते हैं, तो "यह खाता मौजूद नहीं है" और "पासवर्ड अमान्य है" के बीच का अंतर कुछ मामलों में खतरनाक हो सकता है।
— माइकल मेयोर

जवाबों:

551

यदि आप चाहते हैं कि आपके आवेदन सुरक्षित रहें तो ध्यान में रखें:

  • कभी किसी इनपुट पर भरोसा मत करो!
  • सभी अविश्वसनीय स्रोतों से वैध इनपुट - श्वेतसूची का उपयोग करें न कि ब्लैक लिस्ट
  • शुरुआत से सुरक्षा की योजना बनाएं - यह ऐसा कुछ नहीं है जिसे आप अंत में बोल्ट कर सकते हैं
  • इसे सरल रखें - जटिलता से सुरक्षा छिद्रों की संभावना बढ़ जाती है
  • अपनी हमले की सतह को कम से कम रखें
  • सुनिश्चित करें कि आप सुरक्षित रूप से विफल हो गए हैं
  • गहराई में रक्षा का उपयोग करें
  • कम से कम विशेषाधिकार के सिद्धांत का पालन करें
  • धमकी मॉडलिंग का उपयोग करें
  • कम्पार्टमेंटलाइज़ करें - इसलिए आपका सिस्टम सभी या कुछ भी नहीं है
  • रहस्य छिपाना कठिन है - और कोड में छिपे रहस्य लंबे समय तक गुप्त नहीं रहेंगे
  • अपना स्वयं का क्रिप्टो न लिखें
  • क्रिप्टो का उपयोग करने का मतलब यह नहीं है कि आप सुरक्षित हैं (हमलावर एक कमजोर लिंक की तलाश करेंगे)
  • बफर ओवरफ्लो के बारे में जागरूक रहें और उनसे कैसे बचाव करें

आपके एप्लिकेशन को सुरक्षित बनाने के बारे में कुछ उत्कृष्ट पुस्तकें और लेख ऑनलाइन हैं:

अपने डेवलपर्स को एप्लिकेशन सिक्योरिटी बेस्ट प्रैटिस पर प्रशिक्षित करें

कोडबैशिंग (भुगतान किया गया)

सुरक्षा नवाचार (भुगतान)

सुरक्षा कम्पास (भुगतान)

OWASP WebGoat (मुक्त)

— बिग्नम
स्रोत
+1 "शोषण करने वाला सॉफ्टवेयर: कोड कैसे तोड़ना है" एक महान पुस्तक है, हालांकि वह स्लाइड जो आप से जुड़ी है वह भयानक है।
— किश्ती
7
हालांकि, दुर्भाग्य से किसी भी आधुनिक प्रणाली में कम से कम विशेषाधिकार के सिद्धांत को तुरंत लागू करना लगभग असंभव है। उदाहरण के लिए, लिनक्स कर्नेल (मैं वर्तमान में उपयोग कर रहा हूं) में सी कोड की 9.4 मिलियन से अधिक रेखाएं और विधानसभा की 400K से अधिक लाइनें हैं, जो सभी एक अप्रतिबंधित संदर्भ में चलती हैं। इन लाखों पंक्तियों में से एक में एक साधारण गलत अनुमान (शायद जानबूझकर) पूरी प्रणाली से समझौता करेगा। शायद अगली शताब्दी या दो में एक समाधान निकलेगा, शायद नहीं, क्योंकि कोई भी वास्तव में सुरक्षित ओएस / भाषा / रूपरेखा बनाने की परवाह नहीं करता है।
— L --o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e
1
मैं उस सूची में "वेब एप्लिकेशन हैकर की हैंडबुक" जोड़ूंगा।
— outcassed
34
बदलें "उपयोगकर्ता इनपुट पर कभी भरोसा न करें!" "किसी भी इनपुट पर कभी भरोसा न करें!"। अन्य सॉफ़्टवेयर से आने वाले इनपुट को उपयोगकर्ता इनपुट के समान माना जाना चाहिए - उदाहरण के लिए, वेबसाइट लॉगिंग में अधिकांश लोग उपयोगकर्ता-एजेंट / ब्राउज़र आईडी फ़ील्ड को 'उपयोगकर्ता इनपुट' के रूप में नहीं सोचेंगे, लेकिन यह आसानी से शामिल हो सकता है, जैसे कि, एसक्यूएल इंजेक्षन।
— पीटरिस
2
@ L @o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e, वैसे, .NET पर बनाया गया Microsoft अनुसंधान प्रायोगिक OS (एकवचन) है, जिसने सुरक्षा को एक प्राथमिक लक्ष्य के रूप में लक्षित किया है (कोई बफर ओवरफ्लो नहीं, yay!)। कोई प्रोसेस मेमोरी शेयरिंग, कोई कोड सेल्फ-मॉडिफिकेशन नहीं, यहां तक ​​कि डिवाइस ड्राइवर भी .NET में एक और सॉफ्टवेयर से अलग प्रक्रिया है। काफी दिलचस्प अवधारणा है, लेकिन इसे लोगों को धकेलना बहुत मुश्किल होगा (सबसे महत्वपूर्ण बात, यह बहुत ज्यादा मौजूदा सॉफ़्टवेयर या यहां तक ​​कि ड्राइवरों के साथ पीछे की संगतता नहीं कर सकता है; लिनक्स के पहले 10 वर्षों की तरह थोड़ा सा: डी)।
— लुआन
102

प्रोग्रामरों के लिए सुरक्षा का नियम # 1: अपना खुद का रोल न करें

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

अब, यह कहना नहीं है कि आपको सुरक्षा के बारे में कुछ भी सीखने की आवश्यकता नहीं है। आपको निश्चित रूप से यह समझने के लिए पर्याप्त जानने की आवश्यकता है कि आप क्या कर रहे हैं और सुनिश्चित करें कि आप सही तरीके से टूल का उपयोग कर रहे हैं। हालाँकि, यदि आप कभी भी खुद के क्रिप्टोग्राफी एल्गोरिथ्म, प्रमाणीकरण प्रणाली, इनपुट सैनिटाइज़र, आदि को लिखना शुरू करने के बारे में पाते हैं, तो रुकें, एक कदम पीछे लें और नियम # 1 को याद रखें।

— टायलर मैकहेनरी
स्रोत
10
मेरी राय में यह एक बुरा नियम है। आपकी संपत्ति में किसी भी वास्तविक ब्याज के बजाय आपके द्वारा चुने गए प्लेटफ़ॉर्म के कारण आपको अनिवार्य रूप से लक्षित किया जा सकता है। उन सभी सुरक्षा छेदों के बारे में सोचें जो तीसरे पक्ष के प्लेटफार्मों में पाए जाते हैं, और वे सभी उत्पाद जो केवल इसलिए असुरक्षित हैं क्योंकि वे इसका उपयोग करते हैं। मैं अपनी सुरक्षा को किसी तीसरे पक्ष पर भरोसा करने के लिए इतनी जल्दी नहीं होगा।
— फोसको
9
मुझे लगता है कि यह क्रिप्टो के लिए एक अच्छा नियम है - अपने स्वयं के एन्क्रिप्शन को रोल करना आपदा के लिए एक नुस्खा है। लेकिन अपने खुद के ब्लॉग इंजन को रोल करना अधिक सुरक्षित हो सकता है क्योंकि फॉस्को बताते हैं - यदि आप अपना रोल खुद करते हैं तो आपको स्वचालित हमलों द्वारा पकड़े जाने की संभावना कम होती है जो कि वर्डप्रेस इंस्टाल से निपटना होता है।
— जेम्स पी मैकग्राथ
5
जब यह क्रिप्टो करने की बात आती है, तो यह नियम बिल्कुल सही है। अपनी खुद की क्रिप्टो, अवधि न लिखें। जब 3 पार्टी प्लेटफॉर्म का उपयोग करने की बात आती है, तो यह निर्भर करता है। कुछ प्लेटफ़ॉर्म स्वाभाविक रूप से अधिक सुरक्षित हैं, कुछ प्लेटफ़ॉर्म स्वाभाविक रूप से कम सुरक्षित हैं, और अधिकांश प्लेटफ़ॉर्म शायद कुछ सुरक्षा सुविधाएँ प्रदान करते हैं लेकिन कुछ ज्ञात अटैक वैक्टर भी हैं। हाल ही में रेल भेद्यता ले लो जो गिटहब पर सुरक्षा छेद का कारण बने । निस्संदेह रेल कई सुरक्षा सुविधाएँ प्रदान करता है, लेकिन इसमें असुरक्षित चूक के साथ कुछ शक्तिशाली विशेषताएं भी हैं।
— माइकल कोपिन्स्की
7
जब यह क्रिप्टो करने की बात आती है, तो अपना स्वयं का रोल न करें - लेकिन उस चीज़ को न समझें जो आप उपयोग कर रहे हैं। यदि आपको समझ नहीं आता है कि दो संदेशों के लिए RC4 के लिए एक ही एन्क्रिप्शन कुंजी का उपयोग करना एक भयानक विचार है, तो उदाहरण के लिए किसी भी स्ट्रीम सिफर का उपयोग करने से पहले पढ़ें।
— क्रिस्टोफर क्रुत्जिग
3
हार्टलेड बग के बाद भी यह स्पष्ट है कि यह एक अच्छा नियम है। कल्पना कीजिए कि किसी रिवाज़ या मालिकाना परियोजना में उष्मीय जैसे बग को खोजने में कितना मुश्किल रहा होगा। यदि आप अपना स्वयं का रोल करते हैं, तो आप केवल अस्पष्टता के पीछे छिपे हुए हैं और यह नहीं जान पाएंगे कि किस कीड़े का शोषण किया जा सकता है।
— सकी
71

हर प्रोग्रामर को पता होना चाहिए कि शोषण कोड कैसे लिखना है।

बिना यह जाने कि सिस्टम का किस तरह से शोषण किया जाता है आप गलती से कमजोरियों को रोक रहे हैं। जब तक आप अपने पैच का परीक्षण करना नहीं जानते, तब तक कोड का पता लगाना बिल्कुल निरर्थक है। सुरक्षा केवल सोचा प्रयोगों का एक गुच्छा नहीं है, आपको वैज्ञानिक होना चाहिए और अपने प्रयोगों का परीक्षण करना चाहिए।

— बदमाश
स्रोत
10
मेरा तर्क है कि यह आवश्यक नहीं है। बस सिद्धांत का पालन करें: यदि हमलावर किसी भी प्रकार के स्मृति भ्रष्टाचार का कारण बन सकता है, तो अपने आप को स्वामित्व पर विचार करें। वास्तव में लिखने (काम करने) के कारनामों के विवरण में आने की आवश्यकता नहीं है।
— newgre 19
6
@newgre हर भेद्यता एक बफर अतिप्रवाह नहीं है। कॉमन वेकनेस एन्यूमरेशन सिस्टम द्वारा कवर की गई कुछ हजार कमजोरियां हैं। एक प्रोग्रामर को हमलावर के दिमाग को समझने की जरूरत है या वह अनजाने में गलतियां करेगा।
— किश्ती
1
मुझे पता है कि उनमें से हर एक बफर अतिप्रवाह नहीं है, लेकिन किसी भी चीज को आमतौर पर "शोषण" के रूप में संदर्भित किया जाता है जो किसी न किसी तरह के स्मृति भ्रष्टाचार पर आधारित होती है: बफर ओवरफ्लो, डबल-फ्री, ढेर ओवरफ्लो, पूर्णांक से संबंधित, प्रारूप स्ट्रिंग , आदि बेशक तर्क कीड़े के रूप में अन्य चीजें हैं, लेकिन इस के साथ शुरू करने के लिए इस जवाब का विषय नहीं था।
— newgre
5
@newgre यह एक प्रकार का शोषण है, लेकिन आज स्मृति भ्रष्टाचार के मुद्दों की तुलना में वेब एप्लिकेशन की खामियों का लाभ उठाने के लिए अधिक कारनामे लिखे जाते हैं। एक्सप्लॉइट्स SQL ​​इंजेक्शन, लोकल फाइल में शामिल हैं, CSRF और XSS को लिखा जाता है, ये सामान्य समस्याएं हैं। (स्रोत: exploit-db.com )
— किश्ती
1
मैं इसके लिए सहमत हूं, यदि आप खुद कारनामे लिख सकते हैं, तो आप समझ सकते हैं कि अधिकतम हैकर्स के दिमाग में क्या जा सकता है!
— linuxeasy
42

सुरक्षा एक प्रक्रिया है, उत्पाद नहीं।

कई लोग इस स्पष्ट तथ्य को भूल जाते हैं।

— ericteubert
स्रोत
23

मेरा सुझाव है कि CWE / SANS TOP 25 सबसे खतरनाक प्रोग्रामिंग एरर्स की समीक्षा करें । इसे भविष्य में नियमित अपडेट के वादे के साथ 2010 के लिए अपडेट किया गया था। 2009 संशोधन के रूप में भी उपलब्ध है।

से http://cwe.mitre.org/top25/index.html

2010 सीडब्ल्यूई / एसएएनएस शीर्ष 25 सबसे खतरनाक प्रोग्रामिंग त्रुटियां सबसे व्यापक और महत्वपूर्ण प्रोग्रामिंग त्रुटियों की एक सूची है जो गंभीर सॉफ्टवेयर कमजोरियों को जन्म दे सकती है। वे अक्सर खोजने में आसान होते हैं, और शोषण करने में आसान होते हैं। वे खतरनाक हैं क्योंकि वे अक्सर हमलावरों को सॉफ्टवेयर को पूरी तरह से संभालने, डेटा चोरी करने या सॉफ़्टवेयर को बिल्कुल भी काम करने से रोकने की अनुमति देते हैं।

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

— jschmier
स्रोत
1
ध्यान दें कि उस सूची में शीर्ष 4 त्रुटियां (और साथ ही दूसरों का एक गुच्छा) सभी एक ही त्रुटि हैं - ट्रस्टिंग इनपुट।
— क्रिस डोड
13

कंप्यूटर नेटवर्क और सिक्योरिटी में एक अच्छा स्टार्टर कोर्स MIT कोर्स हो सकता है । एक चीज जो मैं सुझाऊंगा वह है निजता को न भूलना। गोपनीयता, कुछ इंद्रियों में, वास्तव में सुरक्षा के लिए मूलभूत है और अक्सर सुरक्षा पर तकनीकी पाठ्यक्रमों में शामिल नहीं होती है। आपको इस पाठ्यक्रम में नैतिकता और कानून पर कुछ सामग्री मिल सकती है क्योंकि यह इंटरनेट से संबंधित है।

— टवानफॉसन
स्रोत
MIT पाठ्यक्रम लिंक काम नहीं करता है
— एंटोनियोसीएस
1
लिंक अभी (के लिए) तय धन्यवाद।
— tvanfosson
8

चौखटे और एपीआई में सुरक्षित चूक का महत्व:

  • प्रारंभिक वेब फ्रेमवर्क के बहुत सारे HTML डिफ़ॉल्ट रूप से टेम्प्लेट से बच नहीं पाए और इसकी वजह से XSS की समस्या थी
  • शुरुआती वेब फ्रेमवर्क के बहुत सारे SQL को आसान बनाने के बजाय SQL इंजेक्शन बग्स के बहुत से पैरामीटर वाले क्वेरीज़ बनाने के लिए आसान बनाते हैं।
  • Erlang (R13B, शायद अन्य) के कुछ संस्करण डिफ़ॉल्ट रूप से ssl सहकर्मी प्रमाणपत्र सत्यापित नहीं करते हैं और संभवतः बहुत सारे erlang कोड हैं जो SSL MITM हमलों के लिए अतिसंवेदनशील होते हैं
  • जावा का XSLT ट्रांसफार्मर डिफ़ॉल्ट रूप से मनमाने जावा कोड के निष्पादन की अनुमति देता है। इसके द्वारा कई गंभीर सुरक्षा कीड़े बनाए गए हैं।
  • जावा के XML पार्सिंग डिफ़ॉल्ट रूप से पार्स किए गए दस्तावेज़ को फाइलसिस्टम पर मनमानी फ़ाइलों को पढ़ने की अनुमति देता है। ज्यादा मस्ती :)
— benmmurphy
स्रोत
5

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

— rapadura
स्रोत
1
सभी प्राधिकरणों को प्रमाणीकरण की आवश्यकता नहीं है। "एबीएसी से जेडबीएसी के लिए" एनबीएसी (प्रमाणीकरण आधारित) अभिगम नियंत्रण को उन समाधानों के साथ नियंत्रित करता है जिन्हें प्रमाणीकरण की आवश्यकता नहीं होती है। "IBAC, RBAC, ABAC और यहां तक ​​कि CBAC - दावे आधारित अभिगम नियंत्रण सभी प्रमाणीकरण पर भरोसा करते हैं ... सादगी के लिए यह पेपर उन्हें एकल समाधान के रूप में मानता है और उन संस्करणों को अनदेखा करता है जिन्होंने ZBAC वास्तुकला के पहलुओं को लागू किया है। उन्हें सामूहिक रूप से आत्मीयता के रूप में जाना जाता है। आधारित अभिगम नियंत्रण (NBAC)। "
— माइक सैमुअल
4
  • याद रखें कि आपको (प्रोग्रामर को) सभी हिस्सों को सुरक्षित करना है, लेकिन हमलावर को केवल अपने कवच में एक किंक को खोजने में सफल होना है।
  • सुरक्षा "अज्ञात अज्ञात" का एक उदाहरण है। कभी-कभी आपको पता नहीं होगा कि संभावित सुरक्षा दोष क्या हैं (बाद तक)।
  • बग और सुरक्षा छेद के बीच का अंतर हमलावर की बुद्धिमत्ता पर निर्भर करता है।
— रोरी
स्रोत
4

मैं निम्नलिखित जोड़ूंगा:

  • डिजिटल हस्ताक्षर और डिजिटल प्रमाणपत्र कैसे काम करते हैं
  • सैंडबॉक्सिंग क्या है

समझें कि कैसे अलग हमले वैक्टर काम करते हैं:

  • मूल कोड पर बफर ओवरफ्लो / अंडरफ्लो / आदि
  • सोशल इंजिनियरिंग
  • डीएनएस स्पूफिंग
  • बीच वाला व्यक्ति
  • CSRF / XSS एट अल
  • एसक्यूएल इंजेक्षन
  • क्रिप्टो हमलों (उदा: डेस जैसे कमजोर क्रिप्टो एल्गोरिदम का शोषण)
  • कार्यक्रम / रूपरेखा त्रुटियां (उदा: जीथब की नवीनतम सुरक्षा दोष)

आप आसानी से इस सब के लिए google कर सकते हैं। इससे आपको एक अच्छी नींव मिलेगी। यदि आप वेब ऐप की कमज़ोरियों को देखना चाहते हैं, तो Google gruyere नामक एक प्रोजेक्ट है जो आपको दिखाता है कि एक काम करने वाले वेब ऐप का शोषण कैसे किया जाए।

— मिगुएल पिंग
स्रोत
4

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

  • हमेशा अपने कोड को तोड़ने की कोशिश करें (cheatsheets का उपयोग करें और अधिक informations के लिए Google को देखें)।
  • अपने प्रोग्रामिंग क्षेत्र में सुरक्षा खामियों के लिए अद्यतन रहें।
  • और जैसा कि ऊपर उल्लेख किया गया है कि किसी भी प्रकार के उपयोगकर्ता या स्वचालित इनपुट पर भरोसा नहीं है।
  • ओपनसोर्स अनुप्रयोगों का उपयोग करें (उनके सबसे सुरक्षा दोष ज्ञात और हल किए गए हैं)।

आप निम्न लिंक पर अधिक सुरक्षा संसाधन पा सकते हैं:

आपके एप्लिकेशन विक्रेता सुरक्षा प्रवाह के बारे में अधिक जानकारी के लिए Google।

— rahul_pratap
स्रोत
3
  1. क्यों महत्वपूर्ण है
  2. यह व्यापार के बारे में है।
  3. क्रिप्टोग्राफी सुरक्षा से काफी हद तक विचलित है।
— रिचर्ड
स्रोत
3

सुरक्षा की सामान्य जानकारी के लिए, मैं ब्रूस श्नेयर को पढ़ने की सलाह देता हूं । उन्होंने एक वेबसाइट, अपने क्रिप्टो-ग्राम न्यूज़लेटर , कई किताबें , और बहुत सारे साक्षात्कार किए हैं ।

मैं सोशल इंजीनियरिंग (और केविन मिटनिक ) से भी परिचित हो जाऊंगा ।

वास्तविक दुनिया में सुरक्षा कैसे चलती है, इस पर एक अच्छी (और बहुत ही मनोरंजक) पुस्तक के लिए, मैं क्लिफ स्टोल द्वारा उत्कृष्ट (हालांकि थोड़ा सा दिनांक) 'द कुक्कू एग' की सिफारिश करूंगा ।

— डान एस्पारज़ा
स्रोत
3

इसके अलावा सभी मुख्य हमले वैक्टर / कमजोरियों के वर्गीकरण के लिए OWASP टॉप 10 लिस्ट की जाँच अवश्य करें ।

इन चीजों के बारे में पढ़ने के लिए आकर्षक हैं। एक हमलावर की तरह सोचना सीखना आपको इस बारे में सोचने के लिए प्रशिक्षित करेगा कि आप अपना कोड क्या लिख ​​रहे हैं।

— माइकल कोपिन्स्की
स्रोत
2

नमक और अपने उपयोगकर्ताओं के पासवर्ड हैश। अपने डेटाबेस में उन्हें कभी भी प्लेनटेक्स्ट में सेव न करें।

— abdull
स्रोत
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.