मॉड्यूल 17 · सिक्योरिटी टेस्टिंग

इंटरसेप्टिंग प्रॉक्सी

Mutqan Soft QA टीम द्वारा · · 18 मिनट · मध्यम

Intercepting proxy एक ऐसा tool है जो आपके browser और web server के बीच बैठता है और गुज़रती हर HTTP request और response आपको दिखाता है: method, URL, headers, cookies और body, सिर्फ़ तैयार page नहीं। इस पाठ में उदाहरण ZAP (Zed Attack Proxy) है, वह free open-source proxy जो लंबे समय तक OWASP ZAP के नाम से जाना गया; दूसरे intercepting proxies भी इसी तरह काम करते हैं, बस menus के नाम अलग होते हैं।

चूँकि traffic इसी से होकर बहता है, proxy हर message का searchable history रख सकता है, किसी request को रोककर (intercept) server तक पहुँचने से पहले बदलने दे सकता है, और किसी पुरानी request को अलग values के साथ replay कर सकता है। Tester इससे देखता है कि जब client कुछ ऐसा भेजे जो असली app कभी नहीं भेजती — किसी और user की order id, ऊँचा role, या बिल्कुल कोई session नहीं — तो server क्या करता है।

यह क्यों ज़रूरी है

कई गंभीर web defects उन्हीं बातों में छिपे होते हैं जिन पर server भरोसा करता है। अगर server मान ले कि browser सिर्फ़ logged-in user की order ids ही भेजेगा, तो proxy में वह id बदलकर कुछ ही मिनटों में broken access control उजागर हो सकता है — पिछले पाठ के OWASP Top 10:2025 में यह A01 है। Disabled button, hidden field और client-side validation browser के लिए सिर्फ़ सुझाव हैं; proxy आपको server को टेस्ट करने देता है, और security को वहीं टिकना होता है।

Tester के लिए proxy एक धुँधली चिंता को दोहराने-योग्य सबूत में बदल देता है: ठीक वही request, वह एक value जो आपने बदली, और response। यह ऐसी bug report है जिस पर developer काम कर सकता है, और history ठीक-ठीक दिखाता है कि आपने क्या भेजा, इसलिए आप दिखा सकते हैं कि authorised test अपनी सीमाओं के अंदर रहा।

Proxy कहाँ बैठता है, और उसे सुरक्षित तरीके से कैसे set up करें

Proxy एक local address पर listen करता है, जैसे 127.0.0.1:8080। आप browser को उस पर point करते हैं, और अब हर request browser से proxy से server तक जाती है, और हर response उसी रास्ते लौटता है। DevTools का Network panel एक tab ने जो किया उसे record करता है, जबकि proxy रास्ते में खड़ा होता है और message को server तक पहुँचने से पहले रोक सकता है।

दो set-up steps इसे सुरक्षित रखते हैं। पहला, एक dedicated test browser profile, या अलग browser, इस्तेमाल करें जो अपना traffic proxy को भेजे, ताकि आपके रोज़ के logins और cookies इससे होकर कभी न गुज़रें। दूसरा, HTTPS पढ़ने के लिए proxy browser का encrypted connection ख़ुद ख़त्म करता है और हर site के लिए अपने certificate authority (CA) से signed certificate पेश करता है। उस proxy CA पर सिर्फ़ test profile में भरोसा करें — कभी system-wide या personal device पर नहीं — क्योंकि जो browser उस पर भरोसा करता है, वह उसकी key से signed किसी भी site का कोई भी certificate स्वीकार कर लेता है। काम ख़त्म होने पर उसे हटा दें।

Test browser की request पहले proxy की scope जाँच से गुज़रती है; सिर्फ़ in-scope traffic history में दिखता है, उसी का passive scan होता है, और उसी को id, role या session value बदलने को रोका या authorised target पर replay किया जा सकता है।
  1. 1टेस्ट ब्राउज़रसारा traffic → proxyएक dedicated profile जो proxy CA certificate पर भरोसा करता है
  2. 2Scope जाँचक्या यह host authorised सूची में है?Proxy

    शाखा: Scope से बाहर → बिना बदले आगे जाता है: न intercept, न replay, न scanसावधानी

    गेट: सिर्फ़ in scope

  3. 3Historyहर request और response का searchable record; passive scanning उसे पढ़ता हैProxy
  4. 4Intercept और modifyउसे रोकें और एक id, role या session value बदलेंGET /api/orders/1043वैकल्पिक
  5. 5Authorised targetजवाब देता है; response proxy से होकर history में लौटता है

