🥇 वेबसाइट सुरक्षाको घातक पापहरू: हामीले वर्षको लागि भेद्यता स्क्यानर तथ्याङ्कबाट के सिक्यौं

करिब एक वर्ष पहिले, हामीले DataLine मा सुरु गर्यौं सेवा IT अनुप्रयोगहरूमा कमजोरीहरू खोज्न र विश्लेषण गर्न। सेवा Qualys क्लाउड समाधान मा आधारित छ, जसको सञ्चालन बारे हामीले पहिले नै भनिसकेका छौं। समाधानको साथ काम गरेको एक वर्षको अवधिमा, हामीले विभिन्न साइटहरूको लागि 291 स्क्यानहरू सञ्चालन गर्यौं र वेब अनुप्रयोगहरूमा साझा कमजोरीहरूमा तथ्याङ्कहरू संकलन गर्यौं।

तलको लेखमा म तपाईंलाई वेबसाइट सुरक्षामा के प्वालहरू आलोचनात्मकताको विभिन्न स्तरहरू पछाडि लुकेको छ भनेर देखाउनेछु। स्क्यानरले विशेष गरी प्रायः के कस्ता कमजोरीहरू फेला पार्छ, ती किन हुन सक्छन्, र आफूलाई कसरी सुरक्षित गर्ने भनेर हेरौं।

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

तर आलोचनात्मकको अर्थ हानिरहित हुँदैन। तिनीहरूले पनि गम्भीर क्षति हुन सक्छ।

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

मिश्रित सामग्री कमजोरीहरू।
वेबसाइट सुरक्षाको लागि मानक HTTPS प्रोटोकल मार्फत क्लाइन्ट र सर्भर बीचको डेटा स्थानान्तरण हो, जसले इन्क्रिप्शनलाई समर्थन गर्दछ र जानकारीलाई अवरोधबाट सुरक्षित गर्दछ।

केही साइटहरू प्रयोग गर्छन् मिश्रित सामग्री: केहि डाटा असुरक्षित HTTP प्रोटोकल मार्फत स्थानान्तरण गरिएको छ। प्रायः यसरी व्यक्त गरिन्छ निष्क्रिय सामग्री - जानकारी जसले साइटको प्रदर्शनलाई मात्र असर गर्छ: चित्रहरू, सीएसएस शैलीहरू। तर कहिलेकाहीँ यो कसरी प्रसारित हुन्छ सक्रिय सामग्री: साइटको व्यवहार नियन्त्रण गर्ने लिपिहरू। यस अवस्थामा, विशेष सफ्टवेयर प्रयोग गरेर, तपाइँ सर्भरबाट आउँदै गरेको सक्रिय सामग्रीको साथ जानकारीको विश्लेषण गर्न सक्नुहुन्छ, उडानमा तपाइँको प्रतिक्रियाहरू परिमार्जन गर्न सक्नुहुन्छ र मेसिनलाई यसका सिर्जनाकर्ताहरूले नचाहेको रूपमा काम गर्न सक्नुहुन्छ।

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

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

वेब विकासकर्ताले के सम्झनुपर्छ: साइट प्रशासकले SSL/TLS प्रमाणपत्र स्थापना र कन्फिगर गरेको भए पनि, मानव त्रुटिको कारणले जोखिम उत्पन्न हुन सक्छ। उदाहरणका लागि, यदि तपाईंले कुनै एक पृष्ठमा सापेक्ष लिङ्क राख्नुभयो, तर http बाट पूर्ण लिङ्क राख्नुभयो, र थप रूपमा तपाईंले http बाट https मा रिडिरेक्टहरू सेट अप गर्नुभएन।

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

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

दुबै विशेषताहरू कुकी गुणहरूमा निर्दिष्ट गरिएका छन्:
```
Set-Cookie: Secure; HttpOnly
```
के खतरनाक छ: यदि साइट विकासकर्ताले यी विशेषताहरू निर्दिष्ट गरेन भने, आक्रमणकारीले कुकीबाट प्रयोगकर्ताको जानकारीलाई रोक्न र शोषण गर्न सक्छ। यदि कुकीहरू प्रमाणीकरण र प्राधिकरणको लागि प्रयोग गरिन्छ भने, उसले प्रयोगकर्ताको सत्र हाइज्याक गर्न र साइटमा आफ्नो तर्फबाट कार्यहरू गर्न सक्षम हुनेछ।

वेब विकासकर्ताले के सम्झनुपर्छ: एक नियमको रूपमा, लोकप्रिय फ्रेमवर्कहरूमा यी विशेषताहरू स्वचालित रूपमा सेट हुन्छन्। तर अझै पनि वेब सर्भर कन्फिगरेसन जाँच गर्नुहोस् र झण्डा सेट गर्नुहोस्: सेट-कुकी HttpOnly; सुरक्षित।

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

