2011-05-31 13 views
12

जैसा कि GitHub's blog में देखा गया है, उन्होंने पेड़ ब्राउज़िंग (आधुनिक ब्राउज़रों के लिए) HTML5's JavaScript pushState सुविधा लागू की है, जिससे AJAX नेविगेशन without Hash Bangs लाया जा रहा है।संभावित सामग्री फर्जीज़ के खिलाफ पुशस्टेट कैसे सुरक्षा करता है?

कोड सरल है:

$('#slider a').click(function() { 
    history.pushState({ path: this.path }, '', this.href) 
    $.get(this.href, function(data) { 
    $('#slider').slideTo(data) 
    }) 
    return false 
}) 

यह काफी सुंदर ढंग से उन्हें अनुमति देता है:

  1. अनुरोध एक पूरा पृष्ठ
  2. के बजाय AJAX के माध्यम से सिर्फ नई सामग्री संक्रमण एनिमेट
  3. और ब्राउज़र यूआरएल बदलें (न केवल #, के रूप में ट्विटर — twitter.com/stackexchangetwitter.com/#!/stackexchange) करता है

मेरा प्रश्न है, कैसे जावास्क्रिप्ट pushState के इस्तेमाल के खिलाफ एक वेबसाइट द्वारा एक ठोस phishing attack में जिसके परिणामस्वरूप एक और की नकल करने, रोकने करता है?

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

उत्तर

9

मेरी समझ यह है कि यह Same Origin Policy के साथ पूरी तरह से संगत है जो XMLHttpRequest, कुकीज़ सेट करने और कई अन्य ब्राउज़र कार्यों को नियंत्रित करता है। धारणा यह है कि यदि यह एक ही डोमेन + प्रोटोकॉल + पोर्ट पर है, तो यह एक विश्वसनीय संसाधन है। आम तौर पर, वेब डेवलपर के रूप में, आप अपनी AJAX स्क्रिप्ट को काम करने के लिए और अपनी कुकीज़ को अपनी साइट पर पढ़ने योग्य बनाने के लिए यही चाहते हैं (और आवश्यकता)। यदि आप ऐसी साइट चला रहे हैं जहां उपयोगकर्ता सामग्री पोस्ट कर सकते हैं, तो यह सुनिश्चित करने के लिए कि वे एक दूसरे के आगंतुकों को फ़िश या कीलॉग नहीं कर सकते हैं, यह ब्राउज़र है, यह आपका काम है।

यहां कुछ और detail on what the FireFox folks are thinking about pushState है - ऐसा लगता है कि यह उनके लिए एक मुद्दा नहीं है। possible pushState security hole here की एक और चर्चा है, लेकिन यह किसी और के यूआरएल के अंत में एक दुर्भावनापूर्ण क्वेरीस्ट्रिंग को छिपाने में सक्षम होने के बारे में एक अलग चिंता है।

2

जैसा कि nrabinowitz ने कहा है और अधिक आम आदमी के नियमों में: यह उसी डोमेन तक सीमित है, जैसे AJAX कॉल और कुकीज़। तो यह पूरी तरह से सुरक्षित है-हालांकि अंतिम उपयोगकर्ता को थोड़ा स्नीकी।

हमारे (डेवलपर्स) हमेशा के लिए हैश टैग के साथ हमेशा के लिए यह कर दिया है, लेकिन यह बेहतर है क्योंकि:

  1. यह क्लीनर लग रहा है।
  2. एक गहरे लिंक की समीक्षा पर आप वास्तव में एसईओ और फेसबुक ओपन ग्राफ जैसी चीजों का समर्थन करने के लिए असली एचटीएमएल डेटा की सतह पर जा सकते हैं (दोनों स्पाइडर को आपके पृष्ठ के एचटीएमएल को स्कैप करने के लिए भेजें)।
  3. सर्वरों के पास हैश टैग डेटा तक पहुंच नहीं है, इसलिए आप इसे अपने सर्वर लॉग में नहीं देखते हैं, इसलिए यह कुछ विश्लेषिकी के साथ मदद करता है।
  4. यह हैश टैग समस्याओं को ठीक करने में मदद करता है। उदाहरण के लिए, मेरे पास मेरे ऐप पर आने वाले उपयोगकर्ताओं को उसी https url पर रीडायरेक्ट करने के लिए एक Nginx पुनर्लेख था।यह सभी ब्राउज़रों में काम करता है लेकिन सफारी जो आपको हैश के बिना डोमेन पर रीडायरेक्ट करेगा (बहुत परेशान!)
संबंधित मुद्दे