चरण 3–5 के दौरान Authorised scope के अंदर · लिखित अनुमति इन hosts को नाम से बताती है

चरण 3 पर वापस Replay: history से एक value बदलकर दोबारा भेजें

आज़माएँ: HTTP रिक्वेस्ट इंस्पेक्टर

History, intercept-and-modify, और replay

History (ZAP में History tab; कुछ tools इसे HTTP history कहते हैं) हर request और response की सूची रखता है, method, status code और किसी एक host से मेल खाने वाले URL pattern जैसे filters के साथ, ताकि सैकड़ों में से वही एक call मिल जाए जो आपको चाहिए। Intercept-and-modify request को proxy पर रोक देता है: आप एक header, parameter या body edit करते हैं, फिर उसे आगे जाने देते हैं, तो server को आपका version मिलता है, browser वाला नहीं।

Replay history की किसी request को एक value बदलकर दोबारा भेजता है ताकि आप responses की तुलना कर सकें; ZAP में उस पर right-click करके "Open/Resend with Request Editor" चुनें। Replay "button greyed out है" को server के बारे में एक तथ्य में बदल देता है। तीन replays ज़्यादातर शुरुआती checks कवर करते हैं:

  • बदली हुई id: अपना session वैसा ही रखें और किसी दूसरे user का order या profile माँगें। Server को मना करना चाहिए।
  • बदला हुआ role: ऐसी request जो सिर्फ़ admin को करनी चाहिए, एक normal user के session से दोबारा भेजें, या अपने test account को update करते समय role field को user से admin कर दें। Server को मना करना या बदलाव को ignore करना चाहिए।
  • बदली हुई session value: session cookie हटा दें, या किसी ऐसे session की cookie दोबारा इस्तेमाल करें जिससे आप log out कर चुके हैं। Server को 401 Unauthorized देना या login पर भेजना चाहिए, data कभी नहीं लौटाना चाहिए।

आज़माएँ: HTTP हेडर पार्सर आज़माएँ: API ऑथेंटिकेशन टेस्टर

Passive scanning: एक सुराग़, फ़ैसला नहीं

Traffic के इससे होकर बहते समय proxy हर message को जाँच सकता है और अपनी ओर से कुछ भेजे बिना alerts दे सकता है। यही passive scanning है, और चूँकि यह सिर्फ़ वही traffic पढ़ता है जो आप पहले से भेज और पा रहे थे, इसे सामान्य testing के दौरान चालू रखना सुरक्षित है।

Alert एक सुराग़ है, फ़ैसला नहीं: यह false positive हो सकता है, और passive scanning वह सब चूक जाता है जिसके लिए ऐसी request चाहिए जो app ने बनाई ही नहीं। Report करने से पहले हर alert की हाथ से पुष्टि करें। Active scanning, जहाँ tool अपनी ओर से गढ़ी हुई attack requests भेजता है, एक अलग, ज़्यादा जोखिम वाला mode है जिसे explicit authorisation चाहिए, और वह इस पाठ से बाहर है।

  • ग़ायब header: ऐसा response जिसमें Strict-Transport-Security या Content-Security-Policy नहीं है।
  • कमज़ोर cookie: Secure या HttpOnly attribute के बिना set की गई session cookie (RFC 6265)।
  • Leak: URL की query string में token, या stack trace दिखाता error page।

आज़माएँ: सिक्योरिटी हेडर एनालाइज़र आज़माएँ: कुकी एनालाइज़र

पहले scope और लिखित authorisation

