AntiSamy

अविश्वसनीय स्रोतों से आने वाले HTML का तेज़, कॉन्फ़िगर करने योग्य शोधन (cleansing) करने के लिए एक लाइब्रेरी। Java 8+ को सपोर्ट करती है।

इसे दूसरे शब्दों में कहें तो: यह एक API है जो यह सुनिश्चित करने में आपकी मदद करती है कि क्लाइंट अपने प्रोफ़ाइल, टिप्पणियों आदि के लिए जो HTML भेजते हैं, उसमें कोई दुर्भावनापूर्ण कार्गो कोड न हो, जो सर्वर पर संग्रहीत (persist) हो जाता है। वेब अनुप्रयोगों के संदर्भ में "दुर्भावनापूर्ण कोड" का अर्थ आमतौर पर "JavaScript" होता है। अधिकतर, कैस्केडिंग स्टाइलशीट (Cascading Stylesheets) को केवल तभी दुर्भावनापूर्ण माना जाता है जब वे JavaScript को आमंत्रित करते हैं। हालाँकि, ऐसी कई स्थितियाँ हैं जहाँ "सामान्य" HTML और CSS का उपयोग दुर्भावनापूर्ण तरीके से किया जा सकता है।

IMPORTANT! - 1.7.0 में API तोड़ने वाले बदलाव (API breaking changes)

1.6.x श्रृंखला के विकास के दौरान, हमने कई सुविधाओं और APIs की पहचान की और उन्हें deprecated घोषित किया। इन सभी deprecated वस्तुओं को 1.7.0 रिलीज़ में हटा दिया गया है। ये सभी परिवर्तन टिकट में दर्ज किए गए थे: https://github.com/nahsra/antisamy/issues/195। प्रत्येक परिवर्तन नीचे वर्णित है:

CssHandler में 2 कंस्ट्रक्टर थे जिनमें LinkedList<URI> embeddedStyleSheets पैरामीटर हटा दिया गया था। अब दोनों कंस्ट्रक्टर एक खाली आंतरिक LinkedList<URI> बनाते हैं और यदि आवश्यक हो तो getImportedStylesheetsURIList() विधि का उपयोग करके उसका संदर्भ प्राप्त किया जा सकता है। यह सुविधा बहुत कम उपयोग की जाती है, और वास्तव में इन कंस्ट्रक्टरों का सीधा आह्वान भी दुर्लभ है, इसलिए इस परिवर्तन से AntiSamy के अधिकांश उपयोगकर्ताओं पर प्रभाव पड़ने की संभावना नहीं है। जब उपयोग किया जाता है, तो आमतौर पर इस पैरामीटर के मान के रूप में एक खाली सूची दी जाती है और उस सूची का फिर कभी उपयोग नहीं किया जाता है।

• CssHandler(Policy, LinkedList<URI>, List<String>, ResourceBundle) सिग्नेचर हटा दिया गया था

  • इसे इससे बदल दिया गया: CssHandler(Policy, List<String>, ResourceBundle)

• CssHandler(Policy, LinkedList<URI>, List<String>, String, ResourceBundle) सिग्नेचर हटा दिया गया था

  • इसे इससे बदल दिया गया: CssHandler(Policy, List<String>, ResourceBundle, String)। NOTE: इस विधि के अंतिम 2 पैरामीटरों का क्रम उलट दिया गया था।

• XHTML के लिए समर्थन हटा दिया गया था। AntiSamy अब केवल HTML का समर्थन करता है। चूँकि हमारा मानना है कि यह एक बहुत कम उपयोग की जाने वाली सुविधा थी, इसलिए हमें उम्मीद नहीं है कि इससे कई AntiSamy उपयोगकर्ता प्रभावित होंगे।

• XML स्कीमा सत्यापन अब AntiSamy पॉलिसी फ़ाइलों पर आवश्यक है और इसे अक्षम नहीं किया जा सकता। AntiSamy के साथ उपयोग करने के लिए आपको अपनी पॉलिसी फ़ाइल को स्कीमा-अनुरूप (schema compliant) बनाना होगा।

• पॉलिसी निर्देश noopenerAndNoreferrerAnchors अब डिफ़ॉल्ट रूप से चालू (ON) है। यदि इसे अक्षम किया जाता है, तो AntiSamy एक नाग (nag) जारी करता है, जो आपको इसे सक्षम करने के लिए प्रोत्साहित करता है।

