👩🏽‍🤝‍👨🏿 🚵🏿 🧛🏽 हैकर्स की आंखों के माध्यम से WAF 👦🏾 💹 💩

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

डिस्क्लेमर: यह रूसी से अंग्रेजी में लेख का अनुवाद है, यह लेख क्रमशः 2017 के अंत में जारी किया गया था, कुछ जानकारी पुरानी हो सकती है।

अंतर्वस्तु

परिचय
आधुनिक WAF
WAF की पहचान करना
WAF बाईपास धोखा देती है
व्यवहार में WAF बाईपास
निष्कर्ष

यदि आप जानते हैं कि WAF का उपयोग क्यों किया जाता है और वे कैसे काम करते हैं, तो आप सीधे बाईपास अनुभाग पर जा सकते हैं।

परिचय

WAFs हाल ही में काफी लोकप्रिय हो गए हैं। छोटे व्यवसायों से लेकर बड़े उद्यमों तक विभिन्न ग्राहकों को लक्षित करते हुए वेंडर विभिन्न मूल्य श्रेणियों, वितरण किटों और विकल्पों में विभिन्न समाधान प्रदान करते हैं। WAFs लोकप्रिय हैं क्योंकि वे वेब अनुप्रयोगों की सुरक्षा के लिए एक जटिल समाधान हैं, जो कार्यों के पूरे स्पेक्ट्रम को कवर करता है। यही कारण है कि वेब ऐप डेवलपर कुछ सुरक्षा पहलुओं में WAF पर भरोसा कर सकते हैं। हालाँकि, WAFs कुल सुरक्षा नहीं दे सकते।

तो, एक WAF को किसी परियोजना में इसके कार्यान्वयन को सही ठहराने में क्या सक्षम होना चाहिए? इसका मुख्य कार्य किसी भी अनुरोध का पता लगाना और अवरुद्ध करना है, जो कि WAF के विश्लेषण के अनुसार, कोई भी विसंगति या एक हमला वेक्टर है। विश्लेषण को वैध उपयोगकर्ताओं और वेब ऐप के बीच बातचीत में बाधा नहीं होनी चाहिए, जबकि एक ही समय में, किसी भी हमले के प्रयासों का सही और समय पर पता लगाना चाहिए। इस तरह की कार्यक्षमता को लागू करने के लिए, WAF डेवलपर्स नियमित अभिव्यक्ति, टोकन, व्यवहार विश्लेषण, प्रतिष्ठित विश्लेषण और निश्चित रूप से मशीन सीखने का उपयोग करते हैं। अक्सर, इन सभी तकनीकों का एक साथ उपयोग किया जाता है। WAF अन्य कार्यों को भी लागू कर सकता है: DDoS सुरक्षा, हमलावर के IP पर प्रतिबंध, संदिग्ध IP की निगरानी, सुरक्षा हेडर (X-XSS- सुरक्षा, X- फ़्रेम-विकल्प, आदि) को जोड़ना, केवल कुकी में http- फ्लैग जोड़ना, कार्यान्वयन। HSTS तंत्र और CSRF टोकन। इसके अलावा, कुछ WAFs में वेबसाइटों के लिए जावास्क्रिप्ट क्लाइंट साइड मॉड्यूल हैं।

बेशक, WAFs हैकर्स और पेंटेस्टर्स के लिए कुछ बाधाएं पैदा करते हैं। WAF अधिक संसाधन-गहनता का पता लगाने और उनका दोहन करने की क्षमता बनाता है (सिवाय इसके कि हमलावर एक विशेष WAF के लिए प्रभावी 0day बाईपास के तरीकों को जानता है)। WAF- संरक्षित वेब एप्लिकेशन का विश्लेषण करते समय स्वचालित स्कैनर व्यावहारिक रूप से बेकार हैं। WAF "स्क्रिप्टकीडीज़" के खिलाफ विश्वसनीय सुरक्षा है। हालांकि, एक अनुभवी हैकर या पर्याप्त प्रेरणा के बिना एक शोधकर्ता शायद समय बर्बाद करने के लिए इसे बायपास करने के तरीके खोजने की कोशिश नहीं करना चाहेगा। यह ध्यान दिया जाना चाहिए कि अधिक जटिल वेब ऐप इसकी हमले की सतह जितनी बड़ी है, और बाईपास विधि खोजने में आसान है।

हमारे हाल के ऑडिट में, हम अक्सर बहुत अलग WAFs पाएंगे। हम उनमें से कुछ के बारे में बाद में बात करेंगे। हमने पहले से ही दो मुख्य परिदृश्यों में दो स्वामित्व वाले WAF का परीक्षण किया है:

