🏞️ 🛣️ 🚣🏽 ब्राउज़र कैसे काम करते हैं - वेब एप्लिकेशन सुरक्षा के लिए एक परिचय 🚍 👨‍💻 🖊️

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

क्रोम और लिनेक्स

ब्राउज़र एक रेंडरिंग इंजन है । उसका काम एक वेब पेज को डाउनलोड करना और उसे मानव-पठनीय तरीके से प्रस्तुत करना है।

हालाँकि यह लगभग एक आपराधिक सरलीकरण है, लेकिन फिलहाल यह सब हमें जानना चाहिए।

उपयोगकर्ता ब्राउज़र इनपुट लाइन में पता दर्ज करता है।
ब्राउज़र इस URL पर "दस्तावेज़" डाउनलोड करता है और इसे प्रदर्शित करता है।

आप क्रोम, फ़ायरफ़ॉक्स, एज या सफारी जैसे सबसे लोकप्रिय ब्राउज़रों में से एक के साथ काम करने के आदी हो सकते हैं, लेकिन इसका मतलब यह नहीं है कि दुनिया में कोई अन्य ब्राउज़र नहीं हैं।

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

सामान्य तौर पर, हमें इस बात का अंदाजा होता है कि ब्राउज़र क्या करता है, लेकिन आइए उन क्रियाओं पर बारीकी से विचार करें जो ये सरल अनुप्रयोग हमारे लिए करते हैं।

ब्राउज़र क्या करता है?

संक्षेप में, ब्राउज़र मूल रूप से होते हैं

डीएनएस संकल्प
HTTP एक्सचेंज
प्रतिपादन
रीसेट करें और दोहराएँ

डीएनएस संकल्प

यह प्रक्रिया ब्राउज़र को यह जानने में मदद करती है कि किसी उपयोगकर्ता को URL में प्रवेश करते समय इसे किस सर्वर से कनेक्ट करना चाहिए। ब्राउज़र DNS सर्वर से संपर्क करता है और पता लगाता है कि google.com अंकों का सेट 216.58.207.110 से मेल खाता है - आईपी पता जिससे ब्राउज़र कनेक्ट हो सकता है।

HTTP एक्सचेंज

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

HTTP केवल नेटवर्क पर संचार के लिए सबसे लोकप्रिय प्रोटोकॉल का नाम है, और सर्वरों के साथ संचार करते समय ब्राउज़र ज्यादातर HTTP चुनते हैं। HTTP एक्सचेंज का तात्पर्य है कि क्लाइंट (हमारा ब्राउज़र) एक अनुरोध भेजता है, और सर्वर एक प्रतिक्रिया भेजता है।

उदाहरण के लिए, ब्राउज़र google.com की सेवा करने वाले सर्वर से सफलतापूर्वक कनेक्ट होने के बाद, यह एक अनुरोध भेजेगा जो इस तरह दिखता है

GET / HTTP/1.1
Host: google.com
Accept

आइए प्रश्न पंक्ति को पंक्ति द्वारा पार्स करें:

GET / HTTP / 1.1 : इस पहली पंक्ति के साथ, ब्राउज़र सर्वर को दस्तावेज़ को / के स्थान से पुनः प्राप्त करने के लिए कहता है, फिर यह जोड़ते हुए कि शेष अनुरोध HTTP / 1.1 के माध्यम से होगा (या आप संस्करण 1.0 या 2 का उपयोग भी कर सकते हैं)
होस्ट: google.com : यह HTTP / 1.1 प्रोटोकॉल के लिए आवश्यक केवल HTTP हेडर है । चूंकि सर्वर कई डोमेन (google.com, google.co.uk , इत्यादि) की सेवा कर सकता है , यहाँ क्लाइंट का उल्लेख है कि अनुरोध इस विशेष होस्ट के लिए था।
स्वीकार करें: * / * : एक वैकल्पिक हेडर जिसमें ब्राउज़र सर्वर को बताता है कि वह किसी भी प्रतिक्रिया को स्वीकार करेगा। सर्वर में JSON, XML या HTML में एक संसाधन उपलब्ध हो सकता है, इसलिए यह किसी भी प्रारूप को चुन सकता है जो इसे पसंद करता है

