مفهوم Cryptography =

رمزنگاری.کاربرد: اطلاعات رو از یه طرف بفرستیم به یه طرف دیگه بدون اینکه خونده یا دستکاری بشه. داده هامونو با یه سری الگورتیم ریاضی تبدیل به اطلاعاتی میکنیم که قابل خوندن نباشه، برای اینکه این الگورتیم کار کنه نیاز به کلید داریم که داده هامونو باهاش رمز یا encrypt کنیم. برای decrypt یا رمزگشایی هم باز به کلید نیاز داریم.
2 نوع الگوریتم رمزنگاری داریم.
1. Symmetric : متقارن
2. Asymmetric : نامتقارن
در رمزنگاری متقارن، فرستنده و گیرنده هر دو از یک کلید واسه encrypt و decrypt کردن استفاده میکنن مثل الگوریتم AES.
در رمزنگاری نامتقارن، به جای یک کلید جفت کلید داریم که با اولی encrypt و با دومی decrypt میکنن مثل RSA. در این رمزنگاری مفهوم Private key و Public key وجود داره که اگه با Private key چیزی رو encrypt کنیم همه میتونن با public key ما اونو باز کنن چون public key رو همه دارن. اگه کسی بخواد پیغامی رو واسه ما بفرسته که فقط ما بتونیم ببینیم، با public key ما دیتارو encrypt میکنه و فقط Private key ما میتونه اونو decrypt کنه و اونم فقط خودمون داریمش.
نکته مهم: در مواردی مثل jwt که باید یک کلید واسش انتخاب کنیم، کلید باید پیچیدگی لازم رو داشته باشه و توی password list های گیت هاب نباشه تا بقیه نتونن با brute force کردن به مقدار دقیق کلید ما پی ببرن.
#Cryptography
#Encryption
#jwt
#brute_force

مفهوم Encoding =

یک فرایندی که هر کاراکتر رو به یه شکل یا فرمت دیگه نمایش میدیم و برای کامپیوتر قابل درکه. انواع مختلفی داره و هر کدوم واسه هدفی ساخته شده.
ascii :
یه فرمت Encoding دیتا هست در کامپیوتر و اینترنت. به هر کاراکتر یه عددی رو نسبت میدیم که این شامل کاراکتر های printable و non printable هست. 32 کاراکتر اول از ascii قابل چاپ نیستند مثل Enter.

Unicode :
یه استاندارد برای نمایش و پردازش متن به اکثر زبان های دنیا است. و به روش های مختلف کدگذاری را انجام میدهد که UTF-8 معروف ترین و پر استفاده ترین روش کدگذاریه که در میان وب سایت ها استفاده میشه.

Hexadecimal:
بهش Hex یا base16 هم میگن. بر پایه 16 میباشد و از اعداد 0 تا 9 و حروف A تا F استفاده میکند. برای مثال Hex شده ی https://news.1rj.ru/str/web_appsec میشه

68747470733a2f2f742e6d652f7765625f617070736563

Decimal :
اعداد بر پایه 10. هر عدیی که تو دنیای واقعی استفاده میکنیم بر پایه 10 هست.

URL encoding :
یک فرایندی است که کاراکتر هارو به یه فرمتی تبدیل میکنیم که قابل انتقال باشه در سطح وب و اینترنت. برای مثال URL encode شده ی https://news.1rj.ru/str/web_appsec میشه به :

https%3A%2F%2Ft.me%2Fweb_appsec

Base64 encode:
برای تبدیل داده ها به یک فرمت متنی استفاده میشود. و برای انتقال داده ها در کامپیوتر و ذخیره سازی داده کاربرد دارد . از حروف بزرگ و کوچک انگلیسی و اعداد و برخی کاراکتر ها استفاده میکند. برای مثال https://news.1rj.ru/str/web_appsec در base64 میشود :

aHR0cHM6Ly90Lm1lL3dlYl9hcHBzZWM=

html encoding :
یک فرایندی است که متن را به فرمتی تبدیل میکنند که برای مرورگر قابل نمایش باشه ولی به عنوان html تفسیر نشه توسط مرورگر. برای مثال از <> در html برای آغاز و پایان تگ استفاده میکنند و برای مرورگر معنا دارند. فرمت html encode شده اینا میشه <>,
که یکی از روش های جلوگیری از حملات xss و html injection تبدیل همین >< به معادل html encode شون هست.

