क्या GET या POST दूसरे की तुलना में अधिक सुरक्षित है?

Question

HTTP POST से HTTP GET की तुलना करते समय, सुरक्षा परिप्रेक्ष्य से क्या अंतर हैं? क्या विकल्पों में से एक स्वाभाविक रूप से दूसरे की तुलना में अधिक सुरक्षित है? यदि हां, तो क्यों?

मुझे पता है कि POST URL पर जानकारी को उजागर नहीं करता है, लेकिन क्या इसमें कोई वास्तविक मूल्य है या यह केवल अस्पष्टता के माध्यम से सुरक्षा है? क्या कभी कोई कारण है कि मुझे POST पसंद करना चाहिए जब सुरक्षा एक चिंता का विषय हो?

संपादित करें:
HTTPS से अधिक, POST डेटा एनकोडेड है, लेकिन क्या URL को किसी 3rd पार्टी द्वारा सूँघा जा सकता है? इसके अतिरिक्त, मैं JSP के साथ काम कर रहा हूँ; JSP या इसी तरह के ढांचे का उपयोग करते समय, क्या यह कहना उचित होगा कि POST या GET में संवेदनशील डेटा रखने से बचने के लिए सबसे अच्छा अभ्यास है और इसके बजाय संवेदनशील जानकारी को संभालने के लिए सर्वर साइड कोड का उपयोग करना है?

Comments

जेफ के ब्लॉग कोडिंग हॉरर: क्रॉस-साइट रिक्वेस्ट फोर्सेज एंड यू पर इस बारे में एक अच्छी ब्लॉग प्रविष्टि है ।

— fhe

क्या आप ज्यादातर चीजों के लिए POST का उपयोग नहीं करेंगे। उदाहरण के लिए, एक API के लिए, आपको एक DB से डेटा प्राप्त करने की आवश्यकता है, लेकिन सर्वर के डेटा को वापस करने से पहले आपको पहले प्रमाणित होना होगा? पोस्ट का उपयोग करके आप अपनी सत्र आईडी + उन सभी मापदंडों को पारित करेंगे जो आपको अनुरोध के लिए आवश्यक हैं। यदि आपने इसके लिए GET req का उपयोग किया है तो आपकी सत्र आईडी आसानी से या तो आपके ब्राउज़र के इतिहास में या कहीं बीच में मिल सकती है।

— जेम्स ११

मुझे यह चर्चा युद्ध (99 'या '00) से पहले याद है जब https प्रचलित नहीं था।

— डेविड टोनहोफर

@DavidTonhofer, आप किस युद्ध का उल्लेख कर रहे हैं? ब्राउज़र युद्ध?

— DeltaFlyer

@ डेल्फ्टफेयर नं, फॉरएवर वार ऑन स्टफ, उर्फ ​​GWOT। हमने क्या किया है।

— डेविड टोनहोफर 22

Answer 1

जहां तक ​​सुरक्षा है, वे स्वाभाविक रूप से समान हैं। हालांकि यह सच है कि POST URL के माध्यम से जानकारी को उजागर नहीं करता है, यह क्लाइंट और सर्वर के बीच वास्तविक नेटवर्क संचार में एक GET के रूप में सिर्फ अधिक जानकारी को उजागर करता है। यदि आपको ऐसी जानकारी पारित करने की आवश्यकता है जो संवेदनशील है, तो आपकी पहली पंक्ति की सुरक्षा HTTP का उपयोग करके इसे पारित करना होगा।

GET या क्वेरी स्ट्रिंग पोस्ट वास्तव में किसी विशेष आइटम को बुकमार्क करने के लिए या खोज इंजन अनुकूलन और अनुक्रमणिका आइटम में सहायता के लिए आवश्यक जानकारी के लिए अच्छे हैं।

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

Comments

कैविटी के साथ जो GET के लिए लोकेशन बार में दिखाया गया है वह डेटा को उजागर कर सकता है जो POST में छिपा होगा।

— तवान्फोसन

यह सबसे भोली भावना में ही छिपा हुआ है

— davetron5000

सच है, लेकिन आप यह भी कह सकते हैं कि कीबोर्ड असुरक्षित है क्योंकि कोई व्यक्ति आपके पासवर्ड को टाइप करते समय आपके कंधे को देख सकता है। अस्पष्टता के माध्यम से सुरक्षा के बीच बहुत कम अंतर है और कोई भी सुरक्षा नहीं है।

— स्टीफनबेयर

URL में querystrings की दृश्यता (और कैशिंग) और इस प्रकार पता बॉक्स स्पष्ट रूप से कम सुरक्षित नहीं है। पूर्ण सुरक्षा जैसी कोई चीज नहीं है इसलिए सुरक्षा की डिग्री प्रासंगिक हैं।

— pbreitenbach

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

— स्टीफनबायर

Answer 2

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

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

मकड़ियों और वेब त्वरक खोजें

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

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

भ्रमित डिप्टी हमला

एक भ्रमित डिप्टी अटैक (जहां डिप्टी ब्राउज़र है) चाहे आप GET या POST अनुरोध का उपयोग करें , संभव है ।

हमलावर नियंत्रित वेबसाइटों पर GET और POST समान रूप से उपयोगकर्ता इंटरैक्शन के बिना सबमिट करना आसान है ।

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

कोई यह तर्क दे सकता है कि वेब एक्सेलेरेटर भ्रमित डिप्टी हमले का एक उदाहरण है, लेकिन यह केवल परिभाषा की बात है। यदि कुछ भी, एक दुर्भावनापूर्ण हमलावर का इस पर कोई नियंत्रण नहीं है, तो यह शायद ही कोई हमला है , भले ही डिप्टी हो उलझन में।

