सिक्योरिटी टेस्टिंग की बुनियाद

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

एक functional defect आम तौर पर एक user का एक काम बिगाड़ता है। एक security defect एक साथ हर user का data उजागर कर सकता है, और जो attacker उसे ढूँढता है वह bug report नहीं लिखता। लागत बाद में आती है: data breach, regulatory जुर्माना, खोए हुए ग्राहक और दबाव में emergency fix, और यह आम तौर पर उस test की लागत से कहीं ज़्यादा होती है जो कमज़ोरी पहले पकड़ लेता।

Tester के लिए security वह जगह है जहाँ रोज़ की आदतें सबसे ज़्यादा काम आती हैं: negative cases में सोचना, requirement को इस नज़र से पढ़ना कि वह क्या मना करती है, और system जो मान लेता है उस पर सवाल उठाना। कई security defects साधारण defects हैं, एक छूटी हुई जाँच, एक गलत default, एक ज़रूरत से ज़्यादा बोलने वाला error message, जिन्हें जानकार tester बिना ख़ास tools के पकड़ लेता है। यह lesson शब्दावली और बुनियादी नियम देता है; अगले lessons OWASP Top 10 से शुरू होकर मुख्य areas, authentication, sessions, access control, injection और बाकी, को एक-एक करके लेते हैं।

Security क्या बचाती है: confidentiality, integrity, availability

Security requirements टेस्ट करना आसान हो जाता है जब आप नाम दें कि हर requirement तीन properties में से किसे बचाती है। Confidentiality: जानकारी सिर्फ़ उन्हें दिखे जिन्हें देखने की अनुमति है। Integrity: data और functions सिर्फ़ authorised actors और authorised रास्तों से बदलें, और हर बदलाव trace हो सके। Availability: जब वैध users को service चाहिए तब वह मौजूद हो, स्वीकार्य performance के साथ। Security के लोग इन्हें CIA triad कहते हैं। ISO/IEC 25010:2023 confidentiality और integrity को security की sub-characteristics में गिनता है, non-repudiation, accountability, authenticity और resistance (attack के दौरान भी काम चलाते रहना) के साथ, और availability को reliability के नीचे रखता है, इसीलिए availability tests अक्सर performance के काम के साथ होते हैं।

हर property अपने test questions सुझाती है, और security test का expected result अक्सर यह होता है कि कुछ नहीं होता: request reject होती है, data वैसा ही रहता है, service चलती रहती है।

• Confidentiality: क्या logged-out visitor, दूसरा कर्मचारी या नीचे की role salary slip पढ़ सकती है? क्या slip किसी URL, log, cache या error message से leak होती है?
• Integrity: क्या bank account बिना re-authentication, tampered request या replay की गई request से बदला जा सकता है? क्या हर बदलाव के साथ दर्ज होता है कि किसने और कब किया?
• Availability: failed attempts की एक बौछार में login page का क्या होता है, या जब "query my slip" form में 50 MB की file भेजी जाए? क्या एक user का दुरुपयोग सबको धीमा कर देता है?

Threats, vulnerabilities, attacks और risk

पाँच शब्द security की ज़्यादातर बातचीत संभालते हैं, और testers इन्हें आपस में मिला देते हैं। Asset वह है जिसे बचाना है: salary data, payroll run, कंपनी की साख। Threat किसी asset को नुक़सान पहुँचाने की संभावित वजह है, जिसे आम तौर पर उसके actor के साथ बताया जाता है: नाराज़ कर्मचारी, criminal group, automated bot, ग़लती करता हुआ ईमानदार administrator। Vulnerability वह कमज़ोरी है जिसका threat इस्तेमाल कर सकता है: छूटी हुई authorisation check, पुरानी library, password reset link जो कभी expire नहीं होता, public folder में छोड़ा गया backup। Attack किसी asset के ख़िलाफ़ vulnerability का इस्तेमाल करने की कोशिश है, और exploit वह technique या code है जिससे यह किया जाता है। Risk सफल attack की संभावना को उससे होने वाले नुक़सान की मात्रा से जोड़ता है, वही likelihood-और-impact वाली सोच जो risk-based testing में थी।

काम का बँटवारा इसी से निकलता है। Testers threats नहीं हटा सकते; bots मौजूद हैं चाहे portal कमज़ोर हो या न हो। Testers vulnerabilities attacker से पहले ढूँढते हैं और उन्हें इतने सबूत के साथ report करते हैं कि team risk आँक सके। नीचे जैसा एक छोटा note, feature की शुरुआत में लिखा हुआ, एक धुँधली चिंता को test conditions में बदल देता है:

Asset:          Salary slips (PDF)
Threat:         कोई कर्मचारी सहकर्मी की slip पढ़ ले
Vulnerability:  Slip URL में अंदाज़ा लगाने लायक id है, ownership check नहीं
Test condition: अपने session से दूसरे user की slip id पर GET -> 403 या 404, slip नहीं