हम जानते हैं कि एक वेब ऐप में एक निश्चित भेद्यता है और हम इसका फायदा उठाने के लिए WAF को दरकिनार करने की कोशिश करते हैं;
हम किसी भी कमजोरियों के बारे में नहीं जानते हैं, इसलिए हमें WAF के बावजूद एक को खोजना होगा और फिर WAF को दरकिनार कर इसका फायदा उठाना होगा।

लेकिन पहले, चलो WAF के पीछे बुनियादी तंत्रों पर एक करीब से नज़र डालें और देखें कि उन्हें क्या समस्याएँ हैं।

आधुनिक WAF

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

नियमित अभिव्यक्ति के आधार पर नियम

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

Scorebuilding

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

Tokenizers

यह पता लगाने का तरीका ब्लैक हैट 2012 में C / C + लाइब्रेरी लिबिनेंस के रूप में प्रस्तुत किया गया था, जो SQL इंजेक्शन को जल्दी और सटीक रूप से पहचानने की अनुमति देता है। इस समय, विभिन्न प्रोग्रामिंग भाषाओं के लिए कई लिबिन्यूजन पोर्ट हैं, जैसे PHP, Lua, Python, आदि। यह तंत्र टोकन के एक सेट के रूप में प्रस्तुत किए गए हस्ताक्षरों की खोज करता है। हस्ताक्षर की एक निश्चित संख्या को ब्लैकलिस्ट किया जाता है, और उन्हें अवांछित और दुर्भावनापूर्ण माना जाता है। दूसरे शब्दों में, कुछ अनुरोधों का विश्लेषण करने से पहले, इसे टोकन के सेट में अनुवादित किया जाता है। टोकन को कुछ प्रकारों में विभाजित किया जाता है, जैसे चर, स्ट्रिंग, नियमित ऑपरेटर, अज्ञात, संख्या, टिप्पणी, संघ-जैसे ऑपरेटर, फ़ंक्शन, अल्पविराम, आदि। विधि का एक मुख्य नुकसान यह है कि यह एक संरचना का निर्माण करना संभव है जो टोकन के गलत गठन का कारण होगा, इसलिए अनुरोध हस्ताक्षर अपेक्षा से अलग होगा। इन संरचनाओं को आमतौर पर टोकन ब्रेकर के रूप में संदर्भित किया जाता है, और हम बाद में उनकी चर्चा करेंगे

व्यवहार विश्लेषण

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

प्रतिष्ठा विश्लेषण

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

मशीन सीखने

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

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

WAF की पहचान करना

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

यहां संभावित WAF उंगलियों के निशान की सूची दी गई है:

अतिरिक्त कुकीज़
किसी भी प्रतिक्रिया या अनुरोध के लिए अतिरिक्त हेडर
प्रतिक्रिया सामग्री (अवरुद्ध अनुरोध के मामले में)
प्रतिक्रिया कोड (अवरुद्ध अनुरोध के मामले में)
IP पता (क्लाउड WAF)
JS क्लाइंट साइड मॉड्यूल (क्लाइंट साइड WAF)

आइए इसे कुछ उदाहरणों के साथ स्पष्ट करते हैं

पीटी एएफ
अवरुद्ध अनुरोध के लिए प्रतिक्रिया कोड: 403
प्रतिक्रिया पृष्ठ में क्लाइंट मॉड्यूल waf.js सम्मिलित कर सकते हैं
प्रतिक्रिया की बॉडी:

<h1>Forbidden</h1> <pre>Request ID: 2017-07-31-13-59-56-72BCA33A11EC3784</pre>

एक अतिरिक्त हेडर जो waf.js द्वारा जोड़ रहा है:

 X-RequestId: cbb8ff9a-4e91-48b4-8ce6-1beddc197a30

निमेसिडा वफ़
अवरुद्ध अनुरोध के लिए प्रतिक्रिया कोड: 403
प्रतिक्रिया की बॉडी:

 <p style="font-size: 16px; align: center;"> Suspicious activity detected. Access to the site is blocked. If you think that is's an erroneous blocking, please email us at <a href="mailto:nwaf@pentestit.ru">nwaf@pentestit.ru</a> and specify your IP-address. </p>

Wallarm
अवरुद्ध अनुरोध के लिए प्रतिक्रिया कोड: 403
अतिरिक्त हेडर: nginx-wallarm

Citrix NetScaler AppFirewall
अतिरिक्त कुकी:

 ns_af=31+LrS3EeEOBbxBV7AWDFIEhrn8A000; ns_af_.target.br_%2F_wat=QVNQU0VTU0lP TklEQVFRU0RDU0Nf?6IgJizHRbTRNuNoOpbBOiKRET2gA