प्रॉक्सी लॉग करता है

प्रॉक्सी सर्वर क्वेरी स्ट्रिंग को अलग किए बिना, GET URL को अपनी संपूर्णता में लॉग इन करने की संभावना रखते हैं। POST अनुरोध पैरामीटर आमतौर पर लॉग इन नहीं होते हैं। कुकीज़ को किसी भी मामले में लॉग इन होने की संभावना नहीं है। (उदाहरण)

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

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

प्रॉक्सी कैश

कैशिंग प्रॉक्सी GET प्रतिक्रियाओं को बनाए रख सकते हैं, लेकिन POST प्रतिक्रियाएं नहीं। यह कहते हुए कि, GET प्रतिक्रियाओं को URL को POST हैंडलर में बदलने की तुलना में कम प्रयास से गैर-उपलब्ध किया जा सकता है।

HTTP "संदर्भकर्ता"

यदि उपयोगकर्ता GET अनुरोध के जवाब में दिए गए पृष्ठ से किसी तृतीय पक्ष की वेबसाइट पर नेविगेट करना चाहते थे, तो उस तृतीय पक्ष वेबसाइट को सभी GET अनुरोध पैरामीटर देखने को मिलते हैं।

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

ब्राउज़र का इतिहास

यह "प्रॉक्सी लॉग" तर्क के समान है: जीईटी अनुरोधों को उनके मापदंडों के साथ ब्राउज़र इतिहास में संग्रहीत किया जाता है। यदि मशीन में उनकी भौतिक पहुँच है तो हमलावर आसानी से इन्हें प्राप्त कर सकते हैं।

ब्राउज़र रिफ्रेश एक्शन

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

ब्राउज़र चेतावनी के बिना एक POST अनुरोध को फिर से नहीं करेगा।

यह डेटा बदलने के लिए केवल POST अनुरोधों का उपयोग करने का एक अच्छा कारण है, लेकिन दुर्भावनापूर्ण व्यवहार और इसलिए, सुरक्षा से इसका कोई लेना-देना नहीं है।

तो मुझे क्या करना चाहिए?

• डेटा को बदलने के लिए केवल POST अनुरोधों का उपयोग करें, मुख्य रूप से गैर-सुरक्षा-संबंधी कारणों के लिए।
• लॉगिन फ़ॉर्म के लिए केवल POST अनुरोधों का उपयोग करें; अन्यथा हमला करने वाले वैक्टर का परिचय देते हैं।
• यदि आपकी साइट संवेदनशील संचालन करती है, तो आपको वास्तव में किसी ऐसे व्यक्ति की आवश्यकता है जो जानता है कि वे क्या कर रहे हैं, क्योंकि यह एक उत्तर में कवर नहीं किया जा सकता है। आपको HTTPS, HSTS, CSP का उपयोग करना होगा, SQL इंजेक्शन, स्क्रिप्ट इंजेक्शन (XSS) , CSRF और अन्य चीज़ों का एक gazillion जो आपके प्लेटफ़ॉर्म के लिए विशिष्ट हो सकता है (जैसे विभिन्न असाइनमेंट में सामूहिक असाइनमेंट भेद्यता का उपयोग करने के लिए : ASP.NET MVC , पटरियों पर रूबी , आदि)। कोई भी एक चीज नहीं है जो "सुरक्षित" (शोषक नहीं) और "सुरक्षित नहीं" के बीच अंतर करेगी।

---

HTTPS से अधिक, POST डेटा एनकोडेड है, लेकिन क्या URL को किसी तृतीय पक्ष द्वारा सूँघा जा सकता है?

नहीं, उन्हें सूँघा नहीं जा सकता। लेकिन URL को ब्राउज़र इतिहास में संग्रहीत किया जाएगा।

क्या यह कहना उचित होगा कि POST या GET में संवेदनशील डेटा रखने से बचने के लिए सबसे अच्छा अभ्यास है और इसके बजाय संवेदनशील जानकारी को संभालने के लिए सर्वर साइड कोड का उपयोग करना?

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

Comments

अहम, CSRF POST के साथ ही संभव है।

— एवीडी

@ लोटस नोट्स, यह थोड़ा अधिक कठिन है, लेकिन आपको किसी भी प्रकार के XSS की आवश्यकता नहीं है। POST अनुरोधों को हर समय सभी जगह भेजा जा रहा है, और न भूलें कि CSRF को किसी भी वेबसाइट से प्राप्त किया जा सकता है , जिसमें XSS शामिल है।

— एवीडी

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

— किबजितर

ठीक है, आप अपने सभी GET अनुरोधों के लिए एक हैश जोड़ सकते हैं, ठीक उसी तरह जैसे आप उन्हें POST फ़ॉर्म में जोड़ते हैं ... लेकिन आपको अभी भी डेटा संशोधित करने वाली किसी भी चीज़ के लिए GET का उपयोग नहीं करना चाहिए।

— एली

GET पर POST का उपयोग किसी भी प्रकार के CSRF को नहीं रोकता है। यह सिर्फ उन्हें करने के लिए थोड़ा आसान बनाता है, क्योंकि लोगों को यादृच्छिक वेबसाइट पर जाना आसान होता है जो कि यूआरएल से छवियों की अनुमति देता है, उस वेबसाइट पर जाएं, जिसे आप नियंत्रित करते हैं (जो जावास्क्रिप्ट के लिए पर्याप्त है)। ऐसा करने से <body onload="document.getElementById('a').submit()"><form id="a" action="http://example.com/delete.php" action="post"><input type="hidden" name="id" value="12"></form>वास्तव में है कि एक लिंक पर क्लिक करके कहीं से कोई पोस्ट प्रस्तुत करने के लिए कठिन नहीं है (जिसमें एचटीएमएल कि)

