वेब सुरक्षा: HTTP का परिचय

HTTP एक ख़ूबसूरत चीज़ है: एक प्रोटोकॉल जो बिना किसी बदलाव के 20 वर्षों से अधिक समय से मौजूद है।



यह वेब सुरक्षा श्रृंखला का भाग दो है: भाग एक था कि ब्राउज़र कैसे काम करते हैं ।

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

यह समझना कि HTTP कैसे काम करता है, हम ग्राहकों और सर्वरों के बीच संचार को कैसे सुरक्षित कर सकते हैं, और सुरक्षा संबंधी कौन-सी सुविधाएँ प्रोटोकॉल प्रदान करती हैं, यह हमारी सुरक्षा को बेहतर बनाने की दिशा में पहला कदम है।

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

उनके बीच के महत्वपूर्ण अंतर को बहुत सरल सादृश्य द्वारा समझाया जा सकता है: 20 साल पहले, लोग अपने रिश्तेदारों की देखभाल उसी तरह करते थे जैसे वे अब करते हैं, भले ही जिस तरह से उन्होंने बातचीत की है वह काफी बदल गया है। हमारे माता-पिता को अपनी बहन को पकड़ने और अपने परिवार के साथ कुछ समय बिताने के लिए अपनी कार और ड्राइव करने की संभावना है।

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

HTTP अलग नहीं है: प्रोटोकॉल के शब्दार्थ बहुत ज्यादा नहीं बदले हैं, जबकि क्लाइंट और सर्वर के इंटरैक्शन के तकनीकी कार्यान्वयन को वर्षों से अनुकूलित किया गया है। यदि आप 1996 HTTP अनुरोध को देखते हैं, तो यह पिछले लेख में हमारे द्वारा देखे गए लोगों के समान होगा, हालाँकि ये पैकेट नेटवर्क से गुजरने का तरीका बहुत अलग है।

सिंहावलोकन

जैसा कि हमने देखा है, जब क्लाइंट से जुड़ा क्लाइंट रिक्वेस्ट भेजता है और सर्वर उस पर प्रतिक्रिया देता है, तो HTTP एक रिक्वेस्ट / रिस्पांस मॉडल को फॉलो करता है।

एक HTTP संदेश (अनुरोध या प्रतिक्रिया) में कई भाग होते हैं:

• "पहली पंक्ति" (पहली पंक्ति)
• हेडर (अनुरोध हेडर)
• शरीर (अनुरोध शरीर)

अनुरोध में, पहली पंक्ति क्लाइंट द्वारा उपयोग की जाने वाली विधि को इंगित करती है, उस संसाधन का पथ जो वह चाहती है, साथ ही प्रोटोकॉल का वह संस्करण जिसका वह उपयोग करने जा रही है:

GET /players/lebron-james HTTP/1.1

इस मामले में, क्लाइंट प्रोटोकॉल संस्करण 1.1 माध्यम से /Players/Lebron-James पर संसाधन ( GET ) GET करने की कोशिश करता है - समझने के लिए कुछ भी जटिल नहीं है।

पहली पंक्ति के बाद, HTTP हमें हेडर के माध्यम से संदेश में मेटाडेटा जोड़ने की अनुमति देता है जो कुंजी-मान का रूप लेता है, जो एक कॉलोन से अलग होता है:

