वेब सिक्योरिटी टेस्टिंग इन प्रैक्टिस

Mutqan Soft QA टीम द्वारा · अपडेट 6 अक्टूबर 2026 · 21 मिनट · मध्यम

व्यवहार में web security testing एक running web application की दोहराई जा सकने वाली, authorised जाँच है, जो written scope के अंदर और तय क्रम में होती है: site जो पहले से भेजती है उसे देखें, साधारण requests से configuration जाँचें, test हो रहे build के dependency scan को triage करें, जहाँ scope अनुमति दे वहाँ scan करें, OWASP Web Security Testing Guide (WSTG) से manual tests जोड़ें, और अंत में private report दें।

जैसे किसी bookshop के release से पहले tester intercepting proxy के ज़रिए staging के हर हिस्से से गुज़रता है और चार leads लेकर लौटता है: malformed order id पर stack trace, /static/ के नीचे directory listing, और दो dependency alerts, जिनमें से एक 9.8 Critical है। हर lead verify होती है, OWASP Top 10:2025 की किसी category से map होती है और private रूप से file होती है, और पता चलता है कि 9.8 वाला alert product को छूता ही नहीं।

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

सावधानी से लिखा code भी इस बात से बेकार हो सकता है कि उसे कैसे deploy किया गया और वह किन चीज़ों से बना है। चालू छोड़ा गया debug page, default admin account, या published vulnerability वाली पुरानी library दरवाज़ा खोल देती है, जबकि test किए गए feature में एक भी coding गलती नहीं थी। दोनों OWASP Top 10:2025 की categories हैं, Security Misconfiguration (A02:2025) और Software Supply Chain Failures (A03:2025), और दोनों उन automated tools से आसानी से मिल जाती हैं जिन्हें attackers public sites पर चलाते हैं।

Tester के लिए workflow काम को safe और defensible बनाता है: scope, environment, test accounts और reporting channel पहली request से पहले तय होते हैं, और बाद में आप दिखा सकते हैं कि क्या test हुआ, कैसे, और क्या जानबूझकर छोड़ा गया।

Workflow: तय क्रम में सात steps

किसी भी request से पहले permission, active checks से पहले low-impact checks, और reporting से पहले verification। इन steps के पीछे की checklist OWASP WSTG है: area के हिसाब से grouped tests, हर एक का WSTG-CONF-06 जैसा identifier, objectives और remediation advice। Product के risks के हिसाब से areas चुनें, हर test को done, not applicable या finding mark करें, और report में identifier लिखें।

Dedicated test browser को intercepting proxy से होकर चलाएँ, जैसे intercepting proxy वाले lesson में set up किया था: उसकी history map बन जाती है, उसका passive scanner missing headers और cookie attributes flag करता है, और उसकी scope setting हर request को authorisation के अंदर रखती है।

1. Scope और permission: hosts, test window, excluded actions, emergency contact और findings का channel, लिखित में।
2. Proxy से map: pages, roles, API endpoints, uploads, third-party scripts; हर role के लिए एक test account।
3. Passive pass: HTTPS redirect, HSTS, TLS 1.2 या 1.3, हर page type पर security headers और cookie attributes।
4. Configuration probes: default accounts, debug output, errors, directory listing, HTTP methods, admin paths।
5. Components: test हो रहे build के dependency scan और SBOM का triage।
6. Scanner और manual tests: active DAST scan, जो records बना सकता है और e-mails भेज सकता है, सिर्फ़ जहाँ scope अनुमति दे; access control, business logic और CSRF के लिए manual WSTG tests, जिन्हें scanners भरोसेमंद तरीके से judge नहीं कर सकते।
7. Verify, map, report, retest: हर lead हाथ से reproduce करें, उसकी Top 10 category लिखें, private channel में file करें, fix के बाद retest करें।

सात steps में web security check: written permission, proxy से map, passive checks, configuration probes, components का triage, manual tests के साथ scoped scan, और verified private report।

1Scope और permissionHosts, test window, exclusions, emergency contact, findings का channel
गेट: सिर्फ़ written permission के साथ
2Proxy से mapPages, roles, API endpoints, uploads, third-party scripts
3Passive passA04:2025 और A02:2025HTTPS और HSTS, TLS 1.2 या 1.3, हर page type पर headers और cookie attributes
4Configuration probesA02:2025 और A10:2025Default accounts, debug, errors, directory listing, methods, admin paths
5ComponentsA03:2025SCA alerts: CVE, CVSS vector, build का SBOM, triage के चार सवाल
6Scanner और manual testsActive scan सिर्फ़ जहाँ scope अनुमति दे; access control और logic के लिए WSTG tests
गेट: हर result reproduce होने तक सिर्फ़ lead है
7Verify, map और reportहाथ से reproduce, Top 10 category, private filing, redacted evidence
दोहराता है: हर fix के बाद retest

