https://virgool.io/feed/@mohsen.mehrabanpour fa 2026-06-17 05:08:50 https://files.virgool.io/upload/users/2667205/avatar/3py7ng.jpg?height=120&width=120 https://virgool.io/@mohsen.mehrabanpour https://virgool.io/@mohsen.mehrabanpour/%D9%85%D9%88%D8%AA%D9%88%D8%B1-%D9%85%D8%B1%D9%88%D8%B1%DA%AF%D8%B1-%D9%87%D8%A7-browser-engines-gecko-blink-wdxjuayrxjsb browser enginesتوی این پست دنبال پشت پرده ی مرورگرها هستیم! خیلیامون میدونیم مرورگر ها کد های HTML , CSS و JS رو اجرا میکنن و خیلیامون دنبال درک عمیقی از پشت پرده ی نحوه ی این اقدامات هستیم ، این نشون میده که الان جای درستی هستیم - حالا میخوایم بریم سراغ اینکه مرورگر ها چجوری کار میکنن و چه لایه هایی دارن! میخوایم ببینیم browser engine هایی مثل Gecko , Blink , Webkit چی هستند ؟ چی کار میکنن ؟ چه فرقی با javaScript engine هایی مثل spiderMonkey , V8 و ... دارنموتورهای مرورگرها (browser engines) چی هستند و چیکار می کنند؟معمولا در مواجه با این سوال رایج ترین کج فهمی ای که وجود داره این هست که ذهن به سمت js engine های مرورگر ها که وظیفه interpret (تفسیر) کدهای جاوااسکریپتی رو دارن میره ! و همین اول بگم ما صرفا راجع به اون ها نمیخوایم صحبت بکنیم . در واقع وظیفه browser engine ها (موتور های مرورگرها) render کردن صفحات وب هست . و خب browser engine ها از بخش های مختلف کنار هم تشکیل میشن که به این وظیفه بپردازن . در ادامه به بررسی این بخش ها به صورت مختصر که حوصله سر بر نباشه میپردازیم :) 1 - Parsing HTML and CSS : توی این بخش browser engine به تفسیر فایل های HTML و CSS میپردازه که خروجی اون یک آبجکت مختص به اون ها هست . بخوایم دقیق تر اشاره کنیم خروجی تفسیر HTML میشه یک Document Object Model (DOM) و خروجی تفسیر CSS میشه یک CSS Object Model (CSSOM) که ساختار درختی دارن - این ساختار درختی یک data model درونی خود browser هست که توی بخش های بعدی باهاش کار میکنه. بعد از اینکه DOM و CSSOM ساخته شدن ، سه فاز زیر اتفاق میوفتن : layoutتوی این فاز DOM و CSSOM ساخته شدن و تمام ! حالا browser engine به محاسبات لازم برای ایجاد ساختار صفحه میپردازه - مثلا اینکه هر element چقدر سایز داره و در چه جایگاهی از صفحه قرار میگیره . paintingاین فاز در ادامه فاز قبل میاد - تا اینجا browser engine جایگاه المان ها و سایزشون رو پیدا کرده و حالا میره تا پیکسل های مورد نظر رو در جایگاه درست قرار بده . (ایده اسم painting برای اینه که عملا داره عکس ها و رنگ ها و نوشته هارو پیکسل به پیکسل نقاشی میکنه)compositingتوی این فاز browser engine بررسی میکنه که اگر المان هامون یکجاهایی باهم overlap داشته باشن ، در نهایت لایه ها چجوری روی هم باید قرار بگیرن و چه خروجی ای به کاربر نشون داده بشه - پس وظیفه ی این فاز این هست که در صورت وجود overlap بین المان ها بیاد یک تصویر درست از اولویت قرار گرفتن لایه بندی به کاربر نشون بده2 - Executing JavaScriptبه طور کلی هر مرورگر علاوه بر browser engine یک js engine هم داره - مثلا توی مرورگر فایرفاکس Gecko browser engine رو در کنار spiderMonkey js engine داریم ! یا توی کروم Blink browser engine رو در کنار V8 js engine داریم .به یاد میاریم که js engine ها وظیفشون تفسیر کد های جاوااسکریپتی و تبدیل اون ها به کد های قابل فهم برای ماشین و اجرای اون ها هست، برای رسیدن به این هدف js engine ها هم از چند جزء تشکیل شدن که در ادامه به اختصار بهشون میپردازیم :Parserتوی این مرحله js engine کد های جاوا اسکریپتی مون رو به یک ساختار به نام abstract syntax tree (به اختصار AST) تبدیل میکنه .خیلی خلاصه بخوایم به چیستی AST بپردازیم - یک درخت از ساختار کد هامون ایجاد میکنه ، شکلش رو پایین آوردم و دیدنش یک ایده خیلی خوب راجع به چیستیش بهتون میدهof fabstract syntax treeInterpreterتوی این مرحله js engine کد هارو به صورت مستقیم از AST اجرا میکنهJust-In-Time (JIT) Compilerخب در واقع این یک تکنیک هست که توی زبان های برنامه نویسی دیگه هم استفاده میشه - اما به طور خلاصه میتونیم بگیم با تبدیل کردن کد های جاوااسکریپتی به کد ماشین یک بهینه سازی انجام میده که اجرا رو سریع تر میکنه .Garbage Collectorاونایی که با زبون C کد زدن قطعا یادشونه که برای گرفتن حافظه و آزادسازی حافظه باید توابع مختص خودشون رو صدا میزدیم. توی زبان های سطح بالا - حذف کردن حافظه هایی که دیگه استفاده نمیشن توسط این بخش مدیریت میشن.حالا js engine چجوری با browser engine کنار هم کار میکنن ؟ وقتی که browser engine به یک تگ `script` برسه ، کد های اون رو به جاوااسکریپت میده تا اجراشون کنه .از طرفی js engine میتونه با browser engine در تعامل باشه برای کارهایی مثل ایجاد تغییر در DOM . در این حالت js engine میاد browser engine رو وارد فاز repainting میکنه تا مجددا المان هارو در صفحه قرار بده.3 - Handling User Interactionsبه طور کلی پردازش تعاملات کاربر با صفحات وب هم بر عهده browser engine ها هستش!تعاملاتی هم که ازش صحبت میکنیم چیز هایی مثل کلیک کردن، اسکرول کردن، فشردن یک دکمه روی کیبورد و ... هستش.در صورتی که هرکدوم از این ایونت ها موجب تغییر در DOM یا CSSOM بشه (مثل مثالی که در بخش قبل زدیم) browser engine وظیفه repaint رو داره.4 - Networkingاز دیگر وظایف browser engine ها مدیریت کانکشن های شبکه ای هستش . دانلود کردن فایل ها (مثل فایل های عکس , JS , CSS , HTML و ...) بر عهده ی این بخش از موتور مرورگر هست. توی این لایه مکانیزم های کش کردن داده ها به صورت لوکالی برای افزایش سرعت هم تعبیه شده5 - Sandboxing and isolationیکی از کارهایی که مرورگر ها برای ایجاد امنیت انجام میدن ، ایجاد فضای ایزوله به ازای هر صفحه وب هست . مرورگرها با اختصاص دادن یک process به هر صفحه وب (هر تب) باعث میشن که به فکر این نیوفتیم که یک بد افزار بنویسیم که بخواد روی یک صفحه ی دیگه تاثیر منفی بزاره ! 6 - Content Security Policiesاز دیگر کارهایی که یک browser engine انجام میده اعمال policy های امنیتی هستش . به عنوان مثال CSP که ازش اسم آوردیم میتونه مشخص کنه هر ریسورس از چه دامنه هایی اجازه دانلود رو داره ؟ مثلا میگیم فونت هارو فقط از same origin لود کن و یا تصاویر رو فقط از دامین خودمون لود کن . این جلوی حملاتی مثل XSS رو میگیره .به پایان آمد این دفتر حکایت همچنان باقی :)) توی این نوشته هدفم این بود که به عنوان یک web developer یک نگاه متفاوت تر از اتفاقاتی که توی مرورگر میوفته داشته باشیم - قطعا جزییات خیلی خیلی بیشتر داره و اینجا خیلی ساده به موضوع و سیکل اتفاقات نگاه شده که اگر علاقمندین که بیشتر راجع بهش بدونین بهتون خوندن داکیومنت های مرورگرهارو پیشنهاد میکنم (البته که اگر web developer این احتمالا در همین حد آشنایی تا 98% کارمون رو راه بندازه:) شاد و خندون باشین ❤ محسن مهربان‌پور محسن مهربان‌پور Sat, 10 Aug 2024 22:12:30 +0330 https://virgool.io/@mohsen.mehrabanpour/syn-flooding-attack-gumlznbyqzkt فرض کنیم توی یک مغازه یک عالمه مشتری میفرستیم که فقط قیمت میپرسن و هیچکدومم خرید نمیکنن ! خریدار واقعی هم دم در کلافه میشه و اصلا جا نمیشه بره تو ! این میشه مصداق SYN flooding attackتوی این پست میخوام آنچه در مورد SYN flooding attack یاد گرفتم با شما به اشتراک بزارم ، پس اگر توهم برات جالبه که این آسیب پذیری protocol لایه transport رو بشناسی خوشحال میشم با من همراه باشی .این آسیب پذیری واقع در پرتکل TCP واقع در لایه انتقال (transport layer) هست ، خوبه که برای شفاف تر شدن ماجرا اول یکم راجع به خود TCP صحبت کنیم تا برامون یادآوری بشه چیکار میکنه.پرتکل TCP چی هست و چیکار میکنه ؟به طور کلی پرتکل TCP همونطور که از لایه اش هم معلومه ، یک واسط بین application و لایه شبکه هست که میتونه بین process های فعال در دو سیستم مختلف داده جا به جا کنه (اصطلاحا بهش میگن Process-to-Process Communication)این انتقال داده هم اینجوریه که به هر process یک port اختصاص داده میشه و این پرتکل میتونه با استفاده از همین port number داده رو به application ما برسونه.این پرتکل داده رو از لایه application میگیره و در بسته هایی به نام segment ذخیره میکنه . هر segment خودش از دو بخش تشکیل میشه :Data:شامل داده هایی میشن که میخوایم ارسال کنیمHeader: بخش header شامل داده های مختلفی میشه ، مثل source port number, destination port number , header length, … که ما چون موضوعمون تشریح پرتکل TCP نیست از بررسی اجزا هم فعلا صرف نظر میکنیم . اما یک تعداد flag توی header هستن که به دوتا موردش باید اشاره کنیم .SYN (Synchronize sequence numbers):این flag خیلی جزئیات داره اما بخوام خلاصه شرحش بدم که در ادامه درک مفهوم رو برای ما راحت کنه ، توی TCP وقتی داده رو میخوایم ارسال کنیم ، بایت های داده ای که در segment ها قرار میدیم شماره گذاری میشن تا به ترتیب سمت گیرنده دریافت بشن . از این flag برای اینکه مشخص کنیم ما از چه شماره ای شروع کردیم به شماره گذاری تا گیرنده بدونه شماره های ما (اصطلاحا بهش میگن sequence number) از چند شروع شده استفاده میکنیمACK (Acknowledgment):کاربردش تایید دادنه – گفتیم ما بایت ها رو شماره گذاری میکنیم و ارسال میکنیم ، گیرنده به ازای بایت های دریافتی شمارشون رو به فرستنده میفرسته تا اطمینان بده این بایت ها دریافت شدن.کل این بسته میره توی دل بسته های لایه های پایین تر مثل IP که وظیفه مسیریابی در شبکه رو داره.اما اصل داستان از جایی شروع میشه که ...پرتکل TCP اصلا چطوری ارتباط برقرار میکنه ؟توی پرتکل TCP برقراری ارتباط در سه گام اتفاق میوفته که بهش اصطلاحا میگن (Three-Way Handshaking)تصور کنیم یک کلاینت میخواد با استفاده از پرتکل TCP به یک سرور وصل بشه .اول از همه سرور به TCP خودش میگه آماده دریافت connection باش – به این فاز میگن passive open و سرور آماده ی دریافت درخواست از سرتاسر جهان میشه .بعد نوبت میرسه به کلاینت که به امید برقراری ارتباط با یک سرور به اون سرور یک درخواست ارسال میکنه ، که به این مورد میگن active open و از این جا به بعد اون سه گام اتصال به وقوع می پیونده . گام 1️⃣ : کلاینت یک SYN segment رو به سمت سرور میفرسته ، توی این بسته فقط SYN flag ست شده و داره‌ میگه شماره گذاری های من از چه عددی شروع میشه گام 2️⃣ : سرور در پاسخ به این بسته ارسالی از کلاینت یک segment حاوی flag های SYN و ACK رو میفرسته به کلاینت که دوتا هدف رو دنبال میکنه ، با SYN داره میگه شماره گذاری هاش از چه عددی شروع میشه و با ACK میگه من بسته ارسال شده توسط تورو دریافت کردم گام 3️⃣ : کلاینت در جواب به این بسته سرور یک ACK segment میفرسته به سرور بگه آقا من بسته ارسالی توسط تورو دریافت کردمبعد از طی شدن این سه گام یک connection بین کلاینت و سرور باز میشه و میتونن دیتا رد و بدل کنن .پس SYN flooding attack چیشد ؟برای اینکه بتونیم بهتر مفهوم این حمله رو درک کنیم لازم بود یک یادآوری ای از چیستی و چگونگی TCP داشته باشیم .این حلمه در دسته حملات Denial of service که به اختصار DoS معروف هست قرار میگیره و توی این روش attacker از اون سه گامی که توضیح دادیم سوع استفاده میکنه .برای رخ دادن این حمله : با توجه به گام 1️⃣ ، مهاجم به جای یک SYN segment تعداد خییییلیی زیادی SYN segment به سمت سرور ارسال میکنه .با توجه به گام 2️⃣ سرور برای پاسخ دادن به درخواست های گام 1️⃣ اقدام میکنه ، پاسخ رو به سمت کلاینت ما میفرسته (که اینجا کلاینت ما همون attacker هست) و بر اساس گام 3️⃣ منتظر میمونه کلاینت ACK segment رو به سمتش ارسال کنه و برای این امر یک پورت رو باز نگه میداره .امااااا! اما اینجا کلاینت ما گام 3️⃣ رو بر نمیداره و سرور رو منتظر میزاره و به جاش دوباره گام یک رو تکرار میکنه ! دوباره کلاینت به سرور درخواست میده – سرور درخواستش رو پاسخ میده و یک پورت باز برای پاسخش در نظر میگیره و میوفته توی این چرخه – و این چرخه انقدررررر اتفاق میوفته که تمام پورت های سرور درگیر بشن و دیگه نتونه عملکردی که باید رو داشته باشه .انواع مختلف SYN flooding attackاصل داستان SYN flooding attack همون بود که در بخش قبل توضیحش دادیم ، به طور کلی این حمله رو به سه روش مختلف انجام میدن .Direct attackتوی این مدل مهاجم با IP خودش میاد همین گام هایی که گفتیم رو طی میکنه ، روی یک ماشین درخواست های گام یک رو ارسال میکنه به سرور و از پاسخ دادن بهشون پرهیز میکنهSpoofed Attackهمونطور که در توضیحات بالاتر گفتیم بسته های TCP در بسته های لایه های پایین تر قرار میگیرن ، یکی از این بسته ها IP هست که وظیفه ی مسیریابی در شبکه رو داره و توی گام دوم سرور با توجه به IP کلاینت پاسخ رو بهش ارسال میکنه ، توی این مدل از حمله ، مهاجم بسته های ارسالی رو دستکاری میکنه و IP های جعلی ای رو در درخواست قرار میده ، در این صورت سرور گام دومش رو که پاسخ به کلاینت هست ، این پاسخ رو به کلاینت اشتباهی میرسونه که اصلا منتظر این پاسخ نیستDistributed attack (DDoS)این حمله به صورت توزیع شده اتفاق میوفته یعنی مهاجم گام هارو از روی ماشین های مختلف طی میکنهراهکار های ارائه شده برای کاهش حمله SYN flooding attack چیست؟Increasing Backlog queueتوی لایه ی سیستم عامل اومدن گفتن که ما باید تعداد مشخصی کانکشن نیمه نصفه (half-open) داشته باشیم و برای بیشتر از اون به طور داینامیک باید مموری و منابع ای که میخوایم به کانکشن ها اختصاص بدیم رو مدیریت کنیم Recycling the Oldest Half-Open TCP connectionعملکرد این روش اینجوریه که اگر تعداد زیادی کانکشن نیمه نصفه داشتیم که صف ما رو پر کرد و یک درخواست جدید اومد ، اون کانکشن های نیمه نصفه قدیم رو میبندیم و برای درخواست جدید کانکشن باز میکنیم .باگ این روش اینه که اگر صف ما کوچیک باشه و زمان پردازش یک درخواست واقعی بیشتر از زمانی باشه که طول میکشه یک صف پر بشه ، اون درخواست واقعی نیز بسته میشه .SYN cookiesتوی این روش عملکرد بدین گونه هست که سرور برای پاسخ به کلاینت یک کوکی ایجاد میکنه و یک سری داده های لازم رو توش قرار میده ، بعدش کلا کانکشنش رو میبنده و همه چیز مربوط به اون درخواست رو از حافظه پاک میکنه ، اگر کلاینت به سرور پاسخ داد ، سرور با استفاده از همون کوکی ، دوباره کانکشن رو میسازه و در صف قرار میده . با این استراتژی ریسک باگی رو که در روش قبلی گفتیم هم کاهش میدیم . گفته میشه این روش که دوباره کانکشن رو میسازیم ممکنه روی از دست دادن داده های مربوط به کانکشن TCP تاثیر بزاره اما بهتر از این هست که تحت حمله قرار بگیریم و سرویس به طور کلی از دسترس خارج بشهthird party services such as cloudflareمعمولا استفاده از این سرویس ها بدین گونه هست که به صورت واسط بین کلاینت و سرور قرار میگیرن ، توی برقراری اتصال TCP کلاینت سه گام رو باید با سرویس خارجی طی کنه و وقتی سه گام با موفقیت طی شد ، سرویس کلاینت رو به سرور متصل میکنهشما چه روش های دیگه ای رو برای مقابله با این آسیب پذیری میشناسین ؟ خوشحال میشم نظراتتون رو برام کامنت کنین ❤ محسن مهربان‌پور محسن مهربان‌پور Mon, 20 Nov 2023 22:23:11 +0330 https://virgool.io/@mohsen.mehrabanpour/%D8%A7%D9%85%D9%86%DB%8C%D8%AA-%D9%88%D8%A8-%D8%A8%D8%A7-%D8%A7%D8%B5%D9%88%D9%84-owasp-qt2p3oqvv5lr OWASP top-10همه‌ی ماهایی که در دنیای کامپیوترها (مخصوصا بر پایه وب) مشغول به فعالیت هستیم می‌دونیم که امنیت یکی از ارکان اصلی کارمون هست . اما همه ی ما نمیدونیم که چه رکن (فاکتور/ابزار)هایی می‎تونه برای برقراری امنیت به ما کمک کنه .اینجاست که پای Open Worldwide Application Security Project (اُ-اَسپ / OWASP) میاد وسط !توی تعریفی که OWASP توی سایت خودش راجع به خودش ارائه میده ، میگه که :ما یک جامعه باز و متعهد به امکان سنجی، توسعه، تهیه، عملیات و نگهدای برنامه‌هایی که قابل اعتماد باشند هستیم . تمامی پروژه‌ها، ابزارها، اسناد، انجمن‌ها و بخش‌های ما رایگان و باز برای همه‌ی علاقه‌مندان به بهبود امنیت برنامه‌ها می‌باشد. بنیاد OWASP در تاریخ ۱ دسامبر ۲۰۰۱ راه‌اندازی شد و در تاریخ ۲۱ آوریل ۲۰۰۴ به شکل یک خیریه غیرانتفاعی در ایالات متحده آمریکا ثبت شد.اونا توی سایتشون از چشم اندازشون : نرم افزار ناامن بیشتری نداشته باشیم (no more insecure software)و حتی ماموریتشون : به عنوان یک جامعه باز جهانی، ما نیرویی هستیم که از طریق آموزش، ابزارها و همکاری، نرم‌افزارهای امن را تامین می‌کنیم.هم گفتن . توی OWASP ابزارها و اصول(/سیاست) های مختلفی وجود داره که امنیت رو از جنبه های مختلف مورد بررسی قرار میده و نکات توسعه امن رو به ما ارائه میده . بخوام مثال بزنم ، مثلا ابزاری به نام OWASP AMASS رو دارن که ابزار نقشه برداری از شبکه هست و کمک به شناخت آسیب پذیری ها می کنه یا ابزاری به اسم OWASP ZAP وجود داره (که در دسته ی penetration testing toolkits قرار میگیره) و با کمک اون می تونیم امنیت وبسایت خودمون رو محک بزنیم . من قصد دارم در ادامه یک نگاهی به اولین مورد از بخشی به نام OWASP top 10 بندازم و آنچه رو که یاد میگیرم با شما به اشتراک بزارم . پس اگر توهم دوست داری یک نگاهی بندازی ببینی اولین اصل OWASP top 10 چیه ، همراه من باش . A01: Broken Access Control (کنترل دسترسی شکسته)برای اینکه ببینیم کنترل دسترسی شکسته چیه ، اول باید ببینیم مفهوم کنترل دسترسی چیه ؟ کنترل دسترسی (access control) سیاستی رو پیاده سازی می کنه که کاربران نباید خارج از مجوز های اون سیاست بتونن عملیاتی رو انجام بدن .اگر این کنترل دسترسی شکسته بشه (broken access control) می تونه منجر به افشای اطلاعات حساس ، دستکاری و یا از بین رفتن تمام دیتاهای تجاری بشه .کنترل دسترسی انواع مختلفی داره (مثل discretionary access control ، mandatory access control و ...) که هرکدومش هم دنیای خودش رو داره که اگر بخوایم بهشون بپردازیم خارج از حوصله شما و توان تایپی من هست ? پس فعلا به آنچه در توصیف نوشته های سایت OWASP هست می پردازیم. آسیب پذیری هایی که در مورد کنترل دسترسی رایج هستند شامل موارد زیر میشن :Principle of least privilege : داستان از این قراره که اگه ما یک آبدارچی رو استخدام می کنیم ، فقط کافیه که بهش کلید آبدارخونه رو بدیم و این کار غیرمنطقی ای هست که بهش کلید گاوصندوق رو هم بدیم که نکنه بعدا لازمش بشه ! توی دنیای امنیت هم داستان از همین قراره ، سطح دسترسی ای که به هر کاربر می دیم باید حداقل سطح دسترسی ای باشه که با اون سطح می تونه وظایفش رو انجام بده . مثلا اگر وظیفه ی شخص اینه که داده ای رو بزاره ، کار غیر منطقی ای هست بهش اجازه ویرایش داده های افراد دیگه رو هم بدیم. دسترسی ها باید به نقش ها و قابلیت ها (capabilities) به صورت حداقلی داده بشن .Bypassing access control :این مورد حالتی رو شرح میده که مهاجم می تونه یک جوری اون چک کردن access control ما رو دور بزنه . مثلا همون طور که گفتیم ما میایم یک role (نقش) در نظر می گیریم تحت عنوان admin که بالاترین سطح دسترسی هارو هم داره ، حالا اگر ما اون نقش (role) کاربر رو از طریق url بگیریم و با توجه به اون بهش دسترسی بدیم ، مهاجم به راحتی با دستکاری url می تونه اون access control ما رو دور بزنه .Insecure direct object references :تعریفش می شه اینکه یک مهاجم می تونه با ارائه یک شناسه منحصر به فرد یک شی دیگه به اون دسترسی داشته باشه . بخوایم براش مثال بزنیم ، فرض کنین شما یک api ای رو توسعه دادین که یک آیدی بهش پاس می دین و اون api داده های مربوط به کاربر با اون ID رو برای شما بر می گردونه . حالا اگر من بتونم به ID یک کاربر دیگه دسترسی پیدا کنم چی ؟ باید داده های اون کاربر رو هم بهم برگردونه؟ قطعا نه! پس این اصل داره به این اشاره می کنه که آقا نباید اجازه بدیم به یک آبجکت ما بدون کنترل دسترسی ، دسترسی مستقیم پیدا کنند.Missing access controls for POST, PUT and DELETE :هممون میدونیم که http verb های مختلف وظایف مختلفی رو دارن ، و هممون میدونیم که از POST برای درج داده (create) ، از PUT برای به روز رسانی داده (update) و از DELETE برای حذف داده استفاده می کنیم . پس اینجا access control حائز اهمیت می شه که یک سیاست بچنیم چه کسانی (user/roles/capabilities) باید توانایی اجرای این verb ها رو داشته باشند .Elevation of privilege :این آسیب پذیری حالتی رو شرح میده که به عنوان مثال ما بدون ورود به سایت (login) بتونیم قابلیت هایی که یک کاربر لاگین شده در سایت داره رو داشته باشیم و یا با لاگین شدن به سایت به عنوان کاربر ساده توانایی های یک ادمین سایت رو داشته باشیم، در واقع به صورت غیرمجاز سطح دسترسی خودمون رو بالا ببریم .Metadata manipulation : دستکاری meta data یکی از آسیب پذیری های رایج دنیای وب هستش و وقتی اتفاق میوفته که یک مهاجم به دستکاری داده های مهم مثل cookie ها ، headerها و query string ها ، یا محتوای توکن (JWT) به هدف دسترسی غیرمجاز (unauthorized access) می پردازه .اگر بخوایم برای meta data manipulation مثالی بزنیم ، به نوعی می تونیم به حمله ی replay اشاره کنیم . این حمله بدین صورت هستش که یک مهاجم session مربوط به یک کاربر احراز هویت شده (/یا توکنش) رو کپی می کنه و با استفاده از اون عملیات غیرمجازی رو انجام میده .CORS misconfiguration :اگر شماهم در حوزه ی کلاینت فعالیت داشتین ، پس احتمالا جفتمون یک درد مشترک که خطاهای مربوط به CORS باشن رو تجربه کردیم و دادمون در اومده ?. ولی خب این سیاست ها (CORS policy) اگر درست پیکربندی بشه می تونه توی امنیت داشتنمون به ما کمک کنه . در واقع cross-origin resource sharing policies یک مجموعه سیاست هستند که تعریف میشن تا به وب سرور ها این اجازه رو بدن که دسترسی کدوم ـJS ها (/درخواست ها) در کدوم صفحات وبسایت به منابع مجاز/یاغیرمجاز هست. وقتی این CORS policy ها به درستی پیکربندی نشن ، این اجازه رو میدن که origin ها (web page) های غیر مجاز به یک api دسترسی پیدا کنند.Force browsing to authenticated pages :یک حالتی هست که مهاجم به صفحاتی دسترسی اجباری می گیره که مجوز مربوطش رو نداشته . مثلا اگر شما بتونین توی یک سایت مربوط به بانک یا کیف پول ، به هر نحوی balance مربوط به شخص دیگه ای رو ببینین مثالی بر این موضوع هستش.و اما راه های مقابله چی هستن؟نکته ای که باید به اون توجه بشه اینه که کنترل دسترسی ها باید در جایی اتفاق بیوفته که مهاجم توانایی تغییر(modify) بررسی هارو رو نداشته باشه ، در مورد راه های امن سازی کنترل دسترسی موارد دیگه ای هم به چشمم خورده اما در حال حاظر در مورد مواردی که در سایت OWASP برای مقابله با آسیب پذیری broken access control ارائه داده صحبت می کنیم .به جز منابع (resource) هایی که به صورت عمومی هستند ، دسترسی به تمام منابع رو غیرمجاز کنین . بخوایم مثال بزنیم اگر من دارم api می نویسم ، میدونم api هایی که داره صفحه اولم رو میسازه باید public باشه ، که با توجه به ماهیت سایتم اگر کسی صفحه اول سایت رو باز کرد بتونه محتوای مورد نظر من رو ببینه ، اما دلیلی نداره api هایی که داده های یک کاربر خاص رو با استفاده از ID داره برمیگردونه public باشه .یک بار سیاست های مربوط به کنترل دسترسی رو پیاده سازی کنین و در تمام برنامه از اون ها استفاده کنین. خب در توضیح این مورد می تونیم بگیم که کنترل دسترسی سناریوها و حالت های مختلفی داره ، بخوام یک مثال بزنم ، مثلا یک نوع از کنترل دسترسی داریم تحت عنوان RBAC یا (role based access control) ، این سیاست میگه توی طراحی سیستمت اول نقش های مورد نظرت (roles) ها رو پیدا کن ، بعد ببین هر نقش با توجه به شرح وظایفش چه دسترسی هایی نیاز داره ، دسترسی ها رو به نقش ها اعطا کن و نقش هارو به کاربران منسوب کن. نکته ای که بهش اشاره میشه اینه که حتی کوچکترین سیاست هارو هم در نظر بگیرین ، مثل همون CORS policy ها که ازش صحبت کردیم .نکته ی بعدی ای که بهش اشاره شده در مورد طراحی مدل کنترل دسترسیمون هست . میگه آقا توی طراحی مدل کنترل دسترسی حواسمون به این باشه که هر موجودیت بتونه رکورد های تحت مالکیت (ownership) خودش رو ایجاد یا بروزرسانی کنه . و دادن قابلیت CRUD (create, read, update, delete) روی تمامی رکورد ها احتمالا یک ضعف امنیتی محسوب می شه . بخوام براش مثال بزنم ، اگر شما یک نقش حسابدار دارین ، احتمالا طبق سیاست های شرکتتون فقط همون نقش باید اجازه درج داده در جدول مربوط به فاکتور ها رو داشته باشه . محدودیت های بیزینسی رو در domain model در نظر بگیریم . خب همونطور که می دونین، توی طراحی یک نرم افزار ما یک بخشی به نام domain model داریم که توی این بخش ما حالات (state) و منطق (logic) های مربوط به بیزینس رو تحت عنوان رفتارها و قوانین به نرم افزار انتقال میدیم . در این بند هدف بر این بوده که محدودیت های بیزینسی رو در سطح نرم افزار هم ببینیم . مثلا اگر توی سطح بیزینس (جایی که کارفرما یک درخواستی داره) عنوان میشه که افرادی که کمتر از 2 سال سابقه بیمه دارند نمی تونن به فلان منابع دسترسی داشته باشن ، شما باید این محدودیت رو در لایه ی نرم افزارتون در نظر داشته باشین و اعمال کنین if کمتر از دوسال سابقه then نتونه منابع رو ببینه ? .مورد بعدی Disable web server directory listing هستش ، در واقع directory listing به یک قابلیت web server ها اشاره می کنه که این اجازه رو به ما میده که بین فایل ها و پوشه ها گشت و گذار کنیم :)) به این صورت که شما وقتی آدرس یک پوشه که در مسیر root directory هست رو میزنین ، مثل تصویر زیر میتونین به فایل ها دسترسی پیدا کنین علاوه بر اون میگه به طور کلی فایل های مهم و فایل هایی که شامل متادیتا میشن ، مثل فایل های مربوط به git یا فایل هایی مثل package.json درجاوااسکریپت که نشون میده از چه package هایی استفاده کردیم ، مثل composer.json که مشابه package.json هست اما برای php، مثل فایل های مربوط به لاگ ها ، مثل بک آپ هایی که گرفتیم و ... نباید در webserver root directory قرار بگیرن و از طریق web server در دسترس باشند. لاگ گرفتن از تمام درخواست های کنترل دسترسی ناموفق ! هدف از این بند این هست که بتونیم الگوهای تشخص نفوذ رو بدست بیاریم ، مثلا اگر در یک بازه زمانی برای لاگین کردن کلی درخواست داشتیم که همش ناموفق بوده می تونیم یک حمله ی brute force روی یک اکانت رو تشخیص بدیم .(این مورد رو گوشه ذهنتون داشته باشین که سیستم هایی مثل IPS هم برای تشخیص الگوهای نفوذ وجود دارند اما چون مورد این بحث OWASP نیست ماهم اینجا بهش نمی پردازیم) استفاده از api rate limiter : به طور کلی api rate limiter یک سیاست محدودیت گذاری روی api هستش ، کارکرد اون هم به این صورت هست که بر اساس سیاست های کاری سامانه مون یک سیاست تعریف می کنیم ، مثلا میگیم هر کاربر بر اساس IP مجازه در دقیقه حداکثر 10 درخواست به فلان API ارسال کنه. اگر بتونیم یک سیاست درست برای rate limiting در نظر بگیریم ، میتونه توی امنیت و کنترل دسترسی به ما کمک کنه ، بخصوص در برابر ابزار های automated attack که ابزار هایی هستند که حالت های مختلفی رو در نظر میگیرن و با درخواست های زیاد سعی دارن حالات زیادی رو ایجاد کنند که از یک آسیب پذیری استفاده کنن ، حالا اگر ما یک سیاست برای rate limiting داشته باشیم که تعداد درخواست های هر api رو محدود کنه ، درصد امکان آسیب پذیری از این طریق رو کاهش دادیم.مورد بعدی در مورد identifier های احراز هویت هستش ، در یک نوع طبقه بندی میتونیم بگیم به طور کلی ما دو نوع احراز هویت داریم :1 - Stateful2 - Statelessدر مورد stateful athentication یک شناسه سمت سرور نگهداری میشه (session) که وقتی ما یکبار ارتباطمون با سرور برقرار میشه ، متناظر اون ارتباط یک session ایجاد میشه که مارو در درخواست های بعدی احراز هویت می کنه ، توی این بند در مورد stateful session ها میگه که آقا وقتی کاربر ما دکمه خروج رو زد حواسمون به اون session سمت سرور هم باشه که باید نامعتبر بشه .در مورد stateless authentication هم میتونیم به توکن های JWT اشاره کنیم که صرفا یک توکن هست که بر خلاف stateful ، متناظر اون توی سرور هیچ چیزی ذخیره نمی شه ! و اعتبار سنجی اون بر اساس مکانسیم های رمزنگاری و امضای دیجیتال هستش . توی این بند برای stateless token ها توصیه می کنه که short lived باشن ، حالا short lived یعنی چی ؟ هر توکن که تولید میشه یک TTL (time to live) داره که مشخص میکنه اون توکن برای چه مدت معتبر هستش ، قاعدتا هرچی زمان اعتبار یک توکن کمتر باشه ، امنیت هم بالاتر میره . اما خب توی این بند اشاره میکنه برای توکن هایی که نیاز داریم طول اعتبارشون بیشتر باشه از استاندارد های OAuth برای ابطال دسترسی ها استفاده کنین .این ها مواردی بود که در سایت OWASP برای مقابله با آسیب پذیری broken access control ذکر شده بود که تشریحشون کردیم ، در نهایت این وظیفه ی QA و توسعه دهنده ها هستش که موارد مربوط به کنترل دسترسی رو تست کنن.چند سناریو از این آسیب پذیری و نحوه ی حمله به اون : سناریو اول : در نظر بگیرین که یک برنامه ، از داده های اعتبار سنجی نشده برای ایجاد یک SQL جهت دسترسی به اطلاعات یک حساب کاربری استفاده می کنه :pstmt.setString(1, request.getParameter(&quotacct&quot)); ResultSet results = pstmt.executeQuery( );اتفاقی که توی قطعه کد بالا میوفته اینه که برای گرفتن اطلاعات یک حساب کاربری ، شناسه مربوط به حساب کاربری رو مستقیم از url و پارامتر acct دریافت می کنه ، حالا مهاجم میاد و درخواست زیر رو ارسال می کنه . https://example.com/app/accountInfo?acct=notmyacctو اینجوری به اطلاعات کاربری حسابی که مال خودش نیست دسترسی پیدا می کنه . سناریو دوم : در نظر بگیرین یک api توسعه دادیم که اطلاعات یک application رو برای ما بر میگردونه ، بنابر این بوده که اگر ادمین درخواست بده ، اطلاعات بیشتری رو ببینه ، حالا اگر ما در مورد access controlling اطلاعاتی نداشته باشیم ممکنه بیایم api هامون رو به صورت زیر طراحی بکنیم : https://example.com/app/getappInfo https://example.com/app/admin_getappInfoدر این صورت ، برای دسترسی به اطلاعات ادمین ، فقط کافیه عبارت _admin رو مهاجم به درخواستش اضافه کنه ، در این صورت می تونه به اطلاعات ادمین که برای مهاجم غیرمجاز هستند دسترسی پیدا کنه . این بود اولین قسمت از 10 قسمت مربوط به OWASP TOP TEN . مباحث مربوط به این بخش بیشتر انتزاعی بود . خیلی دوست دارم اگر فرصت بشه 10 تاشو باهم بررسی کنیم و آگاهیمون رو ببریم بالا تر مرسی که تا اینجا همراهم بودی ❤ راستی این هم صفحه لینکدین منه ، اگر دوست داشتی منو دنبال کن . محسن مهربان‌پور محسن مهربان‌پور Fri, 08 Sep 2023 00:47:18 +0330