نکته مهم : encoding قابل برگشت هست و هرکسی میتونه دیتای encode شده رو به مقدار اولیش برگردونه، پس نباید دیتای حساس مثل اطلاعات ورود به سامانه و... رو encode کنیم چون قابل برگشت هست و مثل رمزنگاری نیست که به کلید احتیاج داشته باشه.
#Encoding

جدول ascii برای درک بهتر

مفهوم Hash =

یک تابع یک طرفس. ما بهش ورودی میدیم و بهمون خروجی میده. تبدیل خروجی به ورودی غیر ممکنه. الگوریتم های زیادی برای hashing وجود داره که هر کدوم ساختار مشخضی دارن مثل طول کاراکترها، که یکی از معروف ترین الگوریتم هاش MD5 هست.
حالا کجا استفاده میشه؟ معمولا پسورد رو به صورت Hash شده تو دیتابیس ذخیره میکنن. ممکنه سوال پیش بیاد که چرا از رمزنگاری برای پسورد استفاده نمیشه. جواب: چون ممکنه به هر طریقی کلید اون رمزنگاری افشا بشه و اطلاعات همه کاربران سامانه به خطر بیفته.
وقتی از Hashing برای پسورد استفاده میکنیم، به این معنی نیست که هکر به هیچ وجه نمیتونه به پسورد اصلی برسه و فقط کار برای هکر سخت میشه.
هکر از rainbow table برای به دست اوردن مقدار واقعی Hash استفاده میکنه. rainbow table یه جدوله که حاوی اطلاعات از پیش نوشته شده است به این صورت:
Password : Hash
یعنی Hash پسورد های رایج رو حساب میکنند و تو یه دیتابیس ذخیره میکنن. معمولا از سایت های آنلاین به عنوان rainbow table استفاده میکنند. فرض کنین که هکر به یه Hash با مقدار زیر رسیده :
58b4e38f66bcdb546380845d6af27187
میره به سایت https://crackstation.net/ و Hash رو اینجا سرچ میکنه و چون این سایت پسورد qwerty1234 و Hash مربوط بهش رو تو دیتابیس خودش داشته بهمون نشون میده.
#Hash
#rainbow_table

Same Origin Policy/SOP چیست =


فرض کنین روی مرورگر دوتا Tab باز هست که یکی attacker.com و دیگری bank.com هست، اگه هکر از attacker.com یه درخواست xhr میزد به bank.com و اطلاعات بانکی کاربر رو میتونست بخونه، هیچ امنیتی وجود نداشت. ولی مرورگرا جلوی این اتفاق رو میگیرن با SOP. SOP کارش اینه که اجازه نمیده یه صفحه تو مرورگر به اطلاعات یه صفحه دیگه دسترسی داشته باشه، مگر اینکه با هم Same Origin باشن. حالا اصلا Origin چیه؟ ترکیب protocol و host name و port میشه یه Origin، و اگه دوتا دامنه حداقل تو یکی از این 3 شرط با هم برابر نباشند، دیگه Same Origin نیستند و به اصطلاح Cross Origin هستند و مرورگر اجازه نمیده که به اطلاعات همدیگه دسترسی داشته باشند.
برای مثال دوتا سایت زیر با هم Same Origin هستند :
http://Google.com:8080/search/index.php?key=stuff#top
http://Google.com:8080
نکته : path و پارامتر و fragment توی Origin تاثیری ندارن.
نکته : SOP به صورت پیشفرض روی همه مرورگرها هست و وب سرور نقشی تو فعال سازی این مکانیزم امنیتی نداره بر خلاف CSP(در آینده کاور میشه)
ولی دوتا سایت زیر با هم Cross Origin هستند :
http://Google.com:80
http://Google.com:443
دلیلش هم تفاوت داشتن پورت هاس.
حالا دقیقا SOP کجا و چطور کار میکنه؟
وقتی کاربر سایت attacker.com رو باز میکنه این سایت یه کد مخرب xhr با جاوااسکریپت نوشته که کاربر رو مجبور میکنه یه درخواست بزنه به Bank.com (کاربر متوجه درخواست نمیشه) و درخواست هم با موفقیت ارسال میشه و اطلاعات کاربر رو تو Bank.com میخونه، ولی وقتی میخواد اطلاعات رو در اختیار attacker.com که Cross Origin هست قرار بده، SOP میاد تو بازی و جلوی این کار رو میگیره. پس SOP با ارسال درخواست کاری نداره و فقط موقع برگشتن response جلوشو میگیره.