Mod_Security ver। 2.9
अवरुद्ध अनुरोध के लिए प्रतिक्रिया कोड: 403
प्रतिक्रिया शरीर:

 <head> <title>403 Forbidden</title> </head><body> <h1>Forbidden</h1> <p>You don't have permission to access /form.php on this server.<br /></p>

Mod_Security ver। <2.9
अवरुद्ध अनुरोध के लिए प्रतिक्रिया कोड: 406 या 501
प्रतिक्रिया शरीर में, आप mod_security, Mod_Security, या NOYB पा सकते हैं

वार्निश फ़ायरवॉल
निम्नलिखित शीर्षकों को प्रतिक्रिया में जोड़ता है:

 X-Varnish: 127936309 131303037. X-Varnish: 435491096 Via: 1.1 varnish-v4

WAF डेवलपर्स खुद को तय करते हैं कि अवरुद्ध अनुरोध के मामले में कौन सा प्रतिक्रिया कोड वापस करना है; कुछ विशिष्ट कोड भी हैं। उदाहरण के लिए, Web_Knight WAF कोड 999 का रिटर्न देता है, और dotDefender एक खाली प्रतिक्रिया निकाय के साथ या एक त्रुटि संदेश के साथ कोड 200 देता है। इसके अलावा, डेवलपर्स कुछ अन्य सामग्री के साथ एक कस्टम प्रतिक्रिया पृष्ठ बना सकते हैं।

WAF, किसी भी अन्य ऐप की तरह, विकसित और बदलता है। यही कारण है कि आपके पास उंगलियों के निशान की प्रासंगिकता की लगातार जांच करना महत्वपूर्ण है।

WAF बाईपास धोखा शीट

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

या तो WAF सुरक्षा तंत्र या उपयोग के क्षेत्र द्वारा WAF को बायपास करने के लिए सभी संभव तरीकों को वर्गीकृत करना कठिन है। एक ही बाईपास के तरीके बातचीत कर सकते हैं और साथ ही एक WAF के विभिन्न घटकों को प्रभावित कर सकते हैं। नीचे वर्णित तकनीकों को खुले स्रोतों से एकत्र किया गया था या हमारे अपने शोध के दौरान खोजा गया था और सबसे प्रभावी साबित हुआ था।

विशेष प्रतीक जोड़ना

विभिन्न विशेष प्रतीकों एक WAF के विश्लेषण तर्क का उल्लंघन कर सकते हैं और एक ही समय में सर्वर द्वारा मान्य व्याख्या की जा सकती है। इन प्रतीकों की भिन्नताएं भिन्न हो सकती हैं: वे urlencode (हालांकि अधिकांश WAFs उस से निपट सकते हैं) या अन्य एन्कोडिंग में परिवर्तित हो सकते हैं। कच्चे प्रारूप में किसी भी एन्कोडिंग के बिना विशेष प्रतीकों को सम्मिलित करना संभव है, जो कि WAF के लिए आश्चर्य की बात हो सकती है। उदाहरण के लिए, इस प्रस्तुति में \ r \ n \ r \ n को HTTP अनुरोध निकाय की समाप्ति के रूप में माना जा सकता है, और अशक्त बाइट पूरी तरह से नियमित अभिव्यक्ति और डेटा पार्सर्स के विश्लेषण तर्क का उल्लंघन कर सकता है। इसके अलावा, ASCII तालिका के पहले बीस प्रतीकों में से अन्य विशेष प्रतीकों का उपयोग किया जा सकता है।
उदाहरण:

0x00 - नल बाइट;
0x0D - कैरिज वापसी;
0x0A - लाइन फ़ीड;
0x0 बी - ऊर्ध्वाधर टैब;
0x09 - क्षैतिज टैब;
0x0C - नया पृष्ठ

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

उदाहरण के लिए:

 {"id":1337,"string0x00":"test' or sleep(9)#"} {"id":1337,"string":"test'/*0x00*/ or sleep(9)#"} {"id":1337,"string"0x0A0x0D:"test' or sleep(9)#"}

 <a href="ja0x09vas0x0A0x0Dcript:alert(1)">clickme</a> <a 0x00 href="javascript:alert(1)">clickme</a> <svg/0x00/onload="alert(1)">

 id=1337/*0x0C*/1 UNION SELECT version(), user() --

स्पष्टता के लिए, हमने विशेष प्रतीकों को उनकी हेक्स प्रस्तुति के साथ बदल दिया है।

अंतरिक्ष प्रतीकों की जगह