— FryGuy

Answer 3

आपके पास कोई बड़ी सुरक्षा उपलब्ध नहीं है क्योंकि HTTP POST के ऊपर वैरिएबल HTTP POST से अधिक भेजे गए हैं।

HTTP / 1.1 हमें अनुरोध भेजने के लिए कई तरीके प्रदान करता है :

• विकल्प
• प्राप्त
• सिर
• पद
• डाल
• हटाएँ
• ट्रेस
• जुडिये

मान लें कि आपके पास GET का उपयोग करके निम्नलिखित HTML दस्तावेज़ हैं:

<html>
<body>
<form action="http://example.com" method="get">
    User: <input type="text" name="username" /><br/>
    Password: <input type="password" name="password" /><br/>
    <input type="hidden" name="extra" value="lolcatz" />
    <input type="submit"/>
</form>
</body>
</html>

आपका ब्राउज़र क्या पूछता है? यह यह पूछता है:

 GET /?username=swordfish&password=hunter2&extra=lolcatz HTTP/1.1
 Host: example.com
 Connection: keep-alive
 Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/ [...truncated]
 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) [...truncated]
 Accept-Encoding: gzip,deflate,sdch
 Accept-Language: en-US,en;q=0.8
 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

अब दिखावा करते हैं कि हमने उस अनुरोध विधि को एक POST में बदल दिया है:

 POST / HTTP/1.1
 Host: example.com
 Connection: keep-alive
 Content-Length: 49
 Cache-Control: max-age=0
 Origin: null
 Content-Type: application/x-www-form-urlencoded
 Accept: application/xml,application/xhtml+xml,text/ [...truncated]
 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; [...truncated]
 Accept-Encoding: gzip,deflate,sdch
 Accept-Language: en-US,en;q=0.8
 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

 username=swordfish&password=hunter2&extra=lolcatz

दोनों इन HTTP अनुरोध कर रहे हैं:

• एन्क्रिप्ट नहीं किया गया
• दोनों उदाहरणों में शामिल
• पर प्रकट किया जा सकता है, और MITM हमलों के अधीन है।
• आसानी से तीसरे पक्ष, और स्क्रिप्ट बॉट द्वारा पुन: प्रस्तुत किया जाता है।

कई ब्राउज़र POST / GET के अलावा HTTP तरीकों का समर्थन नहीं करते हैं।

कई ब्राउज़र व्यवहार पृष्ठ पते को संग्रहीत करते हैं, लेकिन इसका मतलब यह नहीं है कि आप इनमें से किसी भी अन्य मुद्दे को अनदेखा कर सकते हैं।

तो विशिष्ट होने के लिए:

क्या एक स्वाभाविक रूप से अधिक सुरक्षित है? मुझे पता है कि POST URL की जानकारी को उजागर नहीं करता है, लेकिन क्या इसमें कोई वास्तविक मूल्य है या यह केवल अस्पष्टता के माध्यम से सुरक्षा है? यहां सबसे अच्छा अभ्यास क्या है?

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

Https पर, POST डेटा एन्कोड किया गया है, लेकिन क्या url को किसी 3rd पार्टी द्वारा सूँघा जा सकता है?

यहाँ SSL कैसे काम करता है मेरे द्वारा भेजे गए उन दो अनुरोधों को याद रखें? यहाँ वे SSL में क्या दिखते हैं: (मैंने पृष्ठ को https://encrypted.google.com/ में बदल दिया है क्योंकि example.com SSL पर प्रतिक्रिया नहीं देता है)।

एसएसएल पर पोस्ट

q5XQP%RWCd2u#o/T9oiOyR2_YO?yo/3#tR_G7 2_RO8w?FoaObi)
oXpB_y?oO4q?`2o?O4G5D12Aovo?C@?/P/oOEQC5v?vai /%0Odo
QVw#6eoGXBF_o?/u0_F!_1a0A?Q b%TFyS@Or1SR/O/o/_@5o&_o
9q1/?q$7yOAXOD5sc$H`BECo1w/`4?)f!%geOOF/!/#Of_f&AEI#
yvv/wu_b5?/o d9O?VOVOFHwRO/pO/OSv_/8/9o6b0FGOH61O?ti
/i7b?!_o8u%RS/Doai%/Be/d4$0sv_%YD2_/EOAO/C?vv/%X!T?R
_o_2yoBP)orw7H_yQsXOhoVUo49itare#cA?/c)I7R?YCsg ??c'
(_!(0u)o4eIis/S8Oo8_BDueC?1uUO%ooOI_o8WaoO/ x?B?oO@&
Pw?os9Od!c?/$3bWWeIrd_?( `P_C?7_g5O(ob(go?&/ooRxR'u/
T/yO3dS&??hIOB/?/OI?$oH2_?c_?OsD//0/_s%r

SSL पर प्राप्त करें

rV/O8ow1pc`?058/8OS_Qy/$7oSsU'qoo#vCbOO`vt?yFo_?EYif)
43`I/WOP_8oH0%3OqP_h/cBO&24?'?o_4`scooPSOVWYSV?H?pV!i
?78cU!_b5h'/b2coWD?/43Tu?153pI/9?R8!_Od"(//O_a#t8x?__
bb3D?05Dh/PrS6_/&5p@V f $)/xvxfgO'q@y&e&S0rB3D/Y_/fO?
_'woRbOV?_!yxSOdwo1G1?8d_p?4fo81VS3sAOvO/Db/br)f4fOxt
_Qs3EO/?2O/TOo_8p82FOt/hO?X_P3o"OVQO_?Ww_dr"'DxHwo//P
oEfGtt/_o)5RgoGqui&AXEq/oXv&//?%/6_?/x_OTgOEE%v (u(?/
t7DX1O8oD?fVObiooi'8)so?o??`o"FyVOByY_ Supo? /'i?Oi"4
tr'9/o_7too7q?c2Pv