चरण 3–5 के दौरान Low impact: साधारण requests और results पढ़ना

इसके बाद:बड़े releases से पहले और infrastructure changes के बाद फिर से

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

Security misconfiguration और safe failure

Misconfiguration software को set up करने के तरीके की कमज़ोरी है, code लिखने की नहीं: framework का default, कोई feature जिसे किसी ने बंद नहीं किया, development से copy हुई setting। हर check एक साधारण request और उसके response को ध्यान से पढ़ना है।

Safe failure दूसरा आधा हिस्सा है। A10:2025 Mishandling of Exceptional Conditions में unhandled exceptions, fail open होने वाले checks (permission service के timeout पर access दे देना) और आधे-अधूरे operations आते हैं। Condition को safe तरीके से पैदा करें, malformed value या test environment पर timeout होने वाले dependency stub से, और जाँचें कि request refuse हुई, message generic है और कोई आधा record नहीं बचा।

Default accounts (WSTG-ATHN-02): map में मिले हर console पर सिर्फ़ vendor के documented defaults आज़माएँ, ज़्यादा से ज़्यादा कुछ attempts। Expected: reject।
Debug modes: debug pages और toolbars, source maps, test-only endpoints। Release candidate पर confirm करें कि release configuration इन्हें बंद करता है।
Stack traces और verbose errors (WSTG-ERRH-01): गलत type (/api/orders/abc), missing field, बहुत लंबी value भेजें। Expected: 4xx status और reference id वाला छोटा message; कोई stack trace, SQL, file paths या versions नहीं।
Directory listing: /static/ जैसे folders request करें। Expected: 403 या 404, "Index of" page नहीं।
HTTP methods (WSTG-CONF-06): OPTIONS भेजें और Allow पढ़ें; TRACE refuse होना चाहिए और गैर-ज़रूरी methods को 405 मिलना चाहिए। PUT या DELETE सिर्फ़ अपने बनाए record पर आज़माएँ।
Admin और diagnostic endpoints (WSTG-CONF-05): consoles और detailed health, metrics या status pages admin login के बिना internet से जवाब न दें।
Security headers: passive pass में record हुए; ये अक्सर error pages, redirects और API responses पर गायब होते हैं।

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

Vulnerable और supply-chain components: SCA, CVE, CVSS और SBOM

Web application के कई components दूसरे components के ज़रिए indirectly आते हैं। A03:2025 Software Supply Chain Failures में known-vulnerable, unmaintained, untracked या compromised components और build steps आते हैं। Scan आम तौर पर pipeline में चलता है; tester उसे पढ़ता है, developer के साथ triage करता है और release decision तक ले जाता है।

हर alert को चार सवालों से triage करें। Vulnerable version shipped build में है या सिर्फ़ development dependency में? क्या product के इस्तेमाल के तरीके से vulnerable code तक पहुँचा जाता है? क्या fix उपलब्ध है, और वह क्या बदलता है? क्या vulnerability के exploited होने की जानकारी है (यह advisory में, या CISA के Known Exploited Vulnerabilities catalog जैसी public list में मिलती है)? नतीजे: अभी fix, planned release में fix, कारण लिखकर not affected, या false positive। Risk accept करना security या product owner का फ़ैसला है।

SCA (software composition analysis) dependency files पढ़ता है (जैसे package.json और उसकी lock file package-lock.json, या Maven की pom.xml), हर direct और transitive dependency को version के साथ list करता है और published advisories से match करता है।
CVE ID (CVE-<year>-<number>) एक publicly disclosed vulnerability का नाम है; यह advisory, scanner और fix को जोड़ती है और duplicates merge करने देती है।
CVSS (Common Vulnerability Scoring System), जिसे FIRST maintain करता है, 0.0 से 10.0 तक base score देता है: None 0.0, Low 0.1–3.9, Medium 4.0–6.9, High 7.0–8.9, Critical 9.0–10.0। Vector कारण बताता है: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (9.8) यानी network attack, low complexity, कोई privileges नहीं, कोई user action नहीं, और confidentiality, integrity और availability पर high impact। Scores की तुलना से पहले version prefix (3.1 या 4.0) देखें।
CVSS इन bands को severity ratings कहता है, पर base score vulnerability को आम तौर पर rate करता है, आपके product में नहीं: यह आपकी defect report की severity का input है, वह severity नहीं।
SBOM (software bill of materials) एक build के components को versions, suppliers और dependency relations के साथ list करता है, SPDX या CycloneDX जैसे standard format में, ताकि "क्या हम affected हैं?" एक search बन जाए।