अधिकांश सिंटैक्स में, कुंजी शब्दों और ऑपरेटरों को अलग करना पड़ता है, लेकिन बेहतर स्थान के प्रतीकों को निर्दिष्ट नहीं किया जाता है। इस प्रकार, सामान्य 0x20 (स्थान) के बजाय, आप 0x0B (कार्यक्षेत्र टैब) या 0x09 (क्षैतिज टैब) का उपयोग कर सकते हैं। अपने स्वयं के अर्थ के बिना विभाजन संरचनाओं के साथ रिक्त स्थान की जगह एक ही श्रेणी में आती है। SQL में, यह / ** / (बहु-पंक्ति SQL टिप्पणियाँ), # \ r \ n (एक-पंक्ति SQL टिप्पणी, लाइन फ़ीड के साथ समाप्त होता है), - \ r \ n (वैकल्पिक एक-पंक्ति SQL टिप्पणी, समाप्त लाइन फीड के साथ)। यहाँ कुछ उदाहरण हैं:

 http://test.com/test?id=1%09union/**/select/**/1,2,3 http://test.com/test?id=1%09union%23%0A%0Dselect%2D%2D%0A%0D1,2,3

इसके अलावा, हम भाषा के वाक्य विन्यास का उपयोग करके रिक्त स्थान से छुटकारा पाने के लिए एक अभिव्यक्ति को बदल सकते हैं। उदाहरण के लिए, SQL में, हम कोष्ठक का उपयोग कर सकते हैं:

 UNION(SELECT(1),2,3,4,5,(6)FROM(Users)WHERE(login='admin'))

और JS में, उपयोग करें:

 <svg/onload=confirm(1)>

एन्कोडिंग बदलना

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

HTML प्रतीक का दशमलव रूप है & # 106 या # 0000106 .WAF लघु संस्करण के बारे में और अतिरिक्त शून्य वाले संस्करण के बारे में नहीं पता हो सकता है (कुल 7 प्रतीकों से अधिक नहीं होना चाहिए)। उसी तरह, एक HTML प्रतीक का हेक्स रूप & # x6A या & # x000006A है ।

उदाहरण के लिए, बैकस्लैश \ _ के साथ भागने वाले पात्रों के साथ एक चाल भी है:

 <svg/on\load=a\lert(1)>

हालांकि, यह इस बात पर निर्भर करता है कि कोई वेब ऐप ऐसे इनपुट डेटा को कैसे प्रोसेस करता है। तो, अनुक्रम \ l को l के रूप में संसाधित किया जाएगा और एक एकल प्रतीक में बदल दिया जाएगा; WAF प्रत्येक प्रतीक को अलग से संसाधित कर सकता है और यह नियमित अभिव्यक्ति या एक अन्य WAF तर्क को तोड़ सकता है। इस प्रकार, WAF खोजशब्दों को याद करेगा। इस तकनीक का उपयोग करके हम वर्णों से नहीं बच सकते, \ r , \ t , क्योंकि वे विभिन्न वर्णों में बदल जाएंगे: नई पंक्ति, गाड़ी वापसी और टैब।

उदाहरण के लिए HTML-encode का उपयोग टैग विशेषताओं के अंदर किया जा सकता है:

 <a href="javascript&colon;alert(1)">clickme</a> <input/onmouseover="javascript&colon;confirm&lpar;1rpar;">

इन वर्णों को आसानी से लक्ष्य पात्रों के अन्य HTML अभ्यावेदन द्वारा प्रतिस्थापित किया जा सकता है। आप यहां पात्रों के विभिन्न परिवर्तनों को देख सकते हैं ।

HTML सांकेतिक शब्दों में बदलना के अलावा, हम \ u के साथ वर्ण सम्मिलित कर सकते हैं :

 <a href="javascript:\u0061lert(1)">Clickme</a> <svg onload=confir\u006d(1)>

आइए विशेष चरित्र डालने से संबंधित वेक्टर को भी देखें। एचटीएमएल एनकोड के साथ पेलोड को तोड़ दें:

 <a href="ja&Tab;vas&#x0000A;cript:alert(1)">clickme</a>

इस मामले में, हम अन्य अलग-अलग वर्ण भी रख सकते हैं।

इस प्रकार, हम विभिन्न तरीकों के साथ विभिन्न एन्कोडिंग के संयोजन की सलाह देते हैं, उदाहरण के लिए, विशेष वर्णों को एनकोड करने के लिए।

Atypical समतुल्य वाक्य रचना के लिए खोजें

