वेब एप्लिकेशन सुरक्षा स्कैनर lcamtuf द्वारा google के लिए निर्मित - अनाधिकारिक मिरर
skipfish - वेब एप्लिकेशन सुरक्षा स्कैनर
===========================================
http://code.google.com/p/skipfish/
* लिखित और अनुरक्षित:
Michal Zalewski <[email protected]>
Niels Heinen <[email protected]>
Sebastian Roschke <[email protected]>
* कॉपीराइट 2009 - 2012 Google Inc, सर्वाधिकार सुरक्षित।
* Apache License, संस्करण 2.0 की शर्तों और प्रावधानों के अंतर्गत जारी।
--------------------
1. skipfish क्या है?
--------------------
Skipfish एक सक्रिय वेब एप्लिकेशन सुरक्षा टोही (reconnaissance) उपकरण है। यह
लक्षित साइट के लिए एक इंटरैक्टिव साइटमैप तैयार करता है, जो
पुनरावर्ती क्रॉल (recursive crawl) और शब्दकोश-आधारित जाँचों द्वारा किया जाता है। परिणामी मानचित्र को
फिर कई सक्रिय (लेकिन उम्मीद है कि
विघटनकारी नहीं) सुरक्षा जाँचों के आउटपुट के साथ एनोटेट किया जाता है। उपकरण द्वारा उत्पन्न अंतिम रिपोर्ट
पेशेवर वेब एप्लिकेशन सुरक्षा मूल्यांकनों के लिए एक आधार के रूप में काम करने के लिए है।
-------------------------------------------------
2. मुझे इस विशेष उपकरण की चिंता क्यों करनी चाहिए?
-------------------------------------------------
समान कार्यक्षमता वाले कई व्यावसायिक और ओपन सोर्स उपकरण
आसानी से उपलब्ध हैं (जैसे, Nikto, Nessus); उसी पर टिके रहें जो आपको
सबसे उपयुक्त लगे। फिर भी, skipfish वेब सुरक्षा स्कैनर से जुड़ी कुछ सामान्य समस्याओं को
हल करने का प्रयास करता है। विशिष्ट लाभों में शामिल हैं:
* उच्च प्रदर्शन: उत्तरदायी इंटरनेट लक्ष्यों के विरुद्ध 500+ अनुरोध प्रति सेकंड,
LAN / MAN नेटवर्क पर 2000+ अनुरोध प्रति सेकंड, और स्थानीय इंस्टेंस के विरुद्ध 7000+ अनुरोध
देखे गए हैं, बहुत ही मामूली CPU, नेटवर्क, और मेमोरी फुटप्रिंट के साथ। यह निम्न के लिए जिम्मेदार ठहराया जा सकता है:
* मल्टीप्लेक्सिंग सिंगल-थ्रेड, पूरी तरह से एसिंक्रोनस नेटवर्क I/O और डेटा
प्रोसेसिंग मॉडल जो कुछ मल्टी-थ्रेडेड क्लाइंट्स में मौजूद मेमोरी प्रबंधन, शेड्यूलिंग, और IPC
अक्षमताओं को समाप्त करता है।
* उन्नत HTTP/1.1 सुविधाएँ जैसे रेंज अनुरोध, सामग्री संपीड़न,
और कीप-अलाइव कनेक्शन, साथ ही नेटवर्क-स्तरीय ओवरहेड को नियंत्रण में रखने के लिए
बाध्य प्रतिक्रिया आकार सीमा।
* अनावश्यक ट्रैफ़िक को कम करने के लिए स्मार्ट प्रतिक्रिया कैशिंग और उन्नत सर्वर व्यवहार
ह्युरिस्टिक्स का उपयोग किया जाता है।
* प्रदर्शन-उन्मुख, शुद्ध C कार्यान्वयन, जिसमें एक कस्टम
HTTP स्टैक शामिल है।
* उपयोग में आसानी: skipfish अत्यधिक अनुकूलनीय और विश्वसनीय है। स्कैनर की विशेषताएँ:
* अस्पष्ट पथ- और क्वेरी-आधारित पैरामीटर हैंडलिंग योजनाओं की ह्युरिस्टिक पहचान।
* मल्टी-फ्रेमवर्क साइटों का सुगम संचालन जहाँ कुछ पथ पूरी तरह से अलग अर्थों का पालन करते हैं,
या विभिन्न फ़िल्टरिंग नियमों के अधीन होते हैं।
* साइट सामग्री विश्लेषण के आधार पर स्वचालित वर्डलिस्ट निर्माण।
* मनमाने ढंग से जटिल साइटों के आवधिक, समय-बद्ध मूल्यांकन की अनुमति देने के लिए
संभाव्य स्कैनिंग सुविधाएँ।
* अच्छी तरह से डिज़ाइन किए गए सुरक्षा जाँच: उपकरण सटीक और सार्थक परिणाम देने के लिए है:
* हस्तनिर्मित शब्दकोश उत्कृष्ट कवरेज प्रदान करते हैं और उचित समय सीमा में
गहन $keyword.$extension परीक्षण की अनुमति देते हैं।
* भेद्यता का पता लगाने के लिए सिग्नेचर जाँचों के बजाय तीन-चरणीय डिफरेंशियल प्रोब
को प्राथमिकता दी जाती है।
* सूक्ष्म सुरक्षा समस्याओं का पता लगाने के लिए ratproxy-शैली तर्क का उपयोग किया जाता है:
क्रॉस-साइट रिक्वेस्ट फोर्जरी, क्रॉस-साइट स्क्रिप्ट इंक्लूजन, मिक्स्ड कंटेंट,
MIME- और चार्सेट बेमेल, गलत कैशिंग निर्देश, आदि।
* बंडल की गई सुरक्षा जाँचें कठिन परिदृश्यों को संभालने के लिए डिज़ाइन की गई हैं:
संग्रहीत XSS (पथ, पैरामीटर, हेडर), ब्लाइंड SQL या XML इंजेक्शन,
या ब्लाइंड शेल इंजेक्शन।
* Snort-शैली सामग्री सिग्नेचर जो सर्वर त्रुटियों,
सूचना लीक या संभावित रूप से खतरनाक वेब एप्लिकेशनों को उजागर करेंगे।
* रिपोर्ट पोस्ट-प्रोसेसिंग दोहराव वाले पैटर्न की पहचान करके किसी भी
शेष झूठी सकारात्मकता या सर्वर गिमिक्स के कारण होने वाले शोर को काफी कम कर देती है।
फिर भी, skipfish कोई चाँदी की गोली नहीं है, और कुछ उद्देश्यों के लिए अनुपयुक्त हो सकता है।
उदाहरण के लिए, यह WASC वेब एप्लिकेशन सुरक्षा स्कैनर मूल्यांकन मानदंडों में उल्लिखित अधिकांश आवश्यकताओं को पूरा नहीं करता है (उनमें से कुछ
जानबूझकर, कुछ आवश्यकता से); और इस प्रकार की अधिकांश अन्य परियोजनाओं के विपरीत,
यह बैनर-प्रकार की जाँचों के लिए ज्ञात भेद्यताओं का एक व्यापक डेटाबेस के साथ नहीं आता है।
-----------------------------------------------------
3. सबसे उत्सुक! कौन से विशिष्ट परीक्षण लागू किए गए हैं?
-----------------------------------------------------
उपकरण द्वारा प्रस्तुत सुरक्षा जाँचों की एक मोटी सूची नीचे दी गई है।
* उच्च जोखिम वाले दोष (संभावित रूप से सिस्टम समझौते की ओर ले जाने वाले):
* सर्वर-साइड क्वेरी इंजेक्शन (ब्लाइंड वेक्टर, संख्यात्मक पैरामीटर सहित)।
* GET या POST पैरामीटर में स्पष्ट SQL-जैसा सिंटैक्स।
* सर्वर-साइड शेल कमांड इंजेक्शन (ब्लाइंड वेक्टर सहित)।
* सर्वर-साइड XML / XPath इंजेक्शन (ब्लाइंड वेक्टर सहित)।
* फॉर्मेट स्ट्रिंग भेद्यताएँ।
* पूर्णांक अतिप्रवाह भेद्यताएँ।
* HTTP PUT स्वीकार करने वाले स्थान।
* मध्यम जोखिम वाले दोष (संभावित रूप से डेटा समझौते की ओर ले जाने वाले):
* दस्तावेज़ बॉडी में संग्रहीत और परावर्तित XSS वेक्टर (न्यूनतम JS XSS समर्थन)।
* HTTP रीडायरेक्ट के माध्यम से संग्रहीत और परावर्तित XSS वेक्टर।
* HTTP हेडर स्प्लिटिंग के माध्यम से संग्रहीत और परावर्तित XSS वेक्टर।
* डायरेक्ट्री ट्रैवर्सल / LFI / RFI (प्रतिबंधित वेक्टर सहित)।
* विभिन्न फ़ाइल POI (सर्वर-साइड स्रोत, कॉन्फ़िगरेशन, आदि)।
* हमलावर-आपूर्ति स्क्रिप्ट और CSS इंक्लूजन वेक्टर (संग्रहीत और परावर्तित)।
* बाहरी अविश्वसनीय स्क्रिप्ट और CSS इंक्लूजन वेक्टर।
* स्क्रिप्ट और CSS संसाधनों पर मिक्स्ड कंटेंट समस्याएँ (वैकल्पिक)।
* गैर-SSL पृष्ठों से या उन पर सबमिट होने वाले पासवर्ड फ़ॉर्म (वैकल्पिक)।
* रेंडरेबल्स पर गलत या अनुपलब्ध MIME प्रकार।
* रेंडरेबल्स पर सामान्य MIME प्रकार।
* रेंडरेबल्स पर गलत या अनुपलब्ध चार्सेट।
* रेंडरेबल्स पर परस्पर विरोधी MIME / चार्सेट जानकारी।
* कुकी सेट करने वाली प्रतिक्रियाओं पर खराब कैशिंग निर्देश।
* कम जोखिम वाले मुद्दे (सीमित प्रभाव या कम विशिष्टता):
* डायरेक्ट्री लिस्टिंग बायपास वेक्टर।
* हमलावर-आपूर्ति URL पर रीडायरेक्शन (संग्रहीत और परावर्तित)।
* हमलावर-आपूर्ति एम्बेडेड सामग्री (संग्रहीत और परावर्तित)।
* बाहरी अविश्वसनीय एम्बेडेड सामग्री।
* गैर-स्क्रिप्टेबल सबरिसोर्सेस पर मिक्स्ड कंटेंट (वैकल्पिक)।
* HTML फ़ॉर्म का HTTPS -> HTTP सबमिशन (वैकल्पिक)।
* URL में HTTP क्रेडेंशियल।
* समाप्त या अभी-अभी-मान्य SSL प्रमाणपत्र।
* बिना XSRF सुरक्षा वाले HTML फ़ॉर्म।
* स्व-हस्ताक्षरित SSL प्रमाणपत्र।
* SSL प्रमाणपत्र होस्ट नाम बेमेल।
* कम संवेदनशील सामग्री पर खराब कैशिंग निर्देश।
* आंतरिक चेतावनियाँ:
* विफल संसाधन लाने के प्रयास।
* क्रॉल सीमा पार हो गई।
* विफल 404 व्यवहार जाँचें।
* IPS फ़िल्टरिंग का पता चला।
* अप्रत्याशित प्रतिक्रिया विविधताएँ।
* प्रतीत होता है गलत वर्गीकृत क्रॉल नोड।
* गैर-विशिष्ट सूचनात्मक प्रविष्टियाँ:
* सामान्य SSL प्रमाणपत्र जानकारी।
* महत्वपूर्ण रूप से बदलते HTTP कुकीज़।
* बदलते Server, Via, या X-... हेडर।
* नए 404 सिग्नेचर।
* ऐसे संसाधन जिन्हें एक्सेस नहीं किया जा सकता।
* HTTP प्रमाणीकरण की आवश्यकता वाले संसाधन।
* टूटे हुए लिंक।
* सर्वर त्रुटियाँ।
* सभी बाहरी लिंक अन्यथा वर्गीकृत नहीं (वैकल्पिक)।
* सभी बाहरी ई-मेल (वैकल्पिक)।
* सभी बाहरी URL रीडायरेक्टर (वैकल्पिक)।
* अज्ञात प्रोटोकॉल के लिंक।
* फ़ॉर्म फ़ील्ड जिन्हें ऑटोकम्प्लीट नहीं किया जा सका।
* पासवर्ड प्रविष्टि फ़ॉर्म (बाहरी ब्रूट-फोर्स के लिए)।
* फ़ाइल अपलोड फ़ॉर्म।
* अन्य HTML फ़ॉर्म (अन्यथा वर्गीकृत नहीं)।
* संख्यात्मक फ़ाइल नाम (बाहरी ब्रूट-फोर्स के लिए)।
* उपयोगकर्ता-आपूर्ति लिंक अन्यथा किसी पृष्ठ पर प्रस्तुत किए जाते हैं।
* कम महत्वपूर्ण सामग्री पर गलत या अनुपलब्ध MIME प्रकार।
* कम महत्वपूर्ण सामग्री पर सामान्य MIME प्रकार।
* कम महत्वपूर्ण सामग्री पर गलत या अनुपलब्ध चार्सेट।
* कम महत्वपूर्ण सामग्री पर परस्पर विरोधी MIME / चार्सेट जानकारी।
* OGNL-जैसी पैरामीटर पासिंग परंपराएँ।
पहचाने गए मुद्दों की सूची के साथ, skipfish पाए गए दस्तावेज़ प्रकारों और मुद्दों के प्रकारों का
सारांश अवलोकन भी प्रदान करता है; और एक इंटरैक्टिव
साइटमैप, जिसमें ब्रूट-फोर्स द्वारा खोजे गए नोड्स को एक विशिष्ट तरीके से दर्शाया गया है।
नोट: एक सचेत डिज़ाइन निर्णय के रूप में, skipfish अत्यधिक गैर-विशिष्ट मुद्दों के बारे में अनावश्यक रूप से
शिकायत नहीं करेगा, जिनमें शामिल हैं लेकिन इन्हीं तक सीमित नहीं:
* गैर-httponly या गैर-सुरक्षित कुकीज़,
* गैर-HTTPS या ऑटोकम्प्लीट-सक्षम फ़ॉर्म,
* किसी पृष्ठ पर पाए गए HTML टिप्पणियाँ,
* त्रुटि संदेशों में फ़ाइलसिस्टम पथ प्रकटीकरण,
* फ्रेमवर्क संस्करण प्रकटीकरण का सर्वर,
* TRACE या OPTIONS अनुरोधों का समर्थन करने वाले सर्वर,
* WebDAV जैसी कुछ तकनीकों की मात्र उपस्थिति।
इनमें से अधिकांश पहलुओं का रिपोर्ट में निरीक्षण करना आसान है यदि ऐसा चाहें -
उदाहरण के लिए, सभी HTML फ़ॉर्म अलग से सूचीबद्ध हैं, नई कुकीज़ या दिलचस्प HTTP हेडर भी - और
अपेक्षा यह है कि लेखा परीक्षक उपयुक्त होने पर इस डेटा के आधार पर कुछ डिज़ाइन सिफारिशें करना चुन सकता है।
फिर भी, इन घटनाओं को एक विशिष्ट सुरक्षा दोष के रूप में उजागर नहीं किया गया है।
-----------------------------------------------------------
4. ठीक है, मैं इसे आज़माना चाहता हूँ। मुझे क्या जानने की आवश्यकता है?
-----------------------------------------------------------
सबसे पहले और सबसे महत्वपूर्ण, कृपया बुरा न बनें। skipfish का उपयोग केवल उन सेवाओं के विरुद्ध करें
जिनके आप मालिक हैं, या जिनके परीक्षण की अनुमति आपके पास है।
ध्यान रखें कि सभी प्रकार के सुरक्षा परीक्षण विघटनकारी हो सकते हैं। हालाँकि
स्कैनर को दुर्भावनापूर्ण हमले करने के लिए डिज़ाइन नहीं किया गया है, यह गलती से साइट के संचालन में हस्तक्षेप कर सकता है। आपको
जोखिम स्वीकार करना होगा, और तदनुसार योजना बनानी होगी। जहाँ संभव हो परीक्षण इंस्टेंस के विरुद्ध स्कैनर चलाएँ,
और गलत होने पर परिणामों से निपटने के लिए तैयार रहें।
यह भी ध्यान दें कि उपकरण सुरक्षा पेशेवरों द्वारा उपयोग के लिए है, और स्वभाव से प्रयोगात्मक है।
यह झूठी सकारात्मकता वापस कर सकता है या स्पष्ट सुरक्षा समस्याओं को याद कर सकता है - और तब भी जब यह पूरी तरह से संचालित होता है,
यह एक पॉइंट-एंड-क्लिक एप्लिकेशन होने के लिए नहीं है। इसके आउटपुट को अंकित मूल्य पर न लें।
विक्रेता-आपूर्ति डेमो साइटों के विरुद्ध उपकरण चलाना इसे मूल्यांकन करने का अच्छा तरीका नहीं है,
क्योंकि वे आमतौर पर भेद्यताओं का बहुत अपूर्ण अनुमान लगाते हैं; हमने इन मामलों को समायोजित करने का कोई प्रयास नहीं किया।
अंत में, स्कैनर केवल दुष्ट और दुर्व्यवहार करने वाले HTTP सर्वरों से निपटने के लिए डिज़ाइन नहीं किया गया है - और वहाँ
सुरक्षित (या समझदार) व्यवहार की कोई गारंटी नहीं देता है।
--------------------------
5. स्कैनर कैसे चलाएँ?
--------------------------
इसे संकलित करने के लिए, बस संग्रह को अनपैक करें और make आज़माएँ। संभावना है, आपको
पहले libidn स्थापित करने की आवश्यकता होगी।
इसके बाद, आपको सही शब्दकोश फ़ाइल का चयन करने और उसे सही ढंग से कॉन्फ़िगर करने के लिए doc/dictionaries.txt में दिए गए निर्देशों को पढ़ना होगा। यह कदम बाद में स्कैन परिणामों की गुणवत्ता पर गहरा प्रभाव डालता है, इसलिए इसे छोड़ें नहीं।
एक बार शब्दकोश चयनित हो जाने पर, आप उस शब्दकोश को लोड करने के लिए -S, और किसी भी नए सीखे गए साइट-विशिष्ट कीवर्ड के लिए प्रारंभ में खाली फ़ाइल निर्दिष्ट करने के लिए -W का उपयोग कर सकते हैं (जो भविष्य के मूल्यांकनों में काम आएगा):
$ touch new_dict.wl
$ ./skipfish -o output_dir -S existing_dictionary.wl -W new_dict.wl \
http://www.example.com/some/starting/path.txt
यदि आप स्वतः-सीखे गए कीवर्ड कहीं संग्रहीत नहीं करना चाहते हैं तो आप -W- का उपयोग कर सकते हैं।
ध्यान दें कि आप चाहें तो एक से अधिक प्रारंभिक URL प्रदान कर सकते हैं; उन सभी को क्रॉल किया जाएगा। निम्नलिखित सिंटैक्स का उपयोग करके फ़ाइल से URL पढ़ना भी संभव है:
$ ./skipfish [...अन्य विकल्प...] @../path/to/url_list.txt
स्कैन चलने के दौरान उपकरण कुछ सहायक आँकड़े प्रदर्शित करेगा। आप एंटर दबाकर चालू HTTP अनुरोधों की सूची में भी स्विच कर सकते हैं।
ऊपर के उदाहरण में, skipfish पूरी www.example.com साइट को स्कैन करेगा (अन्य पोर्ट पर सेवाओं सहित, यदि मुख्य पृष्ठ से लिंक किया गया है), और रिपोर्ट output_dir/index.html में लिखेगा। आप इस रिपोर्ट को अपने पसंदीदा ब्राउज़र से देख सकते हैं (JavaScript सक्षम होना चाहिए; और कुछ ब्राउज़रों में हाल के file:/// सुरक्षा सुधारों के कारण, आपको परिणामों को HTTP के माध्यम से एक्सेस करने की आवश्यकता हो सकती है)। index.html फ़ाइल स्थिर है; वास्तविक परिणाम JSON फ़ाइलों के पदानुक्रम के रूप में संग्रहीत होते हैं, जो मशीन प्रोसेसिंग या विभिन्न प्रस्तुति फ्रंटएंड के लिए उपयुक्त होते हैं यदि आवश्यक हो। इसके अलावा, खोजे गए सभी URL की एक सूची एक ही फ़ाइल, pivots.txt, में सहेजी जाएगी, आसान पोस्टप्रोसेसिंग के लिए।
एक सरल साथी स्क्रिप्ट, sfscandiff, का उपयोग एक ही लक्ष्य के विरुद्ध समान फ्लैग के साथ निष्पादित दो स्कैनों के लिए डेल्टा की गणना करने के लिए किया जा सकता है। नई रिपोर्ट को गैर-विनाशकारी रूप से एनोटेट किया जाएगा, जिसमें सभी नए या बदले हुए नोड्स में लाल पृष्ठभूमि जोड़ी जाएगी; और पाए गए सभी नए या बदले हुए मुद्दों के लिए नीली पृष्ठभूमि जोड़ी जाएगी।
कुछ साइटों को प्रमाणीकरण की आवश्यकता हो सकती है जिसके लिए हमारा समर्थन doc/authentication.txt में वर्णित है। अधिकांश मामलों में, आप फ़ॉर्म प्रमाणीकरण विधि का उपयोग करना चाहेंगे जो पुनः प्रमाणीकरण के लिए टूटे हुए सत्रों का पता लगाने में सक्षम है।
एक बार प्रमाणित होने के बाद, साइट पर कुछ URL आपके सत्र को लॉग आउट कर सकते हैं; आप इसे दो तरीकों से लड़ सकते हैं: -N विकल्प का उपयोग करके, जो स्कैनर को कुकीज़ सेट करने या हटाने के प्रयासों को अस्वीकार करने का कारण बनता है; या -X पैरामीटर के साथ, जो मेल खाने वाले URL को लाने से रोकता है:
$ ./skipfish -X /logout/logout.aspx ...अन्य पैरामीटर...
-X विकल्प /icons/, /doc/, /manuals/, और इसी तरह के अन्य मानक, सांसारिक स्थानों को बाहर करके अपने स्कैन को तेज करने के लिए भी उपयोगी है। सामान्य तौर पर, आप स्कैन के दायरे को किसी भी तरह से सीमित करने के लिए -X और -I (केवल एक सबस्ट्रिंग से मेल खाने वाले URL को स्पाइडर करें) का उपयोग कर सकते हैं - जिसमें केवल एक विशिष्ट प्रोटोकॉल और पोर्ट तक प्रतिबंधित करना शामिल है:
$ ./skipfish -I http://example.com:1234/ ...अन्य पैरामीटर...
एक संबंधित फ़ंक्शन, -K, आपको फज़ न करने वाले पैरामीटर नाम निर्दिष्ट करने की अनुमति देता है (उन एप्लिकेशनों के लिए उपयोगी जो URL में सत्र आईडी डालते हैं, शोर को कम करने के लिए)।
एक और उपयोगी स्कोपिंग विकल्प -D है - जो आपको परीक्षण के लिए दायरे में माने जाने वाले अतिरिक्त होस्ट या डोमेन निर्दिष्ट करने की अनुमति देता है। डिफ़ॉल्ट रूप से, कमांड-लाइन URL में दिखाई देने वाले सभी होस्ट सूची में जोड़े जाते हैं - लेकिन आप इन नियमों को व्यापक बनाने के लिए -D का उपयोग कर सकते हैं, उदाहरण के लिए:
$ ./skipfish -D test2.example.com -o output-dir http://test1.example.com/
...या, डोमेन वाइल्डकार्ड मिलान के लिए, उपयोग करें:
$ ./skipfish -D .example.com -o output-dir http://test1.example.com/
कुछ मामलों में, आप वास्तव में किसी तीसरे पक्ष के डोमेन को क्रॉल नहीं करना चाहते हैं, लेकिन आप उस डोमेन के मालिक पर इतना भरोसा करते हैं कि उस स्थान से क्रॉस-डोमेन सामग्री इंक्लूजन के बारे में चिंता न करें। चेतावनियों को दबाने के लिए, आप -B विकल्प का उपयोग कर सकते हैं, उदाहरण के लिए:
$ ./skipfish -B .google-analytics.com -B .googleapis.com ...अन्य
पैरामीटर...
डिफ़ॉल्ट रूप से, skipfish तार पर आदान-प्रदान किए गए डेटा की मात्रा को कम करने के लिए न्यूनतम HTTP हेडर भेजता है; हालाँकि, कुछ साइटें असमर्थित क्लाइंटों को अस्वीकार करने के लिए User-Agent स्ट्रिंग या हेडर ऑर्डरिंग की जाँच करती हैं। ऐसे मामले में, आप दो लोकप्रिय ब्राउज़रों (या iPhone) में से किसी एक की नकल करने के लिए -b ie, -b ffox, या -b phone का उपयोग कर सकते हैं।
जब आपके HTTP अनुरोधों को अनुकूलित करने की बात आती है, तो आप कोई भी अतिरिक्त, गैर-मानक हेडर डालने के लिए -H विकल्प का भी उपयोग कर सकते हैं; या होस्ट और IP के बीच एक कस्टम मैपिंग परिभाषित करने के लिए -F (रिज़ॉल्वर को बायपास करके)। बाद की सुविधा विशेष रूप से अभी-लॉन्च नहीं हुई या लिगेसी सेवाओं के लिए उपयोगी है।
कुछ साइटें उचित समय सीमा में स्कैन करने के लिए बहुत बड़ी हो सकती हैं। यदि साइट में अच्छी तरह से परिभाषित टारपिट्स हैं - उदाहरण के लिए, सोशल नेटवर्क के हिस्से के रूप में 100,000 लगभग समान उपयोगकर्ता प्रोफ़ाइल - इन विशिष्ट स्थानों को -X या -S के साथ बाहर रखा जा सकता है। अन्य मामलों में, आपको अन्य सेटिंग्स का सहारा लेने की आवश्यकता हो सकती है: -d क्रॉल गहराई को निर्दिष्ट संख्या में सबडायरेक्ट्रीज़ तक सीमित करता है; -c प्रति डायरेक्ट्री बच्चों की संख्या सीमित करता है; -x प्रति क्रॉल ट्री शाखा कुल वंशजों की संख्या सीमित करता है; और -r स्कैन में भेजे जाने वाले अनुरोधों की कुल संख्या सीमित करता है।
बार-बार मूल्यांकन के लिए एक दिलचस्प विकल्प उपलब्ध है: -p। 1 से 100% के बीच प्रतिशत निर्दिष्ट करके, क्रॉलर को सभी लिंक के 100% से कम का पालन करने और शब्दकोश की सभी प्रविष्टियों के 100% से कम प्रयास करने के लिए कहना संभव है। यह - स्वाभाविक रूप से - स्कैन की पूर्णता को सीमित करता है, लेकिन अधिकांश अन्य सेटिंग्स के विपरीत, यह संतुलित, गैर-नियतात्मक तरीके से करता है। यह अत्यंत उपयोगी है जब आप अपने बुनियादी ढांचे के समय-बद्ध, लेकिन आवधिक मूल्यांकन स्थापित कर रहे हैं। एक और संबंधित विकल्प -q है, जो क्रॉलर के लिए प्रारंभिक यादृच्छिक बीज को निर्दिष्ट मान पर सेट करता है। इसका उपयोग परिणामों की तुलना करने के लिए पिछले स्कैन को ठीक से पुन: उत्पन्न करने के लिए किया जा सकता है। यादृच्छिकता सबसे अधिक -p मोड में निर्भर है, लेकिन कहीं और कुछ अन्य स्कैन प्रबंधन निर्णय लेने के लिए भी।
कुछ विशेष रूप से जटिल (या टूटी हुई) सेवाओं में बहुत अधिक संख्या में समान या लगभग समान पृष्ठ शामिल हो सकते हैं। हालाँकि ये घटनाएँ डिफ़ॉल्ट रूप से रिपोर्ट में ग्रे की जाती हैं, फिर भी वे कुछ स्क्रीन स्थान का उपयोग करती हैं और JavaScript स्तर पर संसाधित होने में कुछ समय लेती हैं। ऐसे चरम मामलों में, आप रिपोर्ट लिखे जाने से पहले डुप्लिकेट नोड्स की रिपोर्टिंग को पूरी तरह से दबाने के लिए -Q विकल्प का उपयोग कर सकते हैं। यह आपको साइट के आयोजन की कम व्यापक समझ दे सकता है, लेकिन परीक्षण कवरेज पर कोई प्रभाव नहीं पड़ता है।
कुछ त्वरित मूल्यांकनों में, आपको साइट की वांछित कार्यक्षमता पर कोई विशेष ध्यान देने में भी रुचि नहीं हो सकती है - केवल गैर-लिंक किए गए रहस्यों का पता लगाने की उम्मीद में। ऐसे मामले में, आप सभी HTML पार्सिंग को रोकने के लिए -P निर्दिष्ट कर सकते हैं। यह कवरेज को सीमित करता है और HTML को देखकर स्कैनर के लिए नए कीवर्ड सीखने की क्षमता को हटा देता है, लेकिन परीक्षण को नाटकीय रूप से तेज करता है। एक और समान रूप से अपंग करने वाला विकल्प जो स्कैन के लगातार प्रभावों के जोखिम को कम करता है, -O है, जो सभी फ़ॉर्म पार्सिंग और सबमिशन चरणों को रोकता है।
कुछ साइटें जो संवेदनशील उपयोगकर्ता डेटा संभालती हैं, SSL के बारे में परवाह करती हैं - और इसे सही करने के बारे में। Skipfish वैकल्पिक रूप से समस्याग्रस्त मिक्स्ड कंटेंट या पासवर्ड सबमिशन परिदृश्यों को समझने में आपकी सहायता कर सकता है - इसे सक्षम करने के लिए -M विकल्प का उपयोग करें। स्कैनर https:// पृष्ठों पर लोड किए जा रहे http:// स्क्रिप्ट जैसी स्थितियों के बारे में शिकायत करेगा - लेकिन छवियों जैसे गैर-जोखिम परिदृश्यों की उपेक्षा करेगा।
इसी तरह, कुछ पांडित्यपूर्ण साइटें उन मामलों की परवाह कर सकती हैं जहाँ HTTP/1.1 स्तर पर कैशिंग प्रतिबंधित है, लेकिन कमांड-लाइन में -E निर्दिष्ट करने पर कोई स्पष्ट HTTP/1.0 कैशिंग निर्देश नहीं दिया गया है, जिससे skipfish ऐसे सभी मामलों को ध्यान से लॉग करता है।
कुछ अवसरों पर, आप लक्ष्य सर्वर पर लोड सीमित करने के लिए (या संभवतः DoS सुरक्षा को बायपास करने के लिए) प्रति सेकंड अनुरोधों को सीमित करना चाहते हैं। -l फ्लैग का उपयोग इस सीमा को सेट करने के लिए किया जा सकता है और दिया गया मान प्रति सेकंड अनुरोधों की अधिकतम मात्रा है जिसे आप skipfish द्वारा करना चाहते हैं।
स्कैन में आमतौर पर सप्ताह नहीं लगने चाहिए। कई मामलों में, आप शायद स्कैन अवधि को सीमित करना चाहते हैं ताकि यह एक निश्चित समय विंडो में फिट हो सके। यह -k फ्लैग के साथ किया जा सकता है, जो घंटों, मिनटों और सेकंडों की मात्रा को H:M:S प्रारूप में निर्दिष्ट करने की अनुमति देता है। इस फ्लैग का उपयोग स्कैन कवरेज को प्रभावित कर सकता है यदि सभी पृष्ठों के परीक्षण से पहले स्कैन टाइमआउट होता है।
अंत में, कुछ मूल्यांकनों में जिनमें व्यापक उपयोगकर्ता सामग्री के बिना स्व-निहित साइटें शामिल हैं, लेखा परीक्षक किसी भी बाहरी ई-मेल या देखे गए HTTP लिंक की परवाह कर सकता है, भले ही उनका कोई तत्काल सुरक्षा प्रभाव न हो। इन्हें लॉग करने के लिए -U विकल्प का उपयोग करें।
शब्दकोश प्रबंधन एक विशेष विषय है, और - जैसा कि उल्लेख किया गया है - doc/dictionaries.txt में अधिक विवरण में शामिल है। आगे बढ़ने से पहले कृपया उस फ़ाइल को पढ़ें। कुछ प्रासंगिक विकल्पों में -S और -W (पहले कवर किए गए), स्वतः-सीखने को दबाने के लिए -L, कीवर्ड अनुमान जार आकार सीमित करने के लिए -G, पुरानी शब्दकोश प्रविष्टियों को हटाने के लिए -R, और महंगे $keyword.$extension फज़िंग को रोकने के लिए -Y शामिल हैं।
Skipfish में स्कैन कवरेज को अधिकतम करने के लिए एक फ़ॉर्म ऑटो-कम्प्लीशन तंत्र भी है। मान गैर-दुर्भावनापूर्ण होने चाहिए, क्योंकि वे सुरक्षा जाँचों को लागू करने के लिए नहीं हैं - बल्कि, इनपुट सत्यापन तर्क से गुजरने के लिए हैं। आप -T विकल्प के साथ अतिरिक्त नियम परिभाषित कर सकते हैं, या मौजूदा नियमों को ओवरराइड कर सकते हैं (-T form_field_name=field_value, जैसे -T login=test123 -T password=test321 - हालाँकि ध्यान दें कि -C और -A लॉग इन करने का एक बेहतर तरीका है)।
```प्रदर्शन-संबंधी विकल्पों का एक समूह भी है। सभी लक्ष्यों के लिए वैश्विक रूप से बनाए रखने हेतु कनेक्शनों की अधिकतम संख्या निर्धारित करने के लिए `-g` का उपयोग करें (अपने सिस्टम या आस-पास के NAT/फ़ायरवॉल उपकरणों पर TCP/IP स्टैक को अत्यधिक भारित करने से बचने के लिए इसे लगभग 50 से कम रखना उचित है); तथा प्रति-IP सीमा निर्धारित करने के लिए `-m` का उपयोग करें (थोड़ा प्रयोग करें: localhost के लिए 2-4 सामान्यतः अच्छा रहता है, स्थानीय नेटवर्क के लिए 4-8, बाहरी लक्ष्यों के लिए 10-20, तथा अत्यधिक धीमे या non-keep-alive होस्ट्स के लिए 30+)। आप I/O टाइमआउट निर्धारित करने के लिए `-w` का भी उपयोग कर सकते हैं (अर्थात, skipfish किसी व्यक्तिगत read या write के लिए केवल एक निश्चित समय तक प्रतीक्षा करेगा), तथा कुल अनुरोध टाइमआउट निर्धारित करने के लिए `-t` का, ताकि अत्यधिक धीमी या अत्यधिक तेज़ साइटों को ध्यान में रखा जा सके।
अंत में, `-f` उन लगातार HTTP त्रुटियों की अधिकतम संख्या नियंत्रित करता है जिन्हें आप स्कैन रद्द करने से पहले देखना चाहते हैं; तथा `-s` किसी प्रतिक्रिया को लाने और पार्स करने की अधिकतम लंबाई निर्धारित करता है (लंबी प्रतिक्रियाएँ काट दी जाएँगी)।
बड़ी, मल्टीमीडिया-भारी साइटों को स्कैन करते समय, आप `-e` निर्दिष्ट करना चाह सकते हैं। यह बाइनरी दस्तावेज़ों को रिपोर्टिंग उद्देश्यों के लिए मेमोरी में रखने से रोकता है, और बहुत सारी RAM मुक्त करता है।
आगे की दर-सीमा (rate-limiting) तृतीय-पक्ष यूज़र मोड टूल्स जैसे trickle, या कर्नेल-स्तरीय ट्रैफ़िक शेपिंग के माध्यम से उपलब्ध है।
और हाँ, रीयल-टाइम स्कैन आँकड़ों को `-u` के साथ दबाया जा सकता है।
--------------------------------
6. लेकिन गंभीरता से, इसे कैसे चलाएँ?
--------------------------------
एक सुव्यवस्थित और स्व-निहित साइट का एक मानक, प्रमाणित स्कैन (सभी बाहरी लिंक, ईमेल, मिश्रित सामग्री, और कैशिंग हेडर समस्याओं के बारे में चेतावनी देता है), जिसमें हल्का brute-force शामिल है:
$ touch new_dict.wl
$ ./skipfish -MEU -S dictionaries/minimal.wl -W new_dict.wl \
-C "AuthCookie=value" -X /logout.aspx -o output_dir \
http://www.example.com/
पाँच-कनेक्शन क्रॉल, लेकिन कोई brute-force नहीं; MSIE होने का दिखावा करते हुए और example.com सामग्री पर भरोसा करते हुए:
$ ./skipfish -m 5 -L -W- -o output_dir -b ie -B example.com \
http://www.example.com/
केवल भारी brute force (कोई HTML लिंक निष्कर्षण नहीं), एक एकल निर्देशिका तक सीमित और 5 सेकंड के बाद टाइमआउट:
$ touch new_dict.wl
$ ./skipfish -S dictionaries/complete.wl -W new_dict.wl \
-P -I http://www.example.com/dir1/ -o output_dir -t 5 -I \
http://www.example.com/dir1/
सभी कमांड-लाइन विकल्पों की एक संक्षिप्त सूची के लिए, ./skipfish -h आज़माएँ।
----------------------------------------------------
7. रिपोर्ट की गई समस्याओं की व्याख्या और समाधान कैसे करें?
----------------------------------------------------
skipfish द्वारा रिपोर्ट की गई अधिकांश समस्याएँ स्वतः स्पष्ट होनी चाहिए, बशर्ते आपको वेब सुरक्षा के मूल सिद्धांतों की अच्छी समझ हो। यदि आपको कुछ अधिक जटिल विषयों, जैसे MIME sniffing, पर त्वरित पुनर्कथन की आवश्यकता है, तो आपको हमारी व्यापक Browser Security Handbook एक प्रारंभिक बिंदु के रूप में पसंद आ सकती है:
http://code.google.com/p/browsersec/
यदि आपको अभी भी सहायता चाहिए, तो कई संगठन हैं जो सामान्य वेब सुरक्षा खतरों में से कई का दस्तावेजीकरण और व्याख्या करने, तथा जनता को उनके समाधान के बारे में सलाह देने में काफी प्रयास करते हैं। मैं आपको OWASP और Web Application Security Consortium द्वारा प्रकाशित सामग्री को देखने के लिए प्रोत्साहित करता हूँ, अन्यों के अलावा:
* http://www.owasp.org/index.php/Category:Principle
* http://www.owasp.org/index.php/Category:OWASP_Guide_Project
* http://www.webappsec.org/projects/articles/
हालाँकि मुझे स्कैनर की समस्याओं का निदान करने में खुशी होती है, दुर्भाग्य से मैं तृतीय-पक्ष वेब अनुप्रयोगों के आंतरिक कार्यों में कोई सहायता नहीं दे सकता।
---------------------------------------
8. ज्ञात सीमाएँ / सुविधा इच्छा-सूची
---------------------------------------
नीचे skipfish में वर्तमान में अनुपलब्ध सुविधाओं की एक सूची दी गई है। यदि आप इनमें से किसी क्षेत्र में कोड का योगदान करके टूल को बेहतर बनाना चाहते हैं, तो कृपया मुझे बताएं:
* बफर ओवरफ्लो जाँच: सावधानीपूर्वक विचार करने के बाद, मुझे संदेह है कि बफर ओवरफ्लो के लिए दूरस्थ रूप से परीक्षण करने का कोई विश्वसनीय तरीका नहीं है। जिस वास्तविक दोष स्थिति की हम तलाश कर रहे हैं, उसी तरह उचित बफर आकार जाँच के परिणामस्वरूप भी अनकैच्ड अपवाद, 500 संदेश आदि हो सकते हैं। हालाँकि, मुझे यह सिद्ध होता देख अच्छा लगेगा कि मैं गलत हूँ।
* पूर्ण विकसित JavaScript XSS का पता लगाना: कोड में कई प्रारंभिक जाँचें मौजूद हैं, लेकिन अभिव्यक्तियों और DOM एक्सेस का मूल्यांकन करने के लिए कोई उचित स्क्रिप्ट इंजन निर्मित नहीं है।
* परिवर्तनीय लंबाई एन्कोडिंग वर्ण खपत / इंजेक्शन बग: ये समस्याएँ इस बिंदु पर बड़े पैमाने पर ब्राउज़र स्तर पर हल हो गई लगती हैं, इसलिए इस लेखन के समय उनकी प्राथमिकता बहुत कम थी।
* तृतीय-पक्ष, प्लगइन-आधारित सामग्री (Flash, Java, PDF, आदि) के लिए सुरक्षा जाँच और लिंक निष्कर्षण।
* पासवर्ड brute-force और संख्यात्मक फ़ाइलनाम brute-force प्रोब।
* खोज इंजन एकीकरण (vhosts, प्रारंभिक पथ)।
* VIEWSTATE डिकोडिंग।
* NTLM और digest प्रमाणीकरण।
* अधिक विशिष्ट PHP परीक्षण (eval इंजेक्शन, RFI)।
* प्रॉक्सी समर्थन: config.h में #define निर्देश के माध्यम से एक प्रयोगात्मक HTTP प्रॉक्सी समर्थन उपलब्ध है। HTTPS प्रॉक्सिंग के लिए समर्थन जोड़ना अधिक जटिल है, और अभी भी कार्याधीन है।
* स्कैन फिर से शुरू करने का विकल्प, बेहतर रनटाइम जानकारी।
* स्टैंडअलोन इंस्टॉलेशन (make install) समर्थन।
* शेड्यूलिंग और प्रबंधन वेब UI।
-------------------------------------
9. अरे! कुछ बुरी तरह गलत हो गया!
-------------------------------------
ऐसा कोई वेब क्रॉलर नहीं है जो इतना अच्छा हो कि कोई वेब फ्रेमवर्क उसे किसी दिन आग न लगा दे। यदि आपको कुछ गलत व्यवहार दिखे (जैसे, एक स्कैन जो हमेशा के लिए चलता है और बहुत सारे अनुरोध उत्पन्न करता है, स्कैन आउटपुट में पूरी तरह से फर्जी नोड्स, या सीधे क्रैश), तो कृपया पहले हमारे ज्ञात मुद्दों वाले पृष्ठ को देखें:
http://code.google.com/p/skipfish/wiki/KnownIssues
यदि आपको वहाँ संतोषजनक उत्तर नहीं मिलता है, तो स्कैनर को इस प्रकार पुनः संकलित करें:
$ make clean debug
...और इसे इस प्रकार पुनः चलाएँ:
$ ./skipfish [...previous options...] 2>logfile.txt
फिर आप यह जानने के लिए logfile.txt का निरीक्षण कर सकते हैं कि क्या गलत हुआ; यदि यह स्कैनर की समस्या लगती है, तो कृपया लॉग फ़ाइल से किसी भी संवेदनशील जानकारी को हटा दें और इसे लेखक को भेजें।
यदि स्कैनर क्रैश हो गया, तो कृपया ऊपर बताए अनुसार इसे पुनः संकलित करें, और फिर टाइप करें:
$ ulimit -c unlimited
$ ./skipfish [...previous options...] 2>logfile.txt
$ gdb --batch -ex back ./skipfish core
...और उस अंतिम कमांड का आउटपुट भी लेखक को अवश्य भेजें।
------------------------
10. श्रेय और प्रतिक्रिया
------------------------
Skipfish, Google की सूचना सुरक्षा इंजीनियरिंग टीम के योगदान और बहुमूल्य प्रतिक्रिया की बदौलत संभव हुआ है।
यदि आपके पास एप्लिकेशन से संबंधित कोई बग रिपोर्ट, प्रश्न, सुझाव या चिंताएँ हैं, तो मुख्य लेखक से [email protected] पर संपर्क किया जा सकता है।