🥇वेबसाइट सुरक्षा के घातक पाप: हमने वर्ष के लिए भेद्यता स्कैनर आँकड़ों से क्या सीखा

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

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

क्वालिस सभी वेब एप्लिकेशन कमजोरियों को गंभीरता के तीन स्तरों में विभाजित करता है: निम्न, मध्यम और उच्च। यदि आप वितरण को "गंभीरता" से देखें तो ऐसा लगता है कि सब कुछ इतना बुरा नहीं है। उच्च स्तर की आलोचनात्मकता वाली कुछ कमजोरियाँ हैं, अधिकतर सभी गैर-महत्वपूर्ण हैं:

लेकिन आलोचनात्मक का मतलब हानिरहित नहीं है। इनसे गंभीर क्षति भी हो सकती है.

शीर्ष "गैर-महत्वपूर्ण" कमजोरियाँ

मिश्रित सामग्री कमजोरियाँ.
वेबसाइट सुरक्षा के लिए मानक HTTPS प्रोटोकॉल के माध्यम से क्लाइंट और सर्वर के बीच डेटा का स्थानांतरण है, जो एन्क्रिप्शन का समर्थन करता है और जानकारी को अवरोधन से बचाता है।

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

ब्राउज़र के नए संस्करण उपयोगकर्ताओं को चेतावनी देते हैं कि मिश्रित सामग्री वाली साइटें असुरक्षित हैं और सामग्री को अवरुद्ध कर देती हैं। वेबसाइट डेवलपर्स को कंसोल में ब्राउज़र चेतावनियाँ भी प्राप्त होती हैं। उदाहरण के लिए, यह इस तरह दिखता है Firefox:

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

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

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

साथ ही, लीगेसी-कोड - वह कोड जो विरासत में मिला था, के साथ समस्याओं के कारण भेद्यता उत्पन्न हो सकती है। उदाहरण के लिए, यदि कुछ पेज पुराने टेम्पलेट का उपयोग करके तैयार किए जाते हैं, जो साइटों के https में संक्रमण को ध्यान में नहीं रखता है।
"केवल HTTP" और "सुरक्षित" फ़्लैग के बिना कुकीज़।
"HTTPOnly" विशेषता कुकीज़ को उन स्क्रिप्ट द्वारा संसाधित होने से बचाती है जिनका उपयोग हमलावर उपयोगकर्ता डेटा चुराने के लिए करते हैं। "सुरक्षित" ध्वज कुकीज़ को स्पष्ट पाठ में भेजने की अनुमति नहीं देता है। संचार की अनुमति केवल तभी दी जाएगी जब कुकीज़ भेजने के लिए सुरक्षित HTTPS प्रोटोकॉल का उपयोग किया जाता है।

दोनों विशेषताएँ कुकी गुणों में निर्दिष्ट हैं:
```
Set-Cookie: Secure; HttpOnly
```
क्या खतरनाक है: यदि साइट डेवलपर ने इन विशेषताओं को निर्दिष्ट नहीं किया है, तो एक हमलावर कुकी से उपयोगकर्ता की जानकारी को रोक सकता है और उसका फायदा उठा सकता है। यदि कुकीज़ का उपयोग प्रमाणीकरण और प्राधिकरण के लिए किया जाता है, तो वह उपयोगकर्ता के सत्र को हाईजैक करने और उसकी ओर से साइट पर कार्रवाई करने में सक्षम होगा।

एक वेब डेवलपर को क्या याद रखना चाहिए: एक नियम के रूप में, लोकप्रिय ढांचे में ये विशेषताएँ स्वचालित रूप से सेट हो जाती हैं। लेकिन फिर भी वेब सर्वर कॉन्फ़िगरेशन की जाँच करें और ध्वज सेट करें: Set-Cookie HttpOnly; सुरक्षित।

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

