2012-12-11 62 views
5

मेरे पास एक मोबाइल ऐप (आईओएस) है जो यूआरएल में जीईटी चर के साथ सर्वर अनुरोध भेजता है।एसएसएल = सुरक्षित पर चर प्राप्त करने के पास?

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

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

ने कहा कि साथ

, यह अनुमान है कि प्राप्त चर पारित कर सुरक्षित हैं और हमले 'मध्य में मैन' एक से काट दिया नहीं किया जा सकता सुरक्षित है?

उत्तर

5

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

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

हैकर किसी तरह एक विश्वस्त CA के प्रमुख के साथ उनके धोखाधड़ी प्रमाण पत्र पर हस्ताक्षर करने में सक्षम है, तो उन्हें रोक नहीं है। यह दुर्लभ है, लेकिन सीएएस से समझौता किया जा सकता है।

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

सारांश में, अगर आपके आवेदन लक्ष्य सर्वर के साथ एक SSL चैनल बातचीत और सुनिश्चित करता है कि लौटे प्रमाणपत्र किसी विश्वसनीय प्राधिकारी द्वारा हस्ताक्षरित किया गया है (और उपयोगकर्ता नहीं पूछता है), तो आप ठीक होना चाहिए। सभी HTTP यातायात, जिसमें GET/POST क्रिया और बाद में हेडर शामिल हैं, को एन्क्रिप्ट किया जाएगा। चेतावनी के दो और शब्द जरूरी हैं।

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

दिलचस्प उत्तर लेकिन आरसी 4 का अब नवंबर 2015 तक उपयोग नहीं किया जाना चाहिए। – Corni

0

यह न भूलें कि आपका अनुरोध प्रॉक्सी से गुज़र सकता है और वे संदेश भी लॉग कर सकते हैं।

1

एसएसएल आपके अनुरोध तथापि में यात्रा करने के लिए के रूप में आप जानते हैं एक बार अनुरोध अपने गंतव्य सादा पाठ चर आपकी पहुंच को लॉग द्वारा लॉग इन किया जाएगा तक पहुँच जाता है के लिए एक एन्क्रिप्टेड चैनल प्रदान करता है।

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