🥇वेबसाइट सुरक्षेची घातक पापे: वर्षाच्या असुरक्षा स्कॅनरच्या आकडेवारीतून आम्ही काय शिकलो

सुमारे एक वर्षापूर्वी, आम्ही DataLine लाँच केली सेवा आयटी ऍप्लिकेशन्समधील भेद्यता शोधणे आणि त्यांचे विश्लेषण करणे. सेवा क्वालिस क्लाउड सोल्यूशनवर आधारित आहे, ज्याच्या ऑपरेशनबद्दल आम्ही आधीच सांगितले आहे. सोल्यूशनसह काम करण्याच्या एका वर्षाच्या कालावधीत, आम्ही वेगवेगळ्या साइट्ससाठी 291 स्कॅन केले आणि वेब ऍप्लिकेशन्समधील सामान्य भेद्यतेची आकडेवारी जमा केली.

खालील लेखात मी तुम्हाला दाखवेन की वेबसाइट सुरक्षेमध्ये नेमके कोणते छिद्र गंभीरतेच्या विविध स्तरांमागे लपलेले आहेत. स्कॅनरला विशेषत: अनेकदा कोणत्या असुरक्षा आढळतात, त्या का उद्भवू शकतात आणि स्वतःचे संरक्षण कसे करावे ते पाहू या.

Qualys सर्व वेब ऍप्लिकेशन असुरक्षा तीन स्तरांमध्ये विभागते: निम्न, मध्यम आणि उच्च. जर आपण "तीव्रता" द्वारे वितरणाकडे पाहिले तर असे दिसते की सर्व काही इतके वाईट नाही. उच्च पातळीच्या गंभीरतेसह काही असुरक्षा आहेत, बहुतेक सर्व गैर-गंभीर आहेत:

पण अक्रिटिकल म्हणजे निरुपद्रवी असा नाही. ते गंभीर नुकसान देखील करू शकतात.

शीर्ष "नॉन-क्रिटिकल" भेद्यता

मिश्रित सामग्री भेद्यता.
वेबसाइट सुरक्षेसाठी मानक म्हणजे HTTPS प्रोटोकॉलद्वारे क्लायंट आणि सर्व्हरमधील डेटाचे हस्तांतरण, जे एन्क्रिप्शनला समर्थन देते आणि माहितीचे व्यत्यय येण्यापासून संरक्षण करते.

काही साइट वापरतात मिश्र सामग्री: काही डेटा असुरक्षित HTTP प्रोटोकॉलद्वारे हस्तांतरित केला जातो. हे बहुतेक वेळा असेच व्यक्त केले जाते निष्क्रिय सामग्री - केवळ साइटच्या प्रदर्शनावर परिणाम करणारी माहिती: चित्रे, css शैली. परंतु कधीकधी हे असेच प्रसारित केले जाते सक्रिय सामग्री: साइटचे वर्तन नियंत्रित करणाऱ्या स्क्रिप्ट. या प्रकरणात, विशेष सॉफ्टवेअर वापरून, आपण सर्व्हरवरून येणार्‍या सक्रिय सामग्रीसह माहितीचे विश्लेषण करू शकता, फ्लायवर आपले प्रतिसाद सुधारू शकता आणि मशीनला त्याच्या निर्मात्यांनी अभिप्रेत नसलेल्या पद्धतीने कार्य करू शकता.

ब्राउझरच्या नवीन आवृत्त्या वापरकर्त्यांना चेतावणी देतात की मिश्र सामग्री असलेल्या साइट असुरक्षित आहेत आणि सामग्री अवरोधित करतात. वेबसाइट विकसकांना कन्सोलमध्ये ब्राउझर चेतावणी देखील प्राप्त होतात. उदाहरणार्थ, ते असे दिसते फायरफॉक्स:

