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

مفهوم 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