تا الان یاد گرفتیم که SOP جلوی خوندن اطلاعات Cross Origin رو میگیره، ولی آیا همیشه اینطوره؟ خیر. SOP روی یه سری فایلا اعمال نمیشه و همین باعث موارد امنیتی میشه. برای مثال SOP روی عکس ها اعمال نمیشه و میتونیم از هر سایتی به هر سایتی درخواست بزنیم و عکس رو تو سایتمون لود کنیم. و همچنین روی فایل های Javanoscript اعمال نمیشه. یعنی هر فایل جاوااسکریپتی که تو سایت ما هست، میتونه توسط Origin های دیگه خونده بشه و اینجا ممکنه تحت شرایطی باعث به وجود اومدن آسیب پذیری بشه(در آینده کاور میشه).
باور غلطی که خیلیا دارن اینه که SOP همیشه روی وب اپلیکیشن ما کار میکنه:)
در صورتی که اینطور نیست و این مکانیزم امنیتی مختص پروتکل HTTP هست و اگه سایت از پروتکل websocket استفاده کرده باشه ، SOP اعمال نمیشه:))
#SOP
#websocket

لیست همه هشتگ ها برای دسترسی سریع(لیست آپدیت میشه)
#Cryptography
#Encryption
#jwt
#brute_force
#Encoding
#Hash
#rainbow_table
#SOP
#websocket
#reverse_proxy
#load_balancer
#http_headers
#abusing_hop_by_hop_headers
#bypass_waf
#Javanoscript
#application_security
#interview
#vulnerabilities_root_cause
#CDN
#WAF
#SSRF
#Research
#DOS
#EAR
#parameter_fuzz
#mass_hunting
#writeup
#Authentication
#passive_recon
#XSS
#checklist
#bug_bounty_methodology
#vulnerability_hunting
#SQLi
#CRLF_injection
#resource
#wide_recon
#Methodology
#DNS_Rebinding
#docker
#API_fuzzing
#LFI
#RFI
#Path_traversal
#Directory_traversal
#dependency_confusion
#google_dork
#information_gathering
#Account_Takeover
#Session_Fixation
#Response_Manipulation
#WordPress
#pixel_flood
#Cookie_Bomb
#rate_limit_bypass
#CSRF
#Django
#ICS
#SCADA
#shodan

مفهوم و استفاده Reverse Proxy چیه =


واسه فهمیدن چیستی reverse proxy اول باید بدونیم خود proxy چیه. Proxy بین کاربر و اینترنت قرار میگیره، درخواست کاربر اول میره واسه Proxy و بعد میره سمت اینترنت و اگه با نرم افزار Burp Suite کار کرده باشین طبق صحبت های من متوجه میشین که این نرم افزار به عنوان یه Proxy استفاده میشه.
و اما Reverse Proxy: کاربر درخواست رو میفرسته واسه سایت example.com و درخواست مستقیم نمیره واسه سرور مقصد، بلکه example.com یه سرور اضافی قبل از خودش قرار داده که درخواست از اون عبور میکنه و بعد به سرور اصلی میرسه. اینجا Reverse Proxy تصمیم میگیره که درخواست رو بفرسته واسه سرور اصلی یا ن. استفاده های مختلفی ممکنه تو دنیای واقعی داشته باشه برای مثال به عنوان یه لایه امنیتی یا همون WAF استفاده بشه واسه محافظت از صفحات حساس مثل /admin و یا به عنوان یه Load Balancer کار کنه.
واسه یادگیری بهتر استفاده از Reverse Proxy به عنوان لایه امنیتی میتونیم این سناریو رو در نظر بگیریم :
تو حالت نرمال، درخواست کاربر میره واسه reverse proxy و reverse proxy درخواست رو هدایت میکنه به سرور اصلی. ولی reverse proxy بعضی از صفحات حساس رو مثل /admin میاد محافظت میکنه ازش و اگه کاربر /admin رو درخواست کنه، reverse proxy درخواست رو واسه سرور اصلی نمیفرسته که page بالا بیاد. و این پیاده سازی ممکنه ناامن باشه و هکر بتونه bypass کنه با روش های مختلف که در آینده بهشون اشاره میکنیم و صفحه ی /admin رو باز کنه.
استفاده از reverse proxy به عنوان یک load balancer :
فرض کنین سایت ما یه سایت خیلی پر بازدیده و اگه یه سرور داشته باشه ممکنه نتونه به همه پاسخ بده، اینجا میایم یه reverse proxy بالا میاریم که درخواست های کاربران رو بین چندین سرور مختلف پخش میکنه و همه درخواست ها سمت یه سرور نمیره که باعث down شدن سرور بشه. تو این سناریو به reverse proxy میگیم load balancer. این تا حدودی میتونه احتمال موفقیت حملات dos رو پایین بیاره.