काय धोकादायक आहे: आक्रमणकर्ते वापरकर्त्याची माहिती रोखण्यासाठी, स्क्रिप्ट बदलण्यासाठी आणि त्याच्या वतीने साइटवर विनंत्या पाठवण्यासाठी असुरक्षित प्रोटोकॉल वापरतात. जरी एखाद्या साइट अभ्यागताने डेटा प्रविष्ट केला नसला तरीही हे त्याचे संरक्षण करत नाही फिशिंग - फसव्या पद्धतींचा वापर करून गोपनीय माहिती मिळवणे. उदाहरणार्थ, स्क्रिप्ट वापरून, तुम्ही वापरकर्त्याला असुरक्षित साइटवर रीडायरेक्ट करू शकता जी वापरकर्त्याला परिचित आहे. काही प्रकरणांमध्ये, दुर्भावनायुक्त साइट मूळपेक्षा अधिक चांगली दिसते आणि वापरकर्ता स्वतः फॉर्म भरू शकतो आणि गोपनीय डेटा सबमिट करू शकतो.

वेब डेव्हलपरने काय लक्षात ठेवले पाहिजे: जरी साइट प्रशासकाने SSL/TLS प्रमाणपत्र स्थापित आणि कॉन्फिगर केले असले तरीही, मानवी त्रुटीमुळे असुरक्षा उद्भवू शकते. उदाहरणार्थ, जर एखाद्या पानावर तुम्ही सापेक्ष दुवा ठेवला नाही तर http वरून एक परिपूर्ण दुवा ठेवला असेल आणि त्याव्यतिरिक्त तुम्ही http वरून https वर पुनर्निर्देशन सेट केले नसेल.

आपण ब्राउझर वापरून साइटवर मिश्रित सामग्री शोधू शकता: पृष्ठाचा स्त्रोत कोड शोधा, विकसक कन्सोलमध्ये सूचना वाचा. तथापि, विकसकाला कोडमध्ये बराच वेळ आणि दमछाक करावी लागेल. तुम्ही स्वयंचलित विश्लेषण साधनांसह प्रक्रियेची गती वाढवू शकता, उदाहरणार्थ: SSL तपासा, मोफत Lighthouse सॉफ्टवेअर किंवा सशुल्क सॉफ्टवेअर Screaming Frog SEO Spider.

तसेच, लेगसी-कोड - वारशाने मिळालेल्या कोडमधील समस्यांमुळे भेद्यता उद्भवू शकते. उदाहरणार्थ, जर काही पृष्ठे जुन्या टेम्पलेटचा वापर करून व्युत्पन्न केली गेली असतील, जी साइट्सचे https मध्ये संक्रमण विचारात घेत नाही.
"HTTPOnly" आणि "सुरक्षित" ध्वजांशिवाय कुकीज.
"HTTPOnly" विशेषता कुकीज वापरकर्त्यांचा डेटा चोरण्यासाठी वापरणाऱ्या स्क्रिप्टद्वारे प्रक्रिया करण्यापासून संरक्षित करते. "सुरक्षित" ध्वज कुकीज स्पष्ट मजकुरात पाठविण्याची परवानगी देत नाही. जर सुरक्षित HTTPS प्रोटोकॉल कुकीज पाठवण्यासाठी वापरला असेल तरच संप्रेषणास अनुमती दिली जाईल.

दोन्ही विशेषता कुकी गुणधर्मांमध्ये निर्दिष्ट केल्या आहेत:
```
Set-Cookie: Secure; HttpOnly
```
काय धोकादायक आहे: साइट डेव्हलपरने या विशेषता निर्दिष्ट केल्या नसल्यास, आक्रमणकर्ता कुकीमधून वापरकर्त्याची माहिती रोखू शकतो आणि त्याचे शोषण करू शकतो. प्रमाणीकरण आणि अधिकृततेसाठी कुकीज वापरल्या गेल्यास, तो वापरकर्त्याचे सत्र हायजॅक करू शकेल आणि त्याच्या वतीने साइटवर क्रिया करू शकेल.