आउटपुट प्रारूप अस्वीकरण (Output format disclaimers)

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

यह उस आउटपुट सीरियलाइज़र पर भी लागू हो सकता है जो आंतरिक HTML प्रतिनिधित्व को टूल के अंतिम टेक्स्ट आउटपुट में बदलता है।

बाहरी स्टाइलशीट के समर्थन को deprecated करना

AntiSamy टीम ने निर्णय लिया है कि एम्बेडेड रिमोट CSS को अनुमति देने की क्षमता का समर्थन करना खतरनाक है और इसलिए हम इस सुविधा को deprecated कर रहे हैं और इसे भविष्य के रिलीज़ में हटा दिया जाएगा। यह अपेक्षित है कि इस सुविधा के बहुत कम, यदि कोई हों, उपयोगकर्ता हैं।

यदि यह सुविधा आह्वान की जाती है तो हमने एक लॉग WARNing जोड़ा है। यदि आप ऐसा करते हैं, तो कृपया प्राथमिक CssScanner कंस्ट्रक्टर पर स्विच करके इस सुविधा को अक्षम/हटा दें जो इस सुविधा को सक्षम नहीं करता है।

उपयोग कैसे करें (How to Use)

1. निर्भरता आयात करें

सबसे पहले, Maven से निर्भरता जोड़ें:

<dependency>
   <groupId>org.owasp.antisamy</groupId>
   <artifactId>antisamy</artifactId>
   <version>LATEST_VERSION</version>
</dependency>

2. एक आधार पॉलिसी फ़ाइल चुनना

संभावना है कि AntiSamy के लिए आपकी साइट का उपयोग-मामला कम से कम मोटे तौर पर पूर्वनिर्धारित पॉलिसी फ़ाइलों में से एक के समान है। उनमें से प्रत्येक उपयोगकर्ताओं को HTML (और संभवतः CSS) स्वरूपण जानकारी प्रदान करने की अनुमति देने के लिए एक "विशिष्ट" परिदृश्य का प्रतिनिधित्व करता है। आइए विभिन्न पॉलिसी फ़ाइलों पर नज़र डालें:

1. antisamy-slashdot.xml

Slashdot एक तकनीकी समाचार साइट है जो उपयोगकर्ताओं को बहुत सीमित HTML मार्कअप के साथ समाचार पोस्टों पर अनाम रूप से उत्तर देने की अनुमति देती है। अब, Slashdot न केवल आसपास की सबसे बढ़िया साइटों में से एक है, बल्कि यह उन साइटों में से एक है जो कई अलग-अलग सफल हमलों के अधीन रही है। Slashdot के नियम काफी सख्त हैं: उपयोगकर्ता केवल निम्नलिखित HTML टैग जमा कर सकते हैं और कोई CSS नहीं: <b>, <u>, <i>, <a>, <blockquote>।

तदनुसार, हमने एक पॉलिसी फ़ाइल बनाई है जो काफी समान कार्यक्षमता की अनुमति देती है। सभी टेक्स्ट-फ़ॉर्मेटिंग टैग जो सीधे फ़ॉन्ट, रंग या ज़ोर पर काम करते हैं, अनुमति दी गई है।

2. antisamy-ebay.xml

eBay, जहाँ तक हम बता सकते हैं, ब्रह्मांड की सबसे लोकप्रिय ऑनलाइन नीलामी साइट है। यह एक सार्वजनिक साइट है इसलिए किसी को भी समृद्ध HTML सामग्री के साथ लिस्टिंग पोस्ट करने की अनुमति है। यह आश्चर्य की बात नहीं है कि eBay को लक्ष्य के रूप में आकर्षक होने के कारण यह कुछ जटिल XSS हमलों के अधीन रहा है। लिस्टिंग में Slashdot की तुलना में बहुत अधिक समृद्ध सामग्री की अनुमति दी जा सकती है — इसलिए इसकी आक्रमण सतह काफी बड़ी है।

3. antisamy-myspace.xml