आज़माएँ: JSON ट्री व्यूअर आज़माएँ: JSON डिफ़

Findings को OWASP Top 10:2025 से map करना

हर report entry में WSTG test (check कैसे हुआ) और साल के साथ Top 10 category (risk किस तरह का है) लिखी जाती है। Finding दो categories में fit हो तो root cause चुनें: चालू छोड़ा गया debug page A02 है, unhandled exception से निकला stack trace A10 है।

A02:2025 Security Misconfiguration: default accounts, debug modes, verbose error settings, directory listing, गैर-ज़रूरी methods, exposed admin या diagnostic endpoints, missing headers और cookie attributes।
A10:2025 Mishandling of Exceptional Conditions: leak हुए stack traces, fail-open checks, आधे-अधूरे operations।
A03:2025 Software Supply Chain Failures: vulnerable, unmaintained या untracked components और build tools।
A04:2025 Cryptographic Failures: plain HTTP, पुराना TLS।
A01:2025 Broken Access Control: सही role के बिना जवाब देने वाला admin endpoint; manual role tests की findings।
A08:2025 Software or Data Integrity Failures: untrusted CDN से बिना integrity check वाले scripts, बिना verification के updates।

Worked example: scanner finding का triage और report

Security report attacker के लिए नक़्शा है। उसे सिर्फ़ scope में बताए channel में file करें, आम तौर पर tracker का restricted project, कभी public issue या team chat नहीं। Session identifiers, tokens, passwords और personal data redact करें, और उतना ही साबित करें जितना ज़रूरी हो: दूसरे user का e-mail address दिखाने वाला एक response proof है; पूरी table download करना incident है।

Bookshop check में build 412 के dependency scan ने दो alerts दिए; developer और tester ने दोनों को build के SBOM से मिलाया। Names और advisory ID गढ़े हुए हैं।

दूसरा alert, 9.8 Critical वाली test-runner library, not affected record हुआ: development dependency जो shipped SBOM में नहीं है। फिर भी उसका upgrade schedule हुआ, क्योंकि यह secrets रखने वाली CI machines पर चलती है।
8.8 वाला alert finding बना, क्योंकि vulnerable version ship होता है और कोई भी logged-in user उस तक पहुँचता है: फ़ैसला presence और reachability ने किया, score ने नहीं। Proposed severity team की scale पर Critical है, CVSS band वाला High नहीं, क्योंकि advisory के अनुसार कोई भी logged-in user image service पर code चला सकता है।
Build 413 पर retest: फिर scan करें और close करने से पहले SBOM में fixed version confirm करें। Component में ख़ुद की vulnerability उसके maintainer को published security contact से जाती है, public issue से कभी नहीं।

Finding WS-05  Vulnerable image library in avatar upload   Severity: Critical (proposed)
Category:  A03:2025 Software Supply Chain Failures
Source:    dependency scan (SCA), build 412
Component: acme-img-resize 3.2.0, transitive via avatar-service 1.4.2, runtime
Advisory:  CVE-YYYY-NNNNN  CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H  8.8 High
Fixed in:  acme-img-resize 3.2.4 (per the advisory)
Triage:    in the SBOM of build 412; reached on every avatar upload, which any
           logged-in user can make. No exploit attempted.
Impact:    per the advisory, a crafted image can run code on the image service.
Fix:       upgrade avatar-service, or pin acme-img-resize >= 3.2.4; rescan.
Evidence:  scan report and SBOM excerpt attached; no tokens or user data in them.
Status:    filed as SEC-231 (restricted security project); retest on build 413.

आम गलतियाँ

Written scope बनने से पहले test शुरू करना, या "बस एक और request" के लिए उससे आगे जाना।
Production या shared environment पर active scan चलाना या default credentials आज़माना।
CVSS base score को ही severity मान लेना: सिर्फ़ development dependency में 9.8 शायद product को न छुए; login path पर 6.5 छू सकता है।
Scanner और SCA output बिना verify किए file करना: duplicates, false positives, खोई हुई credibility।
Headers और errors सिर्फ़ home page पर जाँचना; error, admin और API responses अलग से configure होते हैं।
Public channels से या बिना redact किए evidence के साथ report करना, या finding को ज़रूरत से ज़्यादा साबित करना।

QA का नज़रिया

