2010-06-28 12 views
14

दूसरे शब्दों में, आजकल इनपुट और/या आउटपुट को स्वच्छ करने के लिए सबसे अधिक उपयोग की जाने वाली तकनीकें क्या हैं? औद्योगिक (या यहां तक ​​कि केवल व्यक्तिगत उपयोग) वेबसाइटों में लोग समस्या का मुकाबला करने के लिए उपयोग करते हैं?एक्सएसएस के खिलाफ आम सुरक्षा क्या हैं?

+3

एक्सएसएस के खिलाफ सुरक्षा पर बहुत अधिक विषय हैं, कहने की जरूरत नहीं है कि वे आम हैं। http://stackoverflow.com/questions/tagged/xss – mauris

+0

इनपुट और आउटपुट कहां से कहां से? – Gumbo

+0

HTTP अनुरोध के रूप में किसी सर्वर पर इनपुट, या प्रतिक्रिया के रूप में किसी सर्वर से आउटपुट। – Admiraldei

उत्तर

0

यदि आप एक्सएसएस में बचने के लिए सबसे प्रभावी तरीकों में से एक .NET में विकसित कर रहे हैं तो Microsoft AntiXSS Library का उपयोग करना है। यह आपके इनपुट को स्वच्छ करने का एक बहुत ही प्रभावी तरीका है।

0

जेएसटीएल/जेएसपी में एक्सएसएस के खिलाफ सुरक्षा का सबसे अच्छा तरीका सी: आउट टैग का उपयोग डिफ़ॉल्ट रूप से डिफ़ॉल्ट एक्सप्लोरएक्स पैरामीटर को गलत के बराबर सेट करने के बिना करना है।

<c:out value="${somePossiblyDangerousVar}"/> 
1

आपके कोड में केवल दो प्रमुख क्षेत्र हैं जिन्हें xss मुद्दों से बचने के लिए ठीक से संबोधित करने की आवश्यकता है।

  1. प्रश्नों में किसी भी उपयोगकर्ता इनपुट मूल्य उपयोग करने से पहले, तो डेटा पर mysql_escape_string तरह डेटाबेस सहायक कार्यों का उपयोग और उसके बाद क्वेरी में इसका इस्तेमाल करते हैं। यह xss सुरक्षा gurantee होगा।

  2. उपयोगकर्ता इनपुट मानों को फॉर्म इनपुट फ़ील्ड में वापस प्रदर्शित करने से पहले, उन्हें htmlspecialchars या htmlentities के माध्यम से पास करें। यह सभी एक्सएसएस प्रवण मानों को उन वर्णों में परिवर्तित कर देगा जो ब्राउज़र समझौता किए बिना प्रदर्शित कर सकते हैं।

एक बार जब आप ऊपर कर चुके हैं, तो आप xss हमलों से 95% से अधिक सुरक्षित हैं। फिर आप आगे बढ़ सकते हैं और सुरक्षा वेबसाइटों से उन्नत तकनीक सीख सकते हैं और अपनी साइट पर अतिरिक्त सुरक्षा लागू कर सकते हैं।

सबसे अधिक ढांचे क्या करते हैं कि वे आपको सीधे HTML फॉर्म कोड लिखने या स्ट्रिंग फॉर्म में क्वेरी करने के लिए हतोत्साहित करते हैं, ताकि फ्रेमवर्क सहायक कार्यों का उपयोग करके आपका कोड साफ रहे, जबकि किसी भी गंभीर समस्या को तुरंत अपडेट करके तुरंत संबोधित किया जा सकता है या ढांचे में कोड की दो पंक्तियां। आप सामान्य कार्यों के साथ अपने आप की एक छोटी पुस्तकालय लिख सकते हैं और अपनी सभी परियोजनाओं में उनका पुन: उपयोग कर सकते हैं।

+0

स्पष्ट होने के लिए, जब आप डेटाबेस पर जा रहे डेटा से निपट रहे हैं, तो आप एसक्यूएल इंजेक्शन की बात कर रहे हैं, क्रॉस साइट स्क्रिप्टिंग नहीं। इसके अलावा, प्रति http://php.net/manual/en/function.mysql-escape-string.php, यह फ़ंक्शन बहिष्कृत है (चूंकि यह वर्णमाला को अनदेखा करता है, और वर्णमाला एन्कोडिंग फ़िल्टर चोरी तकनीक के लिए कमजोर हो सकता है), इसलिए mysql_real_escape_string() इस्तेमाल किया जाना चाहिए। बेशक, PHP के साथ, और भी कुछ करने की आवश्यकता है: http://php.net/manual/en/security.database.sql-injection.php – atk

6

दो प्रकार के एक्सएसएस हमले हैं। एक वह जगह है जहां आपकी साइट HTML को इंजेक्शन देने की अनुमति देती है। इसके खिलाफ बचाव करना मुश्किल नहीं है: या तो सभी उपयोगकर्ता इनपुट डेटा से बचें, या सभी <> टैग को पट्टी करें और इसके बजाय यूबीबी-कोड जैसे कुछ का समर्थन करें। नोट: यूआरएल आपको अभी भी रिक-रोलिंग प्रकार के हमलों तक खुल सकता है।

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

21

