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

HTML5 के हमले

कॉर्स पर हमले (क्रॉस ओरिजिनल रिसोर्स शेयरिंग) - रिवर्स शेलकोड प्राप्त करना

उच्च-गुणवत्ता वाली साइट बनाने के लिए डेवलपर्स की बढ़ती जरूरतों को पूरा करने के लिए, एचटीएमएल 5 ने कुछ सीमाओं पर ध्यान दिया, जो पहले एसओपी (एक ही मूल नीति) की अवधारणा द्वारा घोषित किया गया था। अवधारणा के सरल नियम हैं: साइट पर चलने वाली लिपियों में इस साइट के तरीकों और गुणों तक पहुंच है, लेकिन यह किसी अन्य साइट के पृष्ठों पर नहीं है (एसओपी जैसा कि यह एक व्यापक अलग विषय है, हम अनुशंसा करते हैं कि आप इसे आगे पढ़ने से पहले पढ़ें)।



HTML5 अब इन प्रतिबंधों का उल्लंघन करता है।



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



इसलिए, जब xyz.com आपको डेटा प्राप्त करने की अनुमति देता है, तो abc.com xyz.com को एक अजाक्स अनुरोध कर सकता है और उत्तर पढ़ सकता है। इस सुविधा का उपयोग क्रॉस-डोमेन कॉल के साथ HTTP ट्रैफ़िक को टनल करने के लिए किया जाता है।



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

एक महत्वपूर्ण सवाल: हमलावर के लिए पीड़ित का सत्र कैसे प्रदर्शित किया जाता है?

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

CSRF टोकन की चोरी

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



नामक एक अतिरिक्त HTTP हेडर को कोर के लिए जोड़ा जाना चाहिए। withCredentials



विशेषता के मान को true



बदलने से आप अनुरोध के साथ-साथ कुकीज़ चोरी कर सकते हैं। इस मामले में सर्वर हेडर Access-Control-Allow-Origin: *



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



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

आंतरिक सर्वर तक पहुंच

कई वाणिज्यिक संगठनों में आंतरिक साइटें होती हैं जिनका उपयोग आंतरिक व्यावसायिक आवश्यकताओं के लिए किया जाता है। वास्तव में, ये इंट्रानेट अनुप्रयोग हैं जो इंटरनेट के माध्यम से सुलभ नहीं हैं। चूंकि ऐसे कई अनुप्रयोग हैं, उन्हें किसी न किसी तरह एक दूसरे के साथ बातचीत करनी चाहिए। और, जल्दी में, अधिकांश डेवलपर्स केवल Access-Control-Allow-Origin: *



जोड़ते हैं Access-Control-Allow-Origin: *



हेडर जिसे हम पहले से जानते हैं Access-Control-Allow-Origin: *



और कॉर्स शामिल हैं। इसका उपयोग एक हमलावर द्वारा किया जा सकता है, जो सोशल इंजीनियरिंग का उपयोग करके किसी कंपनी कर्मचारी को लिंक पर क्लिक करने के लिए मजबूर कर सकता है, जिसके बाद हमलावर बहुत आसानी से सामग्री तक पहुंच पाता है।



एक प्रकार का "स्टेप बाय स्टेप इंस्ट्रक्शन":

1. कंपनी का एक कर्मचारी ऐसी साइट पर लॉग इन करता है जो इंटरनेट के माध्यम से सुलभ नहीं है।
2. इंट्रानेट सर्वर हेडिंग Access-Control-Allow-Origin: *
   
   
   
   (क्यों? यह सर्वर डेटा का उपयोग करने के लिए इंट्रानेट पर अन्य साइटों को अनुमति देना चाहता है) के साथ एक अनुरोध देता है।
