hakluke/bug-bounty-standardsबग बाउंटी कार्यक्रमों में होने वाले एज केसों की एक सूची, और इस बारे में चर्चा कि उन्हें कैसे संभाला जाना चाहिए। लक्ष्य बग बाउंटी में विशिष्ट स्थितियों को संभालने के तरीके को मानकीकृत करना है।
यह रिपॉजिटरी बग बाउंटी प्रोग्रामों में होने वाली स्थितियों और उन्हें कैसे संभाला जाना चाहिए, की एक सूची है। इनमें से कई को वर्तमान में मामले-दर-मामले के आधार पर संभाला जाता है, जिससे हैकर्स, प्रोग्राम मालिकों और प्लेटफार्मों के बीच बहुत अनिश्चितता और निराशा पैदा होती है। इस रिपॉजिटरी का लक्ष्य इन किनारे-मामलों (edge-cases) को सभी बाउंटी प्लेटफार्मों और प्रोग्रामों में एक समान तरीके से संभालने के लिए मानकीकृत करना है। उम्मीद है कि मानकीकरण से सभी पक्षों की अपेक्षाएँ अधिक बार पूरी हो सकेंगी।
यह दस्तावेज़ एक मसौदा है, और अभी तक किसी भी बग बाउंटी प्लेटफॉर्म द्वारा लागू नहीं किया गया है। इस चरण में, मैं सभी इच्छुक पार्टियों से टिप्पणियाँ माँग रहा हूँ।
कृपया GitHub issues खोलकर योगदान करें। प्रस्तुत सभी उचित issues टिप्पणियों के लिए न्यूनतम 30 दिनों तक खुले रहेंगे।
आपकी issue में एक राय होनी चाहिए, जैसे:
Issue पर टिप्पणियाँ किसी भी व्यक्ति के लिए स्वागत योग्य हैं, लेकिन वे रचनात्मक और भावनाहीन होनी चाहिए। दुर्व्यवहार करने वाले व्यवहार को बर्दाश्त नहीं किया जाएगा।
| ID | स्थिति | समाधान |
|---|
| 1 | हैकर शोषण के प्रमाण के साथ भेद्यता प्रस्तुत करता है। सबमिशन के ट्रायेज से पहले भेद्यता को ठीक कर दिया जाता है। | प्लेटफ़ॉर्म को यह प्रमाण प्रदान करना होगा कि समाधान से पहले प्रोग्राम द्वारा सबमिशन एक्सेस नहीं किया गया था। यदि सबमिशन प्रोग्राम द्वारा एक्सेस किया गया था, तो प्रोग्राम को प्रासंगिक बाउंटी का भुगतान करना चाहिए, अन्यथा सबमिशन को डुप्लिकेट के रूप में चिह्नित किया जाता है। |
| 2 | हैकर भेद्यता प्रस्तुत करता है, प्रोग्राम जवाब देता है कि उन्हें इसके बारे में पहले से ही आंतरिक रूप से पता था। | प्रोग्राम को यह प्रमाण प्रदान करना होगा कि यह पहले से ज्ञात समस्या थी, उदाहरण के लिए, बनाने की तिथि सहित Jira टिकट का स्क्रीनशॉट। यदि प्रोग्राम प्रमाण प्रदान करने में असमर्थ है, तो उन्हें बाउंटी का भुगतान करना चाहिए, अन्यथा सबमिशन को डुप्लिकेट के रूप में चिह्नित किया जाना चाहिए। |
| 3 | हैकर भेद्यता प्रस्तुत करता है, इसे किसी अन्य सबमिशन का डुप्लिकेट चिह्नित किया जाता है जिसने बग के प्रभाव की पूरी तरह से खोज नहीं की थी। उदाहरण के लिए, एक हैकर एक पूर्ण XSS प्रस्तुत करता है जो खाते पर कब्ज़ा करने की अनुमति देता है, और इसे किसी अन्य सबमिशन के विरुद्ध डुप्लिकेट ठहराया जाता है जिसने केवल HTML इंजेक्शन की रिपोर्ट की थी। | पहले रिपोर्ट करने वाले को उनके सबमिशन के प्रभाव के आधार पर बाउंटी मिलती है, दूसरे रिपोर्ट करने वाले को उनके सबमिशन के प्रभाव के आधार पर बाउंटी मिलती है जिसमें से पहले रिपोर्ट करने वाले द्वारा प्राप्त बाउंटी घटा दी जाती है। |
| 4 | हैकर भेद्यता प्रस्तुत करता है, प्रोग्राम कभी जवाब नहीं देता। | प्लेटफ़ॉर्म बाउंटी का भुगतान करता है। |
| 5 | हैकर भेद्यता प्रस्तुत करता है, हैकर को गलत तरीके से एक नई रिपोर्ट के विरुद्ध डुप्लिकेट ठहराया जाता है। | प्लेटफ़ॉर्म दोनों रिपोर्टों की स्थिति को सटीक बनाने के लिए बदलता है। यदि भुगतान पहले ही गलत तरीके से किया जा चुका है, तो जिस संगठन ने गलत ट्रायेज किया, वह बाउंटी का भुगतान करता है। प्रबंधित बाउंटी कार्यक्रमों के लिए यह आम तौर पर प्लेटफ़ॉर्म होगा, लेकिन अप्रबंधित कार्यक्रमों के लिए यह प्रोग्राम होगा। |
| 6 | हैकर निर्धारित गंभीरता रेटिंग से असहमत है। | हैकर टिकट पर तर्क प्रस्तुत करता है। यदि 14 दिनों तक कोई प्रतिक्रिया नहीं मिलती है, तो हैकर प्लेटफ़ॉर्म के समर्थन चैनल पर तर्क प्रस्तुत करता है। गंभीरता उन्नयन का निर्णय प्रति-सबमिशन आधार पर किया जाता है। |
| 7 | हैकर एक ऐसे बग को सार्वजनिक रूप से उजागर करता है जो पहले प्लेटफ़ॉर्म पर प्रस्तुत किया जा चुका है, बिना प्रोग्राम मालिक की स्पष्ट अनुमति के। | एक शोधकर्ता को निम्नलिखित परिस्थितियों में भेद्यता का सार्वजनिक रूप से खुलासा करने में सक्षम होना चाहिए: a) बग को वैध के रूप में स्वीकार नहीं किया गया है, अर्थात इसे N/A या Informative के रूप में चिह्नित किया गया है। b) बग 30+ दिनों से हल (resolved) स्थिति में है। c) शोधकर्ता के पास प्रोग्राम से सार्वजनिक खुलासा करने की स्पष्ट अनुमति है। अन्य मामलों में, हैकर को प्लेटफ़ॉर्म से 30 दिन का प्रतिबंध मिलता है, हैकर को प्रतिबंध के पीछे पूर्ण तर्क के साथ ईमेल किया जाता है। बार-बार अपराध करने पर स्थायी प्रतिबंध लगता है। |
| 8 | हैकर एक ऐसा बग प्रस्तुत करता है जो प्रोग्राम के दायरे में है, लेकिन वास्तव में किसी तृतीय-पक्ष सेवा में बग है। | प्रत्येक प्रोग्राम को अपने ब्रीफ में यह निर्दिष्ट करना चाहिए कि क्या वे तृतीय-पक्ष प्रणालियों पर बग स्वीकार करते हैं। यदि कोई विशिष्टता नहीं है, तो यह मान लिया जाता है कि दायरे में सूचीबद्ध सभी प्रणालियाँ भुगतान के लिए मान्य होंगी, जिसमें तृतीय-पक्ष प्रणालियाँ भी शामिल हैं। |
| 9 | हैकर एक ज़ीरो-डे भेद्यता प्रस्तुत करता है जिसमें कोई सार्वजनिक एक्सप्लॉइट या खुलासा मौजूद नहीं है, और जो दायरे में आने वाली प्रणालियों को प्रभावित करती है। | यदि रिपोर्ट के परिणामस्वरूप कोई परिवर्तन किए गए थे, जैसे कॉन्फ़िगरेशन परिवर्तन, सिस्टम को ऑफ़लाइन ले जाना, या WAF नियम लागू करना, तो रिपोर्ट को स्वीकार किया जाना चाहिए और पुरस्कृत किया जाना चाहिए। सार्वजनिक ज़ीरो-डे एक्सप्लॉइट्स और उन ज़ीरो-डे एक्सप्लॉइट्स के बीच अंतर किया जाना चाहिए जिनके बारे में आपकी टीम को बग बाउंटी रिपोर्ट के अलावा पता नहीं होता। |
| 10 | हैकर एक ऐसे प्रोग्राम में बग प्रस्तुत करता है जिसका स्कोप ब्रीफ खुला है। बग किसी अधिग्रहण (acquisition) पर है। प्रोग्राम मालिक अधिग्रहण के आईटी बुनियादी ढांचे या कर्मचारियों को नियंत्रित नहीं करता है। | प्रोग्राम मालिक को प्लेटफ़ॉर्म द्वारा सत्यापित, अच्छे विश्वास में प्रयास करना चाहिए कि अधिग्रहण को सूचित किया जाए। यदि अधिग्रहण को सबमिशन से लाभ होता है, तो प्रोग्राम मालिक को बाउंटी का भुगतान करना चाहिए। ब्रीफ को यह दर्शाने के लिए अद्यतन किया जाना चाहिए कि क्या अधिग्रहण दायरे में हैं। |