इस पद्धति का उद्देश्य WAF डेवलपर्स द्वारा विचार नहीं किए गए शोषण का एक तरीका खोजना है, या एक वेक्टर जो मशीन लर्निंग प्रशिक्षण नमूने में मौजूद नहीं था। सरल उदाहरण जावास्क्रिप्ट कार्य होंगे: यह, शीर्ष स्व, माता-पिता, फ्रेम; टैग विशेषताएँ: डेटा-बाइंड, ontoggle, onfilterchange, onbeforescriptexecute, onpointerover, srcdoc; और SQL ऑपरेटर: lpad, फ़ील्ड, bit_count ।

यहाँ कुछ उदाहरण हैं:

 <script>window['alert'](0)</script> <script>parent['alert'](1)</script> <script>self['alert'](2)</script>

 SELECT if(LPAD(' ',4,version())='5.7',sleep(5),null);

आप जावास्क्रिप्ट अभिव्यक्तियों के गैर-प्रतीकात्मक प्रतिनिधित्व का भी उपयोग कर सकते हैं:

उस के साथ एक स्पष्ट समस्या लंबे पेलोड है।

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

एचटीटीपी पैरामीटर प्रदूषण (एचपीपी) और एचटीटीपी पैरामीटर घर्षण (एचपीएफ)

एचपीपी हमला इस बात पर आधारित है कि कैसे सर्वर समान नामों के साथ मापदंडों की व्याख्या करता है। यहाँ कुछ संभावित बायपास हैं:

सर्वर अंतिम प्राप्त पैरामीटर का उपयोग करता है, और WAF केवल पहले की जांच करता है;
सर्वर समान मापदंडों से मूल्य को एकजुट करता है, और WAF उन्हें अलग से जांचता है।

आप तुलना कर सकते हैं कि विभिन्न सर्वर नीचे दिए गए तालिका में समान मापदंडों को कैसे संसाधित करते हैं:

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

 http://test.com/url?a=1+select&b=1+from&c=base

एचपीएफ और एचपीपी बहुत समान हैं, लेकिन पहला एक वेब ऐप को लक्षित करता है, और बाद वाला पर्यावरण जिस में इसे संचालित करता है। इन तकनीकों के संयोजन से एक WAF को दरकिनार करने की संभावना बढ़ जाती है।

यूनिकोड सामान्यीकरण

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

उदाहरण के लिए, ऊपर दी गई तालिका में, हम देख सकते हैं कि प्रतीक ＜ और। सरल < में बदल जाते हैं। यदि कोई ऐप सामान्यीकरण के बाद HTML एन्कोडिंग का उपयोग करता है, तो सबसे अधिक संभावना है कि सामान्यीकृत प्रतीक < < । लेकिन, अन्य मामलों में, डेवलपर्स ने इस सुविधा की अनदेखी की होगी और यूनिकोड प्रतीकों को एन्कोड नहीं किया। इस प्रकार, हमें गैर-एचटीएमएल-एन्कोडेड प्रतीक < और > मिलते हैं, जिसे XSS हमले में बदल दिया जा सकता है। WAF को यूनिकोड प्रतीकों को समझने में परेशानी हो सकती है - इसके पास इस तरह के टोटके के नियम नहीं हो सकते हैं, और मशीन सीखना भी बेकार हो सकता है। यूनिकोड सामान्यीकरण के साथ वेब एप्लिकेशन में बाईपास खोजने के दौरान, हम न केवल <> बल्कि पेलोड से अन्य प्रतीकों को भी बदल सकते हैं।

उदाहरण के लिए:

 ＜img src﹦x onerror＝alert︵1)>

हाल ही में हैकरऑन में रॉकस्टार बगबाउटी कार्यक्रम में यह समस्या पाई गई। कोई वाफ़ नहीं था, केवल सख्त उपयोगकर्ता इनपुट फ़िल्टरिंग:

hackerone.com/reports/231444
hackerone.com/reports/231389

टोकन तोड़ने वाले

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

 SELECT-@1,version()

जहां - @ एक टोकन ब्रेकर है।

एक चीयर शीट है जिसे mysql fuzzing द्वारा हासिल किया गया था और परिणाम को जांचने के लिए किया गया था।

कामेच्छा में मुद्दों को खोजने के बारे में अधिक:

एक और फजीहत
बाईपास पर फजीहत
कामवासना को कैसे दरकिनार किया जाए

RFC की विशेषताओं का उपयोग करना

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