हमलों के सारांश (including XSS) और उनके खिलाफ सुरक्षा के लिए उत्कृष्ट OWASP website का उल्लेख करना चाहिए। यहां सबसे सरल व्याख्या है जिसके साथ मैं आ सकता हूं, जो वास्तव में उनके वेब पेज से अधिक पठनीय हो सकता है (लेकिन शायद कहीं भी पूर्ण नहीं)।

  1. एक वर्णमाला निर्दिष्ट करना। सबसे पहले, सुनिश्चित करें कि आपका वेब पेज हेडर में यूटीएफ -8 वर्णसेट निर्दिष्ट करता है या head तत्व की शुरुआत में एचटीएमएल इंटरनेट एक्सप्लोरर (और फ़ायरफ़ॉक्स के पुराने संस्करण) में UTF-7 attack को रोकने के लिए सभी इनपुट को एन्कोड करता है, अन्य प्रयासों के बावजूद एक्सएसएस को रोकें।

  2. एचटीएमएल से बचने। ध्यान रखें कि आपको HTML उपयोगकर्ता से बचने की आवश्यकता है। इसमें <&lt;, >&gt;, &&amp; और "&quot; के साथ के साथ प्रतिस्थापित कर रहा है। यदि आप कभी भी एकल-उद्धृत HTML विशेषताओं का उपयोग करेंगे, तो आपको ' को &#39; के साथ प्रतिस्थापित करने की आवश्यकता है। विशिष्ट सर्वर-साइड स्क्रिप्टिंग भाषाएं such as PHP ऐसा करने के लिए फ़ंक्शंस प्रदान करती हैं, और मैं आपको इन्हें विस्तारित करने के बजाय HTML तत्वों को सम्मिलित करने के लिए मानक फ़ंक्शंस बनाकर इन पर विस्तार करने के लिए प्रोत्साहित करता हूं।

  3. अन्य प्रकार के भागने। हालांकि, आपको अभी भी उपयोगकर्ता इनपुट को एक अनिवार्य विशेषता या जावास्क्रिप्ट के रूप में व्याख्या की गई विशेषता के रूप में डालने के लिए सावधान रहने की आवश्यकता नहीं है (उदा। onload या onmouseover)। जाहिर है, यह script तत्वों पर तब भी लागू होता है जब तक कि इनपुट ठीक से जावास्क्रिप्ट से बच न जाए, जो एचटीएमएल से बचने से अलग है। एस्केपिंग का एक अन्य विशेष प्रकार यूआरएल पैरामीटर के लिए यूआरएल से बच रहा है (एचटीएमएल से बचने से पहले इसे लिंक में पैरामीटर को सही तरीके से शामिल करने से पहले)।

  4. यूआरएल और सीएसएस मूल्यों को मान्य करना।javascript: यूआरएल योजना, और सीएसएस स्टाइलशीट यूआरएल और style विशेषताओं के भीतर सीएसएस स्टाइलशीट यूआरएल और डेटा के कारण लिंक और छवियों के यूआरएल (अनुमोदित उपसर्गों के आधार पर मान्य किए बिना) के लिए भी जाता है। (इंटरनेट एक्सप्लोरर जावास्क्रिप्ट अभिव्यक्तियों को सीएसएस मानों के रूप में डालने की अनुमति देता है, और फ़ायरफ़ॉक्स अपने एक्सबीएल समर्थन के साथ समान समस्याग्रस्त है।) यदि आपको अविश्वसनीय स्रोत से सीएसएस मान शामिल करना होगा, तो आपको सुरक्षित रूप से और सख्ती से सत्यापित करना चाहिए या सीएसएस से बचना चाहिए।

  5. उपयोगकर्ता द्वारा प्रदत्त HTML को अनुमति नहीं दे रहा है। यदि आपके पास विकल्प है तो उपयोगकर्ता द्वारा प्रदत्त HTML की अनुमति न दें। यह एक एक्सएसएस समस्या के साथ समाप्त करने का एक आसान तरीका है, और इसलिए सरल रेगेक्स प्रतिस्थापन के आधार पर आपकी अपनी मार्कअप भाषा के लिए "पार्सर" लिख रहा है। I केवल स्वरूपित पाठ की अनुमति देगा यदि HTML आउटपुट वास्तविक पार्सर द्वारा स्पष्ट रूप से सुरक्षित तरीके से उत्पन्न किया गया था जो मानक से बचने वाले कार्यों का उपयोग करके इनपुट से किसी भी पाठ से बच निकलता है और व्यक्तिगत रूप से HTML तत्व बनाता है। यदि आपके पास इस मामले पर कोई विकल्प नहीं है, तो AntiSamy जैसे वैधकर्ता/sanitizer का उपयोग करें।

  6. डोम-आधारित XSS को रोकना।include user input in JavaScript-generated HTML code नहीं और इसे दस्तावेज़ में डालें। इसके बजाय, यह सुनिश्चित करने के लिए उचित डीओएम विधियों का उपयोग करें कि इसे टेक्स्ट के रूप में संसाधित किया गया है, HTML नहीं।

जाहिर है, मैं प्रत्येक मामले को कवर नहीं कर सकता जिसमें एक हमलावर जावास्क्रिप्ट कोड डाल सकता है। आम तौर पर, HTTP-only कुकीज का उपयोग संभवतः एक्सएसएस हमले को थोड़ा कठिन बनाने के लिए किया जा सकता है (लेकिन किसी भी तरह से एक को रोक नहीं सकता है), और प्रोग्रामर सुरक्षा प्रशिक्षण देने आवश्यक है।

+2

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

+2

@ जोनवाटे वह चीजें सीआरएसएफ को रोक सकती हैं, न कि एक्सएसएस। यह सवाल एक्सएसएस के बारे में है, और अनुरोध है कि जालसाजी के पास एक्सएसएस के साथ कुछ लेना देना नहीं है। –

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