(ध्यान दें: मैंने HEX को ASCII में बदल दिया, इसमें से कुछ स्पष्ट रूप से प्रदर्शित नहीं होनी चाहिए)

संपूर्ण HTTP वार्तालाप एन्क्रिप्ट किया गया है, संचार का एकमात्र दृश्य भाग टीसीपी / आईपी परत (आईपी पते और कनेक्शन पोर्ट जानकारी का अर्थ) पर है।

तो मैं यहां एक बड़ा साहसिक बयान देता हूं। आपकी वेबसाइट को एक HTTP विधि से अधिक सुरक्षा प्रदान नहीं की जाती है, क्योंकि यह दुनिया भर में एक और हैकर और न्यूबस को पता है कि मैंने अभी-अभी जो प्रदर्शन किया है, उसे कैसे करना है। यदि आप सुरक्षा चाहते हैं, तो SSL का उपयोग करें। ब्राउज़र्स इतिहास को संग्रहीत करते हैं, यह RFC2616 9.1.1 द्वारा अनुशंसित है कि वे कार्रवाई करने के लिए GET का उपयोग न करें, लेकिन यह सोचने के लिए कि POST सुरक्षा प्रदान करता है फ्लैट रूप से गलत है।

केवल एक चीज जो POST एक सुरक्षा उपाय है? अपने ब्राउज़र के इतिहास के माध्यम से अपने ईर्ष्या पूर्व flipping के खिलाफ संरक्षण। बस। शेष दुनिया आपके खाते में आपको हँसते हुए लॉग इन करती है।

आगे यह दर्शाने के लिए कि POST सुरक्षित क्यों नहीं है, Facebook सभी जगहों पर POST अनुरोधों का उपयोग करता है, इसलिए फायरशीप जैसे सॉफ्टवेयर कैसे मौजूद हो सकते हैं?

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

Comments

शर्म की बात है कि आपने CSRF :-) के बारे में बात नहीं की। क्या आपसे संपर्क करने का कोई तरीका है?

— फ्लोरियन मार्गाइन

@FlorianMargaine मुझे ट्विटर पर जोड़ें और मैं आपको अपना ईमेल DM करूंगा। twitter.com/#//BrianJGraham

— गुप्त

किसने कहा कि फेसबुक सुरक्षित है? हालांकि अच्छा जवाब। +1।

— अमल मुरली

"[...] इसलिए अश्लीलता के माध्यम से यह पूरी सुरक्षा केवल स्क्रिप्ट किडिज़ और ईर्ष्या करने वाली गर्लफ्रेंड को अश्लीलता प्रदान कर रही है। [...]"। यह पूरी तरह से ईर्ष्या gf के कौशल पर निर्भर करता है। इसके अलावा, किसी भी gf / bf को आपके ब्राउज़र इतिहास पर जाने की अनुमति नहीं दी जानी चाहिए। कभी। जबरदस्त हंसी।

— राजवंश

Answer 4

कोई अतिरिक्त सुरक्षा नहीं है।

पोस्ट डेटा इतिहास और / या लॉग फ़ाइलों में दिखाई नहीं देता है लेकिन अगर डेटा को सुरक्षित रखा जाना चाहिए, तो आपको एसएसएल की आवश्यकता है।
अन्यथा, तार सूँघने वाला कोई भी व्यक्ति आपके डेटा को वैसे भी पढ़ सकता है।

Comments

यदि आप SSL पर एक URL प्राप्त करते हैं, तो एक तृतीय पक्ष URL नहीं देख पाएगा, इसलिए सुरक्षा समान है

— davetron5000

जीईटी की जानकारी केवल एसएसएल सुरंग के शुरू और अंत में देखी जा सकती है

— जैको

और जब वे लॉग फ़ाइलों को गर्त में रखते हैं, तो साइन्स प्रवेश करते हैं।

— टॉमालक

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

— किप

SSL / TLS पर HTTP (सही तरीके से लागू किया गया) हमलावर को तार को सूँघने की अनुमति देता है (या सक्रिय रूप से छेड़छाड़) केवल दो चीज़ों को देखने के लिए - गंतव्य का आईपी पता, और दोनों तरीकों से जाने वाले डेटा की मात्रा।

— आरोन

Answer 5

यहां तक ​​कि अगर अपेक्षाकृत संवेदनशील जानकारी के साथ लॉगिन फ़ॉर्म या किसी अन्य रूप के लिए POSTकोई वास्तविक सुरक्षा लाभ नहीं देता है GET, तो सुनिश्चित करें कि आप इसका उपयोग कर रहे हैं POST:

1. सूचना POST संपादन उपयोगकर्ता के इतिहास में सहेजा नहीं जाएगा।
2. प्रपत्र में भेजी गई संवेदनशील जानकारी (पासवर्ड, आदि) बाद में URL बार में दिखाई नहीं देगी (उपयोग करके GET, यह इतिहास और URL बार में दिखाई देगी)।