GET /players/lebron-james HTTP/1.1
Host: nba.com
Accept: */*
Coolness: 9000

उदाहरण के लिए, इस अनुरोध में, क्लाइंट ने अनुरोध में 3 अतिरिक्त हेडर जोड़े: Host , Accept और Coolness ।

रुको, Coolness ?!?!

हेडर्स को विशिष्ट, आरक्षित नामों का उपयोग नहीं करना चाहिए, लेकिन आमतौर पर उन लोगों पर भरोसा करने की सिफारिश की जाती है जो HTTP विनिर्देशन में मानकीकृत हैं: जितना अधिक आप मानकों से विचलित होते हैं, उतना कम आप किसी अन्य एक्सचेंज प्रतिभागी द्वारा समझा जाएगा।

उदाहरण के लिए, Cache-Control ) एक हेडर है, जिसका उपयोग यह निर्धारित करने के लिए किया जाता है कि क्या (और कैसे) प्रतिक्रिया अस्वीकार्य है: अधिकांश प्रॉक्सी और रिवर्स प्रॉक्सिस इसे एचटीटीपी विनिर्देशन से लेटर तक समझते हैं। अगर आपको Cache-Control हैडर का Awesome-Cache-Control , तो प्रॉक्सी को पता नहीं होगा कि कैसे प्रतिक्रिया को कैश करना है, क्योंकि वे आपके द्वारा आविष्कार किए गए विनिर्देश को पूरा करने के लिए डिज़ाइन नहीं किए गए थे।

हालाँकि, कभी-कभी संदेश में "कस्टम" हेडर को शामिल करना समझ में आता है, क्योंकि आप मेटाडेटा को जोड़ सकते हैं जो वास्तव में HTTP विनिर्देशन का हिस्सा नहीं है: सर्वर अपनी प्रतिक्रिया में तकनीकी जानकारी शामिल करने का निर्णय ले सकता है ताकि क्लाइंट एक साथ अनुरोधों को निष्पादित कर सके और इसके बारे में जानकारी प्राप्त कर सके। एक प्रतिक्रिया देता है कि सर्वर राज्य:

...
X-Cpu-Usage: 40%
X-Memory-Available: 1%
...

कस्टम हेडर का उपयोग करते समय, उनके सामने एक कुंजी के साथ एक उपसर्ग रखना हमेशा बेहतर होता है ताकि वे अन्य हेडर के साथ संघर्ष न करें जो भविष्य में मानक बन सकते हैं: ऐतिहासिक रूप से यह तब तक अच्छी तरह से काम करता है जब तक कि सभी "गैर-मानक" X उपसर्गों का उपयोग करना शुरू न करें, जो बदले में बन गए। आदर्श। X-Forwarded-For और X-Forwarded-Proto हेडर कस्टम हेडर के उदाहरण हैं जो व्यापक रूप से लोड बैलेंसर और प्रॉक्सी द्वारा उपयोग किए जाते हैं और समझे जाते हैं, भले ही वे HTTP मानक का हिस्सा न हों ।

यदि आपको अपने स्वयं के कस्टम हेडर को जोड़ने की आवश्यकता है, तो आमतौर पर Acme-Custom-Header या A-Custom-Header जैसे मालिकाना उपसर्ग का उपयोग करना सबसे अच्छा है।

शीर्षलेखों के बाद, अनुरोध में एक निकाय हो सकता है जो खाली पंक्ति द्वारा हेडर से अलग किया गया है:

POST /players/lebron-james/comments HTTP/1.1
Host: nba.com
Accept: */*
Coolness: 9000

Best Player Ever


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

उत्तर बहुत अलग नहीं है:

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: private, max-age=3600

{"name": "Lebron James", "birthplace": "Akron, Ohio", ...}

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

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

एचटीटीएस बनाम एचटीपीएस बनाम एच 2

HTTP / 1.0 में 2 महत्वपूर्ण अर्थ परिवर्तन हुए: HTTP / 1.0 और HTTP / 1.1.

"HTTPS और HTTP2 कहाँ हैं?", आप पूछते हैं।

HTTPS और HTTP2 (संक्षिप्त रूप में H2) अधिक तकनीकी परिवर्तन हैं क्योंकि उन्होंने प्रोटोकॉल के शब्दार्थ को प्रभावित किए बिना, इंटरनेट पर संदेश देने के नए तरीके पेश किए।

HTTPS एक "सुरक्षित" HTTP एक्सटेंशन है और इसमें क्लाइंट और सर्वर के बीच एक साझा गुप्त कुंजी की स्थापना शामिल है, यह सुनिश्चित करते हुए कि हम सही पार्टी के साथ संवाद करते हैं और संदेशों को साझा करते हैं जो एक साझा गुप्त कुंजी का आदान-प्रदान करते हैं (इस पर बाद में अधिक)। जबकि HTTPS का उद्देश्य HTTP प्रोटोकॉल की सुरक्षा में सुधार करना था, H2 का उद्देश्य उच्च गति प्रदान करना था।

H2 पाठ संदेशों के बजाय बाइनरी का उपयोग करता है, मल्टीप्लेक्सिंग का समर्थन करता है, हेडर को संपीड़ित करने के लिए HPACK एल्गोरिथ्म का उपयोग करता है। ... संक्षेप में, H2 HTTP / 1.1 पर प्रदर्शन में सुधार करता है।

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