क्या खतरनाक है: यदि फ़ाइल सिस्टम "चिपक जाता है", तो एक हमलावर ऑपरेटिंग सिस्टम इंटरफ़ेस में आ सकता है और पासवर्ड वाले फ़ोल्डरों को ढूंढने का प्रयास कर सकता है यदि वे स्पष्ट पाठ में संग्रहीत हैं (ऐसा न करें!)। या आप पासवर्ड हैश चुरा सकते हैं और पासवर्ड को बलपूर्वक लागू कर सकते हैं, और सिस्टम में विशेषाधिकार बढ़ाने और बुनियादी ढांचे में गहराई से जाने का भी प्रयास कर सकते हैं।

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

वेबसाइटों पर मौजूद फॉर्म में पासवर्ड या क्रेडिट कार्ड नंबर जैसी संवेदनशील जानकारी वाले फ़ील्ड शामिल हो सकते हैं। ऐसे फ़ील्ड के लिए, साइट पर ही फ़ॉर्म ऑटोफ़िल फ़ंक्शन को अक्षम करना उचित है।

क्या खतरनाक है: यदि उपयोगकर्ता का ब्राउज़र संवेदनशील जानकारी संग्रहीत करता है, तो एक हमलावर इसे बाद में रोक सकता है, उदाहरण के लिए फ़िशिंग के माध्यम से। संक्षेप में, एक वेब डेवलपर जो इस बारीकियों के बारे में भूल गया है वह अपने उपयोगकर्ताओं को स्थापित कर रहा है।

एक वेब डेवलपर को क्या याद रखना चाहिए: इस मामले में, हमारे पास एक क्लासिक संघर्ष है: सुविधा बनाम सुरक्षा। यदि कोई वेब डेवलपर उपयोगकर्ता अनुभव के बारे में सोच रहा है, तो वह जानबूझकर स्वत: पूर्ण चुन सकता है। उदाहरण के लिए, यदि इसका पालन करना महत्वपूर्ण है वेब सामग्री अभिगम्यता दिशानिर्देश - विकलांग उपयोगकर्ताओं के लिए सामग्री की पहुंच के लिए सिफारिशें।

अधिकांश ब्राउज़रों के लिए, आप autocompete='off' विशेषता के साथ स्वत: पूर्ण अक्षम कर सकते हैं, उदाहरण के लिए:
```
 <body>
    <form action="/hi/form/submit" method="get" autocomplete="off">
      <div>
        <input type="text" placeholder="First Name">
      </div>
      <div>
        <input type="text" id="lname" placeholder="Last Name" autocomplete="on">
      </div>
      <div>
        <input type="number" placeholder="Credit card number">
      </div>
      <input type="submit">
    </form>
  </body>
```
लेकिन यह Chrome के लिए काम नहीं करेगा. इसे जावास्क्रिप्ट का उपयोग करके टाला जाता है, नुस्खा का एक प्रकार पाया जा सकता है यहां.
एक्स-फ़्रेम-ऑप्शंस हेडर साइट कोड में सेट नहीं है।
यह हेडर फ़्रेम, आईफ़्रेम, एंबेड या ऑब्जेक्ट टैग को प्रभावित करता है। इसकी मदद से आप अपनी साइट को किसी फ्रेम के अंदर एम्बेड करने पर पूरी तरह से रोक लगा सकते हैं। ऐसा करने के लिए, आपको मान X-फ़्रेम-विकल्प निर्दिष्ट करना होगा: अस्वीकार करें। या आप एक्स-फ़्रेम-विकल्प निर्दिष्ट कर सकते हैं: सेमऑरिजिन, फिर आईफ़्रेम में एम्बेड करना केवल आपके डोमेन पर उपलब्ध होगा।

