shoucheng3/nahsra__antisamy_cve-2022-29577_1-6-6-1अविश्वसनीय HTML को तेजी से और कॉन्फ़िगरेबल तरीके से साफ करने के लिए जावा लाइब्रेरी, क्रॉस-साइट स्क्रिप्टिंग (XSS) हमलों को रोकने हेतु। उपयोगकर्ता द्वारा प्रदान किए गए मार्कअप को सैनिटाइज़ करने के लिए नीति-संचालित स्कैनिंग का उपयोग करता है।
अविश्वसनीय स्रोतों से आने वाले HTML के तेज़, कॉन्फ़िगरेबल सफाई के लिए एक लाइब्रेरी। Java 7+ को सपोर्ट करता है।
इसे दूसरे तरीके से कहें तो: यह एक API है जो यह सुनिश्चित करने में आपकी मदद करती है कि क्लाइंट अपने प्रोफ़ाइल, टिप्पणियों आदि के लिए जो HTML प्रदान करते हैं, उसमें दुर्भावनापूर्ण कार्गो कोड न डालें, जो सर्वर पर बना रहे। वेब एप्लिकेशन के संदर्भ में "दुर्भावनापूर्ण कोड" का अर्थ आमतौर पर "JavaScript" होता है। अधिकांशतः, कैस्केडिंग स्टाइलशीट केवल तभी दुर्भावनापूर्ण मानी जाती हैं जब वे JavaScript को आमंत्रित करती हैं। हालांकि, ऐसी कई स्थितियां हैं जहां "सामान्य" HTML और CSS का दुर्भावनापूर्ण तरीके से उपयोग किया जा सकता है।
सबसे पहले, Maven से निर्भरता जोड़ें:
<dependency>
<groupId>org.owasp.antisamy</groupId>
<artifactId>antisamy</artifactId>
<version>LATEST_VERSION</version>
</dependency>
संभावना है कि आपकी साइट के लिए AntiSamy का उपयोग कम से कम मोटे तौर पर पूर्वनिर्धारित पॉलिसी फ़ाइलों में से एक के बराबर है। वे प्रत्येक उपयोगकर्ताओं को HTML (और संभवतः CSS) फ़ॉर्मेटिंग जानकारी प्रदान करने की अनुमति देने के लिए एक "विशिष्ट" परिदृश्य का प्रतिनिधित्व करते हैं। आइए विभिन्न पॉलिसी फ़ाइलों पर नज़र डालें:
Slashdot एक तकनीकी समाचार साइट है जो उपयोगकर्ताओं को बहुत सीमित HTML मार्कअप के साथ समाचार पोस्ट पर गुमनाम रूप से जवाब देने की अनुमति देती है। अब, Slashdot न केवल आसपास की सबसे अच्छी साइटों में से एक है, बल्कि यह उन साइटों में से एक है जो कई अलग-अलग सफल हमलों का शिकार हुई है। Slashdot के नियम काफी सख्त हैं: उपयोगकर्ता केवल निम्नलिखित HTML टैग सबमिट कर सकते हैं और कोई CSS नहीं: <b>, <u>, <i>, <a>, <blockquote>।
तदनुसार, हमने एक पॉलिसी फ़ाइल बनाई है जो काफी समान कार्यक्षमता प्रदान करती है। सभी टेक्स्ट-फ़ॉर्मेटिंग टैग जो सीधे फ़ॉन्ट, रंग या जोर पर काम करते हैं, उन्हें अनुमति दी गई है।
eBay ब्रह्मांड में सबसे लोकप्रिय ऑनलाइन नीलामी साइट है, जहां तक मैं बता सकता हूं। यह एक सार्वजनिक साइट है इसलिए कोई भी समृद्ध HTML सामग्री के साथ लिस्टिंग पोस्ट कर सकता है। यह आश्चर्य की बात नहीं है कि eBay एक लक्ष्य के रूप में आकर्षक होने के कारण कुछ जटिल XSS हमलों का शिकार हुआ है। लिस्टिंग में Slashdot की तुलना में बहुत अधिक समृद्ध सामग्री होने की अनुमति है - इसलिए इसकी हमले की सतह काफी बड़ी है।
MySpace, जब यह प्रोजेक्ट शुरू हुआ था, सबसे लोकप्रिय सोशल नेटवर्किंग साइट थी। उपयोगकर्ताओं को लगभग सभी HTML और CSS सबमिट करने की अनुमति थी जो वे चाहते थे - जब तक इसमें JavaScript न हो। MySpace उपयोगकर्ताओं के HTML को मान्य करने के लिए वर्ड ब्लैकलिस्ट का उपयोग कर रहा था, यही कारण है कि वे कुख्यात Samy वर्म के शिकार हुए। Samy वर्म, जिसमें फ़्रेग्मेंटेशन अटैक के साथ एक ऐसा शब्द (eval) शामिल था जिसे ब्लैकलिस्ट किया जाना चाहिए था - इस प्रोजेक्ट के लिए प्रेरणा था।
मुझे इस पॉलिसी फ़ाइल के लिए किसी संभावित उपयोग के मामले के बारे में पता नहीं है। यदि आप हर एक मान्य HTML और CSS तत्व (लेकिन JavaScript या स्पष्ट CSS-संबंधित फ़िशिंग हमलों के बिना) की अनुमति देना चाहते हैं, तो आप इस पॉलिसी फ़ाइल का उपयोग कर सकते हैं। MySpace भी इतना पागल नहीं था। हालांकि, यह एक अच्छे संदर्भ के रूप में कार्य करता है क्योंकि इसमें प्रत्येक तत्व के लिए आधार नियम हैं, इसलिए आप अन्य पॉलिसी फ़ाइलों को अनुकूलित करते समय इसे ज्ञानकोष के रूप में उपयोग कर सकते हैं।
AntiSamy पॉलिसी फ़ाइलों के लिए AntiSamy के XML Schema Definition (XSD) में कुछ सुधारों पर काम करते हुए, हमने देखा कि AntiSamy वास्तव में XSD को लागू नहीं कर रहा था। इसलिए, हमने AntiSamy 1.6.0 से शुरू होने वाले डिफ़ॉल्ट व्यवहार को बदल दिया है ताकि स्कीमा को लागू किया जा सके, और यदि AntiSamy पॉलिसी अमान्य है तो जारी न रखा जाए। हालांकि ...
हम मानते हैं कि डेवलपर्स के लिए अपनी AntiSamy पॉलिसियों को तुरंत ठीक करना संभव नहीं हो सकता है यदि वे अनुपालन नहीं कर रहे हैं, और फिर भी वे किसी भी सुरक्षा सुधार, सुविधा संवर्द्धन और बग फिक्स को प्राप्त करने के लिए AntiSamy को अपग्रेड करना चाहते हैं। इस प्रकार, हमने स्कीमा सत्यापन को (अस्थायी रूप से!) अक्षम करने के दो तरीके प्रदान किए हैं:
Java सिस्टम प्रॉपर्टी सेट करें: owasp.validator.validateschema को false पर। यह कमांड लाइन पर (उदाहरण के लिए, -Dowasp.validator.validateschema=false) या Java सिस्टम प्रॉपर्टीज़ फ़ाइल के माध्यम से किया जा सकता है। किसी कोड बदलाव की आवश्यकता नहीं है।
AntiSamy का उपयोग करने वाले कोड को बदलें: AntiSamy पॉलिसी लोड करने से पहले Policy.setSchemaValidation(false) को कॉल करें। यह एक स्थैतिक कॉल है, इसलिए एक बार अक्षम करने के बाद, यह सभी नए Policy इंस्टेंस के लिए अक्षम हो जाता है।
AntiSamy उपयोगकर्ताओं को केवल XSD अनुपालन पॉलिसियों का उपयोग करने के लिए प्रोत्साहित करने के लिए, AntiSamy हमेशा स्कीमा सत्यापन अक्षम होने पर किसी प्रकार की चेतावनी लॉग करेगा। यह या तो चेतावनी देगा कि पॉलिसी गैर-अनुपालन है ताकि इसे ठीक किया जा सके, या यह चेतावनी देगा कि पॉलिसी अनुपालन है, लेकिन स्कीमा सत्यापन बंद है, इसलिए सत्यापन वापस चालू किया जाना चाहिए (यानी, इसे अक्षम करना बंद करें)। हमने INFO स्तर की लॉगिंग भी जोड़ी है जब AntiSamy स्कीमा लोड और मान्य होते हैं।
नए स्कीमा सत्यापन सुविधा को अक्षम करने की क्षमता अस्थायी होने का इरादा है, ताकि ठीक से मान्य AntiSamy पॉलिसी फ़ाइलों में संक्रमण को सुगम बनाया जा सके। हम अगले प्रमुख रिलीज़ में इस सुविधा को हटाने की योजना बना रहे हैं। हम अनुमान लगाते हैं कि यह 2022 के मध्य से अंत तक कुछ समय होगा, इसलिए जल्दी नहीं। विचार यह है कि AntiSamy का सीधे या ESAPI जैसी अन्य लाइब्रेरीज़ के माध्यम से उपयोग करने वाली डेवलपमेंट टीमों को स्कीमा सत्यापन आवश्यक होने से पहले अपनी पॉलिसी फ़ाइलों को स्कीमा अनुपालन बनाने के लिए पर्याप्त समय दिया जाए।
इसे 1.6.1 में केवल slf4j API का उपयोग करने के लिए जल्दी से ठीक कर दिया गया। AntiSamy अब अपनी लॉगिंग के लिए slf4j-simple लाइब्रेरी शामिल करता है, लेकिन AntiSamy उपयोगकर्ता चाहें तो एक वैकल्पिक slf4j संगत लॉगिंग लाइब्रेरी आयात और उपयोग कर सकते हैं। वे चाहें तो slf4j-simple को बाहर भी कर सकते हैं।
चेतावनी: AntiSamy का slf4j-simple का उपयोग, बिना किसी कॉन्फ़िगरेशन फ़ाइल के, संदेशों को बफ़र्ड तरीके से मानक आउटपुट पर लॉग करता है। इस प्रकार, यदि कोई अपवाद, जैसे PolicyException फेंका जाता है, तो इनमें से कुछ या सभी लॉग संदेश खो सकते हैं। इसे slf4j-simple को मानक त्रुटि पर लॉग करने के लिए कॉन्फ़िगर करके, या ऐसा करने वाले वैकल्पिक slf4j लॉगर का उपयोग करके ठीक किया जा सकता है।
आप AntiSamy को डिफ़ॉल्ट कॉन्फ़िगरेशन में तैनात करना चाह सकते हैं, लेकिन यह भी उतना ही संभावना है कि कोई साइट उपयोगकर्ता क्या अनुमति दे सकता है, इसके लिए सख्त, व्यावसायिक-संचालित नियम चाहती है। अनुकूलन पर चर्चा में हमले की सतह पर भी विचार किया जाना चाहिए - जो पॉलिसी फ़ाइल के सापेक्ष अनुपात में बढ़ती है।
AntiSamy का उपयोग करना आसान है। यहाँ एक पॉलिसी फ़ाइल के साथ AntiSamy को आमंत्रित करने का एक उदाहरण है:
import org.owasp.validator.html.*;
Policy policy = Policy.getInstance(POLICY_FILE_LOCATION);
AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policy);
MyUserDAO.storeUserProfile(cr.getCleanHTML()); // कुछ कस्टम फ़ंक्शन
Policy ऑब्जेक्ट बनाने के कुछ तरीके हैं। getInstance() विधि निम्नलिखित में से कोई भी ले सकती है:
String फ़ाइलनामFile ऑब्जेक्टInputStreamPolicy फ़ाइलों को फ़ाइलनाम द्वारा भी संदर्भित किया जा सकता है, जैसा कि निम्नलिखित उदाहरण AntiSamy#scan() विधि में दूसरा तर्क पास करके दिखाते हैं:AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policyFilePath);
अंत में, पॉलिसी फ़ाइलों को दूसरे पैरामीटर में सीधे File ऑब्जेक्ट द्वारा भी संदर्भित किया जा सकता है:
AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, new File(policyFilePath));
CleanResults ऑब्जेक्ट बहुत सी उपयोगी चीज़ें प्रदान करता है।