के खतरनाक छ: यदि फाइल प्रणाली "स्टिक आउट" छ भने, एक आक्रमणकर्ता अपरेटिङ सिस्टम इन्टरफेसमा पर्न सक्छ र यदि तिनीहरू स्पष्ट पाठमा भण्डारण गरिएका छन् भने पासवर्डहरू सहित फोल्डरहरू फेला पार्न प्रयास गर्नुहोस् (त्यसो नगर्नुहोस्!) वा तपाइँ पासवर्ड ह्यासहरू चोरी गर्न सक्नुहुन्छ र पासवर्ड बलियो बनाउन सक्नुहुन्छ, र प्रणालीमा विशेषाधिकारहरू बढाउन र पूर्वाधारमा गहिरो सार्न प्रयास गर्न सक्नुहुन्छ।

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

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

के खतरनाक छ: यदि प्रयोगकर्ताको ब्राउजरले संवेदनशील जानकारी भण्डार गर्दछ भने, आक्रमणकारीले पछि यसलाई रोक्न सक्छ, उदाहरणका लागि फिसिङ मार्फत। संक्षेपमा, एक वेब विकासकर्ता जसले यस सूक्ष्मताको बारेमा बिर्सेको छ उसले आफ्ना प्रयोगकर्ताहरूलाई सेट गर्दैछ।

वेब विकासकर्ताले के सम्झनुपर्छ: यस अवस्थामा, हामीसँग क्लासिक द्वन्द्व छ: सुविधा बनाम सुरक्षा। यदि एक वेब विकासकर्ता प्रयोगकर्ता अनुभव बारे सोच्दै हुनुहुन्छ भने, उसले सचेत रूपमा स्वत: पूर्ण छनौट गर्न सक्छ। उदाहरणका लागि, यदि यो पालन गर्न महत्त्वपूर्ण छ वेब सामग्री पहुँच मार्गनिर्देशनहरू - असक्षमता भएका प्रयोगकर्ताहरूको लागि सामग्रीको पहुँचको लागि सिफारिसहरू।

