वेब सुरक्षा सारांश

क्षमा करें, लेकिन उबलते हुए।

कई शंकु साइट सुरक्षा के विषय पर पहले से ही भरे हुए हैं। युवा विशेषज्ञ जो विश्वविद्यालयों से स्नातक हैं, भले ही उन्हें पता है कि कैसे प्रोग्राम करना है, लेकिन साइट सुरक्षा के मुद्दे पर वे एक ही रेक पर कदम रखते हैं।



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





तो एक सुरक्षित साइट क्या होनी चाहिए?

1. सर्वर के बारे में

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

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

2. बाहर, केवल वास्तव में आवश्यक बंदरगाहों को देखा जाना चाहिए, बाकी एक फ़ायरवॉल के साथ बंद है।
3. हम हमेशा नवीनतम सॉफ़्टवेयर संस्करणों का उपयोग करते हैं, जो समय पर अपडेट होते हैं।
   
   

   ओपनएसएसएल के साथ हालिया इतिहास इसकी पुष्टि करता है

   
   
   
4. लॉग को कॉन्फ़िगर करना और किसी भी संदिग्ध गतिविधि की निगरानी करना सुनिश्चित करें।
5. प्रोजेक्ट के रूट में कोई भी लेफ्ट फोल्डर और फाइल्स a .svn, .itea, .idea, dip.tar.gz नहीं होनी चाहिए।
   
   

   ऐसे मामले थे जब डेटाबेस और फ़ाइल के साथ अभिलेखागार क्लाइंट साइटों पर खुले रूप से उपलब्ध थे। बैकअप के साथ भी यही बात है।

6. हम फ़ाइलों के लिए न्यूनतम अनुमतियाँ सेट करते हैं, 777 नहीं।
7. यदि संभव हो तो डायनेमिक्स को रूट से बाहर ले जाया जाता है।
8. स्टेटिक्स (जेएस, सीएसएस, छवि) अलग से झूठ बोलना चाहिए, आदर्श रूप से किसी अन्य सर्वर पर,।
9. यदि हम महत्वपूर्ण डेटा के साथ काम करते हैं, तो हम संक्षिप्त समाप्ति के साथ https / ssl का उपयोग करते हैं।
10. त्रुटि संदेश स्क्रीन पर प्रदर्शित नहीं होते हैं prom केवल उपयोगकर्ता को संकेत देता है।
11. बैकअप होना चाहिए और किसी अन्य सर्वर पर संग्रहीत किया जाना चाहिए।

2. इनपुट के बारे में

1. नियंत्रकों में:
   
   
   • हमेशा इनपुट मापदंडों को फ़िल्टर करें
   • हम न्यूनतम अनुमत मूल्य का उपयोग करते हैं। उदाहरण के लिए, यदि हमें एक संख्या मिलती है, तो हम एक संख्या को कम कर देते हैं। आप क्लाइंट पर मान्य कर सकते हैं, और यह सर्वर पर अनिवार्य है।
   • सीमा मूल्यों के लिए चर की जांच करना न भूलें।
   • यदि डेटा सूची से है, तो वैध मूल्यों के सेट से मेल खाना सुनिश्चित करें।
   • यदि संभव हो तो, फ़ाइलों के लिए माइम प्रकार की जांच करें, एक्सटेंशन पर भरोसा न करें, यह बदलना आसान है।
   • हम असीम रूप से किसी भी डेटा को जोड़ने की अनुमति नहीं देते हैं (उदाहरण के लिए, टिप्पणियां)।
   • हम लंबी लाइनों और भारी फ़ाइलों को लोड करने की अनुमति नहीं देते हैं।
   
   
   
2. मॉडल में:
   
   
   • SQL क्वेरी के लिए, तैयार किए गए कथनों का उपयोग करें।
   • हम डेटाबेस प्रश्नों का अनुकूलन करते हैं - लूप में कोई चयन नहीं करते हैं।
   • इंडेक्स के बारे में मत भूलना।
   • परिष्कृत खोज? खोज इंजन (ElasticSearch, Sphinx, आदि) का उपयोग करें।
   
   
   
3. देखने में:
   
   
   • हम आवश्यक संस्थाओं में डेटा लाते हैं। Xss के लिए जांचें, क्लाइंट से कोई html टैग या js स्क्रिप्ट नहीं।
   • प्रपत्र या राज्य परिवर्तन सबमिट करने में, हम प्रत्येक उपयोगकर्ता के लिए अद्वितीय टोकन (सीएसआरएफ) का उपयोग करते हैं। टोकन नहीं चाहते हैं, तो HTTP_REFERER जांचें।
   • यदि आप AJAX का उपयोग करते हैं, तो इनपुट और आउटपुट दोनों पर डेटा की जांच करना न भूलें। 99% मामलों में, JS में eval बुराई है।
   
   
   

3. ग्राहक के बारे में

जैसा कि डॉ। हाउस ने कहा, रोगी हमेशा झूठ बोलता है।

अधिकांश ग्राहक अपनी सुरक्षा के बारे में ध्यान नहीं देते।

1. क्लाइंट पर मान्यता - केवल इसकी सुविधा के लिए, सर्वर पर पुन: जाँच करना सुनिश्चित करें।
2. POST GET की तरह ही आसान है।
3. यदि कैप्चा के बिना सार्वजनिक डोमेन में कोई प्रपत्र है, तो स्पैमर्स निश्चित रूप से इसमें लिखना शुरू कर देंगे।
4. प्राधिकरण को जटिल करें, कई असफल लॉगिन प्रयास - उन्हें कैप्चा दर्ज करने दें।
5. चीजों को जटिल करना चाहते हैं? हम दो-कारक प्रमाणीकरण को फास्ट करते हैं।
6. पुष्टिकरण के लिए, हम एक विशिष्ट उपयोगकर्ता से बंधे हुए एक बार लंबे टोकन का उपयोग करते हैं।
7. हम क्लाइंट को जटिल पासवर्ड बनाने के लिए मजबूर करते हैं।

4. एन्क्रिप्शन के बारे में

1. हम स्पष्ट में कुछ भी संग्रहीत नहीं करते हैं।
2. पासवर्ड - नमक के साथ हैश के रूप में, क्रिप्टोग्राफिक ताकत और संघर्ष की जांच करना उचित है।
3. ValdikSS से MD5 या SHA1 का उपयोग न करें। यह पासवर्ड के लिए सबसे अच्छा है कि पीबीकेडीएफ 2 या स्क्रीप्ट जैसे विशेष हैश फ़ंक्शन का उपयोग करें।
4. ग्राहक का कोई डेटा, यहां तक ​​कि एन्क्रिप्टेड रूप में, केवल कुकीज़ में आईडी सत्र।

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