क्या खतरनाक है: ऐसे हेडर की अनुपस्थिति का उपयोग दुर्भावनापूर्ण साइटों पर किया जा सकता है क्लिकजैकिंग. इस हमले के लिए, हमलावर बटनों के ऊपर एक पारदर्शी फ्रेम बनाता है और उपयोगकर्ता को धोखा देता है। उदाहरण के लिए: स्कैमर किसी वेबसाइट पर सोशल नेटवर्किंग पेज बनाते हैं। उपयोगकर्ता को लगता है कि वह इस साइट पर एक बटन क्लिक कर रहा है। इसके बजाय, क्लिक को रोक दिया जाता है और उपयोगकर्ता का अनुरोध सोशल नेटवर्क पर भेज दिया जाता है जहां एक सक्रिय सत्र होता है। इस प्रकार हमलावर उपयोगकर्ता की ओर से स्पैम भेजते हैं या सब्सक्राइबर और लाइक हासिल करते हैं।

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

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

एक्स-फ़्रेम-ऑप्शंस हेडर के इनकार और समान मूल मान यैंडेक्स वेब व्यूअर के संचालन में हस्तक्षेप करेंगे। वेब व्यूअर के लिए आईफ्रेम के उपयोग की अनुमति देने के लिए, आपको सेटिंग्स में एक अलग नियम लिखना होगा। उदाहरण के लिए, nginx के लिए आप इसे इस प्रकार कॉन्फ़िगर कर सकते हैं:
```
http{
...
 map $http_referer $frame_options {
 "~webvisor.com" "ALLOW-FROM http://webvisor.com";
 default "SAMEORIGIN";
 }
 add_header X-Frame-Options $frame_options;
...
}
```
PRSSI (पथ-सापेक्ष स्टाइलशीट आयात) कमजोरियाँ।
यह साइट की शैली में एक भेद्यता है। ऐसा तब होता है जब शैली फ़ाइलों तक पहुँचने के लिए href='/somefolder/styles.css/' जैसे सापेक्ष लिंक का उपयोग किया जाता है। यदि कोई हमलावर उपयोगकर्ता को दुर्भावनापूर्ण पृष्ठ पर पुनर्निर्देशित करने का कोई तरीका खोज लेता है तो वह इसका लाभ उठाएगा। पेज अपने यूआरएल में एक संबंधित लिंक डालेगा और एक स्टाइल कॉल का अनुकरण करेगा। आपको Badsite.ru/…/somefolder/styles.css/ जैसा अनुरोध मिलेगा, जो स्टाइल की आड़ में दुर्भावनापूर्ण कार्य कर सकता है।

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

एक वेब डेवलपर को क्या याद रखना चाहिए: X-सामग्री-प्रकार-विकल्प शीर्षलेख को यहां सेट करें: nosniff. इस स्थिति में, ब्राउज़र शैलियों के लिए सामग्री प्रकार की जाँच करेगा। यदि प्रकार टेक्स्ट/सीएसएस के अलावा अन्य है, तो ब्राउज़र अनुरोध को ब्लॉक कर देगा।

गंभीर कमजोरियाँ

पासवर्ड फ़ील्ड वाला एक पृष्ठ सर्वर से एक असुरक्षित चैनल पर प्रसारित होता है (पासवर्ड फ़ील्ड युक्त HTML फॉर्म HTTP पर परोसा जाता है)।
अनएन्क्रिप्टेड चैनल पर सर्वर से प्रतिक्रिया "मैन इन द मिडल" हमलों के प्रति संवेदनशील है। एक हमलावर ट्रैफ़िक को रोक सकता है और क्लाइंट और सर्वर के बीच में सेंध लगा सकता है क्योंकि पेज सर्वर से क्लाइंट तक जाता है।

क्या खतरनाक है: जालसाज पेज को बदलने और उपयोगकर्ता को गोपनीय डेटा के लिए एक फॉर्म भेजने में सक्षम होगा, जो हमलावर के सर्वर पर जाएगा।

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

