👾 👩🏽‍⚖️ 🛵 HTML5 - सुरक्षा के चश्मे के माध्यम से एक नज़र 👩‍🔧 🍫 🌏

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

HTML5: एक संक्षिप्त सारांश

कई शायद पहले से ही पृष्ठों पर वीडियो प्रौद्योगिकी एम्बेड करने के लिए कोडेक्स के टकराव के बारे में सुना है। <वीडियो> टैग का उपयोग करते हुए, यह माना जाता है, यदि प्रतिस्थापित नहीं किया गया है, तो कम से कम गंभीरता से एडोब फ्लैश के साथ प्रतिस्पर्धा करें। एचटीएमएल 5 के बारे में एक बातचीत शुरू करते हुए, इस नवाचार को अक्सर याद किया जाता है। अभी भी: Youtube और Vimeo जैसे वीडियो होस्टिंग दिग्गज पहले ही नई तकनीक के लिए समर्थन लागू कर चुके हैं। और एप्पल के मोबाइल उत्पाद, जिसमें फ्लैश के लिए कोई आधिकारिक समर्थन नहीं था और, सबसे अधिक संभावना है, पहले से ही सक्रिय रूप से इसका उपयोग नहीं कर रहे हैं। तो <video> टैग का उपयोग करके पेज में डाला गया वीडियो स्ट्रीमिंग करना कुछ ऐसा है जिसे आप अभी महसूस कर सकते हैं।

एचटीएमएल 5 की पेशकशों को ध्यान में रखते हुए अन्य "गुडीज़" में शामिल हैं:

"ऑफ़लाइन - ब्राउज़र में डेटा स्टोरेज - वेब स्टोरेज, स्थानीय डेटाबेस;
कैनवास 2 डी एपीआई;
क्रॉस-डोमेन इंटरैक्शन (क्रॉस डोमेन मैसेजिंग);
"ड्रैग-एंड-ड्रॉप" -functionality;
वेब सॉकेट्स का उपयोग करके नेटवर्क के साथ काम करें;
स्थान का निर्धारण (जियोलोकेशन)।

वेब संग्रहण - कुकीज़ के लिए एक शक्तिशाली विकल्प

इस तथ्य में कोई आश्चर्य की बात नहीं है कि वेब एप्लिकेशन (जैसे जीमेल) के युग के आगमन के साथ वेब ब्राउज़र की तरफ डेटा सरणियों को संग्रहीत करने की आवश्यकता थी। इसका एक आकर्षक उदाहरण यह है कि इस तरह के वेब अनुप्रयोगों के साथ ऑफ़लाइन काम करना संभव है। Google ने अपनी Google Gears तकनीक के साथ शानदार प्रगति की है। उनकी सीमाओं के साथ कुकीज़ (विशेष रूप से 4K आकार में) और उनके साथ काम करने के तरीके स्पष्ट रूप से ऐसे कार्यों के लिए एक अनुचित और पुराना समाधान है। इस कारण से, कुकीज़ के समान एक नया तंत्र विकसित करने का निर्णय लिया गया, लेकिन उनकी कमियों से रहित। वे WebStorage तकनीक बन गए। 2 शब्दों में, HTML5 की बदौलत अब हमारे पास "कुंजी-मूल्य" प्रकार का एक रिपॉजिटरी (या दो रिपॉजिटरी) है जो कि वेब ब्राउजर की तरफ से जावास्क्रिप्ट के उपयोग के साथ है।

लोकलस्टोरेज - दीर्घकालिक डेटा भंडारण के लिए;
sessionStorage - सत्र उपयोग के लिए।

तंत्र लगभग सभी वेब ब्राउज़रों द्वारा समर्थित है: फ़ायरफ़ॉक्स 3.5, सफारी 4.0, IE8, Google क्रोम, ओपेरा 10.50। निम्नलिखित एक वेब पेज पर आगंतुकों को ट्रैक करने के लिए स्थानीय वेब स्टोरेज का उपयोग करने का एक विशिष्ट उदाहरण है।

<p>    <span id="count">- </span> .</p> <script> if (!localStorage.pageLoadCount)     localStorage.pageLoadCount = 0; localStorage.pageLoadCount += 1; document.getElementById('count').textContent = localStorage.pageLoadCount; </script>