क्लाइंट के रूप में कार्य करने वाले ब्राउज़र द्वारा अपना अनुरोध पूरा करने के बाद, सर्वर एक प्रतिक्रिया भेजेगा। यहाँ जवाब है:

 HTTP/1.1 200 OK Cache-Control: private, max-age=0 Content-Type: text/html; charset=ISO-8859-1 Server: gws X-XSS-Protection: 1; mode=block X-Frame-Options: SAMEORIGIN Set-Cookie: NID=1234; expires=Fri, 18-Jan-2019 18:25:04 GMT; path=/; domain=.google.com; HttpOnly <!doctype html><html"> ... ... </html>

वाह, इस बार काफी जानकारी है जिसे पचाने की जरूरत है। सर्वर हमें बताता है कि अनुरोध सफल था ( 200 ठीक है ) और प्रतिक्रिया के लिए कई हेडर जोड़ता है, उदाहरण के लिए, आप पता लगा सकते हैं कि किस सर्वर ने हमारे अनुरोध को संसाधित किया ( सर्वर: gws ), इस उत्तर के लिए X- XSS- सुरक्षा नीति क्या है, और इसी तरह आगे और पसंद है।

अभी आपको उत्तर में प्रत्येक पंक्ति को समझने की आवश्यकता नहीं है। बाद में प्रकाशनों की इस श्रृंखला में हम HTTP प्रोटोकॉल, इसके हेडर इत्यादि के बारे में अधिक बात करेंगे।

फिलहाल, आपको बस यह जानना होगा कि क्लाइंट और सर्वर सूचनाओं का आदान-प्रदान करते हैं और वे इसे HTTP प्रोटोकॉल के माध्यम से करते हैं।

प्रतिपादन

अंतिम लेकिन कम से कम, प्रतिपादन की प्रक्रिया चल रही है। ब्राउज़र कितना अच्छा है अगर केवल एक चीज जो उपयोगकर्ता को दिखाता है वह मज़ेदार पात्रों की सूची है?

 <!doctype html><html"> ... ... </html>

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

यह ठीक वह क्षण है जहां ब्राउज़र वास्तव में अपनी क्षमताओं को दिखाता है। यह HTML कोड को पढ़ता है और विश्लेषण करता है, मार्कअप में शामिल अतिरिक्त संसाधनों को लोड करता है (उदाहरण के लिए, लोड करने के लिए जावास्क्रिप्ट फ़ाइलों या सीएसएस दस्तावेजों को वहां निर्दिष्ट किया जा सकता है) और उन्हें जल्द से जल्द उपयोगकर्ता को प्रस्तुत करता है।

एक बार फिर, अंतिम परिणाम वही होना चाहिए जो औसत वासियों के लिए सुलभ हो।

यदि आपको ब्राउज़र के एड्रेस बार में एंटर की को दबाने पर वास्तव में क्या होता है, इसके बारे में अधिक विस्तृत विवरण की आवश्यकता है, तो मैं इस प्रक्रिया को समझने वाले तंत्रों को समझाने के लिए एक बहुत ही सावधानी से किया गया लेख "क्या होता है ..." पढ़ता हूं।

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

विक्रेताओं

4 सबसे लोकप्रिय ब्राउज़र विभिन्न विक्रेताओं के हैं:

Google Chrome
मोज़िला द्वारा फ़ायरफ़ॉक्स
Apple सफारी
माइक्रोसॉफ्ट एज

बाजार में पैठ बढ़ाने के लिए एक-दूसरे से लड़ने के अलावा, विक्रेता वेब मानकों को बेहतर बनाने के लिए एक-दूसरे के साथ बातचीत भी करते हैं, जो ब्राउज़रों के लिए "न्यूनतम आवश्यकताओं" का एक प्रकार है।

W3C मानकों के विकास की आधारशिला है, लेकिन ब्राउज़र अक्सर अपने स्वयं के कार्यों को विकसित करते हैं, जो अंततः वेब मानकों में बदल जाते हैं, और सुरक्षा कोई अपवाद नहीं है।

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

यह हमें दो बातें बताता है:

सफारी अपने उपयोगकर्ताओं की सुरक्षा के बारे में पर्याप्त देखभाल नहीं करता है (सिर्फ मजाक कर रहे हैं: सफारी 12 में सेमसाइट कुकीज़ उपलब्ध होंगी, जो कि इस लेख को पढ़ने से पहले ही जारी हो सकती हैं)
एक ब्राउज़र में कमजोरियों को ठीक करने का मतलब यह नहीं है कि आपके सभी उपयोगकर्ता सुरक्षित हैं

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

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