क्या खतरनाक है: पिछले मामले के विपरीत, यह पहले से ही एक गंभीर भेद्यता है। संवेदनशील डेटा को इंटरसेप्ट करना आसान है क्योंकि ऐसा करने के लिए आपको कोड लिखने की भी आवश्यकता नहीं है।
ज्ञात कमजोरियों के साथ जावास्क्रिप्ट लाइब्रेरी का उपयोग करना।
स्कैन के दौरान, व्यापक संख्या में संस्करणों के साथ सबसे अधिक उपयोग की जाने वाली लाइब्रेरी jQuery थी। प्रत्येक संस्करण में कम से कम एक, या उससे भी अधिक, ज्ञात कमजोरियाँ हैं। भेद्यता की प्रकृति के आधार पर प्रभाव बहुत भिन्न हो सकता है।

क्या खतरनाक है: ज्ञात कमजोरियों के लिए कारनामे हैं, उदाहरण के लिए:

एक वेब डेवलपर को क्या याद रखना चाहिए: नियमित रूप से चक्र पर लौटें: ज्ञात कमजोरियों की खोज करें - ठीक करें - जांचें। यदि आप जानबूझकर विरासत पुस्तकालयों का उपयोग करते हैं, उदाहरण के लिए पुराने ब्राउज़रों का समर्थन करने या पैसे बचाने के लिए, किसी ज्ञात भेद्यता को ठीक करने का अवसर तलाशें।
क्रॉस-साइट स्क्रिप्टिंग (XSS)।
क्रॉस-साइट स्क्रिप्टिंग (XSS), या क्रॉस-साइट स्क्रिप्टिंग, एक वेब एप्लिकेशन पर एक हमला है जिसके परिणामस्वरूप डेटाबेस में मैलवेयर पेश किया जाता है। यदि क्वालिस को ऐसी कोई भेद्यता मिलती है, तो इसका मतलब है कि एक संभावित हमलावर दुर्भावनापूर्ण कार्य करने के लिए साइट कोड में अपनी स्वयं की जेएस स्क्रिप्ट पहले ही पेश कर चुका है या कर चुका है।

संग्रहित XSS अधिक खतरनाक, क्योंकि स्क्रिप्ट सर्वर पर एम्बेडेड होती है और हर बार ब्राउज़र में हमला किया गया पृष्ठ खोलने पर निष्पादित होती है।

प्रतिबिंबित XSS इसे लागू करना आसान है क्योंकि एक दुर्भावनापूर्ण स्क्रिप्ट को HTTP अनुरोध में इंजेक्ट किया जा सकता है। एप्लिकेशन एक HTTP अनुरोध प्राप्त करेगा, डेटा को मान्य नहीं करेगा, इसे पैकेज करेगा और तुरंत भेज देगा। यदि कोई हमलावर ट्रैफ़िक को रोकता है और एक स्क्रिप्ट सम्मिलित करता है जैसे
```
<script>/*+что+то+плохое+*/</script> 
```
तो क्लाइंट की ओर से एक दुर्भावनापूर्ण अनुरोध भेजा जाएगा।

एक्सएसएस का एक उल्लेखनीय उदाहरण: जेएस स्निफ़र्स जो सीवीसी, कार्ड समाप्ति तिथि आदि दर्ज करने के लिए पृष्ठों का अनुकरण करते हैं।

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

रिपोर्ट-यूरी का उपयोग करके सब कुछ लॉग करना सुनिश्चित करें और इसे साइट पर लागू करने के प्रयासों को देखें।
एसक्यूएल इंजेक्शन.
भेद्यता किसी वेबसाइट में SQL कोड इंजेक्ट करने की संभावना को इंगित करती है जो सीधे वेबसाइट के डेटाबेस तक पहुँचती है। यदि उपयोगकर्ता के डेटा की जांच नहीं की जाती है तो SQL इंजेक्शन संभव है: इसकी शुद्धता की जांच नहीं की जाती है और तुरंत क्वेरी में उपयोग किया जाता है। उदाहरण के लिए, ऐसा तब होता है जब किसी वेबसाइट पर कोई फॉर्म यह जांच नहीं करता है कि इनपुट डेटा प्रकार से मेल खाता है या नहीं।