نکته مهم : وقتی از load balancer استفاده میشه، ممکنه باعث به وجود اومدن مشکلات نا هماهنگی سرور ها بشیم. مثلا فرض کنین اولین درخواست کاربر که واسه login هستش میره به سرور 1 و دومین درخواست کاربر که واسه مشاهده اطلاعات شخصی خودش هست بره به سرور 2 و سرور 2 این کاربر رو نشناسه و بگه login نیستی. این ممکنه تو فرایند تست نفوذ هم پیش بیاد که یه فایل shell با موفقیت آپلود کنیم و وقتی فایل رو خواستیم باز کنیم بهمون بگه که این فایل وجود نداره چونکه درخواست ما واسه یه سرور دیگه ارسال شده و فایل تو اون سرور وجود نداره و باعث میشه فکر کنیم که آسیب پذیری وجود نداره:)
#reverse_proxy
#load_balancer

انوع header های پروتکل HTTP =

در پروتکل HTTP هدر ها به 2 دسته زیر تقسیم میشوند :
End-to-End
Hop-by-Hop
هدر های End-to-End هدر هایی هستند که وقتی کاربر درخواست رو میفرسته تا سرور اصلی یا به اصطلاح به Origin Server میرسن و وسط راه توسط Reverse Proxy ها تغییر پیدا نمیکنن.
هدر های Hop-by-Hop هدر هایی هستند که فقط به Hop اول ارسال میشه و Hop اول این هدر هارو واسه Hop های بعدی نمیفرسته. برای مثال اگه بین کاربر و سرور اصلی یه Reverse Proxy وجود داشته باشه و ما یه Hop-by-Hop هدر داخل پکت HTTP خودمون بفرستیم، Reverse Proxy اون هدر رو واسه سرور اصلی نمیفرسته.
تعدادی از هدر های استاندارد Hop-by-Hop :
Keep-Alive
Transfer-Encoding
Connection
Upgrade
…..
حالا اگه بتونیم یه End-to-End هدر رو به عنوان Hop-by-Hop هدر واسه Reverse Proxy بفرستیم و اون هم طبق درخواست ما عمل کنه ممکنه آسیب پذیری های مختلفی به وجود بیاد که در آینده بهشون اشاره میکنیم.

نکته: هدر های Hop-by-Hop و آسیب پذیری های مربوط بهش مختص پروتکل HTTP/1.1 هست و تو ورژن های جدیدتر HTTP این مورد رو نداریم.
#http_headers

Abusing Hop by Hop headers =

تو قسمت قبل گفتیم که اگه بتونیم یه هدر End to End رو به عنوان هدر Hop by Hop بفرستیم واسه Reverse Proxy و اونم باهاش مثل یه هدر Hop by Hop رفتار کنه، یعنی هدر رو به Hop بعدی نفرسته ممکنه آسیب پذیری به وجود بیاد. ولی چطور؟

Connection: close, custom_header