इसके अलावा, GETडेटा की एक सैद्धांतिक सीमा है। POSTऐसा नहीं करता।

वास्तविक संवेदनशील जानकारी के लिए, उपयोग करना सुनिश्चित करें SSL( HTTPS)

Comments

डिफ़ॉल्ट सेटिंग्स में, हर बार जब मैं फ़ायरफ़ॉक्स / IE में एक उपयोगकर्ता नाम और पासवर्ड दर्ज करता हूं, तो यह मुझसे पूछता है कि क्या मैं इस जानकारी को सहेजना चाहता हूं, विशेष रूप से इसलिए मुझे इसे बाद में टाइप करने की आवश्यकता नहीं होगी।

— तिब्बती

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

— जेम्स मैकमोहन

हां, ठीक है, यह ऑटो-पूर्ण की बात है, है ना। मेरा मतलब था कि वास्तव में इतिहास था, ऑटो-पूर्ण नहीं।

— एंड्रयू मूर

यदि हमलावर पूर्ण ब्राउज़र इतिहास तक पहुंच सकता है, तो उसके पास पूर्ण ब्राउज़र ऑटो-पूर्ण डेटा तक भी पहुंच है।

— मिक्को रेंटालीनें

Answer 6

न तो GET और POST में से एक स्वाभाविक रूप से दूसरे की तुलना में "अधिक सुरक्षित" है, जैसे कि फैक्स और फोन में से कोई भी एक दूसरे की तुलना में "अधिक सुरक्षित" नहीं है। विभिन्न HTTP तरीके प्रदान किए जाते हैं ताकि आप उस समस्या को हल कर सकें जिसके लिए आप प्रयास कर रहे हैं। जीईटी, बेरोजगार प्रश्नों के लिए अधिक उपयुक्त है, जबकि POST "एक्शन" प्रश्नों के लिए अधिक उपयुक्त है, लेकिन आप अपने आप को किसी भी आसानी से पैर में गोली मार सकते हैं यदि आप उस एप्लिकेशन के लिए सुरक्षा आर्किटेक्चर को नहीं समझते हैं जो आप बनाए रख रहे हैं।

अध्याय 9: यदि आप HTTP / 1.1 RFC की विधि परिभाषाएँ पढ़ते हैं, तो यह जानना सबसे अच्छा है कि मूल रूप से GET और POST का क्या मतलब है।

Answer 7

GET और POST के बीच अंतर को सुरक्षा के संदर्भ में नहीं देखा जाना चाहिए, बल्कि सर्वर के प्रति उनके इरादों में भी होना चाहिए। GET को कभी भी सर्वर पर डेटा नहीं बदलना चाहिए - कम से कम लॉग के अलावा - लेकिन POST नए संसाधन बना सकता है।

अच्छे परदे के पीछे POST डेटा कैश नहीं होगा, लेकिन वे URL से GET डेटा कैश कर सकते हैं, इसलिए आप कह सकते हैं कि POST अधिक सुरक्षित माना जाता है। लेकिन POST डेटा अभी भी प्रॉक्सी के लिए उपलब्ध होगा जो अच्छी तरह से नहीं खेलते हैं।

जैसा कि कई उत्तरों में उल्लेख किया गया है, केवल यकीन है कि एसएसएल के माध्यम से शर्त है।

लेकिन यह सुनिश्चित करें कि GET के तरीके कोई बदलाव नहीं करते हैं, जैसे डेटाबेस पंक्तियों को हटाना आदि।

Comments

मैं इससे सहमत हु। सवाल सुरक्षा नहीं है, यह वही है जो POST और GET करने के लिए डिज़ाइन किया गया है।

— pbreitenbach

Answer 8

चुनने की मेरी सामान्य पद्धति कुछ इस प्रकार है:

• उन वस्तुओं के लिए GET जिन्हें बाद में URL द्वारा पुनः प्राप्त किया जाएगा
  • ईजी सर्च होना चाहिए ताकि आप सर्च कर पाएं। एफपी? एस = XXX बाद में
• भेजी जाने वाली वस्तुओं के लिए POST
  • यह GET के लिए अपेक्षाकृत अदृश्य है और भेजने में कठिन है, लेकिन डेटा अभी भी cURL के माध्यम से भेजा जा सकता है।

Comments

लेकिन यह है एक प्राप्त की तुलना में एक पोस्ट करने के लिए कठिन। GET एड्रेस बॉक्स में सिर्फ एक URL है। HTML पृष्ठ या cURL में एक POST के लिए एक <form> की आवश्यकता होती है।

— pbreitenbach

तो एक नकली पोस्ट नोटपैड और 5 मिनट का समय लेता है ... वास्तव में बहुत कठिन नहीं है। मैंने नोटपैड का उपयोग एक फोन प्रणाली में सुविधाओं को जोड़ने के लिए किया है जो मौजूद नहीं था। मैं उस सिस्टम के लिए व्यवस्थापक रूपों की एक प्रति बनाने में सक्षम था जो मुझे उन बटनों को कमांड देने की अनुमति देगा जो "संभव नहीं थे" जहां तक ​​विक्रेता का संबंध था।

— मैथ्यू Whited

Answer 9

यह सुरक्षा से संबंधित नहीं है, लेकिन ... ब्राउज़र POST अनुरोधों को कैश नहीं करते हैं ।

Answer 10

न तो कोई जादुई अनुरोध पर सुरक्षा प्रदान करता है, हालांकि GET के कुछ दुष्प्रभाव हैं जो आम तौर पर इसे सुरक्षित होने से रोकते हैं।

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

