🌺 😙 🧚🏼 क्लाइंट-सर्वर एपीआई सुरक्षा परीक्षण 🧙🏽 ☦️ ✊

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

एपीआई में कमजोरियों का सामना करना पड़ता है। सच तो यह है।

आप किस बारे में बात कर रहे हैं?

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

इंटरफ़ेस से एपीआई विधियों तक

हम यूट्यूब पर एपीआई में भेद्यता का विश्लेषण करेंगे, जिसे व्यापक प्रचार नहीं मिला है। Youtube इंटरफ़ेस से विशेष के उपयोग को प्रतिबंधित करता है। क्लिप के शीर्षक में <और> (जो html टैग और XSS हमलों के लिए आवश्यक हैं) जैसे अक्षर। लेकिन! यदि आप एपीआई पाते हैं और उसी वीडियो का नाम बदलने की कोशिश करते हैं, तो सब कुछ सफल होगा। परिणामस्वरूप: नहीं, xss ने youtube पृष्ठ पर कार्य नहीं किया। लेकिन इसे जीमेल के लिए एक पत्र में निष्पादित किया गया था (जब वीडियो के साथ पत्र आता है), जो और भी महत्वपूर्ण है।

निष्कर्ष? तार्किक रूप से - समस्या विभिन्न तरीकों में है। लेकिन ऐसा क्यों हुआ यह एक और दिलचस्प सवाल है। यहाँ मैं निम्नलिखित पर प्रकाश डालूंगा:

लगभग सभी बड़ी परियोजनाएँ OOP और MVC जैसे पैटर्न का उपयोग करती हैं। और एपीआई के कार्यान्वयन को केवल इंटरफ़ेस में विधि से विरासत में प्राप्त किया जाना चाहिए और इसकी सभी सीमाओं को दूर करना चाहिए। एक समान टेम्पलेट का मतलब या नहीं और विधि खरोंच से लिखी गई थी (बकवास कौन जानता है) या इंटरफ़ेस में एक कस्टम "हैक";
कस्टम हैक? डेवलपर की समस्या, बिल्कुल। लेकिन एक टीम लीड भी है, आपको डेवलपर्स को लगातार सूचित करने की आवश्यकता है कि कहां और क्या लागू करने की आवश्यकता है। यानी सभी शाश्वत सूत्र के लिए स्पष्ट रूप से समझें: जहां विकास प्रक्रिया में हम डेटा (मॉडल, सेवा, नियंत्रक, कहीं और) में मान्य करते हैं। ये विकास में जटिल पैटर्न का उपयोग करने की समस्या के परिणाम हैं, जिसे टीम के नेता सामान्य रूप से समझते हैं, और डेवलपर्स परियोजना में मान्यताओं के हिस्से तक एक जगह, दूसरे हिस्से में नहीं पहुंचते हैं। एपीआई के लिए सही ढंग से विरासत में मिला, लेकिन भेद्यता मिली।

परीक्षकों के लिए क्या?

हमें इंटरफ़ेस (इसकी सीमाओं) के बारे में हमें जो कुछ भी पता था उसे पूरी तरह से भूल जाने और परियोजना को खरोंच से परखने की आवश्यकता है;
पैरामीटर परिवर्तन की जाँच करना, फेसबुक के बारे में एक स्क्रीन के साथ एक ज्वलंत उदाहरण - इंटरफ़ेस से प्रेषक आईडी को बदलना असंभव था, लेकिन एपीआई से - आप कर सकते हैं;
"मानक" हमलों की जाँच करें, जैसे कि sqli / xss;
यदि ऑटोटेस्ट हैं, तो यह शांत है। आप testValue1 प्रकार के मानक पेलोड को ', ",>, <के विभिन्न विशेष वर्णों के साथ बदल सकते हैं और उनका मिलान कर सकते हैं (हम XSS की तलाश कर रहे हैं)।

दबाव

अक्सर मोबाइल उपकरणों पर उपयोग के लिए एपीआई विकसित होने लगते हैं। और, लागू होने पर, स्वीकृति के बाद भेजने और विघटन से पहले विभिन्न संपीड़न जोड़ें। और जिप बमों की तरह एक पुराना, दाढ़ी वाला हमला (विभिन्न फ़ाइल होस्टिंग सेवाओं ने उसे डाल दिया है)। सवाल यह है कि अनपैक करते समय 42 केबी का एक संग्रह किस आकार तक पहुंच सकता है? 4.5 पेटाबाइट । यहाँ और यहाँ डाउनलोड करें । नीचे की रेखा सरल है - शून्य से भरी फाइल बनाई और संपीड़ित होती है। इसलिए, संपीड़न, या बल्कि अनपैकिंग एक खतरनाक चीज है, सावधान रहें।

ईविल जसन

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

<script type="application/javascript" src="http://server1.example.com/api/getUserInfo?jsonp=parseResponse"> </script>

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

क्रिप्टोग्राफी

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

sign = sha*(... + DATA + ...)

