Payload और Polyglot सूचियाँ

कोई payload काम नहीं कर रहा मिला? कृपया payload, लक्ष्य संदर्भ, और आप क्या होने की अपेक्षा करते थे, के साथ एक issue खोलें। सुधार या नए payload के साथ pull requests का हमेशा स्वागत है।

शोध जारी है। यह परियोजना सक्रिय विकास में है और इसे नए injection संदर्भों, payloads, और validation सुधारों के साथ अद्यतन किया जाएगा।

अस्वीकरण: ये payloads केवल अधिकृत सुरक्षा परीक्षण, शिक्षा, और शोध उद्देश्यों के लिए प्रदान किए गए हैं। लेखक किसी भी दुरुपयोग या परिणामी प्रभावों की कोई जिम्मेदारी या दायित्व नहीं लेते हैं। पूरी तरह से अपने जोखिम पर उपयोग करें। इस परियोजना का उपयोग करके आप अपने कार्यों की पूरी जिम्मेदारी स्वीकार करते हैं।

लाइसेंस: MIT - देखें LICENSE

37 सुरक्षा-परीक्षण श्रेणियों में 1,618 अद्वितीय payload स्ट्रिंग्स के साथ-साथ एक क्रॉस-कटिंग polyglot सेट, 35 नामित deserialization प्रारूप, लाइब्रेरी, और sinks, और 20 template engines। संदर्भ-संरक्षण करने वाले मास्टर में 661 अनुभागों में 1,760 payload-to-section असाइनमेंट हैं, इसलिए एक साझा स्ट्रिंग हर उस parser और insertion संदर्भ से जुड़ी रहती है जहाँ वह लागू होती है। 108-payload न्यूनतम सूची में GraphQL, HQL/JPQL, XPath, JSONPath, JSON निर्माण, HTTP parameter pollution, XQuery, Firestore, SMTP/IMAP और ईमेल हेडर, Host हेडर, XML/SOAP संरचना, LDAP DN, HTML/CSS, CSV, logs, और LaTeX के लिए प्रतिनिधि probes शामिल हैं। Validation कवरेज payload, parser, और insertion संदर्भ के अनुसार भिन्न होती है।

भाषा मैट्रिक्स में C, C++, C#, Dart, Elixir, Erlang, Go, Java, JavaScript, Kotlin, Lua, Objective-C, Perl, PHP, Python, Ruby, Rust, Scala, Swift, और TypeScript शामिल हैं।

सामान्य validator एक smoke check है, शोषण का प्रमाण नहीं: पहले के परिणामों में मनमानी त्रुटियों और request timeouts को hits के रूप में गिना जाता था। संदर्भ regression में नौ live SQL dialects शामिल हैं, जिनमें string, numeric, injected ORDER BY clause और direct sort-expression स्थितियाँ शामिल हैं; GraphQL.js, Hibernate HQL/JPQL, direct XPath/XQuery/JSONPath, JSON निर्माण और duplicate-parameter pollution, Firestore structured filters, SMTP/IMAP command और email-header injection, Host-header URL poisoning, XML और SOAP संरचना, LDAP filter और DN injection, Chromium में HTML/CSS/XSS, CSV formula-cell breakout, log forging, LaTeX source injection, POSIX shell quote/backtick/pipeline, $() और percent-decoded newline संदर्भ, local SSRF/path/XXE fixtures, MongoDB/CouchDB/Redis/ArangoDB/DynamoDB PartiQL/Cassandra CQL/Couchbase SQL++/Elasticsearch/Neo4j, EL, XSLT, SSI, prototype pollution, और प्रतिनिधि deserialization callbacks। Browser checks में unquoted attribute, attribute-fragment, HTML-comment, और </script> parser संदर्भ शामिल हैं। भाषा मैट्रिक्स सभी 20 अनुरोधित भाषाओं में math, errors, timing, OOB, और generated-source quote breakouts की जाँच करता है; सामान्य alternate quote और backtick string संदर्भों का परीक्षण किया जाता है जहाँ समर्थित हो, साथ ही सभी 20 में एक साझा arithmetic polyglot और जहाँ लागू हो वहाँ runtime format strings। सत्यापित मैट्रिक्स और शेष engine-specific अंतरालों के लिए COVERAGE.md देखें।

---

अवधारणा

पारंपरिक Payload सूचियों की समस्या

अधिकांश सार्वजनिक रूप से उपलब्ध payload सूचियाँ भेद्यता प्रकार के अनुसार व्यवस्थित होती हैं: SQL injection के लिए एक सूची, XSS के लिए दूसरी, command injection के लिए एक और, इत्यादि। एक tester वह सूची चुनता है जो उन्हें लगता है कि लक्ष्य से मेल खाती है, उसे intruder tool में लोड करता है, और एक parameter के विरुद्ध चलाता है। यदि वे भेद्यता वर्ग के बारे में गलत अनुमान लगाते हैं, तो पूरा scan कुछ भी उत्पन्न नहीं करता। यदि backend एक असामान्य database, एक गैर-मानक template engine, या एक ऐसी भाषा है जिसे सूची में शामिल नहीं किया गया था, तो payloads चुपचाप विफल हो जाते हैं। Tester यह सोचकर आगे बढ़ जाता है कि parameter साफ़ है।

