2010-03-16 13 views
9

मेरे पास एक ऐसे ग्राहक से अनुरोध है जो किसी अन्य वेबसाइट पर मौजूद उनके मौजूदा फॉर्मों में से एक चाहते हैं।iframe एक गैर एसएसएल साइट पर एक एसएसएल सुरक्षित फॉर्म

वे एक आईफ्रेम में भुगतान फॉर्म मौजूद करना चाहते हैं।

क्या, यदि कोई है, तो भुगतान प्रक्रिया के संबंध में एक गैर-एसएसएल वेबसाइट में एसएसएल वेबसाइट में iframing जब प्रभाव हैं?

+1

@ केविन: स्टैक ओवरफ्लो में आपका स्वागत है :) यहां संबंधित प्रश्न है जो कुछ चीजों पर विचार करने के लिए इंगित कर सकता है: http://stackoverflow.com/questions/2356080/ssl-login-in-iframe –

उत्तर

5

आपके उपयोगकर्ता का ब्राउज़र उन्हें सुरक्षा चेतावनी देगा जो मूल रूप से कहता है कि यह एक असुरक्षित परिदृश्य है। उदाहरण के लिए, एक मैन-इन-द-बीच हमला आपके गैर-SSL पृष्ठ में जावास्क्रिप्ट को इंजेक्ट कर सकता है और अब आप संभावित रूप से समझौता कर रहे हैं।

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

+0

यही मैंने सोचा था। मुझे अभी बताया गया था कि हम एसएसएल भी दूसरी साइट को सुरक्षित कर सकते हैं। इससे हमें असुरक्षित सामग्री चेतावनियों से बाहर निकलना चाहिए। धन्यवाद। – Kevin

6

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

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

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

संबंधित मुद्दे