मैं अन्य प्रकार के हमलों के बारे में चिंतित नहीं हूं। बस जानना चाहते हैं कि एचटीएमएल एनकोड सभी प्रकार के एक्सएसएस हमलों को रोक सकता है या नहीं।क्या एचटीएमएल एन्कोडिंग सभी प्रकार के एक्सएसएस हमलों को रोक देगा?
क्या HTML एनकोड का उपयोग होने पर भी XSS हमले करने का कोई तरीका है?
सं
कुछ टैग (वास्तव में नहीं प्रश्न के बिंदु), HtmlEncode बस सभी XSS हमलों को कवर नहीं करता की अनुमति के अधीन एक तरफ लाना।
उदाहरण के लिए, पर विचार सर्वर द्वारा जेनरेट क्लाइंट-साइड जावास्क्रिप्ट - सर्वर गतिशील रूप से htmlencoded मान आउटपुट करता है सीधे क्लाइंट-साइड जावास्क्रिप्ट में, एचटीएमएलकोड निष्पादित करने से इंजेक्शन स्क्रिप्ट को रोक नहीं पाएगा।
इसके बाद, निम्न स्यूडोकोड पर विचार करें:, अब
<input value=<%= HtmlEncode(somevar) %> id=textbox>
मामले में अपनी तुरंत स्पष्ट नहीं, somevar (बेशक, उपयोगकर्ता द्वारा भेजे गए)
a onclick=alert(document.cookie)
उदाहरण के लिए सेट है, तो परिणामी आउटपुट
<input value=a onclick=alert(document.cookie) id=textbox>
जो स्पष्ट रूप से काम करेगा। जाहिर है, यह (लगभग) किसी भी अन्य स्क्रिप्ट हो सकता है ... और HtmlEncode बहुत मदद नहीं करेगा।
कुछ अतिरिक्त वैक्टर माना जा सकता है ... एक्सएसएस के तीसरे स्वाद सहित, जिसे डोम-आधारित एक्सएसएस कहा जाता है (जिसमें दुर्भावनापूर्ण स्क्रिप्ट क्लाइंट पर गतिशील रूप से उत्पन्न होती है, उदाहरण के लिए # मानों के आधार पर)।
इसके अलावाUTF-7 प्रकार के हमलों के बारे में भूल नहीं है - जहां हमले
तरह+ADw-script+AD4-alert(document.cookie)+ADw-/script+AD4-
वहाँ एन्कोड करने के लिए ज्यादा कुछ नहीं है ...
समाधान, निश्चित रूप से (उचित के अलावा लग रहा है और प्रतिबंधित सफेद-सूची इनपुट सत्यापन), संदर्भ-संवेदनशील एन्कोडिंग करने के लिए है: एचटीएमएल एन्कोडिंग बहुत अच्छा है अगर आप आउटपुट संदर्भ हैं HTML है, या शायद आपको जावास्क्रिप्ट एन्कोडिंग, या VBScriptEncoding, या विशेषता ValueEncoding, या ... आदि
यदि आप एमएस एएसपी.नेट का उपयोग कर रहे हैं, तो आप अपनी एंटी-एक्सएसएस लाइब्रेरी का उपयोग कर सकते हैं, जो सभी आवश्यक संदर्भ-एन्कोडिंग विधियों को प्रदान करता है।
ध्यान दें कि सभी एन्कोडिंग HTTP में दोनों उपयोगकर्ता इनपुट के लिए प्रतिबंधित नहीं किया जाना चाहिए, लेकिन यह भी डेटाबेस, पाठ फ़ाइलें से संग्रहीत मूल्यों, आदि
ओह, और भूल नहीं है स्पष्ट रूप से चारसेट स्थापित करने के लिए, http://ha.ckers.org/xss.html
मुझे विश्वास नहीं है। एचटीएमएल एनकोड सभी कार्यात्मक पात्रों (अक्षरों को ब्राउज़र के रूप में व्याख्या किया जा सकता है) को इकाई संदर्भों में परिवर्तित करता है जिसे ब्राउज़र द्वारा पार्स नहीं किया जा सकता है और इस प्रकार, निष्पादित नहीं किया जा सकता है।
<script/>
ब्राउज़र द्वारा उपर्युक्त निष्पादित करने का कोई तरीका नहीं है।
** जब तक अपने ब्राउज़र में एक बग बिल्कुल है। *
या यदि जावास्क्रिप्ट का उपयोग किसी भी तरह जीयूआई प्रयोजनों के लिए उपयोगकर्ता इनपुट को बदलने के लिए किया जा रहा है। मैं एक एक्सएसएस भेद्यता में आया था, पहले, एन्कोड किया <> से < and > ... लेकिन जब इस समारोह में पारित किया गया, तो उन्हें दोबारा बदल दिया गया! तो ... मुझे लगता है कि आपकी एक्सएसएस रोकथाम है। :) – verix
तुम सब कुछ कहीं भी होगी सांकेतिक शब्दों में बदलना है। (आपके प्लेटफ़ॉर्म और HTMLencode के कार्यान्वयन के आधार पर) लेकिन कोई भी उपयोगी वेब एप्लिकेशन इतना जटिल है कि इसके हर हिस्से को देखना भूलना आसान है। या शायद एक तृतीय पक्ष घटक सुरक्षित नहीं है। या शायद कुछ कोड पथ जो आपने एन्कोडिंग किया था, ऐसा नहीं किया था, इसलिए आप इसे कहीं और भूल गए थे।
तो हो सकता है कि आप इनपुट पक्ष पर चीजों को भी देखना चाहें। और हो सकता है कि आप डेटाबेस से पढ़ी गई सामग्री को देखना चाहें।
यदि आप प्रदर्शित करने से पहले सभी उपयोगकर्ता इनपुट व्यवस्थित रूप से एन्कोड करते हैं तो हाँ, आप सुरक्षित हैं आप अभी भी 100% सुरक्षित नहीं हैं।
(@ AVID 'अधिक जानकारी के लिए पोस्ट देखें) इसके अलावा समस्याओं में पैदा होती है जब आप कुछ टैग unencoded करेंगे, जिससे आप संसाधित किया जा उन छवियों या बोल्ड पाठ या किसी विशेषता यह है कि उपयोगकर्ता के इनपुट की आवश्यकता है पोस्ट करने की अनुमति देने के लिए की जरूरत है अन-एन्कोडेड मार्कअप के रूप में (या परिवर्तित)।
आपको निर्णय लेने के लिए एक निर्णय लेने की व्यवस्था करनी होगी कि कौन से टैग की अनुमति है और कौन नहीं है, और यह हमेशा संभव है कि कोई भी एक अनुमत टैग को पार करने के लिए एक तरीका बताएगा।
अगर आप Making Wrong Code Look Wrong की जोएल की सलाह का पालन करते हैं या your language helps you को अनुमोदित करके संकलित नहीं करते हैं, तो जब आप अनप्रचारित उपयोगकर्ता डेटा (स्थैतिक-टाइपिंग) आउटपुट करते हैं तो संकलन करते हैं।
हालांकि इसमें कुछ टैग बाईपास करने के बारे में एक अच्छा बिंदु शामिल है, सवाल का जवाब गलत है। मेरा जवाब देखें ... – AviD
ओपी को एक टिप्पणी जोड़ा गया ताकि वह इसके बजाय आपका जवाब स्वीकार कर सके। और बस मेरे मामले में, मेरे उत्तर में एक लिंक जोड़ा। – Pat
धन्यवाद :) एक सुरक्षा लड़के के रूप में, मैं बस यह सुनिश्चित करना चाहता हूं कि वह सही हो जाए ... – AviD
जैसा कि अन्य सभी ने उल्लेख किया है, आप तब तक सुरक्षित हैं जब तक आप सभी उपयोगकर्ता इनपुट को प्रदर्शित करने से पहले एन्कोड करते हैं। इसमें डेटाबेस से पुनर्प्राप्त सभी अनुरोध पैरामीटर और डेटा शामिल हैं जिन्हें उपयोगकर्ता इनपुट द्वारा बदला जा सकता है।
mentioned by Pat के रूप में आप कभी-कभी कुछ टैग प्रदर्शित करना चाहते हैं, बस सभी टैग नहीं। ऐसा करने का एक आम तरीका है मार्कअप भाषा जैसे Textile, Markdown, या BBCode का उपयोग करना। हालांकि, यहां तक कि मार्कअप भाषाएं भी एक्सएसएस के लिए कमजोर हो सकती हैं, बस जागरूक रहें।
# Markup example
[foo](javascript:alert\('bar'\);)
आप यह बताने के लिए "सुरक्षित" टैग के माध्यम से मैं & पार्स करने के लिए कुछ मौजूदा पुस्तकालय खोजने की सिफारिश करेंगे फैसला करते हैं उत्पादन से पहले अपने कोड को साफ़। वहाँ a lot of XSS vectors हैं जहां आपको अपने सैनिटाइज़र काफी सुरक्षित होने से पहले पता लगाना होगा।
आउटपुट फ़िल्टरिंग को संभालने के लिए तीसरे पक्ष की लाइब्रेरी खोजने के लिए दूसरी मेटाविडा की सलाह। एक्सएसएसएसएस हमलों को रोकने के लिए एचटीएमएल अक्षरों को बेअसर करना एक अच्छा तरीका है।हालांकि, मेटाएक्टएक्टर्स को बदलने के लिए आप जिस कोड का उपयोग करते हैं वह चोरी के हमलों के लिए कमजोर हो सकता है; उदाहरण के लिए, यदि यह यूनिकोड और अंतर्राष्ट्रीयकरण को सही ढंग से संभाल नहीं करता है।
क्लासिक सरल गलती होमब्रू आउटपुट फ़िल्टर केवल < और> को पकड़ने के लिए है, लेकिन ऐसी चीजों को याद करें ", जो उपयोगकर्ता द्वारा नियंत्रित आउटपुट को HTML टैग की विशेषता स्थान में तोड़ सकता है, जहां जावास्क्रिप्ट को संलग्न किया जा सकता है डोम।
मैं: हेडर और मेटा टैग, अन्यथा आप अभी भी UTF-7 कमजोरियों होगा ...
कुछ अधिक जानकारी के लिए, और एक बहुत निश्चित सूची (लगातार अद्यतन), RSnake के चीट शीट की जाँच डी एचटीएमएल शोधक (http://htmlpurifier.org/) का सुझाव देना पसंद है) यह सिर्फ एचटीएमएल फ़िल्टर नहीं करता है, यह बी समान रूप से इसे टोकन और पुन: संकलित करता है। यह वास्तव में औद्योगिक शक्ति है।
यह आपको वैध HTML/xhtml आउटपुट सुनिश्चित करने की अनुमति देने का अतिरिक्त लाभ है।
इसके अलावा कपड़ा, यह एक अच्छा उपकरण है और मैं इसे हर समय उपयोग करता हूं, लेकिन मैं इसे एचटीएमएल शोधक के बावजूद भी चलाऊंगा।
मुझे नहीं लगता कि आप समझ गए कि मेरा मतलब टोकन था। एचटीएमएल शोधक सिर्फ 'फिल्टर' नहीं करता है, यह वास्तव में एचटीएमएल का पुनर्निर्माण करता है। http://htmlpurifier.org/comparison.html
नहीं, सामान्य HTML टोकन एन्कोडिंग केवल आपकी साइट को XSS हमलों से पूरी तरह से सुरक्षित नहीं करता है। देखें, उदाहरण के लिए, इस XSS जोखिम google.com में पाया:
http://www.securiteam.com/securitynews/6Z00L0AEUE.html
जोखिम के इस प्रकार के बारे में महत्वपूर्ण बात यह है कि हमलावर को UTF-7 का उपयोग कर अपने XSS पेलोड सांकेतिक शब्दों में बदलना करने में सक्षम है, और यदि आप आपके पृष्ठ पर एक अलग वर्ण एन्कोडिंग निर्दिष्ट नहीं किया है, उपयोगकर्ता का ब्राउज़र यूटीएफ -7 पेलोड की व्याख्या कर सकता है और हमले स्क्रिप्ट निष्पादित कर सकता है।
एक अन्य चीज़ जो आपको जांचने की आवश्यकता है वह है जहां आपका इनपुट आता है। आप रेफरर स्ट्रिंग (अधिकांश समय) का उपयोग यह जांचने के लिए कर सकते हैं कि यह आपके अपने पृष्ठ से है, लेकिन एक छिपी हुई यादृच्छिक संख्या या अपने फॉर्म में कुछ डालने और फिर इसे जांचने (सत्र सत्र चर के साथ) यह जानने में भी मदद करता है कि इनपुट आपकी साइट से आ रहा है और कुछ फ़िशिंग साइट नहीं है।
यह लिखने के लिए पहली जगह गलत है <इनपुट मूल्य = <% = एचटीएमएलएनकोड (कुछवर्स)%> आईडी = पाठ बॉक्स> और नहीं <इनपुट मूल्य = "<% = HtmlEncode (somevar)"%> आईडी = पाठ बॉक्स> यदि आप नहीं जानते कि अगर tekst जैसे शामिल खाली। – Erik
यह बिल्कुल सही बात है - HTMLEncode आपको गलतियों के खिलाफ सुरक्षा नहीं करता है। बेशक, प्रोग्रामर ने उम्मीदवार को 23 रखने की उम्मीद की - यह सिर्फ इतना बुरा हमलावर है जिसने एक खाली स्थानांतरित करने का फैसला किया ... – AviD
यह इसे संलग्न करने में मदद नहीं करेगा, छवि है कि SOMEVAR में यह पाठ शामिल है। "onclick =" चेतावनी(); "" | फिर यह एक वैध टैग की तरह प्रस्तुत करेगा। – Espo