Scope उन hosts और paths का ठीक-ठीक समूह है जिन्हें टेस्ट करने की आपको अनुमति है। Proxy में आप सिर्फ़ उन्हें in scope mark करते हैं, history में सिर्फ़ in-scope messages दिखाते हैं, और intercept, replay और scanning को उन्हीं तक सीमित रखते हैं। ZAP में आप target को In Scope mark किए गए context में जोड़ते हैं, protected mode चुन सकते हैं, जो scope के बाहर intercept, resend और active scanning जैसे संभावित रूप से ख़तरनाक actions रोक देता है, और passive scanner को सिर्फ़ in-scope messages scan करने के लिए set कर सकते हैं। Browser का बाक़ी traffic, जैसे कोई analytics host या third-party widget, आम तौर पर फिर भी proxy से गुज़रता है; scope ही आपको उसे बदलने या scan करने से रोकता है।

Authorisation system के मालिक की लिखित अनुमति है जो targets, तारीख़ें और आप क्या कर सकते हैं, नाम से बताती है। सिर्फ़ वही systems टेस्ट करें जो आपके अपने हों या जिन्हें टेस्ट करने की स्पष्ट लिखित अनुमति हो; किसी site का customer होना अनुमति नहीं है। Proxy असली server को असली, बदली हुई requests भेजता है, और बिना authorisation ऐसा करना QA नहीं है और कई देशों में ग़ैरक़ानूनी है। शक हो तो रुकें और पूछें।

Worked example: replay से access-control check

आप लिखित रूप से अपनी team के staging shop को टेस्ट करने के लिए authorised हैं, और staging.shop.example proxy scope में है। अपने test user से log in करके आप अपना एक order खोलते हैं और history में उसकी request ढूँढते हैं। Request editor में आप सिर्फ़ order id बदलकर किसी दूसरे test user की id करते हैं, अपनी session cookie वैसी ही रखते हैं, और दोबारा भेजते हैं।

सुरक्षित नतीजा है 403 Forbidden या 404 Not Found: server जाँचता है कि order caller का ही है। दूसरे user के order के साथ 200 OK broken access control है, यानी insecure direct object reference (IDOR), और bug report के लिए ठीक वही request और response आपके पास पहले से है।

GET /api/orders/1042 HTTP/1.1
Host: staging.shop.example
Cookie: session=<your own test session>

# Replay with one change: an order id that is not yours
GET /api/orders/1043 HTTP/1.1
Host: staging.shop.example
Cookie: session=<your own test session>

# Secure response:   403 Forbidden  or  404 Not Found
# Broken access control: 200 OK with another user's order

आज़माएँ: API रिक्वेस्ट बिल्डर

आम गलतियाँ

  • अपने रोज़मर्रा के browser profile से टेस्ट करना, जिससे personal logins और cookies capture और screenshots में पहुँच जाते हैं।
  • Proxy CA पर system-wide या personal device पर भरोसा करना, और फिर उसे हटाना भूल जाना।
  • Greyed-out button या client-side validation को control का सबूत मान लेना, बजाय request को server पर replay करने के।
  • Scope खुला छोड़ देना, जिससे replay या scanning उन hosts तक पहुँच सकता है जिन्हें टेस्ट करने की अनुमति नहीं।
  • Passive-scan alert को हाथ से जाँचे बिना confirmed defect के रूप में report करना।
  • एक साथ दो values बदलना, या ठीक request और response save न करना, जिससे कोई नहीं बता सकता कि नतीजा किस वजह से आया।

QA का नज़रिया

Team में intercepting proxy जितना specialist का tool है उतना ही functional tester का भी। आप इसे सामान्य feature testing में इस्तेमाल करते हैं — किसी flow के पीछे की requests देखने, किसी bug को ठीक-ठीक दोबारा बनाने, और वे चंद access-control checks चलाने के लिए जो हर authenticated feature के लिए ज़रूरी हैं: क्या मैं किसी और user का record पा सकता हूँ, क्या मैं अपने role से ऊपर काम कर सकता हूँ, क्या server हर request पर session जाँचता है। गहरी और active testing security specialists और OWASP Web Security Testing Guide का काम है।