आइए इस तकनीक के सुरक्षा पक्ष को देखें। जेएस एपीआई की कई चीजों की तरह, एचटीएमएल 5 में एचटीएमएल 5 ओरिजिनल मैकेनिज्म का पालन किया जाता है, यानी डेटा एक ही डोमेन के सभी पेजों के लिए उपलब्ध है, प्रोटोकॉल और पोर्ट नंबर (उदाहरण के लिए, example.com : 80) को ध्यान में रखते हुए। जैसा कि ऊपर उल्लेख किया गया है, वेब स्टोरेज को 4K सीमा से मुक्त किया गया है और विनिर्देश 5 एमबी प्रति डोमेन का उपयोग करने की सलाह देता है। वास्तव में, फ़ायरफ़ॉक्स, सफारी, ओपेरा, गूगल क्रोम के लिए, IE - 10MB के लिए सीमा 5 एमबी है। लेकिन सबसे दिलचस्प बात यह है कि कोटा में ही नहीं है, लेकिन ब्राउज़र उन्हें कैसे उपयोग करता है।

उदाहरण के लिए, फ़ायरफ़ॉक्स की सीमा .example.com है। इस प्रकार, (और यहाँ ध्यान!) एक उप डोमेन पूरी तरह से डोमेन के लिए आरक्षित जगह ले सकता है:

 // Firefox 3.6.8 for (var i = 0; i < 100; i++) { try { localStorage.setItem(rand(1, 10000).toString() + 'foo'+i.toString(), 'AA...AA'+i.toString());    }    catch (e) {    alert(i.toString()+'|'+e);break;    } }

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

चलिए आगे बढ़ते हैं। Google Chrome डोमेन प्रतिबंधों के बारे में अधिक प्रतिबंधक होने की कोशिश कर रहा है और सीमा की गणना में डोमेन को ध्यान में रखा गया है। लेकिन उसी समय, Google Chrome में, आप वाइल्डकार्ड-डोमेन पर iframes का एक समूह बनाते हुए, पूरी तरह से * सभी * अपना * डिस्क स्थान ले सकते हैं, जिसमें आप 5MB उठा सकते हैं!

 for(var i=0; i<10; i++) { var iframe = document.createElement('iframe'); iframe.src = 'http://'+randomString()+'.example.com/ddos.html'; document.body.appendChild(iframe); }

यह बग अभी तक ठीक नहीं किया गया है। अन्य बातों के अलावा, पुरानी समस्याओं को कुकीज़ से एक नए प्रकार के भंडारण में स्थानांतरित कर दिया गया है, जिनमें शामिल हैं:

उपयोगकर्ता ट्रैकिंग
डीएनएस स्पूफिंग हमले।

एक्सेस प्रतिबंधों की प्रकृति (प्रोटोकॉल + डोमेन + पोर्ट) के कारण, हमें भी उदाहरणों का उपयोग करके सेवाओं की मेजबानी करने में समस्याएँ हैं। उदाहरण के लिए «क्रूजर / सिस्टम, जो कि कुकीज़ के साथ नहीं था। हां, लंबे समय से हमने जीवन में एक समान मेजबानी नहीं देखी है, लेकिन अचानक!

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

वेब ब्राउज़र में SQL इंजेक्शन

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

 function showById() { var pos = document.URL.indexOf("book=")+5; var bookId = document.URL.substring(pos,document.URL.length); var author = ''; var title = ''; db.transaction(function(tx) { tx.executeSql("SELECT * FROM books WHERE id = " + bookId, [], function(tx, result){ if ( result.rows.length > 0) { document.getElementById('bookAuthor').textContent =result.rows.item(0)['author']; document.getElementById('bookTitle').textContent = result.rows.item(0)['title']; } }, function(tx, error){}); }); }

और अगर आप निम्नलिखित जैसे किसी पते पर जाते हैं तो क्या होगा? target.com/html5/websql.html?book=1/**/AND/**/1=2