मल्टीपार्ट / फॉर्म-डेटा के साथ एक HTTP अनुरोध में, पैरामीटर सीमा एक अनुरोध के शरीर में विभिन्न मापदंडों के अलगाव के प्रभारी है। RFC के अनुसार, "-" वाले उपसर्ग के साथ पहले से निर्दिष्ट सीमा को प्रत्येक नए POST पैरामीटर के सामने रखा जाना चाहिए, ताकि सर्वर एक अनुरोध के विभिन्न मापदंडों को भेदभाव करने में सक्षम हो।

 POST /vuln.php HTTP/1.1 Host: test.com Connection: close Content-Type: multipart/form-data; boundary=1049989664 Content-Length: 192 --1049989664 Content-Disposition: form-data; name="id" 287356 --1049989664--

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

 POST /vuln.php HTTP/1.1 Host: test.com Connection: close Content-Type: multipart/form-data; boundary= Content-Length: 192 -- Content-Disposition: form-data; name="id" 123' or sleep(20)# ----

हम ZeroNights 2016 में Bo0oM द्वारा स्लाइड से कुछ और दिलचस्प उदाहरण देंगे और इसे समझाएंगे:

 POST /vuln.php HTTP/1.1 Host: test.com Content-Type: multipart/form-data; boundary=FIRST; Content-Type: multipart/form-data; boundary=SECOND; Content-Type: multipart/form-data; boundary=THIRD; --THIRD Content-Disposition: form-data; name=param UNION SELECT version() --THIRD--

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

 POST /vuln.php HTTP/1.1 Host: test.com Content-Type: multipart/form-data; xxxboundaryxxx=FIRST; boundary=SECOND; --FIRST Content-Disposition: form-data; name=param UNION SELECT version() --FIRST--

यह हमला इस धारणा पर आधारित है कि WAF और वेब सर्वर द्वारा HTTP अनुरोध के पार्सिंग में अंतर है। अर्थात्, वेब सर्वर का पार्सर पहले 'सीमा' प्रविष्टि के लिए दिखता है, और फिर '=' प्रतीक के लिए, और उसके बाद ही सीमा के मूल्य को परिभाषित करता है। WAF पार्सर, अपनी बारी में, केवल "सीमा =" प्रविष्टि की तलाश करता है और फिर सीमा को परिभाषित करता है। यदि ये स्थितियां पूरी हो जाती हैं, तो WAF अनुरोध में सीमा नहीं पाएगा, और इसलिए यह पैरामीटर को खोजने और उसका विश्लेषण करने में सक्षम नहीं होगा। इसके विपरीत, वेब सर्वर अनुरोध प्राप्त करेगा और पैरामीटर को संसाधित करेगा। यह हमला दूसरे तरीके से भी काम करेगा: वेब सर्वर पार्सर "सीमा =" के लिए दिखता है, और WAF पार्सर सिर्फ 'सीमा' के लिए दिखता है। इस मामले में, हमें केवल वास्तविक सीमा को FIRST से SECOND में बदलना होगा।

 POST /somepage.php HTTP/1.1 Host: test.com Content-Type: multipart/form-data; boundary=Test0x00othertext; --Test Content-Disposition: form-data; name=param Attack --Test--

इस हमले में विशेष पात्रों का भी उपयोग किया गया है। सीमा पैरामीटर में, हमने NULL-बाइट को जोड़ा ताकि वेब सर्वर इसे काट दे, लेकिन WAF इसे पूर्ण रूप से स्वीकार करेगा। इस मामले में, WAF पैरामीटर का विश्लेषण नहीं कर सकता क्योंकि यह अपनी सीमाओं को नहीं पा सकता है।

मशीन सीखने को दरकिनार करना

तर्क सरल है: हमें एक हमले की रचना करनी होगी जो प्रशिक्षित सांख्यिकीय मॉडल के मापदंडों को पूरा करे। लेकिन यह बहुत निर्भर करता है कि डब्ल्यूएएफ को कैसे प्रशिक्षित किया गया था और किस प्रशिक्षण मॉडल का उपयोग किया गया था। कभी-कभी एक खामियों को खोजने के लिए संभव है, और कभी-कभी यह नहीं है। आमतौर पर, कार्यान्वयन के चरण में, मशीन सीखने के साथ एक WAF को ग्राहक के वेब एप्लिकेशन के अनुरोध के आधार पर अतिरिक्त प्रशिक्षण की आवश्यकता होती है। यह पेंटर्स के लिए एक समस्या बन गया है: पैरामीटर जो एक जैसे दिखते हैं और अनुरोध से अनुरोध में बहुत बदलाव नहीं होते हैं, उन्हें परीक्षण नहीं किया जा सकता है, क्योंकि सामान्य पैरामीटर फॉर्म से किसी भी विषयांतर को विसंगति माना जाएगा। मान लीजिए कि api.test.com/getuser?id=123 पर अनुरोध है। पैरामीटर आईडी हमेशा संख्यात्मक होती है, और प्रशिक्षण नमूने में यह संख्यात्मक थी। यदि मशीन सीखने का मॉड्यूल इस पैरामीटर में संख्याओं के अलावा कुछ पाता है, तो यह सबसे अधिक संभावना तय करेगा कि यह एक विसंगति है। एक और उदाहरण: मान लीजिए कि WAF को POST मापदंडों के साथ POST अनुरोधों को वर्गीकृत करने के लिए प्रशिक्षित किया गया था, जिसमें POST मापदंडों के साथ मार्कडाउन पाठ है। जाहिर है, मार्कडाउन में उद्धरण चिह्न, विशेष प्रतीक और मूल रूप से कुछ भी हो सकते हैं। इस मामले में, मशीन लर्निंग मॉड्यूल को बायपास करना आसान है क्योंकि WAF उद्धरण और विशेष प्रतीकों को सहन करता है।

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