पहले environment के मालिक के साथ scope और authorisation तय करें, production के बजाय staging को चुनें, और सिर्फ़ वही test accounts इस्तेमाल करें जो आपको दिए गए हैं। Bug report में secrets छिपाकर request और response, वह एक value जो आपने बदली, और अपेक्षित सुरक्षित व्यवहार शामिल करें, ताकि developer उसी replay से fix की पुष्टि कर सके।

अभ्यास

Replay से role check और session check की योजना बनाएँ

आपका काम

आप लिखित रूप से अपनी team के staging shop को टेस्ट करने के लिए authorised हैं, और उसका host proxy scope में है। Material में एक request है जो तब capture हुई जब आपके admin test user ने users की सूची खोली, और साथ में आपके customer test user की session cookie है।

दो replays की योजना बनाएँ: एक जो role check टेस्ट करे और एक जो session check टेस्ट करे। हर एक के लिए बताएँ कि आप क्या बदलेंगे, क्या वैसा ही रखेंगे, और अपेक्षित सुरक्षित response क्या है; फिर बताएँ कि भेजने से पहले आप क्या पुष्ट करते हैं।

सामग्री
# Captured as your admin test user
GET /api/admin/users HTTP/1.1
Host: staging.shop.example
Cookie: session=a91e...   (admin test user)
Accept: application/json

# Session cookie of your customer test user
Cookie: session=7c03...
चरण
  1. वह value ढूँढें जो server को बताती है कि call कौन कर रहा है।
  2. Role replay की योजना बनाएँ: क्या बदलेंगे और क्या capture जैसा ही रहेगा।
  3. Session replay की योजना बनाएँ: क्या हटाएँगे और क्या capture जैसा ही रहेगा।
  4. कुछ भी भेजने से पहले क्या पुष्ट करते हैं, उसकी सूची बनाएँ।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

दोनों replays सिर्फ़ session cookie बदलते हैं: यहाँ यही अकेली value है जो server को बताती है कि call कौन कर रहा है, और server उसी session से user और उसका role निकालता है। Method, path और बाक़ी headers ठीक capture जैसे रहते हैं, ताकि response में कोई भी फ़र्क़ उसी एक value से आए।

Role replay: a91e... की जगह customer session 7c03... लगाकर दोबारा भेजें। सुरक्षित: 403 Forbidden, या 404 Not Found अगर app admin routes छिपाती है। User list के साथ 200 OK का मतलब है कि customer admin की तरह काम कर सकता है — यह broken access control है।

Session replay: Cookie header हटाकर दोबारा भेजें। सुरक्षित: 401 Unauthorized या login page पर redirect। Data के साथ 200 OK का मतलब है कि endpoint authentication जाँचता ही नहीं।

भेजने से पहले पुष्ट करें कि host proxy scope में है, आपकी लिखित authorisation इस host, इस तारीख़ और इस तरह के check को शामिल करती है, और दोनों accounts आपको दिए गए test accounts हैं। GET से शुरू करना मदद करता है: RFC 9110 इसे safe method के रूप में परिभाषित करता है, इसलिए replay से data नहीं बदलना चाहिए। कुछ भी अस्पष्ट हो तो रुकें और पूछें।

अक्सर पूछे जाने वाले सवाल

क्या intercepting proxy और browser DevTools एक ही हैं?

इनमें overlap है। DevTools का Network panel किसी tab की requests दिखाता है और उनमें से कुछ को copy करने या दोबारा भेजने देता है, जो कई checks के लिए काफ़ी है। Proxy एक सच्चा intercept step जो request को server तक पहुँचने से पहले रोक लेता है, tabs और clients के पार एक history, और passive scanning जोड़ता है, और mobile app या curl जैसे non-browser clients भी capture करता है। DevTools से शुरू करें; proxy तब इस्तेमाल करें जब request को बीच रास्ते बदलना हो या एक से ज़्यादा client capture करने हों।

मुझे certificate क्यों install करना पड़ता है?