हालाँकि, केवल उस डेटा को पोस्ट करने से वह सुरक्षित नहीं होता है। उसके लिए आपको SSL चाहिए। GET और POST दोनों HTTP पर उपयोग किए जाने पर तार पर प्लेनटेक्स्ट में डेटा भेजते हैं।

POST डेटा के अन्य अच्छे कारण भी हैं - जैसे कि असीमित मात्रा में डेटा जमा करने की क्षमता, या आकस्मिक उपयोगकर्ताओं से पैरामीटर छिपाना।

नकारात्मक पक्ष यह है कि उपयोगकर्ता POST के माध्यम से भेजे गए क्वेरी के परिणामों को बुकमार्क नहीं कर सकते हैं। उसके लिए, आपको GET की आवश्यकता है।

Answer 11

इस स्थिति पर विचार करें: एक मैला एपीआई GET अनुरोध स्वीकार करता है जैसे:

http://www.example.com/api?apikey=abcdef123456&action=deleteCategory&id=1

कुछ सेटिंग्स में, जब आप इस URL का अनुरोध करते हैं और यदि अनुरोध के संबंध में कोई त्रुटि / चेतावनी है, तो यह पूरी लाइन लॉग फ़ाइल में लॉग इन हो जाती है। इससे भी बदतर: यदि आप उत्पादन सर्वर में त्रुटि संदेशों को अक्षम करना भूल जाते हैं, तो यह जानकारी केवल ब्राउज़र में सादे में प्रदर्शित होती है! अब आपने अपनी API कुंजी को सभी को दे दिया है।

दुर्भाग्य से, इस तरह से असली एपीआई काम कर रहे हैं।

मुझे लॉग में कुछ संवेदनशील जानकारी होने या उन्हें ब्राउज़र में प्रदर्शित करने का विचार पसंद नहीं आएगा। POST और GET समान नहीं है। जहाँ उचित हो प्रत्येक का उपयोग करें।

Answer 12

1. पारगमन में डेटा की सुरक्षा के रूप में सुरक्षा: पोस्ट और जीईटी के बीच कोई अंतर नहीं है।

2. कंप्यूटर पर डेटा की सुरक्षा के रूप में सुरक्षा: पोस्ट सुरक्षित है (कोई URL इतिहास नहीं)

Answer 13

सुरक्षा की धारणा तब तक निरर्थक है जब तक आप परिभाषित नहीं करते हैं कि यह क्या है जिसके खिलाफ आप सुरक्षित होना चाहते हैं।

यदि आप संग्रहीत ब्राउज़र इतिहास, कुछ प्रकार के लॉगिंग और आपके URL को देखने वाले लोगों के खिलाफ सुरक्षित होना चाहते हैं, तो POST अधिक सुरक्षित है।

यदि आप अपने नेटवर्क गतिविधि को सूँघने वाले किसी व्यक्ति के खिलाफ सुरक्षित होना चाहते हैं, तो कोई अंतर नहीं है।

Answer 14

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

Comments

वास्तव में यह एक "सम्मेलन" नहीं है जो HTTP मानक का हिस्सा है। RFC बहुत स्पष्ट है कि विभिन्न विधियों से क्या अपेक्षा की जाए।

— जॉन निल्सन

वास्तव में यदि आप GET अनुरोध को राज्य को संशोधित करने की अनुमति देते हैं, तो यह संभव है कि यह ऐसा ब्राउज़र हो जो पहले से मौजूद पृष्ठों के बारे में सोचता हो कि आप यात्रा कर सकते हैं गलती से कार्रवाई करेंगे जो आप इसे नहीं चाहते थे।

— जेसस्टा

Answer 15

एक POST अनुरोध को बदलना कठिन है (इसमें क्वेरी स्ट्रिंग को संपादित करने की तुलना में अधिक प्रयास की आवश्यकता है)। संपादित करें: दूसरे शब्दों में, यह केवल अस्पष्टता से सुरक्षा है, और मुश्किल से ही।

Comments

मैं फ़ायरफ़ॉक्स के लिए कुछ ऐड ऑन का उपयोग करके POST अनुरोधों को क्वेरी स्ट्रिंग अनुरोधों जितना आसान कर सकता हूं। मैं अपने दिल की सामग्री के लिए कुकी डेटा को संशोधित भी कर सकता हूं।

— स्टीफनबेयर

यह स्क्रिप्ट किडीज़ को धीमा नहीं करेगा, यह बिल्कुल उसी प्रकार है जैसे स्क्रिप्ट किडिज़ हर समय कोशिश करते हैं। समस्या यह है कि वे कभी-कभी सफल होते हैं।

— जैको

उह। फ़ायरफ़ॉक्स के लिए addons का उपयोग करना = क्वेरी स्ट्रिंग की तुलना में अधिक प्रयास।

— पलकविहीनता

आपका उत्तर लोगों को एक गलत अर्थ देगा कि वे पोस्ट का उपयोग करते समय अधिक सुरक्षित हो रहे हैं, जब वास्तव में, वे नहीं हैं। बुरा जवाब, बुरा आदमी।

— क्रिस मैरास्टी-जॉर्ज

मैंने अपने उत्तर की मंशा को और अधिक स्पष्ट करने के लिए संपादन किया। उम्मीद है कि मदद करता है।

— पलकविहीनता

Answer 16