डेटा - ईलिप्सिस एपीआई कुंजी के बजाय भेजने के लिए डेटा।
और सवाल यह है कि कुंजी को कहां रखा जाए, बाएं या दाएं? केवल दाईं ओर (हम एक समान, बहुत लोकप्रिय योजना का उपयोग करके अनुरोध पर हस्ताक्षर करने के बारे में बात कर रहे हैं)। क्यों? लाइन एक्सटेंशन पर हमला है। चलो एक करीब देखो
कल्पना करें कि हमारे पास डेटा ए = 1 और बी = 2 और सी = 3 है , हस्ताक्षर 07ce36c769ae130708258fb5dfa3d37ca5a67514 है , हस्ताक्षर गलत योजना = sha1 (KEY + DATA) में है ।
और अब स्थिति: किसी ने क्लाइंट से सर्वर के लिए केवल एक अनुरोध को इंटरसेप्ट किया और अब डेटा को अनुरोध में बदलना चाहता है, लेकिन उसे एक नए हस्ताक्षर की आवश्यकता है, और हस्ताक्षर के लिए कुंजी प्रेषित नहीं है (यह तर्कसंगत है)। वह क्या जानता है? मूल डेटा और उनके हस्ताक्षर। संक्षेप में: शुरुआत में एन बाइट्स को जाने बिना लाइन का एक एक्सटेंशन बनाने (अपने डेटा को जोड़ने के लिए) और एक नया हस्ताक्षर (हैश) बनाने की तकनीकी संभावना है। अभ्यास में, एन बाइट्स के इंडेंटेशन के साथ नया डेटा जब शुरुआत में हैशेड इस तरह दिखता है: ए = 1 और बी = 2 और सी = 3 \ x80 \ x00 \ x00 ... \ x02 और सी = 4 । जहाँ

ए = 1 और बी = 2 और सी = 3 - प्रारंभिक डेटा
\ x80 \ x00 \ x00 ... \ x02 - विशेष। इंडेंटेशन के लिए बाइट्स (हस्ताक्षर करने के लिए कुंजी) जब हैशिंग
& c = 4 - हमारा नया डेटा

एक ही पैरामीटर भेजते समय, उदाहरण के लिए, PHP, यह दूसरा लेगा। बस आपको आक्रमण करने की आवश्यकता है। पहले के बाद से हम प्रभावित नहीं कर सकते

ईविल जीता: आप साइन इन कर सकते हैं, साइन की कुंजी जाने बिना पैरामीटर बदल सकते हैं। और यहाँ एपीआई VK और Mail.RU के साथ काम करने के लिए प्रलेखन से एक अंश है

  Vkontakte: sig = md5 (name1 = value1name2 = value2api_secretret) 
 Mail.RU sig = md5 (uid + params + Private_key)

जैसा कि आप देख सकते हैं, कुंजी दाईं ओर है।

मैंने सिर्फ एक अनुरोध की चोरी का उल्लेख किया। व्यवहार में, यह लगता है की तुलना में थोड़ा आसान है (कहानी # 1, लेख )

असुरक्षित XML

मुझे लगता है कि हर कोई एक्सएमएल पर आ गया है, एक अनारकली डेटा टाइप।

 <recipe name="" preptime="5" cooktime="180"> <title> </title> <composition> <ingredient amount="3" unit=""></ingredient> </composition> ... </recipe>

लेकिन कम लोगों को एक्सएमएल में संस्थाओं का सामना करना पड़ा है

DTD उदाहरण:

 <!ENTITY writer "Donald Duck."> <!ENTITY copyright "Copyright W3Schools.">

XML उदाहरण:

 <author>&writer;©right;</author>

जो आपको कुछ परिभाषित करने की अनुमति देता है, और फिर इसका पुन: उपयोग करता है। उपरोक्त उदाहरण सिर्फ तार है।
और बाहरी XML संस्थाओं में भी बहुत कम लोग आए ...

 <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "file:///etc/passwd" >]> <foo>&xxe;</foo>

कुछ बाहरी, एक स्थानीय फ़ाइल, http के माध्यम से एक बाहरी फ़ाइल, आदि एक इकाई के रूप में कार्य कर सकती है। यानी यह मानक है। प्रारंभ में, मुझे अच्छे उद्देश्यों के लिए कल्पना की गई थी, उदाहरण के लिए, मुझे क्लाइंट को एक्सएमएल देने और दूसरे सर्वर से वर्तमान समय लेने की आवश्यकता है (HTTP के माध्यम से सुलभ एक और xml फ़ाइल)।

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

 <?xml version="1.0"?> <!DOCTYPE lolz [ <!ENTITY lol "lol"> <!ELEMENT lolz (#PCDATA)> <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;"> <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;"> <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;"> <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;"> <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;"> <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;"> <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;"> <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;"> <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;"> ]> <lolz>&lol9;</lolz>

और सर्वर को "डाला"। लब्बोलुआब यह है कि इकाई को इकाई को लगातार स्थानांतरित करना है।
यह याद रखने योग्य है कि यह न केवल सर्वर की समस्या हो सकती है, बल्कि क्लाइंट की भी हो सकती है (उदाहरण के लिए, क्लाइंट भ्रामक सॉफ्टवेयर XML को पार्स करता है)।
भेद्यता का उपयोग करने का सबसे महत्वपूर्ण उदाहरण नवंबर 2013 में एक फेसबुक हैक है , जो ओएस से कमांड के निष्पादन को जन्म दे सकता है।

संक्षेप में:

सबसे पहले, इंटरफ़ेस के सभी "दिलचस्प" सीमाओं का परीक्षण करें;
संपीड़न के साथ सौदा;
निकट से जेएस कॉलबेक देख रहा है;
क्रिप्टोग्राफी। यह न केवल लाइन विस्तार पर हमला हो सकता है, बल्कि सिर्फ एक कमजोर (उदाहरण के लिए, लघु) कुंजी, या किसी भी तरह से अनुमान लगाने योग्य है।
और आप वह डेटा भी पा सकते हैं जो केवल मोबाइल एप्लिकेशन एपीआई में वायर्ड है। वैसे, उन्हें सेवा http://hackapp.com के माध्यम से पाया जा सकता है;
एक्सएमएल - XXE
और कुछ भी।

प्रस्तुति:

डेमो वीडियो शा पैडिंग और XXE:

अपडेट 25/04/0214: रिपोर्ट रिकॉर्डिंग