3. एक कर्मचारी एक ईमेल में हमलावर से एक लिंक प्राप्त करता है और उस पर क्लिक करता है।
4. साइट पूरी तरह से सामान्य दिखती है, कर्मचारी को कुछ भी संदिग्ध नहीं दिखता है। लेकिन साइट में जावास्क्रिप्ट कोड है जो कर्मचारी के ब्राउज़र में चलता है।
5. पृष्ठभूमि में स्क्रिप्ट एक XMLHttpRequest अनुरोध भेजता है और यह अनुरोध भी प्राप्त करता है (क्यों? क्योंकि सर्वर हेडर में Access-Control-Allow-Origin: *
   
   
   
   ।
6. जावास्क्रिप्ट अनुरोध को पार्स करता है और इसे हमलावर के सर्वर पर भेज देता है (आसानी से XMLHttpRequest के माध्यम से किया जाता है)।
7. हमलावर कंपनी की आंतरिक वेबसाइट पर संग्रहीत डेटा को स्वीकार करता है।

नई XSS HTML5 वैक्टर

डेवलपर्स हमेशा XSS हमलों को रोकने के लिए अपने स्वयं के कस्टम फ़िल्टर बनाना पसंद करते हैं। उनमें से ज्यादातर <img, <script



आदि जैसे वर्णों को ब्लैकलिस्ट कर दिया गया है। HTML5 ऑडियो / वीडियो के मल्टीमीडिया और गतिशील लोडिंग का समर्थन करने के लिए कई नए टैग पेश करता है। नए टैग, विशेषताएँ और कार्यक्रम, उचित परिश्रम के साथ, XSS फ़िल्टर को दरकिनार करने के लिए संभावित वैक्टर बन सकते हैं। नीचे कई संभावित वैक्टर हैं जिन्हें विभिन्न संसाधनों से एकत्र किया गया है:



List of XSS vectors for HTML5





<video><source onerror="javascript:alert(1)">





<video onerror="javascript:alert(1)"><source>





<audio onerror="javascript:alert(1)"><source>





<input autofocus onfocus=alert(1)>





<select autofocus onfocus=alert(1)>





<textarea autofocus onfocus=alert(1)>





<keygen autofocus onfocus=alert(1)>





<button form=test onformchange=alert(2)>X





<form><button formaction="javascript:alert(1)">

ऑफ़लाइन वेब अनुप्रयोग कैश विषाक्तता

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



आइए देखें कि एक हमलावर यह कैसे कर सकता है:

1. उपयोगकर्ता एक शॉपिंग सेंटर में असुरक्षित वाई-फाई नेटवर्क से जुड़ता है।
2. एक उपयोगकर्ता एक यादृच्छिक साइट पर जाता है।
3. हमलावर एक पेज के साथ अपने अनुरोध का जवाब देता है जिसमें एक छिपा हुआ IFrame होता है, जिसे उपयोगकर्ता से अपने फेसबुक लॉगिन को इकट्ठा करने के लिए डिज़ाइन किया गया है।
4. उपयोगकर्ता का ब्राउज़र स्वचालित रूप से एक प्राधिकरण अनुरोध भेजता है।
5. इस समय से, नेटवर्क को हमलावर द्वारा नियंत्रित किया जाता है, वह उपयोगकर्ता को केवल एक अतिरिक्त कोड के साथ फेसबुक पर लॉगिन पृष्ठ जैसा दिखने वाला पृष्ठ देता है।
6. यह कोड हमलावर की साइट पर प्रवेश की सूचना भेजेगा। पृष्ठ में उपयोगकर्ता के सिस्टम पर इसे कैश करने के लिए एक कमांड भी है। इसलिए, इस बिंदु तक, वस्तुतः कुछ भी नहीं हुआ - सिवाय इसके कि उपयोगकर्ता के सिस्टम में प्राधिकरण पृष्ठ कैश किया गया था।
7. अब, एक या दो दिनों के बाद, पीड़ित घर या कार्यालय में सुरक्षित नेटवर्क से जुड़ जाता है और पता बार में साइट पर एक लिंक दर्ज करके फेसबुक पर लॉग इन करने की कोशिश करता है।
8. ब्राउज़र कैश से नकली प्राधिकरण पेज लोड करता है।
9. जब कोई उपयोगकर्ता एक्सेस करता है, तो उन्हें हमलावर को स्थानांतरित कर दिया जाता है क्योंकि कैश्ड पृष्ठ को इस तरह प्रोग्राम किया गया है।

निष्कर्ष

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



एक बोनस के रूप में - हमारे मुख्य सूचना अधिवक्ता, अलेक्सी फेडोरोविच द्वारा एक आधिकारिक टिप्पणी:

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



और CSRF, XSS, SQLinj, आदि। वे साइटों पर तभी खोजना शुरू करते हैं जब कोई व्यक्ति दूसरी तरफ अपने सिर के साथ बैठता है, और सोशल इंजीनियरिंग मदद नहीं करता है + जब हमलावर के पास अपनी योजना को पूरा करने के लिए पर्याप्त समय और तकनीकी ज्ञान होता है। यदि आप हैक करना चाहते हैं, तो हैक करें, कोई विकल्प नहीं है। आप पहले स्तर पर केवल स्कूली बच्चों के प्रवेश की सीमा को कम कर सकते हैं और स्कूली बच्चों को फ़िल्टर कर सकते हैं। सौभाग्य है।

Onextrapixel पर मूल लेख ।