पूरा workflow बड़े releases से पहले और infrastructure changes (नया load balancer, CDN या framework version) के बाद staging पर चलता है, क्योंकि ये application code छुए बिना headers, TLS और error pages बदल देते हैं। सस्ते हिस्से लगातार चलते हैं: हर build पर pipeline quality gate के रूप में dependency scan, और non-functional stage में header check।

Scope security और product owners के साथ तय करें, alerts को component के owner developer के साथ triage करें, और severities की पुष्टि security team को करने दें। Scope, proxy या scanner log, test हुए build का SBOM, evidence और report साथ रखें। शुरू करने से पहले पूछें: कौन-सा environment और build, क्या excluded है, कौन-से test accounts, findings किसे मिलेंगी, और खुले Critical और High alerts release पर क्या असर डालते हैं।

अभ्यास

Clinic के staging check की leads triage करें

आपका काम

आपके पास https://staging.clinic.example को तीन दिन test करने की written permission है; production, payment page और active scanning excluded हैं। Material में छह leads हैं (component names और advisory IDs गढ़े हुए हैं)।

हर lead के लिए तय करें: finding है या नहीं, safe तरीके से कैसे verify करेंगे, उसका WSTG test (अगर कोई लागू हो) और Top 10:2025 category, कारण के साथ proposed severity, और fix। फिर तय करें कि क्या redact करना है और कौन-सी finding इंतज़ार नहीं कर सकती।

सामग्री

Scope:    https://staging.clinic.example, 3 days
Excluded: production, the payment page, active scanning

1  OPTIONS /api/appointments       -> 200  Allow: GET, POST, PUT, DELETE, TRACE
2  GET /api/appointments/abc       -> 500  java.lang.NumberFormatException:
                                           For input string: "abc" at com.clinic.api...
3  GET /static/reports/ (no login) -> 200  "Index of /static/reports", 3 PDF files
4  GET /login                      -> 200  no Content-Security-Policy;
                                           X-Frame-Options: DENY
5  SCA build 88  acme-pdfgen 1.9.0  runtime  CVE-YYYY-11111  7.5 High      fix: 1.9.3
6  SCA build 88  acme-mocker 0.8.1  dev      CVE-YYYY-22222  9.8 Critical  fix: 0.9.0

चरण

हर lead mark करें: verify करने वाली finding, not affected, या team के लिए सवाल।
लिखें कि हर lead को असली data बदले या download किए बिना कैसे verify करेंगे।
दोनों SCA alerts को चार सवालों से triage करें।
Report decisions लिखें: category, severity, fix, redaction, channel।

मॉडल उत्तर दिखाएँ

मॉडल उत्तर

Lead 3 इंतज़ार नहीं कर सकती: बिना login के clinic reports जैसी files की listing। सिर्फ़ page और file names record करें, कुछ न खोलें, developers से पूछें कि files बिना login के load होती हैं या नहीं, और उसी दिन emergency contact को बताएँ। A02:2025, और files बिना login के load हों तो A01:2025 भी; listings के लिए कोई अकेला WSTG test नहीं है, इसलिए इसे configuration testing (WSTG-CONF) में record करें। Proposed severity: Critical, अगर उनमें patient data है। Fix: listing बंद करें और reports सिर्फ़ authorised endpoint से दें।

Lead 2: A10:2025 और WSTG-ERRH-01; unchecked id internal class names वाला stack trace leak करता है। Major: patient data वाले endpoint पर internals दिखते हैं। Fix: id validate करें, generic message और reference id के साथ 400 लौटाएँ, trace server log में रखें।

Lead 1: WSTG-CONF-06 और A02:2025। TRACE को एक harmless request से verify करें; PUT और DELETE appointment बदलने और cancel करने के लिए जायज़ हो सकते हैं, इसलिए API contract देखें और सिर्फ़ अपना appointment इस्तेमाल करें। Minor; fix: TRACE बंद करें। Lead 4: passive pass का result, A02:2025। Framing पहले से X-Frame-Options: DENY से blocked है, और CSP न होने से XSS के ख़िलाफ़ सुरक्षा की एक परत कम होती है, पर यह अकेले exploitable नहीं है। Minor (hardening); fix: Content-Security-Policy जोड़ें।

Leads 5 और 6 dependency scan से आती हैं, किसी WSTG test से नहीं। Lead 5 runtime dependency है: shipped SBOM देखें, पूछें कि report generation vulnerable function call करता है या नहीं, ध्यान दें कि fix मौजूद है (1.9.3), और जाँचें कि vulnerability के exploited होने की जानकारी है या नहीं, क्योंकि तब यह urgent है। Shipped और reached हो तो A03:2025 finding, Critical या Major, advisory में बताए impact के हिसाब से, उसके 7.5 High band से नहीं; fix: 1.9.3 पर upgrade और फिर scan। Reached न हो तो कारण लिखकर not affected। Lead 6 पर dev mark है: confirm करें कि यह shipped SBOM में नहीं है, कारण के साथ not affected record करें, और team को CI machines के लिए upgrade schedule करने दें।