HTTPS browser और server के बीच traffic को encrypt करता है, इसलिए उसे पढ़ने और बदलने के लिए proxy browser का connection ख़ुद ख़त्म करता है और अपने CA से signed certificate पेश करता है। आपका test browser इसे तभी स्वीकार करता है जब वह proxy CA पर भरोसा करे। इसे एक dedicated test profile में install करें, कभी system-wide या personal device पर नहीं, और काम पूरा होने पर हटा दें।

क्या मैं किसी भी website पर proxy इस्तेमाल कर सकता हूँ जिसे टेस्ट करना चाहूँ?

नहीं। इसे सिर्फ़ उन्हीं systems पर इस्तेमाल करें जो आपके अपने हों या जिन्हें टेस्ट करने की स्पष्ट लिखित अनुमति हो। Proxy असली server को असली, बदली हुई requests भेजता है, और बिना authorisation ऐसा करना testing नहीं है और कई देशों में ग़ैरक़ानूनी है। Proxy scope को authorised hosts पर सेट करें और बाक़ी सब बाहर रखें।

Passive और active scanning में क्या फ़र्क़ है?

Passive scanning सिर्फ़ वही traffic पढ़ता है जो आप पहले से भेज और पा रहे थे, इसलिए इसे चालू रखना सुरक्षित है। Active scanning कमज़ोरियाँ खोजने के लिए अपनी ओर से गढ़ी हुई requests भेजता है; यह ज़्यादा जोखिम वाला है, data बदल सकता है, और इसे explicit authorisation चाहिए। यह पाठ passive scanning और हाथ से, एक बार में एक request वाले checks पर टिका रहता है।

संदर्भ

  • OWASP Web Security Testing Guide (WSTG)OWASP Foundationवेब एप्लिकेशन और API की सुरक्षा कमज़ोरियों को परखने की संदर्भ कार्यप्रणाली, एक-एक टेस्ट के रूप में।
  • NIST SP 800-115: Technical Guide to Information Security Testing and AssessmentNIST · 2008सुरक्षा मूल्यांकन की योजना और संचालन: समीक्षा, टार्गेट पहचान, कमज़ोरी की पुष्टि और रिपोर्टिंग।
  • OWASP Top 10:2025OWASP Foundation · 2025वेब एप्लिकेशन की दस सबसे गंभीर सुरक्षा जोखिम, हर एक की जाँच और रोकथाम के साथ।
  • RFC 9110: HTTP SemanticsIETF · 2022HTTP मेथड, हेडर फ़ील्ड, स्टेटस कोड और कंटेंट निगोशिएशन के अर्थ, वायर वर्ज़न से स्वतंत्र।
टूल्स

Mutqan tools से अभ्यास करें

API रिक्वेस्ट बिल्डर

HTTP रिक्वेस्ट (method, URL, हेडर, auth, बॉडी) बनाएँ और भेजें, फिर रिस्पॉन्स जाँचें — आपके ब्राउज़र में हल्का-फुल्का Postman।

API टेस्टिंग

API ऑथेंटिकेशन टेस्टर

किसी endpoint पर Bearer, Basic, API-key और कस्टम-हेडर प्रमाणीकरण टेस्ट करें और अधिकृत बनाम अनधिकृत रिस्पॉन्स की तुलना करें।

API टेस्टिंग

HTTP हेडर पार्सर

कच्चे HTTP रिक्वेस्ट/रिस्पॉन्स हेडर को व्याख्या सहित एक संरचित तालिका में बदलें।

वेब

कुकी एनालाइज़र

Set-Cookie हेडर पार्स करें और Secure, HttpOnly, SameSite, Domain, Path, एक्सपायरी तथा साइज़ की सर्वोत्तम प्रथाएँ जाँचें।

वैलिडेशन

सिक्योरिटी हेडर एनालाइज़र

पेस्ट किए गए हेडर या किसी सार्वजनिक URL से HTTP सुरक्षा हेडर (CSP, HSTS, X-Frame-Options, Referrer-Policy, Permissions-Policy, COOP/CORP) को ग्रेड दें।

वैलिडेशन

और गहराई से

इस topic में आपकी प्रगति

QA रोडमैप का हिस्सा