Asset:          Salary वाला bank account number
Threat:         Stolen session वाला attacker salary दूसरे account में भेज दे
Vulnerability:  बदलाव बिना re-authentication या notice के save हो जाता है
Test condition: Account बदलें -> re-auth prompt, notice भेजा गया, audit record

Asset:          Employee accounts
Threat:         कोई bot leaked passwords आज़माता है
Vulnerability:  Rate limit नहीं; error text बताता है कि username मौजूद है या नहीं
Test condition: लगातार failures -> lockout या delay; हर user के लिए एक ही message

आज़माएँ: टेस्ट सिनेरियो जनरेटर आज़माएँ: नेगेटिव टेस्ट जनरेटर

देखने के चार तरीक़े: SAST, DAST, vulnerability scanning और penetration testing

Security testing कई approaches से होती है जो system को अलग-अलग तरफ़ से देखती हैं। हर approach ऐसी कमज़ोरियाँ पकड़ती है जो बाकी से छूट जाती हैं, इसलिए mature teams इन्हें मिलाकर इस्तेमाल करती हैं, और tester को पता होना चाहिए कि किसने क्या पकड़ा।

• Static application security testing (SAST) source या compiled code को बिना चलाए analyse करती है, उस reviewer की तरह जो हर line पढ़ता है। यह code-level कमज़ोरियाँ जल्दी पकड़ती है, string concatenation से बना SQL query, hard-coded secret, और file और line बताती है। यह developer के editor (IDE) और CI pipeline में चलती है, अक्सर ऐसे findings देती है जो false positive निकलते हैं, और runtime configuration या components किस तरह deploy हुए हैं, यह नहीं देख पाती।
• Dynamic application security testing (DAST) चलती हुई application को बाहर से टेस्ट करती है, जैसे user या attacker करता, requests भेजकर और responses जाँचकर। यह नाम आम तौर पर उन automated tools के लिए इस्तेमाल होता है जो application में crawl करके attack जैसी requests भेजते हैं, पर जब tester यही हाथ से करता है तब भी सिद्धांत वही है। यह वह पकड़ती है जो सचमुच exposed है: missing security header, बिना HttpOnly वाली session cookie, script reflect करने वाला input, बिना token जवाब देने वाला endpoint। इसे deployed test environment और test accounts चाहिए, जिस code तक यह नहीं पहुँचती वह छूट जाता है, और यह नहीं बता सकती कि कौन-सी line ठीक करनी है। QA tester browser या API client में हाथ से जो करता है, उसमें से ज़्यादातर इसी अर्थ में dynamic testing है।
• Vulnerability scanning जो installed और exposed है, servers, frameworks, libraries, open ports, TLS settings, उसे ज्ञात vulnerabilities और आम misconfigurations के लिए जाँचती है। ज्ञात vulnerabilities CVE (Common Vulnerabilities and Exposures) identifiers के साथ publish होती हैं, जैसे Log4Shell नाम की Log4j कमज़ोरी के लिए CVE-2021-44228; software composition analysis (SCA) application की dependencies के लिए यही matching करती है। Scanning तेज़, व्यापक और repeatable है, एक अच्छा pipeline gate, पर यह सिर्फ़ पहले से ज्ञात कमज़ोरियाँ जानती है और आपके business logic के बारे में कुछ नहीं।
• Penetration testing एक human-led, authorised attack simulation है, तय scope और समय के भीतर। Tester findings को जोड़ता है, verbose error और कमज़ोर password policy, यह दिखाने के लिए कि attacker सचमुच कहाँ तक पहुँच सकता है। NIST SP 800-115 इसे चार phases में बताता है: planning, discovery, attack और reporting। यह सबसे मज़बूत सबूत और एक system की एक समय पर सबसे गहरी coverage देता है, सबसे महँगा है, इसलिए अक्सर बड़ी release से पहले या साल में एक बार रखा जाता है।

नियम: सिर्फ़ लिखित authorisation के साथ टेस्ट करें

Security test वही requests भेजता है जो attacker भेजता। Testing को attack से अलग करने वाली चीज़ permission है, intent नहीं: कई देशों में बिना authorisation किसी computer system तक पहुँचना आपराधिक अपराध है, भले ही कुछ नुक़सान न हुआ हो और मक़सद कमज़ोरी report करना रहा हो। "मैं सिर्फ़ टेस्ट कर रहा था" कहने से access authorised नहीं हो जाता। इसलिए नियम पूर्ण है: सिर्फ़ उन systems को टेस्ट करें जो आपके हैं या जिन्हें टेस्ट करने की लिखित अनुमति आपके पास है, और सिर्फ़ उस scope में जो वह अनुमति बताती है।

व्यवहार में लिखित अनुमति एक छोटा rules-of-engagement note है जिस पर पहली request से पहले सहमति होती है। अपनी team के test environment के लिए यह वह test plan हो सकता है जिसका security scope product owner ने sign off किया हो; production, किसी third-party service या client के system के लिए यह एक स्पष्ट document है। Bug bounty programme की published policy लिखित authorisation मानी जाती है, पर सिर्फ़ उन targets, techniques और आचरण के लिए जो उसमें लिखे हैं।