Session cookies, test account का password और file names या screenshots में दिखे patients के नाम redact करें; सब कुछ restricted project में file करें, और lead 3 पहले emergency contact को भेजें।

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

क्या DAST scanner चलाना penetration test जैसा ही है?

नहीं। Scanner known patterns automate करता है और ऐसे leads देता है जिन्हें verify करना होता है। Penetration test इंसान के नेतृत्व वाला, goal-driven engagement है जो findings को जोड़ता है और वह authorization और business logic test करता है जिसे scanner judge नहीं कर पाता। Scanner के results penetration test का input हैं, उसका विकल्प नहीं।

Scanner 9.8 score वाला Critical CVE दिखा रहा है। क्या release रोकनी होगी?

अपने आप नहीं। Base score vulnerability को आम तौर पर rate करता है। फ़ैसला इन बातों से होता है: vulnerable version ship होता है या नहीं, उसका code reach होता है या नहीं, fix मौजूद है या नहीं, और vulnerability के exploited होने की जानकारी है या नहीं। आपका काम ये facts लाना है; release decision team की policy के अनुसार security और product owners का है।

SBOM और SCA report में क्या फ़र्क है?

SBOM एक build की inventory है: उसमें क्या है। SCA report उस inventory को किसी एक समय पर vulnerability advisories से match करती है: आज क्या गलत होना ज्ञात है। अगले महीने कोई नया CVE publish हो, तो हर released build का SBOM तुरंत बता देता है कि किन builds में वह component है।

किसी और की site में गलती से vulnerability दिखे तो क्या करूँ?

और कोई probing बंद करें, "पक्का करने" के लिए भी नहीं। Site का security contact ढूँढें, जैसे security.txt file या published vulnerability disclosure policy, उन्हें सिर्फ़ वही बताएँ जो आपने देखा, और कुछ publish न करें। बिना permission test करना criminal offence हो सकता है, इरादा चाहे जो हो।

संदर्भ

OWASP Web Security Testing Guide (WSTG)OWASP Foundationवेब एप्लिकेशन और API की सुरक्षा कमज़ोरियों को परखने की संदर्भ कार्यप्रणाली, एक-एक टेस्ट के रूप में।
OWASP Top 10:2025OWASP Foundation · 2025वेब एप्लिकेशन की दस सबसे गंभीर सुरक्षा जोखिम, हर एक की जाँच और रोकथाम के साथ।
OWASP Cheat Sheet Series: Error HandlingOWASP Foundationऐसी एरर रिस्पॉन्स जो कॉलर की मदद करें पर स्टैक ट्रेस, वर्ज़न या आंतरिक पाथ लीक न करें।
NIST SP 800-115: Technical Guide to Information Security Testing and AssessmentNIST · 2008सुरक्षा मूल्यांकन की योजना और संचालन: समीक्षा, टार्गेट पहचान, कमज़ोरी की पुष्टि और रिपोर्टिंग।

टूल्स

और गहराई से

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

इस topic से पहले

टेस्टर के लिए क्रिप्टोग्राफ़ी

अगले topics

एक्सेसिबिलिटी टेस्टिंग

वेब सिक्योरिटी टेस्टिंग इन प्रैक्टिस

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

Workflow: तय क्रम में सात steps

Security misconfiguration और safe failure

Vulnerable और supply-chain components: SCA, CVE, CVSS और SBOM

Findings को OWASP Top 10:2025 से map करना

Worked example: scanner finding का triage और report

आम गलतियाँ

QA का नज़रिया

अभ्यास

Clinic के staging check की leads triage करें

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

संदर्भ

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

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

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

रीडायरेक्ट चेकर

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

JSON ट्री व्यूअर

JSON डिफ़

और गहराई से

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

इस topic से पहले

अगले topics

इस मॉड्यूल के दूसरे topics

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

Workflow: तय क्रम में सात steps

Security misconfiguration और safe failure

Vulnerable और supply-chain components: SCA, CVE, CVSS और SBOM

Findings को OWASP Top 10:2025 से map करना

Worked example: scanner finding का triage और report

आम गलतियाँ

QA का नज़रिया

अभ्यास

Clinic के staging check की leads triage करें

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

संदर्भ

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

और गहराई से

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

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

इस topic से पहले

अगले topics

इस मॉड्यूल के दूसरे topics