हमारे मामले में, अगर हम तय करते हैं कि हम केवल समरस कुकीज़ के साथ सीएसआरएफ हमलों को बेअसर करेंगे, तो हमें पता होना चाहिए कि हम अपने सफारी उपयोगकर्ताओं को जोखिम में डाल रहे हैं। और हमारे उपयोगकर्ताओं को भी यह जानना चाहिए।

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

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

विक्रेता या मानक बग?

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

विक्रेता आमतौर पर सुरक्षा शोधकर्ताओं को पुरस्कार प्रदान करते हैं (जिसे बग बाउंटी के रूप में भी जाना जाता है) जो स्वयं ब्राउज़र में कमजोरियों की तलाश कर रहे हैं। ये त्रुटियां आपके वेब एप्लिकेशन से संबंधित नहीं हैं, लेकिन ब्राउज़र स्वतंत्र रूप से सुरक्षा का प्रबंधन कैसे करता है।

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

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

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

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

डेवलपर ब्राउज़र

अब तक, हमें एक बहुत ही सरल, बल्कि महत्वपूर्ण अवधारणा को समझना चाहिए: ब्राउज़र केवल "औसत" इंटरनेट उपयोगकर्ता के लिए बनाए गए HTTP क्लाइंट हैं।

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

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

 $ curl -I localhost:8080 HTTP/1.1 200 OK server: ecstatic-2.2.1 Content-Type: text/html etag: "23724049-4096-"2018-07-20T11:20:35.526Z"" last-modified: Fri, 20 Jul 2018 11:20:35 GMT cache-control: max-age=3600 Date: Fri, 20 Jul 2018 11:21:02 GMT Connection: keep-alive

उपरोक्त उदाहरण में, हमने स्थानीयहोस्ट पर एक दस्तावेज़ का अनुरोध किया : 8080 / , और स्थानीय सर्वर ने सफलतापूर्वक इसका उत्तर दिया।

कमांड लाइन पर प्रतिक्रिया निकाय को उतारने के बजाय, हमने -I ध्वज का उपयोग किया, जो बताता है कि हम केवल प्रतिक्रिया हेडर में रुचि रखते हैं। इसे एक कदम आगे बढ़ाते हुए, हम cURL कमांड को थोड़ी और जानकारी दे सकते हैं, जिसमें वह वास्तविक अनुरोध भी शामिल है जिसे वह क्रियान्वित करता है, ताकि हम इस HTTP एक्सचेंज के सभी बेहतर तरीके से जांच कर सकें। विकल्प जो हमें उपयोग करना चाहिए: -v ( क्रिया , अधिक):

 $ curl -I -v localhost:8080 * Rebuilt URL to: localhost:8080/ * Trying 127.0.0.1... * Connected to localhost (127.0.0.1) port 8080 (#0) > HEAD / HTTP/1.1 > Host: localhost:8080 > User-Agent: curl/7.47.0 > Accept: */* > < HTTP/1.1 200 OK HTTP/1.1 200 OK < server: ecstatic-2.2.1 server: ecstatic-2.2.1 < Content-Type: text/html Content-Type: text/html < etag: "23724049-4096-"2018-07-20T11:20:35.526Z"" etag: "23724049-4096-"2018-07-20T11:20:35.526Z"" < last-modified: Fri, 20 Jul 2018 11:20:35 GMT last-modified: Fri, 20 Jul 2018 11:20:35 GMT < cache-control: max-age=3600 cache-control: max-age=3600 < Date: Fri, 20 Jul 2018 11:25:55 GMT Date: Fri, 20 Jul 2018 11:25:55 GMT < Connection: keep-alive Connection: keep-alive < * Connection #0 to host localhost left intact

उसी जानकारी के बारे में लोकप्रिय ब्राउज़र में उनके DevTools के माध्यम से उपलब्ध है।

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

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

HTTP डाइविंग

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

अगले लेख में, हम HTTP प्रोटोकॉल पर करीब से नज़र रखेंगे और समझने की कोशिश करेंगे कि HTTP एक्सचेंज की सुरक्षा सुनिश्चित करने के लिए हमें क्या उपाय करने चाहिए।

अनुवाद को EDISON सॉफ़्टवेयर , बड़े ग्राहकों के लिए एक पेशेवर वेबसाइट विकास कंपनी , साथ ही C # और .NET वेब विकास द्वारा समर्थित किया गया था।

ब्राउज़र कैसे काम करते हैं - वेब एप्लिकेशन सुरक्षा के लिए एक परिचय