باید اسم هدر رو تو value هدر connection بزاریم تا Reverse Proxy رو مجبور کنیم که این هدر رو پاک کنه از درخواست و نفرسته واسه Hop بعدی(ممکنه هم به صورت امن پیاده سازی شده باشه و آسیب پذیر نباشه).
کارایی که میشه باهاش انجام داد :
1. Bypass IP base restriction
2. Stack trace
3. Request smuggling
4. Web Cache Poisoning

که الان دو مورد اول رو با هم یاد میگیریم.
واسه یادگیری Bypass IP base restriction اول باید بدونیم که چطور آیپی کاربر به web application میرسه. تو حالت نرمال که هیچ CDN و Reverse Proxy ای بین کاربر و Origin Server نیست، backend میاد و از TCP Connectionی که دریافت کرده IP کاربر رو به دست میاره. ولی وقتی Reverse Proxy یا CDN این وسط وجود داشته باشه، اگه Origin Server بخواد با متود قبلی IP رو به دست بیاره، IP کاربر به دستش نمیرسه چون کاربر TCP connection زده به Reverse Proxy یا CDN و اونم TCP connection زده به Origin Server. حالا Reverse Proxy وظیفه داره از طریق TCP connectionی که دریافت کرده آیپی کاربر رو به دست بیاره و از طریق یک HTTP Header واسه Origin Server بفرسته که معمولا به این نام هست :

X-Forwarded-For: 192.168.1.1

ولی ممکنه اسمش چیز دیگه ای باشه که ما باید اسم X-Headers های شناخته شده رو بلد باشیم مثل :

X-Real-IP: 127.0.0.1
...

حالا میدونیم دلیل اینکه موقع مواجه شدن با WAF ها میان از این هدرها با مقدار 127.0.0.1 استفاده میکنن چیه، که میخوان به WAF بگن این درخواست از سمت خود سرور هست و از سمت بیرون نیست که جلوی درخواست رو نگیره.


شناخت اولیه آسیب پذیری :
اینجا سعی میکنیم آسیب پذیری رو شناسایی کنیم در ابتدا و اگه آسیب پذیر بود، میتونیم با توجه به سناریو و عملکرد تارگت از یکی از 4 روش بالا برای سوءاستفاده استفاده کنیم. معمولا یکی از Header هایی که هر سامانه داره Cookie یا Auhorization هست واسه فرانید Authentication/Authorization که اگه این هدر ها وجود نداشته باشن، کاربر نباید login باشه. بخاطر همین سعی میکینم این هدر هارو به عنوان Hop by Hop بفرستیم و اگه رفتار سامانه تغییر کرد که نشون میداد این هدر ارسال نشده واسه Origin Server یعنی آسیب پذیری وجود داره.

Conncetion: close, Cookie

1. Bypass IP base restriction :
فرض کنین که میخواین به /admin سامانه ای درخواست بزنین و بهتون میگه که شما مجوز لازم واسه دیدن این صفحه رو ندارید که ممکنه با IP این چک رو انجام بده و ادمین همیشه از یک VPNی استفاده کنه که IP ثابت داره و فقط اون IP اجازه دیدن این صفحه رو داره که IP کاربر رو Reverse Proxy واسه Origin Server میفرسته و اونجا فرایند check IP صورت میگیره. حالا اگه این هدر ارسال نشه، ممکنه Origin Server فکر کنه این درخواست داخلیه و اجازه بده که page لود بشه و ممکن هم هست که کار نکنه و بگه IP حتما باید ارسال بشه.

Conncetion: close, Fuzz

چرا Fuzz میکنیم؟ چون نمیدونیم که کدوم Header داره IP مارو واسه Origin Server میفرسته. به عنوان wordlist هم باید اسم هدر های X-Headers رو بهش بدیم.

2. Stack trace :
همین سناریو بالا رو نظر بگیرین، اگه Origin Server منتظر هدر خاصی باشه و اگه اون هدر ارسال نشه با خطا مواجه بشه و این خطا برگرده سمت کاربر و ممکنه یک سری اطلاعات افشا بشه. واسه تست این مورد باید همه هدر هارو بعلاوه X-Headers ها Fuzz کنیم.

Connection: close, Fuzz_all_headers

#abusing_hop_by_hop_headers
#bypass_waf

تفاوت هدر های 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