HTTPS

HTTPS (HTTP सिक्योर) क्लाइंट और सर्वर को TLS (ट्रांसपोर्ट लेयर सिक्योरिटी), SSL के उत्तराधिकारी (सिक्योर सॉकेट लेयर) के माध्यम से सुरक्षित रूप से संवाद करने की अनुमति देता है।

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

अब आप दो समस्याओं का सामना कर रहे हैं:

• यह प्रमाणित करना कि आप वास्तव में अपनी आत्मा से बात कर रहे हैं, क्योंकि यह कोई उसके होने का नाटक कर सकता है
• एन्क्रिप्शन : अपना पासवर्ड प्रेषित करना ताकि आपके सहकर्मी इसे समझ और लिख न सकें

आप क्या करेंगे? यह वास्तव में समस्या है जिसे HTTPS हल करने की कोशिश कर रहा है।

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

हालांकि, यह "हमलावरों" को पीड़ित के सामाजिक सुरक्षा नंबर का पता लगाने, आपके सोलमेट के स्मार्टफोन को चोरी करने और आपको कॉल करने से नहीं रोकता है। हम कॉल करने वाले की पहचान कैसे सत्यापित करेंगे?

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

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

CA का कार्य डोमेन की प्रामाणिकता को सत्यापित करना और उसके अनुसार प्रमाण पत्र जारी करना है: जब आप एक प्रमाण पत्र (आमतौर पर एक SSL प्रमाणपत्र कहते हैं), हालांकि TLS वर्तमान में उपयोग किया जाता है - नाम वास्तव में छड़ी!), CA आपको कॉल कर सकता है या नहीं। यह सुनिश्चित करने के लिए कि आप इस डोमेन को नियंत्रित करते हैं, DNS सेटिंग बदलने के लिए कहें। सत्यापन प्रक्रिया पूरी होने के बाद, यह एक प्रमाण पत्र जारी करेगा, जिसे तब वेब सर्वर पर स्थापित किया जा सकता है।

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



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

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



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

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



एक बार गुप्त कुंजी स्थापित हो जाने के बाद, क्लाइंट और सर्वर बिना किसी डर के संवाद कर सकते हैं कि कोई उनके संदेशों को रोक सकता है। यहां तक ​​कि अगर हमलावर ऐसा करते हैं, तो उनके पास संदेशों को डिक्रिप्ट करने के लिए आवश्यक साझा गुप्त कुंजी नहीं होगी।

HTTPS और डिफी-हेलमैन के बारे में अधिक जानकारी के लिए, मैं हार्टले ब्रॉडी और " HTTPS वास्तव में कैसे काम करता है?" »रॉबर्ट हेटन। इसके अलावा, नौ अल्गोरिद्म दैट चेंजेड द फ्यूचर में एक अद्भुत अध्याय है जो सार्वजनिक कुंजी एन्क्रिप्शन की व्याख्या करता है, और मैं इसे मूल एल्गोरिदम में रुचि रखने वाले कंप्यूटर विज्ञान के उत्साही लोगों के लिए गर्मजोशी से सलाह देता हूं।

हर जगह Https:

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

आदर्श वाक्य " HTTPS हर जगह " के बाद , ब्राउज़र ने अनएन्क्रिप्टेड कनेक्शन का विरोध करना शुरू कर दिया - Google वेब ब्राउज़र डेवलपर्स था जिसने यह घोषणा करते हुए वेब डेवलपर्स को एक समय सीमा दी कि Chrome 68 (जुलाई 2018) से शुरू होकर यह HTTP वेबसाइटों को असुरक्षित के रूप में चिह्नित करेगा। :



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



इसकी तुलना किसी HTTPS साइट की तरह मान्य प्रमाण पत्र के साथ करें।



सैद्धांतिक रूप से, एक वेबसाइट को सुरक्षित नहीं होना चाहिए, लेकिन व्यवहार में यह उपयोगकर्ताओं को डराता है - और ठीक ही तो। उन दिनों में जब H2 एक वास्तविकता नहीं थी, तो यह बिना मतलब के, सरल HTTP ट्रैफ़िक के साथ चिपकना समझ में आता है। वर्तमान में इसका कोई वस्तुतः कोई कारण नहीं है। HTTPS एवरीवेयर मूवमेंट से जुड़ें और सर्फ करने के लिए इंटरनेट को सुरक्षित जगह बनाने में मदद करें।