MySpace, जब यह प्रोजेक्ट शुरू हुआ था, सबसे लोकप्रिय सोशल नेटवर्किंग साइट थी। उपयोगकर्ताओं को लगभग सभी HTML और CSS जमा करने की अनुमति थी जो वे चाहते थे — जब तक इसमें JavaScript न हो। MySpace उपयोगकर्ताओं के HTML को सत्यापित करने के लिए एक शब्द ब्लैकलिस्ट का उपयोग कर रहा था, यही कारण है कि वे कुख्यात Samy वर्म के अधीन थे। Samy वर्म, जिसने विखंडन हमलों (fragmentation attacks) को एक ऐसे शब्द के साथ जोड़ा जिसे ब्लैकलिस्ट किया जाना चाहिए था (eval) — इस प्रोजेक्ट की प्रेरणा थी।

4. antisamy-anythinggoes.xml

हम इस पॉलिसी फ़ाइल के लिए किसी संभावित उपयोग-मामले के बारे में नहीं जानते हैं। यदि आप हर एक मान्य HTML और CSS तत्व को अनुमति देना चाहते हैं (लेकिन JavaScript या स्पष्ट CSS-संबंधित फ़िशिंग हमलों के बिना), तो आप इस पॉलिसी फ़ाइल का उपयोग कर सकते हैं। MySpace भी इतना पागल नहीं था। हालाँकि, यह एक अच्छे संदर्भ के रूप में कार्य करता है क्योंकि इसमें प्रत्येक तत्व के लिए आधार नियम हैं, इसलिए आप अन्य पॉलिसी फ़ाइलों को तैयार करते समय इसे ज्ञानकोष के रूप में उपयोग कर सकते हैं।

लॉगिंग (Logging)

AntiSamy में अब अपनी लॉगिंग के लिए slf4j-simple लाइब्रेरी शामिल है, लेकिन AntiSamy उपयोगकर्ता चाहें तो एक वैकल्पिक slf4j-संगत लॉगिंग लाइब्रेरी आयात और उपयोग कर सकते हैं। वे चाहें तो slf4j-simple को बाहर भी कर सकते हैं।

चेतावनी: AntiSamy द्वारा slf4j-simple का उपयोग, बिना किसी कॉन्फ़िगरेशन फ़ाइल के, मानक आउटपुट पर संदेशों को बफ़र किए हुए तरीके से लॉग करता है। इस प्रकार, यदि कोई Exception, जैसे PolicyException फेंका जाता है, तो इनमें से कुछ या सभी लॉग संदेश खो सकते हैं। इसे संभवतः slf4j-simple को मानक त्रुटि पर लॉग करने के लिए कॉन्फ़िगर करके, या एक वैकल्पिक slf4j लॉगर का उपयोग करके ठीक किया जा सकता है जो ऐसा करता है।

3. पॉलिसी फ़ाइल तैयार करना (Tailoring the policy file)

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

उदाहरण पॉलिसियों को प्रत्येक टैग की आवश्यकताओं के आधार पर अनुकूलित और परीक्षण किया जा सकता है। समर्थित टैग क्रियाएँ जिन्हें निर्दिष्ट किया जा सकता है वे हैं:

• filter: टैग हटाएँ, लेकिन सामग्री बनाए रखें।
• validate: सामग्री को तब तक रखें जब तक वह नियमों को पारित करती है।
• remove: टैग और सामग्री हटाएँ।
• truncate: टैग विशेषताओं और सभी चाइल्ड टैग्स को हटा दें, सिवाय इसके पाठ्य सामग्री के यदि कोई हो।
• encode: filter के समान लेकिन यह टैग को HTML के लिए एनकोड करता है ताकि इसे कच्चे टेक्स्ट के रूप में संरक्षित किया जा सके और इसके चिल्ड्रन पदानुक्रम में एक स्तर ऊपर ले जाए जाते हैं।

4. AntiSamy API को कॉल करना

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()); // some custom function

Policy ऑब्जेक्ट बनाने के कुछ तरीके हैं। getInstance() विधि निम्नलिखित में से कोई भी ले सकती है:

• एक String फ़ाइलनाम
• एक File ऑब्जेक्ट
• एक InputStream
• Policy फ़ाइलों को फ़ाइलनाम द्वारा भी संदर्भित किया जा सकता है, जैसा कि निम्नलिखित उदाहरण दिखाते हैं, 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));