मैं अन्य सभी उत्तरों को दोहराने के बारे में नहीं हूं, लेकिन एक पहलू है जिसका मैंने अभी तक उल्लेख नहीं किया है - यह डेटा गायब होने की कहानी है। मुझे नहीं पता कि यह कहां मिलेगा, लेकिन ...

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

वास्तव में - इस के हिस्से का उल्लेख किया गया है। यह "जीईटी पर डेटा को केवल POST पर परिवर्तित न करें" के पीछे की कहानी है। क्रॉलर खुशी से GET का पालन करेंगे, कभी POST नहीं। यहां तक ​​कि robots.txt क्रॉलरों के दुर्व्यवहार के खिलाफ मदद नहीं करता है।

Answer 17

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

Answer 18

RFC7231:

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

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

यह RFC स्पष्ट रूप से कहता है कि GET का उपयोग करके संवेदनशील डेटा प्रस्तुत नहीं किया जाना चाहिए। इस टिप्पणी के कारण, कुछ कार्यान्वयनकर्ता GET अनुरोध के क्वेरी भाग से प्राप्त डेटा को समान देखभाल के साथ संभाल नहीं सकते हैं। मैं खुद एक प्रोटोकॉल पर काम कर रहा हूं जो डेटा की अखंडता सुनिश्चित करता है। इस युक्ति के अनुसार मुझे GET डेटा की अखंडता की गारंटी नहीं देनी चाहिए (जो कि मैं करूँगा क्योंकि कोई भी इन चश्मे का पालन नहीं करता है)

Answer 19

जैसा कि पहले कुछ लोगों ने कहा है, HTTPS सुरक्षा लाता है।

हालाँकि, GST की तुलना में POST थोड़ा अधिक सुरक्षित है क्योंकि GET को इतिहास में संग्रहीत किया जा सकता है।

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

Answer 20

GET किसी को भी दिखाई देता है (यहां तक ​​कि अब आपके कंधे पर भी) और कैश पर सहेजा गया है, इसलिए पोस्ट का उपयोग करना कम सुरक्षित है, कुछ क्रिप्टोग्राफिक्स रूट के बिना btw पोस्ट सुनिश्चित नहीं है, थोड़ी सुरक्षा के लिए आपको SSL का उपयोग करना होगा ( https)

Answer 21

POST का एक कारण सुरक्षा के लिए खराब होना भी है को डिफ़ॉल्ट रूप से लॉग किया जाता है, पैरामीटर और सभी डेटा आपके वेबसर्वर द्वारा लगभग सार्वभौमिक रूप से लॉग इन किया जाता है।

पोस्ट है विपरीत , यह लगभग सार्वभौमिक है लॉगिन नहीं , बहुत मुश्किल के लिए अग्रणी हमलावर गतिविधि को पहचानना।

मैं तर्क नहीं खरीदता हूं "यह बहुत बड़ा है", यह कोई कारण नहीं है कि कुछ भी लॉग न करें , कम से कम 1KB, लोगों के लिए एक कमजोर प्रवेश-बिंदु पर दूर काम करने वाले हमलावरों की पहचान करने के लिए एक लंबा रास्ता तय करेगा जब तक कि यह पॉप नहीं होता, तब POST करता है एक डबल डिस-सर्विस, किसी भी HTTP आधारित बैक-डोर को चुपचाप असीमित मात्रा में डेटा को सक्षम करने से।

Answer 22

अंतर यह है कि GET डेटा ओपन और POST छिपाकर (http- हैडर में) भेजता है।

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

Answer 23

हाल ही में एक हमला प्रकाशित किया गया था, जो एक आदमी को संकुचित HTTPS अनुरोधों के अनुरोध को प्रकट करने की अनुमति देता है। चूँकि अनुरोध हेडर और URL HTTP द्वारा संपीड़ित नहीं हैं, इसलिए GET अनुरोध इस विशेष हमले के खिलाफ बेहतर सुरक्षित हैं।

मोड हैं हैं जिनमें GET अनुरोध भी असुरक्षित हैं, SPDY अनुरोध हेडर को संपीड़ित करता है, TLS एक वैकल्पिक (शायद ही कभी उपयोग किया गया) संपीड़न प्रदान करता है। इन परिदृश्यों में हमले को रोकने के लिए आसान है (ब्राउज़र विक्रेताओं ने पहले से ही सुधार प्रदान किए हैं)। HTTP स्तर की संपीड़न एक अधिक मौलिक विशेषता है, यह संभावना नहीं है कि विक्रेता इसे निष्क्रिय कर देंगे।

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

Answer 24

अस्वीकरण: निम्नलिखित बिंदु केवल एपीआई कॉल के लिए लागू होते हैं न कि वेबसाइट के यूआरएल के लिए।

नेटवर्क पर सुरक्षा : आपको HTTPS का उपयोग करना चाहिए। GET और POST इस मामले में समान रूप से सुरक्षित हैं।

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

सर्वर साइड लॉग्स : डेटा-मास्किंग और एक्सेस लॉग्स फॉर्मेट के राइट सेट का उपयोग करने के साथ ही अनुरोध-URL से सभी या केवल संवेदनशील डेटा को छिपाना संभव है।

ब्राउज़र कंसोल में डेटा दृश्यता: निंदनीय इरादे वाले किसी व्यक्ति के लिए, यह POST डेटा को GET के रूप में देखने के लिए लगभग एक ही प्रयास है।

इसलिए, सही लॉगिंग प्रथाओं के साथ, GET API POST API की तरह सुरक्षित है। हर जगह POST के बाद, खराब API परिभाषाओं को बल मिलता है और इससे बचा जाना चाहिए।