सामान्य तौर पर, हमें एक परीक्षण किए गए अनुरोध और उसके मापदंडों की बारीकियों पर विचार करना होगा, मापदंडों के मूल्यों के किसी भी संभावित विकल्प को मानेंगे, जो कि WAF के लिए सहिष्णु हो सकते हैं और उन पर निर्माण कर सकते हैं।

जब WAF बेकार है?

WAF अनुरोधों का विश्लेषण करता है और उन में विसंगतिपूर्ण व्यवहार की तलाश करता है, लेकिन कमजोरियों के कुछ वर्ग हैं जो इसे खोज नहीं सकते हैं। उदाहरण के लिए, तर्क भेद्यता, जिसमें विसंगतियाँ नहीं हैं, लेकिन कुछ क्रियाएं हैं जो वेब ऐप के तर्क को बाधित करती हैं। सबसे अधिक संभावना है, दौड़ की स्थिति, IDOR और असुरक्षित उपयोगकर्ता प्रमाणीकरण के मामले में WAF भी बेकार होगा।

मौजूदा उपयोगिताओं

इस क्षेत्र में उत्साही लोगों द्वारा लिखे गए WAF बाईपास खोजने के लिए कुछ स्वचालित उपकरण हैं। यहाँ सबसे प्रसिद्ध और योग्य हैं:

lightbulb- फ्रेमवर्क - WAF के साथ संरक्षित वेब ऐप्स के परीक्षण के लिए एक संपूर्ण ढांचा। यह पायथन पर लिखा गया है और इसके अलावा बर्प सूट के लिए एक प्लगइन के रूप में चित्रित किया गया है। इसकी मुख्य विशेषताएं ये दो एल्गोरिदम हैं:

GOFA - एक सक्रिय मशीन लर्निंग एल्गोरिदम जो एक वेब ऐप में मापदंडों के निस्पंदन और सैनिटाइजेशन का विश्लेषण करने की अनुमति देता है।
SFADiff - प्रतीकात्मक ब्लैक बॉक्स परीक्षण एल्गोरिथ्म, प्रतीकात्मक परिमित ऑटोमेट्स (SFA) के साथ प्रशिक्षण पर आधारित। यह वेब ऐप्स के व्यवहार में अंतर खोजने की अनुमति देता है जो WAF को पहचानने और बाईपास खोजने में मदद करता है।

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

WAFW00F - WAF पहचान के लिए एक उपकरण, पायथन पर लिखा गया है। इसका एक सभ्य WAF बेस है और अभी भी अपडेट किया जा रहा है। हालाँकि, परिणाम थोड़े समय के लिए हो सकते हैं क्योंकि कई WAF को प्रोजेक्ट से ही बार-बार अपडेट किया जाता है।

व्यवहार में वफ़ा को दरकिनार करना

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

 {"request":{"Count":10,"Offset":0,"ItemName":"Phone"}}

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

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

 SELECT item FROM items WHERE item_name='Phone''

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

 SELECT item FROM items WHERE item_name='Phone'+''

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