पोस्ट बनाम जी.एस.टी.

जैसा कि हमने पहले देखा, एक HTTP अनुरोध एक प्रकार की "पहली पंक्ति" से शुरू होता है:

सबसे पहले, क्लाइंट सर्वर को बताता है कि वह अनुरोध को निष्पादित करने के लिए किन तरीकों का उपयोग करता है: बेसिक HTTP तरीकों में GET, POST, PUT DELETE, लेकिन सूची को कम आम (लेकिन अभी भी मानक) विधियों जैसे TRACE, OPTIONS , या के साथ जारी रखा जा सकता है। HEAD ।

सैद्धांतिक रूप से, कोई भी विधि दूसरों की तुलना में अधिक सुरक्षित नहीं है; व्यवहार में, सब कुछ इतना सरल नहीं है।

GET अनुरोधों में आमतौर पर एक निकाय शामिल नहीं होता है, इसलिए पैरामीटर URL में शामिल होते हैं (उदाहरण के लिए, www.example.com/articles?article_id=1 ), जबकि POST अनुरोधों का उपयोग आमतौर पर शरीर में शामिल ("प्रकाशित") डेटा भेजने के लिए किया जाता है। एक और अंतर यह है कि इन विधियों के साइड इफेक्ट्स हैं: GET एक आदर्श तरीका है, जिसका अर्थ है कि आप चाहे कितने भी अनुरोध भेजें, आप वेब सर्वर की स्थिति को नहीं बदलेंगे। इसके बजाय, POST बेकार नहीं है: आपके द्वारा भेजे गए प्रत्येक अनुरोध के लिए, आप सर्वर की स्थिति बदल सकते हैं (उदाहरण के लिए, एक नया भुगतान रखने के बारे में - अब आप शायद यह समझते हैं कि लेन-देन पूरा करते समय साइटें आपसे पृष्ठ को ताज़ा करने के लिए क्यों नहीं पूछती हैं)।

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

192.168.99.1 - [192.168.99.1] - - [29/Jul/2018:00:39:47 +0000] "GET /?token=1234 HTTP/1.1" 200 525 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36" 404 0.002 [example-local] 172.17.0.8:9090 525 0.002 200
192.168.99.1 - [192.168.99.1] - - [29/Jul/2018:00:40:47 +0000] "GET / HTTP/1.1" 200 525 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36" 393 0.004 [example-local] 172.17.0.8:9090 525 0.004 200
192.168.99.1 - [192.168.99.1] - - [29/Jul/2018:00:41:34 +0000] "PUT /users HTTP/1.1" 201 23 "http://example.local/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36" 4878 0.016 [example-local] 172.17.0.8:9090 23 0.016 201

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

वेब सर्वर HTTP हेडर और बॉडीज को लॉग नहीं करते हैं, क्योंकि संग्रहित डेटा बहुत अधिक मात्रा में होगा - यही कारण है कि URL के बजाय अनुरोध बॉडी के माध्यम से जानकारी भेजना आम तौर पर सुरक्षित होता है। यहां से हम यह अनुमान लगा सकते हैं कि POST (और इसी तरह के गैर-बेरोजगार तरीके) GET तुलना में अधिक सुरक्षित है, भले ही यह इस बात पर अधिक निर्भर करता हो कि डेटा को एक निश्चित विधि का उपयोग करके कैसे भेजा जाता है, और इस तथ्य पर नहीं कि कोई विशेष विधि अनिवार्य रूप से दूसरों के लिए सुरक्षित है: यदि आपने GET अनुरोध के निकाय में गोपनीय जानकारी शामिल की है, तो आपको POST का उपयोग करने से अधिक समस्याएँ नहीं होंगी, भले ही ऐसा दृष्टिकोण असामान्य माना जाए।

हम HTTP हेडर में विश्वास करते हैं

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

---

अनुवाद EDISON सॉफ्टवेयर , एक पेशेवर सुरक्षा कंपनी द्वारा समर्थित था, और इलेक्ट्रॉनिक मेडिकल सत्यापन प्रणाली भी विकसित कर रहा है ।