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

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