इस दृष्टिकोण में दो मौलिक समस्याएँ हैं। पहला, यह tester से अपेक्षा करता है कि वे यह जानें कि कौन सी भेद्यता मौजूद है इससे पहले कि उन्होंने इसे खोजा हो। दूसरा, प्रचलन में अधिकांश payloads सैद्धांतिक हैं -- परियोजनाओं और ब्लॉग पोस्टों के बीच कभी वास्तविक parser के विरुद्ध परीक्षण किए बिना कॉपी किए गए। वे सही दिखते हैं। वे वाक्यात्मक रूप से वैध भी हो सकते हैं। लेकिन वे वास्तव में लक्ष्य से एक पता लगाने योग्य प्रतिक्रिया ट्रिगर नहीं करते।

Polyglot-प्रथम, Signal-चालित

यह परियोजना polyglots का उपयोग करती है जहाँ एक स्ट्रिंग कई संबंधित संदर्भों को कवर कर सकती है। एक payload का व्यवहार अभी भी इस बात पर निर्भर करता है कि कोई application इसे कैसे सम्मिलित करता है: एक shell argument unquoted, single-quoted, या double-quoted हो सकता है; SQL string और numeric expressions भिन्न होते हैं; template engines असंगत delimiters का उपयोग करते हैं। Testbed को उन wrappers को स्पष्ट रूप से मॉडल करने की आवश्यकता है। किसी भी एकल स्ट्रिंग को यह मान नहीं लेना चाहिए कि वह हर quote, comment, या parser से बाहर निकल जाएगी।

Payloads को detection pillars के आसपास समूहीकृत किया गया है -- अवलोकनीय प्रतिक्रियाएँ जो एक मेल खाते संदर्भ में साक्ष्य प्रदान कर सकती हैं:

• Error: payload एक server-side parser या interpreter त्रुटि का कारण बनता है जो प्रतिक्रिया में दिखाई देती है। एक baseline से तुलना करें; अकेली एक त्रुटि injection साबित नहीं करती।
• Math: payload में 7*191 जैसी एक arithmetic expression शामिल है जो 1337 का मूल्यांकन करती है। यदि वह संख्या प्रतिक्रिया में दिखाई देती है और payload ने केवल 7*191 भेजा (शाब्दिक 1337 नहीं), तो लक्ष्य parser ने expression का मूल्यांकन किया। परिणाम उस sink में मूल्यांकन साबित करता है, जो एक query, template, expression language, या code runtime हो सकता है।
• Timing: payload एक विलंब (5+ सेकंड) को बाध्य करता है। एक baseline से तुलना करें और विलंब को निष्पादन मानने से पहले client या server timeouts को बाहर करें।
• OOB (Out-of-Band): payload backend को tester द्वारा नियंत्रित एक callback server से एक outbound HTTP, DNS, LDAP, या TCP कनेक्शन बनाने का कारण बनता है। यह परीक्षण किए गए sink के माध्यम से एक outbound interaction की पुष्टि करता है भले ही प्रतिक्रिया पूरी तरह से अपारदर्शी हो; यह अपने आप में उस primitive की पहचान नहीं करता जिसने request बनाई।

ये signals केवल तब उपयोगी होते हैं जब payload के वास्तविक संदर्भ में जाँचे जाएँ। सामान्य validator एक smoke test है; अकेले एक parser error, timeout, या reflected string यह साबित नहीं करता कि एक payload निष्पादित हुआ। मजबूत साक्ष्य के लिए context-specific Docker checks का उपयोग करें।

Shell कमांड के बजाय Built-ins

पारंपरिक OOB और timing payloads shell कमांड पर निर्भर करते हैं: curl, nslookup, ping, sleep। ये लगातार टूटते रहते हैं। वे लक्ष्य OS, उपलब्ध PATH, कौन सा shell कमांड की व्याख्या करता है, और क्या प्रक्रिया को subprocesses spawn करने की अनुमति है, पर निर्भर करते हैं। एक curl-आधारित OOB payload जो Ubuntu पर काम करता है, Alpine पर विफल हो जाता है (curl नहीं), Windows पर विफल हो जाता है (curl नहीं), और एक प्रतिबंधित container के अंदर विफल हो जाता है (कोई outbound process execution नहीं)।

यह परियोजना जहाँ संभव हो वहाँ shell कमांड को language-native built-ins से प्रतिस्थापित करती है। Python payloads urllib.request.urlopen() और time.sleep() का उपयोग करते हैं। Java payloads java.net.URL.openStream() और Thread.sleep() का उपयोग करते हैं। Ruby Net::HTTP.get() और Kernel.sleep() का उपयोग करता है। PHP file_get_contents() और sleep() का उपयोग करता है। ये फ़ंक्शन language runtime या standard library से आते हैं, इसलिए वे PATH lookup और subprocess निर्भरताओं से बचते हैं। Runtime policy और configuration अभी भी network access या व्यक्तिगत APIs को अक्षम कर सकते हैं; fixture matrix उस सटीक वातावरण को रिकॉर्ड करता है जिसका अभ्यास किया गया था।

जहाँ standard library imports अवरुद्ध हो सकते हैं, कुछ payloads import-free विकल्पों का उपयोग करते हैं जैसे Node में Atomics.wait() और OOB के लिए raw socket connections। Resource-heavy loops को डिफ़ॉल्ट corpus checks से बाहर रखा गया है।

जहाँ Polyglots नहीं पहुँचते