वेब सिक्योरिटी बेसिक्स
Web security basics वे security checks हैं जो एक functional tester web application टेस्ट करते समय सुरक्षित रूप से कर सकता है: हर जगह HTTPS, cookies के सही flags, input को code नहीं बल्कि data की तरह handle करना, cross-site scripting (XSS) और cross-site request forgery (CSRF) से सुरक्षा, और वे security headers जो browser से user की सुरक्षा करवाते हैं। इसके लिए किसी attack tool की ज़रूरत नहीं: browser, DevTools और कुछ harmless inputs काफ़ी हैं।
उदाहरण के लिए, tester display name में Sara <b>QA</b> डालता है। अगर हर page ठीक यही characters दिखाता है, तो input को text की तरह handle किया गया। अगर कहीं QA bold हो जाता है, तो application ने user input को page में markup की तरह डाल दिया — यही वह कमी है जिससे attacker किसी दूसरे user के browser में script चलाता है। बिना किसी attack code के मिला एक गंभीर defect।
यह क्यों ज़रूरी है
Security defects उन्हीं requirements को तोड़ते हैं जिन्हें आप पहले से टेस्ट करते हैं: data private रहे, उसे सिर्फ़ उसका owner बदले, और pages वही दिखाएँ जो users ने type किया। फ़र्क इतना है कि कोई इन्हें जान-बूझकर खोजता है। ऐसी session cookie जिसे scripts पढ़ सकें, या ऐसा form जिसे दूसरी site submit कर सके, एक छोटे defect को चोरी हुए accounts, बदले गए orders और उजागर personal data में बदल देता है।
Penetration testers गहराई तक जाते हैं, पर आमतौर पर तय मौक़ों पर टेस्ट करते हैं, जैसे किसी बड़े release से पहले। Functional tester हर form और हर release को छूता है, इसलिए normal testing के दौरान किए गए basic checks इन defects को जल्दी पकड़ते हैं, जब इन्हें ठीक करना सबसे सस्ता होता है, और security team को बेहतर जानकारी देते हैं।
Functional tester सुरक्षित रूप से क्या जाँच सकता है
Server के लिए harmless test value और attack एक जैसे दिख सकते हैं, और बिना अनुमति testing अच्छी नीयत के बावजूद क़ानून तोड़ सकती है। इसलिए functional tester observe करने वाली तरफ़ रहता है: application जो भेजता है उसे पढ़ें, वही डालें जो असली user डाल सकता है, और जो दिखे उसकी report करें। कोई कमज़ोरी exploit हो सकती है, यह साबित करना security team का काम है।
- सिर्फ़ वही systems टेस्ट करें जो आपके हैं या जिन्हें टेस्ट करने की लिखित अनुमति है, बेहतर हो कि test environment; third-party sites कभी नहीं, और production सिर्फ़ तब जब अनुमति में उसका नाम हो।
- अपने test accounts इस्तेमाल करें। दूसरों का data कभी न पढ़ें, न बदलें, न delete करें, भले ही पता चले कि आप ऐसा कर सकते हैं।
<b>qa</b>, quotes और apostrophes जैसे harmless markers इस्तेमाल करें; security team की मंज़ूरी के बिना script payloads, scanners या attack tools नहीं।- कमज़ोरी का पहला संकेत मिलते ही रुकें, evidence रखें और security defects के लिए team के restricted channel से report करें, tokens और personal data mask करके।
Input handling, XSS और CSRF
बाहर से आने वाली हर value untrusted है: form fields, URL parameters, headers, cookies, files। सुरक्षित applications server पर दो बार बचाव करती हैं। अंदर आते समय वे expected type, length और format की allow-list से input validation करती हैं; browser checks सिर्फ़ सुविधा हैं। बाहर जाते समय वे context के हिसाब से output encoding करती हैं — HTML में < बनता है <, ताकि वह दिखे, interpret न हो — और database को values parameters की तरह देती हैं, query में चिपकाए गए text की तरह कभी नहीं। सिर्फ़ validation काफ़ी नहीं: O'Brien valid input है, इसलिए सुरक्षा इस बात से आती है कि output कैसे लिखा जाता है।
Cross-site scripting (XSS) missing या गलत output encoding का नतीजा है: input markup बन जाता है, इसलिए attacker का type किया script victim के browser में victim के session के साथ चलता है। यह stored होता है जब value save होकर बाद में दूसरों को दिखती है, reflected जब response उसे request से सीधे वापस दिखा देता है, और DOM-based जब page का अपना JavaScript उसे page में लिखता है, जैसे innerHTML से।
Cross-site request forgery (CSRF) इस बात का फ़ायदा उठाता है कि browsers cookies अपने-आप जोड़ते हैं। जब आप किसी shop में logged in हैं, दूसरी site का एक page shop के change-email address पर hidden form submit करता है, और जो shop सिर्फ़ cookie जाँचती है वह मान लेती है। मुख्य बचाव है data बदलने वाले हर form में anti-CSRF token जिसे server जाँचे; SameSite cookies दूसरी परत हैं, उसकी जगह नहीं लेतीं। Lax तब भी cookies भेजता है जब user दूसरी site से link follow करता है — यह एक वजह है कि data कभी GET request से नहीं बदलना चाहिए।
- Text fields में
' " < > &और<b>qa</b>डालें, फिर हर उस जगह देखें जहाँ value बाद में दिखती है: lists, admin screens, e-mails, exports। Expected: वही characters जो type किए, कभी bold text नहीं, और Arabic या emoji input सही-सलामत। - Error pages generic रहें: कोई stack trace, SQL या file path नहीं। जिस apostrophe से database error आए, वह query में चिपकाए गए text का संकेत है; report करें और आगे probe न करें।
- Data बदलने वाले forms में hidden token होता है या वे उसे header में भेजते हैं, और कुछ भी plain link से delete, pay या change नहीं होता।
- अनुमति हो तो ऐसी request को उसके token के बिना replay करें, जैसे cURL के रूप में copy करके token हटाकर। Expected: server उसे refuse करे।
Security headers
Security headers वे response headers हैं जो browser में सुरक्षा चालू करते हैं। ये दूसरी परत हैं जो XSS जैसे defect का नुकसान सीमित करती है; defect ठीक नहीं करती। मुख्य HTML pages को Network panel में जाँचें या उनके headers Security Header Analyzer में paste करें, और हर value पढ़ें, सिर्फ़ उसकी मौजूदगी नहीं।
Content-Security-Policy(CSP) बताती है कि scripts, styles, images और frames कहाँ से load हो सकते हैं।default-src 'self'सिर्फ़ page के अपने origin (वही scheme, host और port) की अनुमति देता है और inline scripts block करता है; scripts के लिए'unsafe-inline'inject किए गए inline script को चलने देता है, और*source उसे किसी भी site से load होने देता है।- CSP में
frame-ancestors, या पुरानाX-Frame-Options: DENY, दूसरी sites को page को frame में रखकर users से छिपे buttons पर click करवाने (clickjacking) से रोकता है। X-Content-Type-Options: nosniffbrowser को file type का अंदाज़ा लगाने से रोकता है, ताकि text के रूप में भेजी गई file script की तरह न चले।Referrer-Policyसीमित करती है कि दूसरी sites को URL का कितना हिस्सा मिले;Permissions-Policyउन features को बंद करती है जिन्हें site इस्तेमाल नहीं करती, जैसे camera।Server: nginx/1.18.0याX-Powered-Byजैसे headers software और अक्सर उसका version दिखाते हैं और attackers को बताते हैं कि कौन-सी known flaws आज़माएँ: इन्हें हटाएँ या generic बनाएँ।
आज़माएँ: सिक्योरिटी हेडर एनालाइज़र आज़माएँ: HTTP हेडर पार्सर
Worked example: profile page की सुरक्षित जाँच
एक shop के test plan में नए profile page का security smoke check शामिल है, और security lead ने scope लिखकर confirm किया है: test environment, दो test accounts, सिर्फ़ harmless inputs। Tester browser और DevTools से काम करता है।
http://test.shop.example/profile का अंत HTTPS पर 301 redirect से होता है, और page के response headers नीचे दिखाए गए हैं। Application panel session cookie sid को Secure और SameSite=Lax के साथ, पर HttpOnly के बिना दिखाता है। Display name Sara <b>QA</b> profile page पर जैसा type किया वैसा दिखता है, पर admin customer list में bold। Order search में apostrophe डालने पर database error वाला 500 page आता है। Profile form hidden csrf_token भेजता है, जबकि Delete address /profile/address/delete?id=12 का plain link है। हर कमज़ोरी के पहले संकेत पर tester उसमें आगे probe करना रोकता है, evidence save करता है और अगले check पर जाता है।
Report findings को सबसे गंभीर से शुरू करती है: admin list में markup (संभावित stored XSS, जो administrator के session में चलेगा), database error, GET वाला delete link, HttpOnly की कमी, CSP व frame protection की कमी, और low-severity note के रूप में nginx version।
GET /profile HTTP/1.1
Host: test.shop.example
HTTP/1.1 200 OK
Server: nginx/1.18.0
Content-Type: text/html; charset=utf-8
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin| Check | Test environment पर क्या दिखा | Check fail होने पर risk |
|---|---|---|
| HTTPS redirect | http:// का अंत https:// पर 301 redirect सेपास | Network पर pages, form data और cookies पढ़े या बदले जा सकते हैं |
| HSTS header | max-age=31536000 के साथ setपास | Type किया गया http:// address redirect से पहले intercept हो सकता है |
| Session cookie flags | Secure और SameSite=Lax, पर HttpOnly नहींफ़ेल | Inject किया गया script session identifier पढ़ सकता है |
| Display name में markup | Profile page पर जैसा type किया वैसा, admin list में boldफ़ेल | Stored XSS: script administrator के session में चलेगा |
| Order search में apostrophe | Database error वाला 500 pageफ़ेल | Possible injection; error अंदरूनी details दिखाता है |
| Data बदलने वाली requests | Profile form token भेजता है; Delete address एक GET link हैफ़ेल | CSRF: दूसरी site user के browser से action करवाती है |
| CSP और frame protection | दोनों में से कोई header set नहींफ़ेल | XSS के सामने दूसरी परत नहीं; clickjacking के लिए page frame हो सकता है |
| बाकी headers | nosniff और Referrer-Policy set; Server में nginx/1.18.0 दिखता हैसावधानी | Version attackers को बताता है कि कौन-सी known flaws आज़माएँ |
Fail हुआ check report करने लायक finding है, exploit का सबूत नहीं: वह कितना गंभीर है, यह security team तय करती है।
आम गलतियाँ
- Production या दूसरी companies की sites पर बिना लिखित अनुमति security checks आज़माना: harmless test value भी log होकर attack मानी जा सकती है।
- Harmless markers की जगह किसी tutorial से copy किए script payloads या scanners इस्तेमाल करना, या कमज़ोरी का पहला संकेत मिलने के बाद report करने की बजाय आगे probe करते रहना।
- Input सिर्फ़ वहीं जाँचना जहाँ वह डाला जाता है, वहाँ कभी नहीं जहाँ वह बाद में दिखता है: admin screens, e-mails, exports और PDFs।
maxlengthयाtype="email"जैसे browser checks को सुरक्षा मान लेना; सिर्फ़ server के checks मायने रखते हैं।- Header की value पढ़े बिना उसे मौजूद मानकर tick कर देना: जो
Content-Security-Policy'unsafe-inline'scripts की अनुमति देती है, वह XSS से बहुत कम बचाती है। - Security findings ऐसे tracker में file करना जिसे सब पढ़ सकें, या असली cookies और tokens report में paste कर देना।
QA का नज़रिया
Security checks normal test design का हिस्सा हैं। जब कोई story form, user content, cookie, redirect या data बदलने वाला action जोड़ती है, तो उसकी test conditions में matching checks जोड़ें और जल्दी पूछें: यह input कहाँ दिखेगा, और data बदलने वाले actions कैसे सुरक्षित हैं? Test plan में security lead के साथ scope और safe inputs तय करें।
Findings को किसी भी defect की तरह report करें — steps, harmless input, वह कहाँ दिखा, secrets mask करके request और response — पर restricted visibility के साथ, और severity security team के साथ तय करें, जो exploitability का आकलन करती है। Fix के बाद हर उस जगह confirmation testing करें जहाँ value दिखती है, और checks को regression suite में रखें: headers और cookie flags अक्सर नए server, proxy या framework version के साथ बदल जाते हैं।
अभ्यास
Clinic booking page की सुरक्षित review करें
आपके पास एक clinic booking site के test environment के security smoke check की लिखित अनुमति है। नीचे appointments page का response और चार observations हैं: (1) http:// address बिना redirect के load होता है; (2) Cancel link; (3) booking form में patient के रूप में आपका लिखा note, जो doctor की screen पर "results" को italics में दिखाता है; (4) login form की भेजी request।
हर item के लिए तय करें कि वह pass है या finding, risk बताएँ और bug title लिखें। Findings को risk के क्रम में रखें, फिर अगले safe checks लिखें और एक ऐसा check जो आप security team के बिना नहीं करेंगे।
GET https://test.clinic.example/appointments
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
X-Powered-By: Express
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'
X-Frame-Options: DENY
Set-Cookie: session=c2Vzc2lvbi0x; Path=/; HttpOnly
(1) GET http://test.clinic.example/appointments -> 200 OK
(2) <a href="/appointments/cancel?id=481">Cancel</a>
(3) Bring <i>results</i>
(4) GET /login?user=sara&password=[masked]- Response headers को Security Header Analyzer में और
Set-Cookieline को Cookie Analyzer में paste करें; लिखें कि क्या मौजूद है, क्या missing है और क्या कमज़ोर। - चारों observations में से हर एक को pass या finding चिह्नित करें।
- हर finding के लिए एक वाक्य में risk और एक bug title लिखें।
- Findings का क्रम तय करें और अगले safe checks लिखें, साथ में एक check जिसके लिए security team की मंज़ूरी चाहिए।
मॉडल उत्तर दिखाएँ
Pass: X-Frame-Options: DENY framing रोकता है और session cookie HttpOnly है। default-src 'self' वाली CSP मौजूद है पर कमज़ोर: script-src में 'unsafe-inline' inject किए गए inline script को चलने देता है, जो finding A के लिए मायने रखता है।
Findings, सबसे गंभीर पहले, letters के साथ ताकि observation numbers से न उलझें। A (observation 3) "Appointment note doctor की screen पर HTML के रूप में render होता है": संभावित stored XSS, जिसे CSP नहीं रोकेगी क्योंकि वह 'unsafe-inline' scripts की अनुमति देती है। B (observation 4) "Login password को GET request के URL में भेजता है", जहाँ history, server logs और Referer header उसे रख लेते हैं। C (observation 1) "Appointments page बिना redirect या HSTS के HTTP पर serve होता है"; Secure flag न होने से session identifier बिना encryption के जाता है।
D (observation 2) "Cancel appointment बिना CSRF protection वाला GET link है": दूसरी site logged-in patient के browser को उस तक ले जा सकती है; cookie में explicit SameSite नहीं है, और SameSite=Lax भी link follow करने पर cookie भेज देता। E (response headers) Low: X-Powered-By: Express framework बता देता है; nosniff और Referrer-Policy missing हैं।
अगले safe checks: patient की screen पर, reminder e-mails और printouts में note; note और बाकी text fields में quotes और apostrophes। Security team के बिना नहीं: note में script आज़माना, scanner चलाना, या id बदलकर किसी दूसरे patient की booking cancel करना।
अक्सर पूछे जाने वाले सवाल
क्या यह penetration testing ही है?
नहीं। Penetration test security specialists का authorised, simulated attack है, जिसमें वे कमज़ोरियों को exploit करने की कोशिश करते हैं और उनका असर आँकते हैं। इस lesson के checks normal tools और harmless inputs से सिर्फ़ यह देखते हैं कि application कैसे व्यवहार करता है। ये आम defects जल्दी पकड़ते हैं और penetration test को ज़्यादा उपयोगी बनाते हैं; उसकी जगह नहीं लेते।
असली script की जगह <b> से क्यों टेस्ट करें?
Formatting tag वही बात साबित करता है — input page तक markup बनकर पहुँचा — बिना किसी के browser में code चलाए, दूसरे users को छुए या attack की तरह security alarms बजाए। Script चलता या नहीं, और क्या कर सकता था, इसकी पुष्टि security team करती है।
Site HTTPS पर redirect करती है। क्या session cookie को फिर भी Secure चाहिए?
हाँ। Secure के बिना browser उसी host की किसी सादी http:// request के साथ भी cookie भेज देता है, जैसे type किया गया address या पुराना link, redirect होने से पहले ही। HSTS ऐसी requests घटाता है, पर Secure cookie की अपनी सुरक्षा है और इसमें कोई लागत नहीं।
क्या header checker का अच्छा grade मतलब site secure है?
नहीं। Headers दूसरी परत हैं जो नुकसान सीमित करती है; वे access control, injection, sessions या business rules के बारे में कुछ नहीं बताते। Grade को missing या कमज़ोर headers की list की तरह इस्तेमाल करें, और हर value खुद पढ़ें।
संदर्भ
- OWASP Web Security Testing Guide (WSTG)वेब एप्लिकेशन और API की सुरक्षा कमज़ोरियों को परखने की संदर्भ कार्यप्रणाली, एक-एक टेस्ट के रूप में।
- OWASP Cheat Sheet Series: Cross Site Scripting PreventionXSS से बचाव: हर context के अनुसार output encoding, उपयोगकर्ता के लिखे HTML का sanitization, सुरक्षित DOM sinks और framework सुरक्षा, और CSP केवल defence in depth के रूप में।
- OWASP Cheat Sheet Series: Cross-Site Request Forgery PreventionCSRF से बचाव: सिंक्रोनाइज़र टोकन, SameSite कुकी और ऑरिजिन जाँच।
- OWASP Cheat Sheet Series: HTTP Headersकौन-से सुरक्षा हेडर भेजें (HSTS, CSP, X-Content-Type-Options, फ़्रेम सुरक्षा) और कौन-से हटाएँ (Server, X-Powered-By)।
Mutqan tools से अभ्यास करें
पेस्ट किए गए हेडर या किसी सार्वजनिक URL से HTTP सुरक्षा हेडर (CSP, HSTS, X-Frame-Options, Referrer-Policy, Permissions-Policy, COOP/CORP) को ग्रेड दें।
Set-Cookie हेडर पार्स करें और Secure, HttpOnly, SameSite, Domain, Path, एक्सपायरी तथा साइज़ की सर्वोत्तम प्रथाएँ जाँचें।
XSS रोकने के लिए HTML के विशेष कैरेक्टर (<, >, &, कोट्स) को एंटिटी में एस्केप करें।
कच्चे HTTP रिक्वेस्ट/रिस्पॉन्स हेडर को व्याख्या सहित एक संरचित तालिका में बदलें।
और गहराई से
इस topic में आपकी प्रगति
प्रगति ट्रैक करने के लिए साइन इन करें
Topics पूर्ण चिह्नित करें, जहाँ छोड़ा था वहीं से जारी रखें और specialisation परीक्षाएँ खोलें।