क्या खतरनाक है: यदि कोई हमलावर इस फॉर्म में SQL क्वेरी दर्ज करता है, तो वह डेटाबेस को क्रैश कर सकता है या गोपनीय जानकारी प्रकट कर सकता है।

एक वेब डेवलपर को क्या याद रखना चाहिए: ब्राउज़र से जो आता है उस पर भरोसा न करें। आपको क्लाइंट साइड और सर्वर साइड दोनों पर खुद को सुरक्षित रखने की जरूरत है।

क्लाइंट पक्ष पर, जावास्क्रिप्ट का उपयोग करके फ़ील्ड सत्यापन लिखें।

लोकप्रिय फ्रेमवर्क में अंतर्निहित फ़ंक्शन सर्वर पर संदिग्ध पात्रों से बचने में भी मदद करते हैं। सर्वर पर पैरामीटरयुक्त डेटाबेस क्वेरीज़ का उपयोग करने की भी अनुशंसा की जाती है।

निर्धारित करें कि वेब एप्लिकेशन पर डेटाबेस के साथ वास्तव में इंटरेक्शन कहां होता है।

इंटरेक्शन तब होता है जब हमें कोई जानकारी प्राप्त होती है: एक आईडी के साथ एक अनुरोध (आईडी का परिवर्तन), एक नए उपयोगकर्ता का निर्माण, एक नई टिप्पणी, या डेटाबेस में नई प्रविष्टियाँ। यहीं पर SQL इंजेक्शन हो सकते हैं। भले ही हम डेटाबेस से कोई रिकॉर्ड हटा दें, SQL इंजेक्शन संभव है।

सामान्य सिफारिशें

पहिए का दोबारा आविष्कार न करें - सिद्ध ढांचे का उपयोग करें. एक नियम के रूप में, लोकप्रिय ढाँचे अधिक सुरक्षित होते हैं। .NET के लिए - ASP.NET MVC और ASP.NET कोर, पायथन के लिए - Django या फ्लास्क, रूबी के लिए - रूबी ऑन रेल्स, PHP के लिए - सिम्फनी, लारवेल, Yii, जावास्क्रिप्ट के लिए - Node.JS-Express.js, जावा के लिए - वसंत MVC।

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

पहुंच अधिकार जांचें. सर्वर साइड पर, अपने कोड को हमेशा ऐसे समझें जैसे कि वह, पहले से आखिरी अक्षर तक, आपके सबसे नफरत करने वाले दुश्मन द्वारा लिखा गया था, जो आपकी साइट को तोड़ना चाहता है, आपके डेटा की अखंडता का उल्लंघन करता है। इसके अलावा, कभी-कभी यह सच भी होता है।

क्लोन, परीक्षण साइटों का उपयोग करें और फिर उत्पादन के लिए उनका उपयोग करें. इससे, सबसे पहले, उत्पादक वातावरण में गलतियों और गलतियों से बचने में मदद मिलेगी: एक उत्पादक वातावरण पैसा लाता है, एक सरल उत्पादक वातावरण महत्वपूर्ण है। किसी भी समस्या को जोड़ते, ठीक करते या बंद करते समय, परीक्षण वातावरण में काम करना, फिर पाई गई कार्यक्षमता और कमजोरियों की जांच करना और फिर उत्पादन वातावरण के साथ काम करने की योजना बनाना उचित है।

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

स्रोत: www.habr.com

वेबसाइट सुरक्षा के घातक पाप: हमने वर्ष के लिए भेद्यता स्कैनर आँकड़ों से क्या सीखा

शीर्ष "गैर-महत्वपूर्ण" कमजोरियाँ

गंभीर कमजोरियाँ

सामान्य सिफारिशें

एक टिप्पणी जोड़ें उत्तर रद्द