वेब डेव्हलपरने काय लक्षात ठेवले पाहिजे: नियमानुसार, लोकप्रिय फ्रेमवर्कमध्ये या विशेषता स्वयंचलितपणे सेट केल्या जातात. पण तरीही वेब सर्व्हर कॉन्फिगरेशन तपासा आणि ध्वज सेट करा: Set-Cookie HttpOnly; सुरक्षित.

या प्रकरणात, "HTTPOnly" विशेषता कुकीज तुमच्या स्वतःच्या JavaScript वर अदृश्य करेल.
पथ-आधारित भेद्यता.
स्कॅनरला सार्वजनिकरित्या प्रवेश करण्यायोग्य फाइल किंवा संभाव्य गोपनीय माहिती असलेली वेबसाइट निर्देशिका आढळल्यास अशा असुरक्षिततेचा अहवाल देतो. उदाहरणार्थ, ते वैयक्तिक सिस्टम कॉन्फिगरेशन फाइल्स किंवा संपूर्ण फाइल सिस्टममध्ये प्रवेश शोधते. साइटवर प्रवेश अधिकार चुकीच्या पद्धतीने सेट केले असल्यास ही परिस्थिती शक्य आहे.

काय धोकादायक आहे: जर फाईल सिस्टीम "चिकटून गेली," तर आक्रमणकर्ता ऑपरेटिंग सिस्टम इंटरफेसमध्ये येऊ शकतो आणि फोल्डर स्पष्ट मजकूरात संग्रहित असल्यास पासवर्डसह शोधण्याचा प्रयत्न करू शकतो (तसे करू नका!). किंवा तुम्ही पासवर्ड हॅश चोरू शकता आणि पासवर्डची सक्ती करू शकता आणि सिस्टममध्ये विशेषाधिकार वाढवण्याचा आणि पायाभूत सुविधांमध्ये खोलवर जाण्याचा प्रयत्न देखील करू शकता.

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

वेबसाइट्सवरील फॉर्ममध्ये पासवर्ड किंवा क्रेडिट कार्ड नंबर यासारख्या संवेदनशील माहितीसह फील्ड समाविष्ट असू शकतात. अशा फील्डसाठी, साइटवरच फॉर्म ऑटोफिल फंक्शन अक्षम करणे फायदेशीर आहे.

काय धोकादायक आहे: वापरकर्त्याच्या ब्राउझरने संवेदनशील माहिती संचयित केल्यास, आक्रमणकर्ता नंतर ती रोखू शकतो, उदाहरणार्थ फिशिंगद्वारे. थोडक्यात, एक वेब डेव्हलपर जो या सूक्ष्मतेबद्दल विसरला आहे तो त्याच्या वापरकर्त्यांना सेट करत आहे.

वेब डेव्हलपरने काय लक्षात ठेवले पाहिजे: या प्रकरणात, आमचा क्लासिक संघर्ष आहे: सुविधा वि सुरक्षा. जर वेब डेव्हलपर वापरकर्त्याच्या अनुभवाचा विचार करत असेल, तर तो जाणीवपूर्वक स्वयंपूर्ण निवडू शकतो. उदाहरणार्थ, जर ते अनुसरण करणे महत्वाचे आहे वेब सामग्री प्रवेशयोग्यता मार्गदर्शक तत्त्वे - अपंग वापरकर्त्यांसाठी सामग्रीच्या प्रवेशयोग्यतेसाठी शिफारसी.

