Methodology on Crusader Research

Line jumping: कैसे एक ज़हरीला MCP tool उस model को हाईजैक कर लेता है जिसे कभी बुलाया ही नहीं गया

Sun, 05 Jul 2026 00:00:00 +0000

अधिकांश MCP सुरक्षा लेख आपको बताते हैं कि हर server “एक नई trust boundary” है। सच है, और बेकार है — क्योंकि यह आपको एक ऐसा दरवाज़ा दिखाता है जिससे होकर गुज़रने का चुनाव आप करते हैं। असली समस्या यह है कि आप ऐसा नहीं करते। खतरनाक निर्देश उसी पल चल जाता है जब आप server को connect करते हैं, कुछ भी invoke करने से पहले। हमला handshake के समय चलता है, call के समय नहीं।

single-packet attack से वेब race conditions को जीतना

Sun, 05 Jul 2026 00:00:00 +0000

अधिकांश लेख आपको बताते हैं कि race condition एक “check और use के बीच का timing window” है। सही है, और बेकार भी — क्योंकि आपके race attacks के असफल होने की वजह यह नहीं है कि आप concept नहीं समझते। वजह यह है कि window इतना छोटा है कि internet की precision उसके सामने कम पड़ जाती है।

एक सामान्य race window — किसी app द्वारा balance पढ़ने और balance - amount लिखने के बीच का अंतराल — microseconds से लेकर कुछ milliseconds में मापा जाता है। दो HTTP requests जिन्हें आप एक ही क्षण पर भेजते हैं, उनके पहुँचने और server पर schedule होने तक का jitter नियमित रूप से 1 से 10 milliseconds होता है, और public internet के आर-पार तो और भी बुरा। तो आपकी “एक-साथ वाली” requests एक साफ-सुथरी कतार में पहुँचती हैं, server उन्हें एक-एक करके process करता है, limit टिकी रहती है, और आप निष्कर्ष निकाल लेते हैं कि endpoint सुरक्षित है। वह नहीं है। आप बस server के वोट देने से पहले ही network jitter के हाथों race हार गए।

आसान फ़िल्टरों को पार करते हुए SSRF: URL-parser की उलझन और metadata endpoint

Sun, 05 Jul 2026 00:00:00 +0000

Server-side request forgery उन कुछ bug classes में से एक है जहाँ एक अकेली खोज आपके हाथ में cloud credentials थमा देती है। इसका तंत्र कहने में मामूली है — आप server से एक ऐसा URL fetch करवाते हैं जो आपके नियंत्रण में है — और हर write-up वहीं रुक जाता है, ठीक इसीलिए वे बेकार हैं। tutorial वाला payload, URL field में चिपकाया गया http://169.254.169.254/, हर जगह blocklist हो चुका है। SSRF के 2026 में भी सबसे उपजाऊ bug classes में से एक बने रहने की वजह यह नहीं है कि developers filter करना भूल गए। वजह यह है कि उनका filter और उनका HTTP client URL को अलग-अलग पढ़ते हैं, और आप उसी अंतर में रहते हैं।

IDOR दूसरे identifier में छिपा होता है: दो-अकाउंट Shadow Replay से BOLA खोजना

Sat, 04 Jul 2026 00:00:00 +0000

हर IDOR tutorial आपको वही drill थमाता है: /api/orders/48210 ढूँढो, उसे 48211 में बदलो, एक 200 की तलाश करो। यह drill आपको ठीक उसी identifier पर हमला करना सिखाता है जिसे application के जाँचने की सबसे ज़्यादा संभावना है। URL path में primary key वहीं है जहाँ framework का @authorize annotation रहता है, जहाँ ORM query को scope करता है, जहाँ review केंद्रित रहा। यह honeypot है। आप इसे fuzz करते हैं, 403 पाते हैं, endpoint को सुरक्षित मान लेते हैं, और bug के ठीक बगल से गुज़र जाते हैं।

Indirect prompt injection एजेंट युग का SSRF है

Fri, 03 Jul 2026 00:00:00 +0000

अधिकांश लेख आपको बताते हैं कि prompt injection “तब है जब model अपने input में मौजूद instructions का पालन करता है।” सही, और बेकार — क्योंकि यह ढाँचा इसे एक chatbot की सनक जैसा दिखा देता है जिसे आप बेहतर system prompt से पैच कर देते हैं। यह वैसा नहीं है। यह एक architecture bug है जिसे आप पहले से ही किसी और नाम से जानते हैं।

SSRF इसलिए हुआ क्योंकि एक server ऐसे URL को fetch करता था जिसे आप नियंत्रित करते थे और response पर भरोसा कर लेता था। Indirect prompt injection इसलिए होती है क्योंकि एक agent ऐसी सामग्री पढ़ता है जिसे आप नियंत्रित करते हैं — एक web page, एक PDF, एक email, एक calendar invite — और उसे instructions मानकर भरोसा कर लेता है। एक ही दोष, नया माध्यम। server-side fetch एक model-side read बन गया; भरोसेमंद response एक भरोसेमंद command बन गया।