DOMXSS + SQL इंजेक्शन प्राप्त करें! यह अफ़सोस की बात है कि इस भेद्यता का उपयोग करने के लिए संभावनाएं काफी कम हैं (वैसे, ऑक्सोड ने SQLite में इंजेक्शन के बारे में एक अच्छा लेख लिखा था, नीचे दिए गए लिंक की तलाश करें)। विशेष रूप से यह देखते हुए कि ओपेरा और क्रोम दोनों अलग-अलग फाइलों में साइटों के लिए स्क्लाइट-बेस स्टोर करते हैं। बेशक, लेखकों ने अवसर प्रदान किया और सुझाव दिया कि आप SQL क्वेरीज़ को "सुरक्षित" निष्पादित करें। लेकिन देखते हैं कि डेवलपर्स उनकी सलाह का पालन कैसे करेंगे। अन्य बातों के अलावा, वेब-एसक्यूएल डेटाबेसों को लोकलस्टोरेज और सेशनस्टोरेज जैसी ही समस्याओं की विशेषता है।

नए टैग और विशेषताएँ - IDS और WAF हस्ताक्षर डेटाबेस को अपडेट करना

HTML5 ने नए टैग और विशेषताएँ जोड़ीं - इसका मतलब है कि आपके WAF नियमों / हस्ताक्षरों को अपडेट करने का समय है (हमने अपने वेब अनुप्रयोगों के लिए फ़ायरवॉल के बारे में विस्तार से लिखा है " # 10/2009] अंक में " रक्षा दीवारों को जलाना " ]]। नए मार्कअप तत्वों में से एक ऑटोफोकस विशेषता है। यह एक लंबे समय से प्रतीक्षित विशेषता है, क्योंकि पहले, लगभग हर समय, मुझे जावास्क्रिप्ट ऑटोफोकस प्रसंस्करण करना पड़ता था। और HTML5 में, आखिरकार, उन्होंने एक विशिष्ट पाठ क्षेत्र पर ऑटोफोकसिंग के लिए एक विशेषता जोड़ी। लेकिन आइए इस विशेषता का उपयोग करके कोड को स्वचालित रूप से निष्पादित करने के तरीके के रूप में कल्पना करें:

 <input onfocus=alert(1) autofocus> <input onblur=write(1) autofocus><input autofocus>

यह तकनीक काम में आ सकती है, उदाहरण के लिए, जब कोण कोष्ठक को फ़िल्टर किया जाता है। <Video> टैग, जिसे हमने आज पहले ही उल्लेख किया है, मल्टीमीडिया कार्यों के अलावा, जावास्क्रिप्ट कोड को निष्पादित करने की संभावना (जो सोचा होगा :) पोस्टर विशेषता के माध्यम से:

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

<वीडियो> के "गुण" में वेब ब्राउज़र की सही पहचान करने की क्षमता शामिल है। यह Metasploit Decloak गुल्लक में एक और चाल होगी। नए तत्वों वाले उदाहरणों को जारी रखा जा सकता है। आप कैसे पसंद करते हैं, उदाहरण के लिए, onscroll टैग हैंडलर और उसी ऑटोफोकस विशेषता का उपयोग करके जावास्क्रिप्ट स्व-निष्पादन?

 <body onscroll=alert(1)><br><br><br>...<br><input autofocus>

या यहाँ एक और चाल है, हालांकि यह केवल ओपेरा के नवीनतम संस्करणों में अब तक काम करता है:

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

नए प्रकार के फॉर्म फ़ील्ड

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

  <style> [required] { background-color: green; } :invalid { background-color: red; } </style> … <input name="email" type="email"/>

सुरक्षा की दृष्टि से जो महत्वपूर्ण है वह यह है कि क्षेत्र स्वयं को मान्य करेंगे!

फॉर्म मान्यता

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

क्रॉस-दस्तावेज़ संदेश

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

गौर कीजिए कि यह तंत्र कैसे काम करता है। साइट को (या उसके क्लाइंट भाग को) उदाहरण दें ।.com/exex.html foo.com/iframe.html के साथ सहभागिता करना चाहता है, जो कि iframe में लोड है। इस स्थिति में, संदेश प्राप्तकर्ता foo.com पर आरंभीकृत होता है। संदेश प्राप्तकर्ता कोड foo.com पर:

 <div id="msg">...</div><script> window.addEventListener('message', receiver, false); function receiver(e) { if (e.origin != 'http://example.com') { return; } document.getElementById('msg').innerHTML = 'Origin: ' + e.origin + ' From: ' + e.source + ' Data: ' + e.data; } </script>

स्पष्ट प्रेषक सत्यापन (e.origin) पर ध्यान दें। लेकिन इस तरह के एक चेक के साथ, किसी को प्राप्त डेटा को मान्य करने के लिए नहीं भूलना चाहिए, यदि उदाहरण के लिए, एक्सएसएस को अचानक एक विश्वसनीय प्रेषक पर पता चला है। और दस्तावेज़ (ग्राहक पक्ष) a.example.com में हम प्राप्तकर्ता को एक संदेश भेजते हैं:

 function postMsg() { var o = document.getElementById('ifra'); o.contentWindow.postMessage(document.getElementById('msg').value, 'http://foo.com/'); return false; }

यहां लक्ष्यऑरिजिन संदेश के गंतव्य को स्पष्ट रूप से निर्दिष्ट करना महत्वपूर्ण है। भले ही मानक "*" निर्दिष्ट करने की क्षमता प्रदान करता है और इस तरह किसी भी पते पर संदेश भेजने की अनुमति देता है। IMHO, इस तंत्र में मुख्य जोखिम संदेश के सुरक्षित कार्यान्वयन की प्रारंभिक जटिलता है। डेवलपर को स्पष्ट रूप से समझने की आवश्यकता है कि वह क्या कर रहा है। प्रेषक सत्यापन के बारे में भूलने का एक प्राथमिक जोखिम है। आने वाले डेटा का अंधा उपयोग खतरनाक हो सकता है, जिससे डोम-आधारित XSS का अध: पतन हो सकता है।

स्थिति

वर्तमान स्थान गोपनीयता ("गोपनीयता") का एक महत्वपूर्ण पहलू है, इसलिए, बड़ी सावधानी से इसके निर्धारण के लिए तंत्र को लागू करना आवश्यक है। इस पहलू को W3C विनिर्देशन के "सुरक्षा और गोपनीयता के विचार" खंड में वर्णित किया गया है। संक्षेप में, विनिर्देश बताता है कि स्थान को आगंतुक द्वारा स्पष्ट रूप से अधिकृत किया जाना चाहिए। तकनीकी रूप से, इसे नेविगेटर.ओजोलोकेशन ऑब्जेक्ट की एक विशेष विधि कहकर लागू किया जाता है

 if (navigator.geolocation) { navigator.geolocation.getCurrentPosition(function(position) { var lat = position.coords.latitude; var lng = position.coords.longitude; var options = {position: new google.maps.LatLng(lat, lng) } var marker = new google.maps.Marker(options); marker.setMap(map); }); }

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

स्थान निर्धारित करने की प्रक्रिया में, वेब ब्राउज़र आपके आईपी पते, निकटतम वायरलेस एक्सेस पॉइंट और संभवतः अन्य समान जानकारी (उदाहरण के लिए, Google द्वारा निर्दिष्ट क्लाइंट के लिए एक यादृच्छिक पहचानकर्ता, जो 2 सप्ताह के बाद समाप्त हो जाता है) के बारे में डेटा एकत्र करता है और सभी को स्थान सेवा में भेजता है। और अब, पागल भाइयों, अनुमान लगाएं कि बड़ी संख्या में Google सेवा (Google Chrome, Firefox, Opera) में यह सेवा कौन होगी! सही है, Google स्थान सेवाएँ! हम निश्चित रूप से, वादा कर रहे हैं कि:

"न तो मोज़िला और न ही Google कभी भी आपकी पहचान करने के लिए Google स्थान सेवाओं द्वारा एकत्रित की गई जानकारी का उपयोग करेगा और कभी भी आपकी जासूसी नहीं करेगा।"

लेकिन हम जानते हैं कि किसी पर भरोसा नहीं किया जा सकता है! :) आपको उन दुखद परिणामों पर भी ध्यान देना चाहिए जो XSS समन्वय स्थापित करने की अनुमति दी गई साइट पर लाएंगे।

निष्कर्ष में

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

उपयोगी लिंक:

हैकर पत्रिका, दिसंबर (12) 143

तारास "ऑक्सडेफ" इवाशेंको

दिमित्री "आविष्कार" सिदोरोव

हैकर की सदस्यता लें

HTML5 - सुरक्षा के चश्मे के माध्यम से एक नज़र