बहुतेक ब्राउझरसाठी, तुम्ही autocompete="off" विशेषता सह स्वयंपूर्ण अक्षम करू शकता, उदाहरणार्थ:
```
 <body>
    <form action="/mr/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 साठी कार्य करणार नाही. हे JavaScript वापरून टाळले आहे, रेसिपीचा एक प्रकार आढळू शकतो येथे.
X-Frame-Options हेडर साइट कोडमध्ये सेट केलेले नाही.
हे शीर्षलेख फ्रेम, iframe, एम्बेड किंवा ऑब्जेक्ट टॅग प्रभावित करते. त्याच्या मदतीने, आपण फ्रेममध्ये आपली साइट एम्बेड करण्यास पूर्णपणे प्रतिबंधित करू शकता. हे करण्यासाठी, तुम्हाला X-Frame-Options: deny हे मूल्य निर्दिष्ट करावे लागेल. किंवा तुम्ही X-Frame-Options निर्दिष्ट करू शकता: sameorigin, नंतर iframe मध्ये एम्बेड करणे फक्त तुमच्या डोमेनवर उपलब्ध असेल.

काय धोकादायक आहे: अशा शीर्षलेखाची अनुपस्थिती दुर्भावनापूर्ण साइटवर वापरली जाऊ शकते क्लिकजॅकिंग. या हल्ल्यासाठी, हल्लेखोर बटणांच्या वर एक पारदर्शक फ्रेम तयार करतो आणि वापरकर्त्याला फसवतो. उदाहरणार्थ: स्कॅमर वेबसाइटवर सोशल नेटवर्किंग पृष्ठे फ्रेम करतात. वापरकर्त्याला वाटते की तो या साइटवर एक बटण क्लिक करत आहे. त्याऐवजी, क्लिक रोखले जाते आणि वापरकर्त्याची विनंती सोशल नेटवर्कवर पाठविली जाते जेथे सक्रिय सत्र असते. अशा प्रकारे आक्रमणकर्ते वापरकर्त्याच्या वतीने स्पॅम पाठवतात किंवा सदस्य आणि पसंती मिळवतात.

आपण हे वैशिष्ट्य अक्षम न केल्यास, आक्रमणकर्ता दुर्भावनापूर्ण साइटवर आपले अनुप्रयोग बटण ठेवू शकतो. त्याला तुमच्या रेफरल प्रोग्राममध्ये किंवा तुमच्या वापरकर्त्यांमध्ये स्वारस्य असू शकते.

वेब डेव्हलपरने काय लक्षात ठेवले पाहिजे: वेब सर्व्हर किंवा लोड बॅलन्सरवर परस्परविरोधी मूल्य असलेले X-फ्रेम-पर्याय सेट केले असल्यास असुरक्षा उद्भवू शकते. या प्रकरणात, सर्व्हर आणि बॅलन्सर फक्त हेडर पुन्हा लिहितात, कारण त्यांना बॅकएंड कोडच्या तुलनेत जास्त प्राधान्य असते.

X-Frame-Options हेडरची नकार आणि समान मूळ मूल्ये Yandex वेब दर्शकाच्या ऑपरेशनमध्ये व्यत्यय आणतील. वेब व्ह्यूअरसाठी iframes वापरण्याची परवानगी देण्यासाठी, तुम्हाला सेटिंग्जमध्ये वेगळा नियम लिहावा लागेल. उदाहरणार्थ, 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="/mr/somefolder/styles.css/" सारख्या सापेक्ष लिंक्स वापरल्या गेल्यास हे घडते. वापरकर्त्याला दुर्भावनापूर्ण पृष्ठावर पुनर्निर्देशित करण्याचा मार्ग सापडल्यास आक्रमणकर्त्याला याचा फायदा होईल. पृष्‍ठ त्‍याच्‍या urlमध्‍ये सापेक्ष दुवा टाकेल आणि स्‍टाइल कॉलचे अनुकरण करेल. तुम्हाला badsite.ru/…/somefolder/styles.css/ सारखी विनंती मिळेल, जी शैलीच्या नावाखाली दुर्भावनापूर्ण कृती करू शकते.

काय धोकादायक आहे: फसवणूक करणारा या असुरक्षिततेचा फायदा घेऊ शकतो जर त्यांना दुसरा सुरक्षा छिद्र सापडला. परिणामी, कुकीज किंवा टोकनमधून वापरकर्ता डेटा चोरणे शक्य आहे.

वेब डेव्हलपरने काय लक्षात ठेवले पाहिजे: X-Content-Type-Options शीर्षलेख यावर सेट करा: nosniff. या प्रकरणात, ब्राउझर शैलींसाठी सामग्री प्रकार तपासेल. प्रकार मजकूर/सीएसएस व्यतिरिक्त असल्यास, ब्राउझर विनंती अवरोधित करेल.

गंभीर असुरक्षा

पासवर्ड फील्ड असलेले पृष्ठ सर्व्हरवरून एका असुरक्षित चॅनेलवर प्रसारित केले जाते (एचटीटीपी वर पासवर्ड फील्ड असलेले HTML फॉर्म दिले जाते).
एनक्रिप्ट न केलेल्या चॅनेलवर सर्व्हरकडून मिळणारा प्रतिसाद “मॅन इन द मिडल” हल्ल्यांसाठी असुरक्षित असतो. आक्रमणकर्ता ट्रॅफिकमध्ये अडथळा आणू शकतो आणि क्लायंट आणि सर्व्हरमधील पृष्ठ सर्व्हरवरून क्लायंटकडे जाताना स्वतःला वेजवू शकतो.

काय धोकादायक आहे: फसवणूक करणारा पृष्ठ बदलण्यात सक्षम असेल आणि वापरकर्त्याला गोपनीय डेटासाठी एक फॉर्म पाठवेल, जो आक्रमणकर्त्याच्या सर्व्हरवर जाईल.

वेब डेव्हलपरने काय लक्षात ठेवले पाहिजे: काही साइट वापरकर्त्यांना पासवर्डऐवजी ईमेल/फोनद्वारे एक-वेळ कोड पाठवतात. या प्रकरणात, भेद्यता इतकी गंभीर नाही, परंतु यंत्रणा वापरकर्त्यांचे जीवन गुंतागुंत करेल.
असुरक्षित चॅनेलवर लॉगिन आणि पासवर्डसह फॉर्म पाठवत आहे (लॉगिन फॉर्म HTTPS द्वारे सबमिट केला जात नाही).
या प्रकरणात, लॉगिन आणि पासवर्डसह एक फॉर्म वापरकर्त्याकडून एनक्रिप्टेड चॅनेलद्वारे सर्व्हरवर पाठविला जातो.

काय धोकादायक आहे: मागील केसच्या विपरीत, ही आधीच एक गंभीर असुरक्षा आहे. संवेदनशील डेटा इंटरसेप्ट करणे सोपे आहे कारण ते करण्यासाठी तुम्हाला कोड लिहिण्याचीही आवश्यकता नाही.
ज्ञात भेद्यतेसह JavaScript लायब्ररी वापरणे.
स्कॅन दरम्यान, सर्वात जास्त वापरलेली लायब्ररी jQuery होती ज्यामध्ये मोठ्या संख्येने आवृत्त्या होत्या. प्रत्येक आवृत्तीमध्ये किमान एक किंवा त्याहून अधिक ज्ञात भेद्यता असतात. असुरक्षिततेच्या स्वरूपावर अवलंबून प्रभाव खूप भिन्न असू शकतो.

काय धोकादायक आहे: ज्ञात भेद्यतेसाठी शोषण आहेत, उदाहरणार्थ:

वेब डेव्हलपरने काय लक्षात ठेवले पाहिजे: नियमितपणे सायकलवर परत या: ज्ञात भेद्यता शोधा - निराकरण करा - तपासा. जर तुम्ही जाणूनबुजून लीगेसी लायब्ररी वापरत असाल, उदाहरणार्थ जुन्या ब्राउझरला सपोर्ट करण्यासाठी किंवा पैसे वाचवण्यासाठी, ज्ञात भेद्यतेचे निराकरण करण्याची संधी शोधा.
क्रॉस-साइट स्क्रिप्टिंग (XSS).
क्रॉस-साइट स्क्रिप्टिंग (XSS), किंवा क्रॉस-साइट स्क्रिप्टिंग, वेब ऍप्लिकेशनवर हल्ला आहे ज्यामुळे डेटाबेसमध्ये मालवेअरचा परिचय होतो. Qualys ला अशी असुरक्षितता आढळल्यास, याचा अर्थ असा होतो की संभाव्य आक्रमणकर्त्याने दुर्भावनापूर्ण कृती करण्यासाठी साइट कोडमध्ये स्वतःची js स्क्रिप्ट आधीच आणली आहे.

संग्रहित XSS अधिक धोकादायक, कारण स्क्रिप्ट सर्व्हरवर एम्बेड केलेली असते आणि प्रत्येक वेळी आक्रमण केलेले पृष्ठ ब्राउझरमध्ये उघडले जाते तेव्हा ते कार्यान्वित केले जाते.

परावर्तित XSS दुर्भावनायुक्त स्क्रिप्ट HTTP विनंतीमध्ये इंजेक्ट केली जाऊ शकते म्हणून अमलात आणणे सोपे आहे. अनुप्रयोगास HTTP विनंती प्राप्त होईल, डेटा प्रमाणित करणार नाही, तो पॅकेज करेल आणि तो त्वरित पाठवेल. जर आक्रमणकर्त्याने रहदारीला अडथळा आणला आणि स्क्रिप्ट सारखी समाविष्ट केली
```
<script>/*+что+то+плохое+*/</script> 
```
नंतर क्लायंटच्या वतीने दुर्भावनापूर्ण विनंती पाठविली जाईल.

XSS चे एक उल्लेखनीय उदाहरण: js sniffers जे CVC, कार्ड एक्सपायरी डेट इत्यादी एंटर करण्यासाठी पृष्ठांचे अनुकरण करते.

वेब डेव्हलपरने काय लक्षात ठेवले पाहिजे: सामग्री-सुरक्षा-पॉलिसी शीर्षलेखामध्ये, क्लायंट ब्राउझरला केवळ विश्वसनीय स्त्रोताकडून कोड डाउनलोड आणि कार्यान्वित करण्यासाठी सक्ती करण्यासाठी स्क्रिप्ट-एसआरसी विशेषता वापरा. उदाहरणार्थ, स्क्रिप्ट-src 'सेल्फ' फक्त आमच्या साइटवरील सर्व स्क्रिप्ट्सना व्हाइटलिस्ट करते.
सर्वोत्तम सराव म्हणजे इनलाइन कोड: असुरक्षित-इनलाइन मूल्य वापरून फक्त इनलाइन जावास्क्रिप्टला अनुमती द्या. हे मूल्य इनलाइन js/css वापरण्यास अनुमती देते, परंतु js फायलींचा समावेश करण्यास मनाई करत नाही. स्क्रिप्ट-src 'सेल्फ' च्या संयोजनात आम्ही बाह्य स्क्रिप्ट्स कार्यान्वित होण्यापासून अक्षम करतो.

रिपोर्ट-उरी वापरून सर्व काही लॉग केल्याचे सुनिश्चित करा आणि साइटवर ते लागू करण्याचे प्रयत्न पहा.
एसक्यूएल इंजेक्शन्स.
भेद्यता वेबसाइटच्या डेटाबेसमध्ये थेट प्रवेश करणार्‍या वेबसाइटमध्ये SQL कोड इंजेक्ट करण्याची शक्यता दर्शवते. वापरकर्त्याकडील डेटा तपासला नसल्यास SQL इंजेक्शन शक्य आहे: ते अचूकतेसाठी तपासले जात नाही आणि क्वेरीमध्ये त्वरित वापरले जाते. उदाहरणार्थ, वेबसाइटवरील फॉर्म इनपुट डेटा प्रकाराशी जुळतो की नाही हे तपासत नसल्यास असे होते.

काय धोकादायक आहे: आक्रमणकर्त्याने या फॉर्ममध्ये SQL क्वेरी प्रविष्ट केल्यास, तो डेटाबेस क्रॅश करू शकतो किंवा गोपनीय माहिती उघड करू शकतो.

वेब डेव्हलपरने काय लक्षात ठेवले पाहिजे: ब्राउझरमधून जे येते त्यावर विश्वास ठेवू नका. तुम्हाला क्लायंट साइड आणि सर्व्हर दोन्ही बाजूंनी स्वतःचे संरक्षण करणे आवश्यक आहे.

क्लायंटच्या बाजूने, JavaScript वापरून फील्ड प्रमाणीकरण लिहा.

लोकप्रिय फ्रेमवर्कमधील अंगभूत फंक्शन्स सर्व्हरवरील संशयास्पद वर्णांपासून दूर जाण्यास मदत करतात. सर्व्हरवर पॅरामीटराइज्ड डेटाबेस क्वेरी वापरण्याची देखील शिफारस केली जाते.

वेब ऍप्लिकेशनवर डेटाबेसशी संवाद नेमका कुठे होतो ते ठरवा.

जेव्हा आम्हाला कोणतीही माहिती मिळते तेव्हा परस्परसंवाद होतो: आयडीसह विनंती (आयडी बदलणे), नवीन वापरकर्ता तयार करणे, नवीन टिप्पणी किंवा डेटाबेसमधील नवीन नोंदी. या ठिकाणी SQL इंजेक्शन होऊ शकतात. आम्ही डेटाबेसमधून रेकॉर्ड हटवले तरीही, SQL इंजेक्शन शक्य आहे.

सामान्य शिफारसी

चाक पुन्हा शोधू नका - सिद्ध फ्रेमवर्क वापरा. एक नियम म्हणून, लोकप्रिय फ्रेमवर्क अधिक सुरक्षित आहेत. .NET - ASP.NET MVC आणि ASP.NET Core साठी, Python - Django किंवा Flask साठी, Ruby - Ruby on Rails साठी, PHP साठी - Symfony, Laravel, Yii, JavaScript साठी - Node.JS-Express.js, Java साठी - स्प्रिंग MVC.

विक्रेता अद्यतनांचे अनुसरण करा आणि नियमितपणे अद्यतनित करा. त्यांना एक असुरक्षितता सापडेल, नंतर एक शोषण लिहा, ते सार्वजनिकपणे उपलब्ध करा आणि सर्वकाही पुन्हा होईल. सॉफ्टवेअर विक्रेत्याकडून स्थिर आवृत्त्यांसाठी अद्यतनांची सदस्यता घ्या.

प्रवेश अधिकार तपासा. सर्व्हरच्या बाजूने, तुमच्या कोडला नेहमी असे वागवा की, तो पहिल्यापासून शेवटच्या अक्षरापर्यंत, तुमच्या अत्यंत द्वेषी शत्रूने लिहिलेला आहे, जो तुमची साइट खंडित करू इच्छितो, तुमच्या डेटाच्या अखंडतेचे उल्लंघन करतो. शिवाय, कधीकधी हे खरे असते.

क्लोन, चाचणी साइट वापरा आणि नंतर उत्पादनासाठी वापरा. हे प्रथमतः, उत्पादक वातावरणातील चुका आणि चुका टाळण्यास मदत करेल: उत्पादक वातावरण पैसे आणते, एक साधे उत्पादक वातावरण गंभीर आहे. कोणतीही समस्या जोडताना, निराकरण करताना किंवा बंद करताना, चाचणी वातावरणात कार्य करणे फायदेशीर आहे, नंतर कार्यशीलता आणि भेद्यता तपासणे आणि नंतर उत्पादन वातावरणासह कार्य करण्याचे नियोजन करणे.

आपल्या वेब अनुप्रयोगास यासह संरक्षित करा वेब अनुप्रयोग फायरवॉल आणि असुरक्षा स्कॅनरचे अहवाल त्याच्यासोबत एकत्रित करा. उदाहरणार्थ, DataLine सेवांचा बंडल म्हणून Qualys आणि FortiWeb वापरते.

स्त्रोत: www.habr.com

वेबसाइट सुरक्षेची घातक पापे: वर्षभरातील भेद्यता स्कॅनर आकडेवारीवरून आम्ही काय शिकलो

शीर्ष "नॉन-क्रिटिकल" भेद्यता

गंभीर असुरक्षा

सामान्य शिफारसी

एक टिप्पणी जोडा Отменить ответ