• Test environments और वे test accounts इस्तेमाल करें जो आपने ख़ुद बनाए हों; किसी असली ग्राहक का data कभी test का victim न बनाएँ।
• ऐसे benign payloads इस्तेमाल करें जो नुक़सान के बिना handling दिखा दें: एक single quote ' या <b> बता देता है कि input escape होता है या नहीं; बात साबित करने के लिए कुछ delete करने की ज़रूरत नहीं।
• जब ऐसे data तक पहुँच जाएँ जो आपको नहीं दिखना चाहिए तो रुकें और report करें, और findings restricted ticket में रखें, असली personal data के screenshots के बिना। आगे जाना penetration tester का काम है, उसकी अपनी authorisation के तहत।

Rules of engagement: payroll portal, release 4.2 का security pass
Authorised by:  HR Systems प्रमुख (product owner), 2026-10-04
Targets:        सिर्फ़ https://payroll-test.example (test environment)
Out of scope:   production, payment provider, SMS gateway, कर्मचारियों के laptops
Accounts:       test users EMP-1001, EMP-1002, HR-ADMIN-01 (सिर्फ़ test data)
Allowed:        manual checks, header, cookie और auth checks, benign payloads
Not allowed:    denial of service, कई accounts पर password guessing,
                social engineering, असली employee data मिले तो उसकी copy बनाना
Window:         2026-10-05 से 2026-10-08, Riyadh समय 08:00 से 18:00
Contacts:       QA lead (findings), platform on-call (अगर कुछ टूटे)
Findings:       tracker में restricted ticket, असली data के screenshots नहीं

Worked example: payroll login पर पहला security pass

ऊपर के rules of engagement sign हो चुके हैं; आपके पास test environment, तीन test accounts और एक दोपहर है। पहला pass अंदर घुसने की कोशिश नहीं करता। यह बुनियादी controls को एक-एक property करके जाँचता है और सबूत दर्ज करता है।

• Confidentiality: EMP-1001 से login करें, अपनी slip खोलें, URL /slips/48213.pdf नोट करें, फिर /slips/48214.pdf request करें, जो आपके दूसरे test account EMP-1002 की slip है। Expected: 403 या 404 और कोई slip नहीं; status दर्ज करें, content नहीं। बिना session दोहराएँ: expected 401 या login page पर redirect।
• Session और configuration: login response के headers Cookie Analyzer और Security Header Analyzer में paste करें। Expected: session cookie में Secure, HttpOnly और कोई SameSite value हो, और Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options: nosniff और frame protection (X-Frame-Options या CSP का frame-ancestors directive) मौजूद हों; ये headers मिलकर browser से कहते हैं कि सिर्फ़ HTTPS इस्तेमाल करे, scripts सिर्फ़ तय जगहों से load करे, content type का अंदाज़ा न लगाए और page को किसी दूसरी site के frame में न दिखाए। हर missing item एक finding है, exact response के साथ।
• Integrity: EMP-1001 के रूप में bank account बदलें। Expected: portal दोबारा password या one-time code माँगे, कर्मचारी को सूचित करे और audit record लिखे। फिर जाँचें कि कोई और यह बदलाव नहीं कर सकता: EMP-1001 के account के लिए वही change request EMP-1002 के token से भेजें, किसी API client से या API Authentication Tester से। Expected: 403 या 404, और दोबारा देखने पर EMP-1001 का account बिना बदलाव के। Tool मानता है कि आप जो token डालते हैं वह accept होना चाहिए, इसलिए वह इस rejection को fail दिखाता है; यहाँ यही rejection वह result है जो आप चाहते हैं, और उसकी जिन rows में इस्तेमाल लायक token नहीं है उन्हें 401 मिलना चाहिए।
• Authentication और availability: EMP-1002 के लिए पंद्रह बार गलत password डालें। Expected: तय संख्या के बाद lockout या बढ़ती हुई देरी, और गलत password व न होने वाले user के लिए एक ही error text, ताकि login यह न बताए कि कौन-से usernames मौजूद हैं। इस बीच EMP-1001 सामान्य रूप से login कर सके: एक account की failures से सबके लिए service बंद नहीं होनी चाहिए।

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

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

संदर्भ

• OWASP Web Security Testing Guide (WSTG)OWASP Foundationवेब एप्लिकेशन और API की सुरक्षा कमज़ोरियों को परखने की संदर्भ कार्यप्रणाली, एक-एक टेस्ट के रूप में।
• NIST SP 800-115: Technical Guide to Information Security Testing and AssessmentNIST · 2008सुरक्षा मूल्यांकन की योजना और संचालन: समीक्षा, टार्गेट पहचान, कमज़ोरी की पुष्टि और रिपोर्टिंग।
• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
• ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelISO/IEC · 2023उत्पाद गुणवत्ता मॉडल: कार्यात्मक उपयुक्तता, प्रदर्शन दक्षता, संगतता, इंटरैक्शन क्षमता, विश्वसनीयता, सुरक्षा, रखरखाव-योग्यता और लचीलापन।