हमने भेद्यता का पता लगाने का वर्णन किया है, लेकिन WAF को दरकिनार करने और भेद्यता का फायदा उठाने के बारे में क्या? कुछ बाईपास से गुजरने के बाद, हमें WAF में एक समस्या मिली। यह पता चला कि यह WAF JSON मापदंडों में जोड़े गए विशेष वर्णों के लिए असुरक्षित है। वास्तव में, अगर हमने JSON प्रतीकों 0x0A, 0x0D (\ r \ n या carrige reutrn और नई लाइन) को बिना किसी एन्कोडिंग के किसी भी टेक्स्ट फ़ील्ड में जोड़ा, तो WAF इसे पारित कर देगा, और वेब ऐप इस पर विचार करेगा। सही हो और इसे संसाधित करें। सबसे अधिक संभावना है, समस्या JSON पार्सर में थी, जो कि विशेष प्रतीकों के लिए नहीं बनाई गई थी और JSON को सही जगह पर रखा गया था, जहां ये प्रतीक दिखाई देंगे। इस प्रकार, WAF विश्लेषक को पूर्ण अनुरोध नहीं मिलेगा, इसलिए हम विशेष वर्णों के बाद किसी भी हमले के वेक्टर को सम्मिलित कर सकते हैं। लाइन ब्रेक के अलावा, अन्य अक्षर (जैसे NULL-बाइट) भी काम करेंगे। परिणामस्वरूप, हम निम्नलिखित अनुरोध लिख सकते हैं, जो WAF को बंद कर देगा क्योंकि उसने इस अनुरोध (लाइन ब्रेक और कैरिज रिटर्न को उनके शाब्दिक प्रतिनिधित्व के साथ बदल दिया गया था) की जाँच करने की कोशिश की:

 {"request":{"kill-waf":"die0x0A0x0D", "Count":10,"Offset":0,"ItemName":["'+(SELECT 'Phone'+CHAR(ASCII(substring(@@version,1,1))-24))+'"]}}

0x0A और 0x0D एक कच्ची बाइट्स है।

इस प्रकार, हम आसानी से और जल्दी से सभी कमजोरियों के लिए सभी मापदंडों का परीक्षण कर सकते हैं (उनमें से एक जोड़े को अन्य मापदंडों में पाया गया था)। WAF को दरकिनार कर और इस इंजेक्शन का फायदा उठाकर हमें वेब एप्लिकेशन के सभी उपयोगकर्ताओं से पूरी तरह से समझौता करने की अनुमति दी।

ऐसी ही समस्याएं नेमेसीडा डब्ल्यूएएफ में भी पाई गईं। एकमात्र अंतर यह है कि, अनुरोध JSON एन्कोडिंग में नहीं था, लेकिन यह मापदंडों के साथ एक सामान्य POST अनुरोध था, और एक पैरामीटर को SQL क्वेरी में संख्या के रूप में छुपाया गया था। यदि कुछ प्रतीकों को url-encode में एक अनुरोध में रखा गया था, उदाहरण के लिए, % 03% 04 तो WAF एक अनुरोध को अवरुद्ध करता है, लेकिन अगर प्रतीकों को url-एन्कोडिंग के बिना कच्चे रूप में रखा गया था, तो WAF इस अनुरोध को अनदेखा कर देता है। यह ध्यान देने योग्य है, कि सामान्य एसक्यूएल-अभिव्यक्ति को पिछले WAF में भी अनुरोध करने के लिए रखा गया था। एसक्यूएल-अभिव्यक्ति सरल 'यूनिअन सिलेक्ट ’ बिना किसी अतिरिक्त अवरोध के थी, जिसका अर्थ है कि डब्ल्यूएएफ केवल अनुरोध को सही ढंग से पार्स नहीं कर सकता है और आगे के विश्लेषण पर पारित कर सकता है। लेकिन एक समस्या है - SQL-क्वेरी सिंटैक्स को सही कैसे बनाया जाए? क्योंकि SQL-क्वेरी में % 03% 04 जैसे विशेष वर्णों का उपयोग करना सही नहीं है। उत्तर सरल है - हमें केवल टिप्पणियों / ** / का उपयोग करने की आवश्यकता है। इसलिए, परिणाम अनुरोध इस तरह दिखाई दिया:

 /*0x03 0x04*/1 UNION SELECT version(), user() --

0x03 और 0x04 एक कच्ची बाइट्स है।

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

 POST /wp-content/plugins/answer-my-question/modal.php HTTP/1.1 Host: example.com Content-Type: multipart/form-data; boundary= Content-Length: 209 -- Content-Disposition: form-data; name="id" 1 UNION SELECT 1,2,3,CONVERT(version() USING utf8) AS name,CONVERT(user() USING utf8) AS name,6,7,8,9,10,11,12 FROM wp_users WHERE id=1 ----

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

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

निष्कर्ष

तो, क्या हमें पूरी तरह से WAF पर निर्भर होना चाहिए? जवाब है नहीं।

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

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

योगदानकर्ता

इलिया बुलटोव बाराकुड 4
डेनिस राइबिन थैफ़राइड्रैगन
अलेक्जेंडर रोमानोव web_rock

हैकर्स की आंखों के माध्यम से WAF