जावास्क्रिप्ट सुरक्षा जोखिम?

13

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

जबकि वहाँ कुछ धीमी प्रगति वे सर्वर साइड पर वेब पन्नों में आउटपुट HTML एन्कोड तार करने के लिए याद करने के लिए वेब लेखकों प्राप्त करने की कोशिश की गई है (उदाहरण के लिए htmlspecialchars PHP में), webapps की एक नई पीढ़ी एक ही गूंगा स्ट्रिंग का उपयोग कर रहे

somediv.innerHTML= '<p>Hello, '+name+'</p>';

अक्सर jQuery का उपयोग कर: -concatenation जावास्क्रिप्ट का उपयोग क्लाइंट साइड पर सामग्री बनाने के लिए हैक करता

$('table').append('<tr title="'+row.title+'"><td>'+row.description+'</td></tr>');

यह बस के रूप में सर्वर साइड HTML इंजेक्शन के रूप में कमजोर है और लेखकों वास्तव में buildin रोकने की आवश्यकता इस तरह जी सामग्री। आप कर सकते हैं ग्राहक के पक्ष में एचटीएमएल एन्कोड पाठ सामग्री, लेकिन जब से जे एस एक अंतर्निहित एचटीएमएल एनकोडर आप चाहते हैं यह अपने आप को क्या करना है नहीं करता है:

function encodeHTML(s) { 
    return s.replace(/&/g, '&amp;').replace(/</g, '&lt;').replace(/"/g, '&quot;'); 
} 

somediv.innerHTML= '<p>Hello, '+encodeHTML(name)+'</p>';

हालांकि यह आम तौर पर ज्यादा बेहतर है

01:

var p= document.createElement('p'); 
p.appendChild(document.createTextNode('Hello, '+name);

और jQuery के साथ attr(), text() और निर्माण शॉर्टकट का उपयोग: उपलब्ध डोम तरीकों और गुण है कि एस्केपिंग के लिए की जरूरत को समाप्त का उपयोग

स्रोत

2010-09-25 10:25:47 bobince

11

जावास्क्रिप्ट क्लाइंट पक्ष पर चलता है तो सबसे बड़ी जोखिम ग्राहक के लिए है। जोखिम का एक उदाहरण यह है कि उनकी कुकी चोरी हो सकती है ताकि कोई अन्य उपयोगकर्ता उनका प्रतिरूपण कर सके। फॉर्म सबमिट करने के माध्यम से पृष्ठ में inject Javascript पर हमले की एक आम विधि है। इसे रोकने के लिए आपको यह सुनिश्चित करना चाहिए कि आप हमेशा HTML आउटपुट से बचें।

आपका सर्वर साइड सुरक्षा जावास्क्रिप्ट की सुरक्षा पर निर्भर नहीं रहना चाहिए। आप मान लेना चाहिए कि अपने हमलावर और जानकारी है कि सामान्य रूप से दिखाई नहीं देता है देखने के लिए प्रयास करने के लिए अपने पृष्ठों पर HTML/CSS/Javascript बदल जाएगा कर सकते हैं, और वे अपने सर्वर पर डेटा सामान्य इंटरफ़ेस के माध्यम से भेजने के लिए यह संभव नहीं होना चाहिए भेज देंगे । इसके खिलाफ सुरक्षा के लिए आपको हमेशा सभी उपयोगकर्ता इनपुट मान्य करना चाहिए - इसे पूरी तरह से अविश्वसनीय डेटा के रूप में देखें। आपके उपयोगकर्ता आपको भेजे जाने वाले सामग्री के बारे में धारणाओं पर भरोसा न करें - हमेशा उन धारणाओं की स्पष्ट रूप से जांच करें जिन्हें आपको सत्य होने की आवश्यकता है।

स्रोत

2010-09-25 09:40:21

-5

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

स्रोत

2010-09-25 09:40:37

+1

सटीक होने पर, यह मानना उचित है कि जावास्क्रिप्ट का उपयोग सर्वर-साइड कोड का उपयोग नहीं कर सकता है, यानी वह सत्यापन और डेटा तर्क * * जावास्क्रिप्ट को ले जाता है, जो निश्चित रूप से हास्यास्पद और अविश्वसनीय रूप से असुरक्षित होगा।नए लोगों के लिए, ध्यान देने योग्य मूल्य। –

+2

@Noon लेकिन जैसा कि वह कहता है कि असली सुरक्षा जोखिम सर्वर साइड कोड में है, जो आपके मामले में कोई नहीं है और इसलिए असुरक्षित है। मुझे लगता है कि यह सही है, सटीक सर्वर साइड कोड के साथ जेएस को सुरक्षा जोखिम नहीं होना चाहिए –

+0

ओस्कर: ठीक है, आपने जो कहा वह बिल्कुल दोहराया। कि बस जावास्क्रिप्ट को कार्यक्षमता पर ध्यान नहीं है "- नई प्रोग्रामर के लिए - हाँ, और मेरी बात है कि यह राज्य के लिए उपयुक्त है: –

-3

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

स्रोत

2014-06-19 17:55:03

जावास्क्रिप्ट सुरक्षा जोखिम?

उत्तर

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