PGDCA, BCA, B-Tech, MCA, M-Tech, B.Sc computer science राजस्थान सूचना सहायक व कंप्यूटर शिक्षक विशेष नोट्स: इस अध्याय में हम Cross-Site Request Forgery (CSRF): Attacks and Anti-CSRF Tokens (CSRF (Cross-Site Request Forgery) अटैक और सुरक्षा टोकन्स) की संपूर्ण थ्योरी, मुख्य तकनीकी बिंदु, तुलनात्मक तालिका और विगत परीक्षाओं के पैटर्न पर आधारित 20 अति-महत्वपूर्ण बहुविकल्पीय प्रश्न (MCQs) विस्तृत हिंदी व अंग्रेजी व्याख्या सहित पढ़ेंगे।
Overview: Cross-Site Request Forgery (CSRF) exploits a browser's automatic attachment of session cookies on cross-site requests to execute unauthorized state-changing actions for an authenticated victim—prevented by Anti-CSRF tokens and SameSite cookie policies.
अध्याय सार: CSRF (Cross-Site Request Forgery) एक ऐसा हमला है जिसमें लॉगिन यूज़र के ब्राउज़र द्वारा अपने-आप कुकी भेजे जाने का फायदा उठाकर किसी तीसरे फर्जी पेज से बैंक ट्रांसफर या पासवर्ड बदलने जैसे अनचाहे अनुरोध भिजवाए जाते हैं।
Cross-Site Request Forgery (CSRF): Attacks and Anti-CSRF Tokens: Detailed Notes & Architecture (CSRF (Cross-Site Request Forgery) अटैक और सुरक्षा टोकन्स)
1. Confused Deputy Principle & Ambient Cookie Authority (कन्फ्यूज़्ड डिप्टी सिद्धांत और स्वतः कुकी संलग्न होना)
[EN] Also known as Session Riding or One-Click Attack, CSRF abuses the browser's 'ambient authority': whenever a user holds an active session cookie for bank.example, any third-party page can trigger an HTTP request to bank.example and the browser automatically attaches the victim's cookies. Crucially, the Same-Origin Policy (SOP) blocks the malicious site from READING the response, yet still allows SENDING simple cross-origin state-changing requests.
[HI] CSRF को 'Session Riding' भी कहा जाता है। जब यूज़र किसी वेबसाइट पर लॉगिन रहता है, तो ब्राउज़र किसी अन्य साइट से उस वेबसाइट पर भेजे जाने वाले HTTP अनुरोध के साथ स्वतः सेशन कुकी जोड़ देता है। Same-Origin Policy दूसरे डोमेन को सर्वर का जवाब पढ़ने से तो रोकती है, लेकिन क्रॉस-साइट अनुरोध भेजने (जैसे फॉर्म सबमिट करने) से नहीं रोकती।
2. GET vs POST CSRF Delivery & Content-Type Traps (GET बनाम POST CSRF हमले व Content-Type जाल)
[EN] When applications violate HTTP semantics by modifying state via GET endpoints (such as '/transfer?to=bob&amount=5000'), a single hidden '<img src="https://bank.example/transfer?to=bob">' triggers the action silently upon page load. For POST endpoints, attackers embed an auto-submitting hidden '<form method="POST">' inside a hidden iframe. Even JSON endpoints can be attacked via 'enctype="text/plain"' forms unless the server strictly verifies 'Content-Type: application/json'.
[HI] यदि वेबसाइट GET अनुरोध से डेटा बदलती है, तो हमलावर केवल '<img src=...>' टैग से चुपचाप हमला कर सकता है। POST अनुरोध के लिए हमलावर छिपे हुए '<form method="POST">' को JavaScript से ऑटो-सबमिट कराता है। यहाँ तक कि JSON API भी असुरक्षित रह सकते हैं यदि सर्वर 'application/json' Content-Type की सख्त जांच न करे।
3. Synchronizer Token Pattern & Double-Submit Cookie (सिंक्रोनाइज़र टोकन पैटर्न व डबल-सबमिट कुकी)
[EN] The primary server-side defense is the Synchronizer Token Pattern: the server generates a cryptographically unpredictable, per-session or per-request Anti-CSRF secret token, stores it in the server session, and embeds it in a hidden form field or custom HTTP header ('X-CSRF-Token'). Because SOP stops cross-origin JavaScript from reading pages or tokens on bank.example, the attacker's forged form lacks the valid token and fails HTTP 403 validation. Stateless APIs alternatively use the Double-Submit Cookie pattern signed with HMAC.
[HI] Synchronizer Token Pattern में सर्वर हर सेशन या फॉर्म के लिए एक गुप्त व अनुमान से परे रैंडम एंटी-CSRF टोकन बनाता है और उसे हिडन इनपुट या कस्टम हेडर ('X-CSRF-Token') में मांगता है। SOP के कारण बाहरी साइट इस टोकन को पढ़ नहीं सकती, इसलिए फर्जी फॉर्म सर्वर पर 403 त्रुटि से अस्वीकार हो जाता है।
4. SameSite Cookie Attributes & Origin/Custom Header Checks (SameSite कुकी एट्रिब्यूट व Origin/कस्टम हेडर जांच)
[EN] Modern browsers support the 'SameSite' Set-Cookie attribute: 'SameSite=Strict' blocks cookies on ALL cross-site requests (even clicking external links), 'SameSite=Lax' (modern default) sends cookies on top-level safe GET navigations while blocking cross-site POST forms/iframes, and 'SameSite=None' requires the 'Secure' flag. Complementary defenses include validating HTTP 'Origin'/'Referer' headers, enforcing CORS preflight via custom headers, and requiring current-password re-authentication on critical actions.
[HI] आधुनिक सुरक्षा में 'SameSite=Strict' सभी क्रॉस-साइट अनुरोधों पर कुकी रोक देता है, जबकि 'SameSite=Lax' (डिफ़ॉल्ट) केवल सुरक्षित लिंक क्लिक पर कुकी भेजता है पर क्रॉस-साइट POST फॉर्म पर रोकता है। इसके साथ 'Origin' हेडर की जांच और संवेदनशील बदलावों पर पुनः पासवर्ड पुष्टि (Re-auth) आवश्यक है।
Syntax, Formula & Technical Example (Cross-Site Request Forgery (CSRF): Attacks and Anti-CSRF Tokens)
<!-- 1. Attacker's Malicious Cross-Site Auto-Submitting CSRF Form -->
<form id="csrf" action="https://bank.example/change-email" method="POST">
<input type="hidden" name="email" value="attacker@evil.test" />
</form>
<script>document.getElementById('csrf').submit();</script>
# 2. Server-Side Defense: SameSite Cookie + Synchronizer Token
Set-Cookie: sid=8b2e4f1a9c; Path=/; Secure; HttpOnly; SameSite=Lax
# HTML Form includes unpredictable server-verified token:
# <input type="hidden" name="csrf_token" value="hmac_or_csprng_token_here">Cross-Site Request Forgery (CSRF): Attacks and Anti-CSRF Tokens Quick Reference & Comparison Table
| CSRF Concept / Defense | Technical Mechanism | Security Guarantee & Caveat |
|---|---|---|
| CSRF Attack (Session Riding) | Forged cross-site GET/POST carrying ambient cookies | Abuses server trust in authenticated victim browser |
| Synchronizer Token Pattern | Server-stored CSPRNG token matched in form/header | Blocks forged requests; attacker cannot read token across origins |
| SameSite=Lax Cookie | Sent on top-level GET links; withheld on POST forms | Modern browser default; stops classic hidden POST CSRF |
| SameSite=Strict Cookie | Withheld on ALL cross-site navigations and embeds | Maximum CSRF isolation; breaks external link login UX |
Cross-Site Request Forgery (CSRF): Attacks and Anti-CSRF Tokens Top 20 Bilingual MCQs with Answers
Q1. Why can an attacker execute a state-changing action via CSRF even though the Same-Origin Policy (SOP) exists?
(Same-Origin Policy (SOP) होने के बावजूद हमलावर CSRF के जरिए सर्वर पर अनचाहा बदलाव कैसे करा सकता है?)
(A) SOP automatically disables authentication cookies on HTTPS pages
(B) SOP shares all session tokens globally across open browser tabs
(C) SOP prevents cross-origin sites from reading HTTP responses, NOT from sending simple cross-origin form submissions or image requests with cookies
(D) SOP only applies to FTP and SSH traffic
Correct Answer: (C)
[EN] Because browsers permit cross-origin HTML <form> POSTs and <img> GETs without preflight, blind state changes succeed even if the attacker can't read the reply.
[HI] SOP बाहरी वेबसाइट को उत्तर पढ़ने से रोकती है, लेकिन फॉर्म सबमिट करने या इमेज लिंक द्वारा कुकी सहित अनुरोध भेजने से नहीं रोकती।
Q2. Which fundamental difference separates CSRF from Cross-Site Scripting (XSS)?
(CSRF और Cross-Site Scripting (XSS) के बीच कौन सा मूलभूत अंतर है?)
(A) XSS exploits a user's trust in a vulnerable website (running attacker JS on that site), whereas CSRF exploits a website's trust in a logged-in user's browser
(B) CSRF always requires stealing the session cookie first, whereas XSS never uses cookies
(C) XSS only affects GET requests while CSRF only affects PUT requests
(D) CSRF executes JavaScript inside the SQL server, whereas XSS attacks routers
Correct Answer: (A)
[EN] In CSRF, zero attacker script executes inside the target origin—the attacker simply induces the victim browser to fire an unwanted HTTP request.
[HI] XSS में वेबसाइट पर हमलावर का कोड चलता है, जबकि CSRF में वेबसाइट विक्टिम के ब्राउज़र से आए वैध कुकी वाले अनचाहे अनुरोध पर भरोसा कर लेती है।
Q3. Why must HTTP GET endpoints NEVER trigger state-changing database actions such as transferring money or deleting users?
(HTTP GET एंडपॉइंट्स द्वारा पैसे ट्रांसफर करने या यूज़र डिलीट करने जैसे बदलाव कभी क्यों नहीं होने चाहिए?)
(A) GET requests automatically expose passwords inside TCP SYN headers
(B) Browsers block GET requests completely over HTTPS port 443
(C) State-changing GET URLs can be triggered silently via simple <img>, <a>, or <link> tags and bypass SameSite=Lax top-level navigation rules
(D) GET requests are limited to 128-bit AES encryption only
Correct Answer: (C)
[EN] RFC 9110 mandates GET be 'safe' and idempotent; furthermore, SameSite=Lax still transmits cookies on top-level GET link clicks.
[HI] GET अनुरोध केवल डेटा पढ़ने (Safe & Idempotent) के लिए होते हैं; इनके द्वारा बदलाव होने पर सामान्य <img> या लिंक क्लिक से भी CSRF हो जाता है।
Q4. How does the 'Synchronizer Token Pattern' successfully block CSRF attacks?
('Synchronizer Token Pattern' CSRF हमलों को सफलतापूर्वक कैसे रोकता है?)
(A) It encrypts the user's session cookie inside the HTML <title> tag
(B) It forces every browser to disable JavaScript globally
(C) The server requires a secret unpredictable per-session/request token in the body or custom header that a cross-origin attacker cannot read due to SOP
(D) It validates the user's MAC hardware address on each HTTP packet
Correct Answer: (C)
[EN] Even though the browser attaches session cookies automatically, the attacker cannot guess or fetch the hidden CSRF token from the target page.
[HI] ब्राउज़र कुकी तो स्वतः भेज देता है, लेकिन बाहरी हमलावर SOP के कारण असली पेज के गुप्त CSRF टोकन को पढ़ या अनुमान नहीं लगा सकता।
Q5. What does setting 'SameSite=Strict' on a session cookie instruct modern browsers to do?
(सेशन कुकी पर 'SameSite=Strict' सेट करने से आधुनिक ब्राउज़र क्या करते हैं?)
(A) Never send the cookie on ANY cross-site request—not even when following a normal external link from Google or email
(B) Expire the cookie immediately after 5 seconds
(C) Allow JavaScript to read the cookie even if HttpOnly is set
(D) Send the cookie exclusively on HTTP POST forms from third-party sites
Correct Answer: (A)
[EN] SameSite=Strict gives total CSRF cookie protection, though clicking an external email link to the site will appear logged out initially.
[HI] SameSite=Strict बाहरी साइट से किसी भी प्रकार के अनुरोध (यहाँ तक कि सामान्य लिंक क्लिक) पर भी कुकी नहीं भेजता।
Q6. How does 'SameSite=Lax' differ from 'SameSite=Strict'?
('SameSite=Lax' और 'SameSite=Strict' के बीच क्या अंतर है?)
(A) SameSite=Lax permits cross-origin hidden iframe POST submissions with cookies
(B) SameSite=Lax sends cookies only on WebSocket connections
(C) SameSite=Lax disables HTTPS requirement for SameSite=None cookies
(D) SameSite=Lax attaches cookies on safe top-level GET navigations (like clicking a link) while withholding cookies on cross-site POST forms and subresource loads
Correct Answer: (D)
[EN] Because SameSite=Lax balances usability (external links keep you logged in) and security (blocks POST form CSRF), modern Chromium/Firefox enforce it by default.
[HI] SameSite=Lax बाहरी लिंक क्लिक करने पर (टॉप-लेवल GET) कुकी भेजता है ताकि यूज़र लॉगिन दिखे, लेकिन क्रॉस-साइट POST फॉर्म व iframe में कुकी रोक देता है।
Q7. What happens if a server sets 'SameSite=None' on a cookie WITHOUT also including the 'Secure' attribute in modern browsers?
(यदि आधुनिक ब्राउज़रों में कोई सर्वर 'Secure' एट्रिब्यूट जोड़े बिना 'SameSite=None' कुकी सेट करे तो क्या होगा?)
(A) The browser automatically upgrades it to SameSite=Strict
(B) The cookie becomes readable from every third-party domain
(C) Modern browsers reject the cookie because SameSite=None strictly requires the Secure flag (HTTPS only)
(D) The browser deletes all cached TLS certificates
Correct Answer: (C)
[EN] Per RFC 6265bis and Chromium/Mozilla policies, cross-site cookies (SameSite=None) are invalid unless paired with 'Secure'.
[HI] आधुनिक ब्राउज़र बिना 'Secure' (HTTPS) फ्लैग के 'SameSite=None' कुकी को स्वीकार ही नहीं करते और अस्वीकार कर देते हैं।
Q8. In stateless REST architectures, how does the 'Double-Submit Cookie' CSRF mitigation work?
(स्टेटलेस REST सिस्टम में 'Double-Submit Cookie' CSRF सुरक्षा कैसे कार्य करती है?)
(A) The client reads/holds a random CSRF value in a cookie AND echoes the exact same value inside a custom HTTP header (e.g., X-CSRF-Token) or form parameter
(B) The user submits their password twice during login
(C) The server issues two identical JSESSIONID cookies with different expiries
(D) The firewall verifies two TCP SYN handshakes sequentially
Correct Answer: (A)
[EN] Since a cross-site attacker cannot read the victim's cookie value (nor set custom cross-origin headers without CORS approval), the header and cookie match proves origin legitimacy.
[HI] चूंकि बाहरी हमलावर यूज़र की कुकी पढ़ नहीं सकता, इसलिए सर्वर जाँचता है कि कुकी का टोकन और कस्टम हेडर/फॉर्म में भेजा गया टोकन मेल खाते हैं या नहीं।
Q9. Why does requiring a custom HTTP header like 'X-Requested-With' or 'Content-Type: application/json' protect REST APIs against classic form-based CSRF?
(REST API में कस्टम हेडर (जैसे 'X-Requested-With') या सख्त 'Content-Type: application/json' की मांग करना सामान्य फॉर्म-आधारित CSRF से कैसे बचाता है?)
(A) JSON automatically strips cookies from every browser packet
(B) HTML <form> tags cannot send custom headers or application/json bodies, and cross-origin fetch() triggers a CORS preflight OPTIONS check blocked by the server
(C) HTML <form> tags cannot submit POST requests over HTTPS
(D) CORS preflight requests require administrator SSH login
Correct Answer: (B)
[EN] Unless CORS explicitly allows cross-origin requests via Access-Control-Allow-Origin + Allow-Credentials, browsers block custom-header cross-site XHR/fetch.
[HI] HTML फॉर्म कस्टम हेडर या application/json नहीं भेज सकता, और JavaScript fetch() करने पर ब्राउज़र पहले CORS preflight जांच करता है जिसे सर्वर ब्लॉक कर देता है।
Q10. What weakness makes relying SOLELY on checking the HTTP 'Referer' header unreliable for CSRF prevention?
(CSRF रोकने के लिए केवल HTTP 'Referer' हेडर की जांच पर निर्भर रहना कमज़ोर क्यों माना जाता है?)
(A) HTTP POST requests never include any headers
(B) Browsers always encrypt the Referer header using RSA-2048
(C) Referer headers only appear inside HTTP 404 responses
(D) Privacy tools, corporate proxies, and 'Referrer-Policy: no-referrer' frequently strip the Referer header, forcing sites to fail-open or break valid users
Correct Answer: (D)
[EN] Checking 'Origin' (with fallback to Referer) is a useful defense-in-depth layer, but should reinforce—not replace—Anti-CSRF tokens.
[HI] प्राइवेसी सेटिंग्स, प्रॉक्सी या Referrer-Policy के कारण Referer हेडर अक्सर गायब रहता है, इसलिए इसे केवल सहायक परत के रूप में उपयोग करना चाहिए।
Q11. Why can an XSS vulnerability completely bypass ALL Anti-CSRF token protections and SameSite cookies?
(कोई XSS कमजोरी सभी Anti-CSRF टोकन और SameSite कुकी सुरक्षा को पूरी तरह विफल क्यों कर सकती है?)
(A) XSS disables TLS encryption on the router
(B) XSS converts SameSite=Strict cookies into SameSite=None automatically
(C) An XSS script runs INSIDE the trusted origin itself, so it can fetch the form page, read the valid CSRF token directly, and submit same-origin requests
(D) XSS breaks the database primary key constraints
Correct Answer: (C)
[EN] CSRF defenses stop external cross-site requests; once XSS runs inside the site's own origin, requests are same-origin and tokens are readable.
[HI] XSS पेलोड खुद उसी वेबसाइट के भीतर चलता है, इसलिए वह सर्वर से असली पेज पढ़कर सही CSRF टोकन भी निकाल लेता है और Same-Origin अनुरोध भेज देता है।
Q12. Which HTML form attribute can still bypass an API that fails to reject 'text/plain' content even when the backend expects JSON?
(यदि कोई JSON API 'Content-Type' की सख्त जांच न करे, तो HTML <form> के किस 'enctype' एट्रिब्यूट का उपयोग कर CSRF किया जा सकता है?)
(A) enctype="text/css"
(B) enctype="text/plain"
(C) enctype="application/xml"
(D) enctype="application/octet-stream"
Correct Answer: (B)
[EN] HTML forms only support three encodings (urlencoded, multipart, text/plain); clever input naming in text/plain produces valid JSON syntax if Content-Type isn't checked.
[HI] HTML फॉर्म केवल urlencoded, multipart और text/plain सपोर्ट करते हैं; यदि सर्वर Content-Type न जांचे तो text/plain से JSON जैसा पेलोड भेजा जा सकता है।
Q13. Why is Anti-CSRF protection generally NOT required for public, unauthenticated read-only search forms or login endpoints (with one caveat)?
(सामान्य अनऑथेंटिकेटेड सर्च फॉर्म पर Anti-CSRF टोकन की आवश्यकता क्यों नहीं होती, जबकि लॉगिन CSRF को संभालना क्यों महत्वपूर्ण है?)
(A) Login pages are exempt from Same-Origin Policy by browser law
(B) Search forms use UDP instead of TCP
(C) Unauthenticated search holds no privileged session to abuse, though 'Login CSRF' can trick a victim into logging into the attacker's own account
(D) Cookies are never created after a user logs in
Correct Answer: (C)
[EN] Wait-free read-only queries lack state changes, whereas Login CSRF (logging a victim into an attacker's account to track saved cards/history) still warrants CSRF protection on login.
[HI] सर्च फॉर्म से कोई खाता बदलाव नहीं होता, लेकिन लॉगिन पर भी CSRF सुरक्षा लगाना अच्छा रहता है ताकि 'Login CSRF' द्वारा पीड़ित को हमलावर के खाते में लॉगिन न कराया जाए।
Q14. What does asking the user to re-enter their current password (or an OTP/FIDO challenge) accomplish on sensitive forms like 'Change Email' or 'Wire Transfer'?
('ईमेल बदलें' या 'फंड ट्रांसफर' जैसे संवेदनशील फॉर्म पर वर्तमान पासवर्ड या OTP दोबारा मांगना CSRF के विरुद्ध कैसे काम करता है?)
(A) It disables browser caching of CSS stylesheets
(B) It compresses the HTTP response body
(C) It blocks blind CSRF completely because an external attacker does not know the user's current password or live MFA code
(D) It refreshes the server's DNS A record
Correct Answer: (C)
[EN] Re-authentication guarantees active user intent and stops CSRF even if cookies or tokens were somehow misconfigured.
[HI] बाहरी हमलावर को यूज़र का वर्तमान पासवर्ड या लाइव OTP पता नहीं होता, इसलिए संवेदनशील कार्य पर पुनः प्रमाणीकरण CSRF को पूरी तरह विफल कर देता है।
Q15. In the OWASP Top 10 security classification, how are CSRF defenses primarily categorized?
(OWASP Top 10 सुरक्षा मानकों में CSRF को सामान्यतः किस श्रेणी या नियंत्रण के अंतर्गत वर्गीकृत किया जाता है?)
(A) Physical Data Center Intrusion
(B) Broken Access Control / Session Management & Cross-Site Request Forgery Prevention
(C) Insecure Hardware BIOS Firmware
(D) Cryptographic Failures (SHA-1 collision)
Correct Answer: (B)
[EN] Because CSRF tricks an application into authorizing actions without validating user intent/origin, OWASP treats it under access/request validation controls.
[HI] CSRF अनधिकृत रूप से यूज़र के अधिकार से कार्रवाई करवाता है, इसलिए OWASP में इसे Access Control व Session/Request Validation सुरक्षा के अंतर्गत रखा जाता है।
Q16. Which statement about Cross-Site Request Forgery (CSRF) is FALSE?
(Cross-Site Request Forgery (CSRF) के संबंध में निम्नलिखित में से कौन सा कथन असत्य (FALSE) है?)
(A) Synchronizer tokens must be unpredictable and tied to the user's authenticated session
(B) Using HTTPS (TLS encryption) alone completely prevents Cross-Site Request Forgery attacks
(C) CSRF attacks rely on browsers automatically attaching cookies to cross-site requests
(D) SameSite=Lax is the default cookie mode in modern Chromium-based browsers when SameSite is omitted
Correct Answer: (B)
[EN] HTTPS encrypts traffic in transit between client and server—it does NOT stop a third-party site from making the victim's browser send valid HTTPS requests with cookies!
[HI] केवल HTTPS (TLS) लगाने से CSRF नहीं रुकता क्योंकि हमलावर की साइट से विक्टिम का ब्राउज़र HTTPS पर भी कुकी के साथ वैध दिखने वाला अनुरोध भेज देता है।
Q17. Within Cross-Site Request Forgery (CSRF): Attacks and Anti-CSRF Tokens, which csrf concept / defense directly maps to: "Forged cross-site GET/POST carrying ambient cookies"?
(Cross-Site Request Forgery (CSRF): Attacks and Anti-CSRF Tokens में कौन सा CSRF Concept / Defense सीधे "Forged cross-site GET/POST carrying ambient cookies" से संबंधित है?)
(A) SameSite=Lax Cookie
(B) CSRF Attack (Session Riding)
(C) Synchronizer Token Pattern
(D) SameSite=Strict Cookie
Correct Answer: (B)
[EN] In Cross-Site Request Forgery (CSRF): Attacks and Anti-CSRF Tokens, 'CSRF Attack (Session Riding)' handles 'Forged cross-site GET/POST carrying ambient cookies' (Abuses server trust in authenticated victim browser).
[HI] Cross-Site Request Forgery (CSRF): Attacks and Anti-CSRF Tokens में 'CSRF Attack (Session Riding)' का कार्य/विवरण 'Forged cross-site GET/POST carrying ambient cookies' (Abuses server trust in authenticated victim browser) है।
Q18. Which option accurately describes 'Synchronizer Token Pattern' in Cross-Site Request Forgery (CSRF): Attacks and Anti-CSRF Tokens?
(Cross-Site Request Forgery (CSRF): Attacks and Anti-CSRF Tokens के संदर्भ में 'Synchronizer Token Pattern' की सही विशेषता कौन सी है?)
(A) Sent on top-level GET links; withheld on POST forms
(B) Withheld on ALL cross-site navigations and embeds
(C) Server-stored CSPRNG token matched in form/header
(D) Forged cross-site GET/POST carrying ambient cookies
Correct Answer: (C)
[EN] 'Synchronizer Token Pattern' provides 'Server-stored CSPRNG token matched in form/header' — key point: Blocks forged requests; attacker cannot read token across origins.
[HI] 'Synchronizer Token Pattern' का मुख्य विवरण 'Server-stored CSPRNG token matched in form/header' है (Blocks forged requests; attacker cannot read token across origins)।
Q19. In Cross-Site Request Forgery (CSRF): Attacks and Anti-CSRF Tokens, identify the correct parameter for the specification: "Sent on top-level GET links; withheld on POST forms".
(Cross-Site Request Forgery (CSRF): Attacks and Anti-CSRF Tokens में "Sent on top-level GET links; withheld on POST forms" विवरण किस विकल्प के लिए सही है?)
(A) SameSite=Strict Cookie
(B) CSRF Attack (Session Riding)
(C) Synchronizer Token Pattern
(D) SameSite=Lax Cookie
Correct Answer: (D)
[EN] 'SameSite=Lax Cookie' corresponds to 'Sent on top-level GET links; withheld on POST forms' (Modern browser default; stops classic hidden POST CSRF).
[HI] 'SameSite=Lax Cookie' का संबंध 'Sent on top-level GET links; withheld on POST forms' (Modern browser default; stops classic hidden POST CSRF) से है।
Q20. Considering Cross-Site Request Forgery (CSRF): Attacks and Anti-CSRF Tokens, what key behavior defines 'SameSite=Strict Cookie'?
(Cross-Site Request Forgery (CSRF): Attacks and Anti-CSRF Tokens में 'SameSite=Strict Cookie' की मुख्य भूमिका या मान क्या है?)
(A) Withheld on ALL cross-site navigations and embeds
(B) Server-stored CSPRNG token matched in form/header
(C) Forged cross-site GET/POST carrying ambient cookies
(D) Sent on top-level GET links; withheld on POST forms
Correct Answer: (A)
[EN] 'SameSite=Strict Cookie' represents 'Withheld on ALL cross-site navigations and embeds' (Maximum CSRF isolation; breaks external link login UX).
[HI] 'SameSite=Strict Cookie' का अर्थ/मान 'Withheld on ALL cross-site navigations and embeds' है (Maximum CSRF isolation; breaks external link login UX)।
Cross-Site Request Forgery (CSRF): Attacks and Anti-CSRF Tokens — Exam FAQs
Q1: Why doesn't HTTPS stop a CSRF attack?
HTTPS होने के बावजूद CSRF हमला क्यों हो जाता है?
[EN] TLS/HTTPS protects data in transit against network eavesdroppers, whereas CSRF tricks the victim's legitimate browser into initiating an authorized HTTPS request carrying valid session cookies directly to the target site.
[HI] HTTPS डेटा को रास्ते में चोरी होने से बचाता है, जबकि CSRF में पीड़ित का असली ब्राउज़र खुद ही सर्वर को वैध कुकी के साथ असली HTTPS अनुरोध भेज देता है।
Q2: If a site uses JWT in an Authorization: Bearer header (in memory) instead of cookies, is it vulnerable to CSRF?
यदि वेबसाइट कुकी के बजाय मेमोरी में मौजूद JWT को 'Authorization: Bearer' हेडर में भेजती है, तो क्या वह CSRF से सुरक्षित है?
[EN] Yes, against CSRF—because browsers never automatically attach Authorization headers to cross-site requests. However, storing JWTs in localStorage remains vulnerable to theft via XSS.
[HI] हाँ, CSRF से सुरक्षित है क्योंकि ब्राउज़र कभी भी अपने-आप Authorization हेडर नहीं जोड़ता। हालांकि localStorage में रखा JWT अभी भी XSS द्वारा चोरी हो सकता है।
Q3: Does CAPTCHA also help defend against CSRF?
क्या CAPTCHA लगाने से भी CSRF हमले को रोका जा सकता है?
[EN] Yes, because an automated cross-site form cannot solve an interactive server-verified CAPTCHA challenge, though Anti-CSRF tokens + SameSite cookies are preferred for seamless UX.
[HI] हाँ, क्योंकि बाहरी फर्जी फॉर्म सर्वर द्वारा जांचा जाने वाला CAPTCHA हल नहीं कर सकता; हालांकि बेहतर यूज़र अनुभव के लिए Anti-CSRF टोकन व SameSite कुकी मानक हैं।
Post a Comment
Post a Comment