XSS हमले

चलो कहते हैं कि हम इस प्रपत्र चलाते हैं और दुर्भावनापूर्ण कोड इंजेक्षन करने के लिए एक उपयोगकर्ता के लिए संभव हिस्सा इस नीचेXSS हमले

... 
<input type=text name=username value= 
     <?php echo htmlspecialchars($_POST['username']); ?>> 
...

हम तो बस एक टैग नहीं डाल सकते हैं , या जावास्क्रिप्ट: चेतावनी(); कॉल करें, क्योंकि मान को स्ट्रिंग के रूप में व्याख्या किया जाएगा, और htmlspecialchars <,>, ', "को फ़िल्टर करते हैं, इसलिए हम उद्धरण के साथ मान को बंद नहीं कर सकते हैं।

हम स्ट्रिंग.फॉमकोड (... ..) उद्धरण के आसपास अभी भी पॉप अप करने के लिए एक सरल चेतावनी बॉक्स प्राप्त करने में असमर्थ पाने के लिए, लेकिन मैं।

कोई भी विचार?

स्रोत

2010-05-24 Setzer

उत्कृष्ट प्रश्न, क्योंकि मैं मैं सुरक्षा के लिए htmlspecialchars() पर भरोसा कर रहा हूं - जैसा कि, मुझे यकीन है कि, बहुत से लोग मुझे आश्चर्यचकित करते हैं कि क्या आप एक eval() में या कुछ फिसल सकते हैं ... विशेष रूप से जब मुझे लगता है कि ब्राउजर पास होने से पहले डी-एंटाइटलाइज करता है जेएस दुभाषिया के लिए मूल्य। मुझे लगता है कि यदि आप उपयोगकर्ता डेटा को ऑनक्लिक या href या अन्य निष्पादन योग्य विशेषता में डाल रहे हैं तो यह सबसे अधिक शोषक होगा; मूल्य विशेषता का शोषण करना कठिन लगता है। –

@ फ्रैंक: यदि आप दुर्भावनापूर्ण डेटा डाल रहे हैं जावास्क्रिप्ट, आपको इसे जावास्क्रिप्ट-एन्कोड करने की भी आवश्यकता है। – SLaks

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

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

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

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

john onclick="alert('hacking your megabits!1')"

फिर अपने स्क्रिप्ट के रूप में पार्स होगा:: अगर कोई व्यक्ति अपने उपयोगकर्ता नाम के रूप में रखा

<input type=text name=username value=john onclick="alert('hacking your megabits!1')">

हमेशा उद्धरण चिह्नों का उपयोग चारों ओर जिम्मेदार बताते हैं। भले ही वे उपयोगकर्ता के इनपुट नहीं हैं, इसे में प्राप्त करने के लिए एक अच्छी आदत है।

<input type="text" name="username" value="<?php echo htmlspecialchars($_POST['username']); ?>">

स्रोत

2010-05-24 03:03:45 Daniel

उद्धृत की गई है, हालांकि मैं सहमत हूं कि आपको उद्धरण देना चाहिए, 'htmlspecialchars' एकल- और डबल कोट्स को प्रतिस्थापित करता है। बेशक –

! धन्यवाद! – Setzer

स्थान सही है, लेकिन आप अभी भी उद्धरणों का उपयोग नहीं कर सकते हैं, यही वह समय है जब स्ट्रिंग.फॉम करकोड उपर्युक्त हमले के लिए आसान होगा – Setzer

value एक सामान्य HTML विशेषता है, और जावास्क्रिप्ट के साथ कोई संबंध नहीं है।
इसलिए, String.fromCharCode को शाब्दिक मान के रूप में व्याख्या किया गया है, और इसे निष्पादित नहीं किया गया है।

स्क्रिप्ट इंजेक्ट करने के लिए, आपको पहले विशेषता को बंद करने के लिए पार्सर को मजबूर करने की आवश्यकता है, जो >'" के बिना करना मुश्किल होगा।

आप विशेषता मूल्य के चारों ओर उद्धरण डालना भूल गए हैं, इसलिए आपको केवल एक जगह चाहिए।

भले ही आप मूल्य उद्धृत करते हैं, फिर भी यह कमजोर हो सकता है; this page देखें।

स्रोत

2010-05-24 02:39:58 SLaks

वास्तव में? जब आप उद्धरण को बंद नहीं कर सकते हैं तो आप उद्धृत 'मान' के अंदर कोड कैसे निष्पादित कर सकते हैं? –

मैं chec उस पेज केड, लेकिन मुझे एक ऐसा हमला नहीं दिख रहा है जो htmlspecialchars को बाईपास करेगा और विशेषता – Setzer

एक तरीका है।आप htmlspecialchars() तीसरे एन्कोडिंग पैरामीटर गुजर रहे हैं नहीं या एन्कोडिंग सही ढंग से जाँच, इसलिए:

$source = '<script>alert("xss")</script>'; 
$source = mb_convert_encoding($source, 'UTF-7'); 
$source = htmlspecialchars($source); //defaults to ISO-8859-1 
header('Content-Type: text/html;charset=UTF-7'); 
echo '<html><head>' . $source . '</head></html>';

केवल काम करता है अगर आप कर सकते हैं एक) उत्पादन UTF-7 पेज सेट या ख) ऐसा करने में पेज चाल (उदाहरण के लिए एक स्पष्ट वर्णसेट सेट के बिना किसी पृष्ठ पर iframe)। समाधान यह सुनिश्चित करना है कि सभी इनपुट सही एन्कोडिंग का है, और अपेक्षित एन्कोडिंग htmlspecialchars() पर सही ढंग से सेट है।

यह कैसे काम करता है? यूटीएफ -7, <> "वर्णों में यूटीएफ -8/आईएसओ/एएससीआईआईआई के मुकाबले अलग-अलग कोड पॉइंट होते हैं, इसलिए जब तक आश्वासन के लिए आउटपुट को यूटीएफ -8 में परिवर्तित नहीं किया जाता है (आइकनव एक्सटेंशन देखें)

स्रोत

2010-06-25 12:24:10 padraicb

मैं कहता हूं कि 'htmlspecialchars()' के बजाय 'htmlNT_OTOTES()' का उपयोग किया जाना चाहिए। ENT_HTML5' झंडे। ;) –

XSS हमले

उत्तर

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