5. CleanResults का विश्लेषण करना

CleanResults ऑब्जेक्ट बहुत सारी उपयोगी चीज़ें प्रदान करता है।

• getCleanHTML() - स्वच्छ, सुरक्षित HTML आउटपुट
• getCleanXMLDocumentFragment() - स्वच्छ, सुरक्षित XMLDocumentFragment जो getCleanHTML() में परिलक्षित होता है
• getErrorMessages() - String त्रुटि संदेशों की एक सूची -- यदि यह 0 लौटाता है तो इसका मतलब यह नहीं है कि कोई हमला नहीं था!
• getNumberOfErrors() - त्रुटि संदेशों की संख्या -- फिर से, 0 का मतलब यह नहीं है कि इनपुट सुरक्षित था!
• getScanTime() - स्कैन समय को सेकंड में लौटाता है

महत्वपूर्ण नोट: getErrorMessages() विधि के बारे में बहुत भ्रम रहा है। getErrorMessages() विधि (न ही getNumberOfErrors()) खाली सूची लौटाने पर सूक्ष्म रूप से "क्या यह सुरक्षित इनपुट है?" प्रश्न का सकारात्मक उत्तर नहीं देती है। आपको हमेशा स्वच्छ किए गए इनपुट का उपयोग करना चाहिए और यह सुनिश्चित करने का कोई तरीका नहीं है कि पारित इनपुट में कोई हमला नहीं था।

सीरियलाइज़ेशन और डिसीरियलाइज़ेशन प्रक्रिया जो सैनिटाइज़र की प्रभावशीलता के लिए महत्वपूर्ण है, जानबूझकर lossy है और कई हमले वैक्टरों के माध्यम से हमलों को फ़िल्टर कर देगी। दुर्भाग्य से, इस रणनीति के व्यापार-नापसंद (tradeoffs) में से एक यह है कि AntiSamy को हमेशा पूर्वव्यापी रूप से यह नहीं पता होता कि कोई हमला देखा गया था। इस प्रकार, getErrorMessages() और getNumberOfErrors() APIs उपयोगकर्ताओं को यह समझने में मदद करने के लिए हैं कि क्या उनका सदाशयी इनपुट सिस्टम की आवश्यकताओं को पूरा करता है, न कि डेवलपर को यह पता लगाने में मदद करने के लिए कि कोई हमला मौजूद था।

अन्य दस्तावेज़ीकरण

अतिरिक्त दस्तावेज़ीकरण इस GitHub प्रोजेक्ट के wiki पृष्ठ पर उपलब्ध है: https://github.com/nahsra/antisamy/wiki और OWASP AntiSamy प्रोजेक्ट पृष्ठ: https://owasp.org/www-project-antisamy/

AntiSamy में योगदान (Contributing to AntiSamy)

कोई समस्या मिली? (Find an Issue?)

यदि आपको कोई बग मिला है, तो AntiSamy रिपॉजिटरी में एक issue बनाएँ: https://github.com/nahsra/antisamy/issues

कोई भेद्यता मिली? (Find a Vulnerability?)

यदि आपको AntiSamy में कोई भेद्यता मिली है, तो पहले issues सूची (ऊपर देखें) खोजें कि क्या यह पहले ही रिपोर्ट की जा चुकी है। यदि नहीं, तो कृपया सीधे Dave Wichers (dave.wichers at owasp.org) से संपर्क करें। कृपया GitHub issues के माध्यम से भेद्यताओं की रिपोर्ट न करें क्योंकि हम पैच लागू और तैनात किए जाने के दौरान अपने उपयोगकर्ताओं को सुरक्षित रखना चाहते हैं। यदि आप भेद्यता खोजने के लिए स्वीकार किया जाना चाहते हैं, तो कृपया इस प्रक्रिया का पालन करें।

अधिक विवरण इस फ़ाइल में उपलब्ध है: SECURITY.md।

निर्माण कैसे करें (How to Build)

आप स्रोत से आसानी से निर्माण और परीक्षण कर सकते हैं:

$ git clone https://github.com/nahsra/antisamy
$ cd antisamy
$ mvn package

लाइसेंस

BSD-3-Clause लाइसेंस के तहत जारी किया गया है जैसा कि यहाँ निर्दिष्ट है: LICENSE।