Answer 25

एसएसएल स्थापित के साथ पोस्ट सबसे सुरक्षित है क्योंकि इसका संदेश शरीर में प्रेषित होता है।

लेकिन ये सभी तरीके असुरक्षित हैं क्योंकि इसके नीचे जो 7 बिट प्रोटोकॉल का उपयोग किया गया है वह भागने में सक्षम है। यहां तक ​​कि एक स्तर 4 वेब एप्लिकेशन फ़ायरवॉल के माध्यम से।

सॉकेट्स की कोई गारंटी नहीं है ... भले ही कुछ तरीकों से यह अधिक सुरक्षित हो।

Answer 26

यह एक पुरानी पोस्ट है, लेकिन मैं कुछ उत्तरों पर आपत्ति करना चाहूंगा। यदि आप संवेदनशील डेटा स्थानांतरित कर रहे हैं, तो आप SSL का उपयोग करना चाहते हैं। यदि आप एक GET पैरामीटर (जैसे? Userid = 123) के साथ SSL का उपयोग करते हैं, तो वह डेटा सादे पाठ में भेजा जाएगा! यदि आप एक POST का उपयोग करके भेजते हैं, तो संदेश के एन्क्रिप्टेड बॉडी में मान डाले जाते हैं, और इसलिए अधिकांश एमआईटी हमलों के लिए पठनीय नहीं हैं।

बड़ा अंतर वह है जहां डेटा पारित किया जाता है। इसका केवल यह अर्थ है कि यदि डेटा को URL में रखा जाता है, तो इसे एन्क्रिप्ट नहीं किया जा सकता है अन्यथा आप सर्वर पर नहीं जा पाएंगे क्योंकि केवल आप ही URL को पढ़ सकते हैं। कि एक GET कैसे काम करता है।

संक्षेप में, आप SSL पर POST में डेटा को सुरक्षित रूप से संचारित कर सकते हैं, लेकिन आप SSL या नहीं का उपयोग करके GET के साथ ऐसा नहीं कर सकते।

Comments

यह पूरी तरह से असत्य है। एसएसएल एक ट्रांसपोर्ट लेयर प्रोटोकॉल है। यह सर्वर FIRST से कनेक्ट होता है, फिर सभी एप्लिकेशन डेटा को डेटा की एन्क्रिप्टेड बाइनरी स्ट्रीम के रूप में भेजता है। इस धागे को देखें: answer.google.com/answers/threadview/id/758002.html

— Simeon G

एक TCPDump करें और आप देखेंगे कि यह 100% सत्य है। सर्वर से कनेक्ट करने के लिए, आपको अपना अनुरोध अनएन्क्रिप्टेड भेजना होगा। यदि आप एक GET के रूप में ऐसा करते हैं, तो आपका args प्रारंभिक अनुरोध में जुड़ जाता है और इसलिए अनएन्क्रिप्टेड होता है। आपके द्वारा लिंक किए गए पोस्ट में आप जो भी देखते हैं, उसके बावजूद आप इसे TCPDump (या समान) के साथ परीक्षण कर सकते हैं।

— LVM

किया हुआ! बस मेरे मैक पर tcpdump भागा। और आपका जवाब 100% गलत आया। यहाँ मैं उपयोग किया गया कमांड है: sudo tcpdump -w ssl.data -A -i en1 -n dst port 443 तब जब मैंने ssl.data में देखा तो निश्चित रूप से मुझे बहुत खुशी मिली। सभी HTTP डेटा एन्क्रिप्ट किया गया था। और यह सुनिश्चित करने के लिए कि एक सामान्य गैर-एसएसएल कॉल ने काम किया, मैंने उपयोग किया: sudo tcpdump -w clear.data -A -i en1 -n dst port 80 और निश्चित रूप से पर्याप्त है, स्पष्टता के अंदर। मेरे पास सभी हेडर थे और यूआरआई स्पष्ट दिखा रहे थे । मैंने अपने gmail और google plus (जो कि HTTPS हैं) और google.com जैसे कुछ गैर SSL पृष्ठों पर इसका परीक्षण किया।

— शिमोन जी

मैं एक नेटवर्क विशेषज्ञ नहीं हूं इसलिए यदि आपको लगता है कि मैंने tcpdump पर गलत कमांड का उपयोग किया है तो कृपया मुझे सुधारने के लिए स्वतंत्र महसूस करें।

— शिमोन जी

मेरे पास कमांड ऑफहैंड नहीं है, लेकिन आप इसे Wireshark / Ethereal से भी देख सकते हैं।

— एलवीएम

Answer 27

यहां तक ​​कि POST GET अनुरोध स्वीकार करता है। मान लें कि आपके पास user.name और user.passwd जैसे इनपुट हैं, जिन्हें उपयोगकर्ता नाम और पासवर्ड का समर्थन करना चाहिए। अगर हम बस एक user.name = "my user & user.passwd =" मेरा पासवर्ड "जोड़ते हैं, तो" लॉगऑन पेज को दरकिनार "करके अनुरोध स्वीकार किया जाएगा।

इसका एक समाधान सर्वर साइड पर फिल्टर (जावा फिल्टर के रूप में ई) को लागू करना है और यह पता लगाना है कि जीईटी तर्क के रूप में कोई स्ट्रिंग क्वेरी पारित नहीं की गई है।

Comments

सच नहीं! यह पूरी तरह से आपके बैकएंड पर निर्भर करता है कि क्या POST को स्वीकार करने वाला कोड GET को भी स्वीकार करता है।

— कॉलिन 'टी हार्ट