धेरै ब्राउजरहरूको लागि, तपाईंले autocompete="off" विशेषताको साथ स्वत: पूर्ण अक्षम गर्न सक्नुहुन्छ, उदाहरणका लागि:
```
 <body>
    <form action="/ne/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-Frame-Options हेडर साइट कोडमा सेट गरिएको छैन।
यो हेडरले फ्रेम, iframe, इम्बेड, वा वस्तु ट्यागहरूलाई असर गर्छ। यसको मद्दतले, तपाइँ तपाइँको साइटलाई फ्रेम भित्र इम्बेड गर्न पूर्ण रूपमा निषेध गर्न सक्नुहुन्छ। यो गर्नको लागि, तपाईंले मान निर्दिष्ट गर्न आवश्यक छ X-Frame-Options: अस्वीकार। वा तपाईले X-Frame-Options: sameorigin निर्दिष्ट गर्न सक्नुहुन्छ, त्यसपछि iframe मा इम्बेडिङ तपाईको डोमेनमा मात्र उपलब्ध हुनेछ।

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

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

वेब विकासकर्ताले के सम्झनुपर्छ: यदि वेब सर्भर वा लोड ब्यालेन्सरमा विवादित मान भएको X-Frame-Options सेट गरिएको छ भने जोखिम हुन सक्छ। यस अवस्थामा, सर्भर र ब्यालेन्सरले केवल हेडरलाई पुन: लेख्नेछ, किनभने तिनीहरूसँग ब्याकएन्ड कोडको तुलनामा उच्च प्राथमिकता छ।

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="/ne/somefolder/styles.css/" शैली फाइलहरू पहुँच गर्न प्रयोग गरिन्छ भने यो हुन्छ। यदि तिनीहरूले प्रयोगकर्तालाई खराब पृष्ठमा रिडिरेक्ट गर्ने तरिका फेला पार्छन् भने आक्रमणकारीले यसको फाइदा उठाउनेछन्। पृष्ठले यसको url मा सापेक्ष लिङ्क सम्मिलित गर्नेछ र एक शैली कल सिमुलेट गर्नेछ। तपाईंले badsite.ru/…/somefolder/styles.css/ जस्तो अनुरोध प्राप्त गर्नुहुनेछ, जसले शैलीको आडमा दुर्भावनापूर्ण कार्यहरू गर्न सक्छ।

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

वेब विकासकर्ताले के सम्झनुपर्छ: X-Content-Type-Options हेडरलाई: nosniff मा सेट गर्नुहोस्। यस अवस्थामा, ब्राउजरले शैलीहरूको लागि सामग्री प्रकार जाँच गर्नेछ। यदि प्रकार पाठ/सीएसएस बाहेक अन्य छ भने, ब्राउजरले अनुरोधलाई रोक्नेछ।

आलोचनात्मक कमजोरीहरू

पासवर्ड फिल्ड भएको पृष्ठलाई सर्भरबाट असुरक्षित च्यानलमा पठाइन्छ (एचटीटीपीमा पासवर्ड फिल्ड(हरू) समावेश भएको HTML फारम।
एन्क्रिप्टेड च्यानलमा सर्भरबाट प्रतिक्रिया "मध्यमा मानिस" आक्रमणहरूको लागि कमजोर छ। एक आक्रमणकारीले ट्राफिकलाई रोक्न सक्छ र ग्राहक र सर्भरको बीचमा पृष्ठ सर्भरबाट ग्राहकमा यात्रा गर्दा वेज गर्न सक्छ।

के खतरनाक छ: जालसाजीले पृष्ठ बदल्न र प्रयोगकर्तालाई गोप्य डाटाको लागि फारम पठाउन सक्षम हुनेछ, जुन आक्रमणकारीको सर्भरमा जान्छ।

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

के खतरनाक छ: अघिल्लो केसको विपरीत, यो पहिले नै एक महत्वपूर्ण जोखिम हो। संवेदनशील डेटालाई रोक्न सजिलो छ किनभने तपाईंले यो गर्नको लागि कोड लेख्न पनि आवश्यक पर्दैन।
जाभास्क्रिप्ट पुस्तकालयहरू ज्ञात कमजोरीहरूको साथ प्रयोग गर्दै।
स्क्यानको समयमा, सबैभन्दा धेरै प्रयोग गरिएको पुस्तकालय jQuery थियो जसमा धेरै संस्करणहरू थिए। प्रत्येक संस्करणमा कम्तिमा एक, वा अझ बढी, ज्ञात कमजोरीहरू छन्। प्रभाव जोखिम को प्रकृति को आधार मा धेरै फरक हुन सक्छ।

के खतरनाक छ: त्यहाँ ज्ञात कमजोरीहरूको लागि शोषणहरू छन्, उदाहरणका लागि:

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

भण्डारण गरिएको XSS अधिक खतरनाक, किनकि स्क्रिप्ट सर्भरमा इम्बेड गरिएको छ र प्रत्येक पटक आक्रमण गरिएको पृष्ठ ब्राउजरमा खोलिएको छ।

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

XSS को एक उल्लेखनीय उदाहरण: js sniffers जसले CVC, कार्डको म्याद सकिने मिति, र अन्यमा प्रवेश गर्नका लागि पृष्ठहरू अनुकरण गर्दछ।

वेब विकासकर्ताले के सम्झनुपर्छ: सामग्री-सुरक्षा-नीति हेडरमा, क्लाइन्ट ब्राउजरलाई विश्वसनीय स्रोतबाट कोड डाउनलोड गर्न र कार्यान्वयन गर्न बाध्य पार्न script-src विशेषता प्रयोग गर्नुहोस्। उदाहरणका लागि, script-src 'self' ले हाम्रो साइटबाट मात्र सबै स्क्रिप्टहरूलाई व्हाइटलिस्ट गर्छ।
सबैभन्दा राम्रो अभ्यास इनलाइन कोड हो: केवल असुरक्षित-इनलाइन मान प्रयोग गरेर इनलाइन जाभास्क्रिप्टलाई अनुमति दिनुहोस्। यो मानले इनलाइन js/css को प्रयोग गर्न अनुमति दिन्छ, तर js फाइलहरू समावेश गर्न निषेध गर्दैन। स्क्रिप्ट-src 'self' सँग संयोजनमा हामी बाह्य स्क्रिप्टहरू कार्यान्वयन हुनबाट असक्षम पार्छौं।

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

के खतरनाक छ: यदि आक्रमणकारीले यस फारममा SQL क्वेरी प्रविष्ट गर्छ भने, उसले डाटाबेस क्र्यास गर्न वा गोप्य जानकारी प्रकट गर्न सक्छ।

वेब विकासकर्ताले के सम्झनुपर्छ: ब्राउजरबाट आउने कुरामा विश्वास नगर्नुहोस्। तपाईंले ग्राहक पक्ष र सर्भर साइड दुवैमा आफूलाई सुरक्षित गर्न आवश्यक छ।

क्लाइन्ट साइडमा, जाभास्क्रिप्ट प्रयोग गरेर फिल्ड प्रमाणीकरण लेख्नुहोस्।

लोकप्रिय फ्रेमवर्कहरूमा निर्मित कार्यहरूले सर्भरमा संदिग्ध क्यारेक्टरहरूबाट बच्न मद्दत गर्दछ। सर्भरमा प्यारामिटराइज्ड डाटाबेस क्वेरीहरू प्रयोग गर्न पनि सिफारिस गरिन्छ।

वेब अनुप्रयोगमा डाटाबेससँगको अन्तरक्रिया कहाँ हुन्छ भनेर निर्धारण गर्नुहोस्।

अन्तरक्रिया तब हुन्छ जब हामीले कुनै पनि जानकारी प्राप्त गर्छौं: आईडी (आईडी परिवर्तन), नयाँ प्रयोगकर्ताको सिर्जना, नयाँ टिप्पणी, वा डाटाबेसमा नयाँ प्रविष्टिहरू सहितको अनुरोध। यो जहाँ 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

वेबसाइट सुरक्षाको घातक पापहरू: हामीले वर्षको लागि भेद्यता स्क्यानर तथ्याङ्कबाट के सिकेका छौं

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

आलोचनात्मक कमजोरीहरू

सामान्य सिफारिसहरू

एक टिप्पणी थप्न Отменить ответ