Mahan
برنامه‌های وب که برای کارای تجاری مهم‌تر میشن، هدف جذاب‌تری هم برای حملات سایبری میشن. ولی متأسفانه، خیلی از توسعه‌دهنده‌های وب توی ساخت یه frontend امن، نسبت به همتایان بک‌اند و DevOps خودشون عقب موندن. این فاصله، خطر لو رفتن داده ها رو بیشتر میکنه.
حوادث اخیر مثل نقض پروتکل Balancer نشون میده که مهاجمان با سوء استفاده از آسیب پذیری های فرانت اند چه میزان خسارت میتونن وارد کنن. طبق گزارش ها، پروتکل Balancer از طریق یک حمله به فرانت اند هک شد و منجر به از دست رفتن بیش از 240,000 دلار شد، طبق چیزی که به طور عمومی تایید شده. به دلیل گسترش ابزارها و اسکریپت های هک، تهدید علیه برنامه های وب با کاهش موانع برای انجام حملات همچنان در حال افزایش است.
این حمله‌ای هستش که کد مخرب سمت کاربر تزریق میکنه. به عنوان مثال، مهاجم میتونه جاوااسکریپتی را که کوکی‌های کاربر رو میدزده، در فرم نظری که ورودی‌ها را sanitize نمیکنه، وارد کنه. وقتی که قربانی ها صفحه آلوده رو باز می‌کنن، اسکریپت اجرا میشه تا به مهاجم دسترسی به حساب کاربری بده.
نمونه کد مشکل‌دار:
<form action="/save_comment" method="post">
<textarea name="comment"></textarea>
<button type="submit">ارسال نظر</button>
</form>
<script>
function showComments() {
const comments = JSON.parse(localStorage.getItem('comments'));
comments.forEach(comment => {
const commentDiv = document.createElement('div');
commentDiv.innerHTML = comment.text; // خطر! تزریق XSS
document.getElementById('comments-container').appendChild(commentDiv);
});
}
showComments();
</script>
توضیح مشکل:
در این کد، نظرات ذخیره‌شده در localStorage با استفاده از innerHTML مستقیماً درون صفحه وب تزریق میشن. اگر مهاجم نظری با کد جاوااسکریپت مخرب ارسال کنه، اون اسکریپت میتونه وقتی نمایش نظر اجرا میشه و به مهاجم کنترل بخشی از صفحه وب یا حتی حساب کاربری قربانی را بده.
کد ایمن:
<form action="/save_comment" method="post">
<textarea name="comment"></textarea>
<button type="submit">ارسال نظر</button>
</form>
<script>
function showComments() {
const comments = JSON.parse(localStorage.getItem('comments'));
comments.forEach(comment => {
const commentDiv = document.createElement('div');
commentDiv.textContent = comment.text; // استفاده از textContent برای جلوگیری از XSS
document.getElementById('comments-container').appendChild(commentDiv);
});
}
showComments();
</script>
توضیح ایمن‌سازی:
در این کد اصلاح‌شده، از textContent به‌جای innerHTML برای نمایش نظرات استفاده شده. textContent فقط متن را نمایش میده و اسکریپت‌ها رو اجرا نمیکنه، بنابراین حمله XSS رو خنثی می‌کند.
پیشگیری از XSS:
سناریو برای حمله XSS:
نکات مهم:
اپلیکیشن‌های تحت وب روی کتابخانه‌ها و کامپوننت‌های متعدد شخص ثالث ساخته میشوند. اگر این کدها آسیب‌پذیری داشته باشن، کل اپلیکیشن شما رو به خطر میندازن. استفاده از دپندسی یا وابستگی‌های آپدیت نشده و آسیب‌پذیر اشتباهی رایج در میان توسعه‌دهندگان هست.
.png)
CSRF مخفف Cross-Site Request Forgery هست، یعنی جعل درخواست بین سایتی. تو این حملات، مهاجم کاربر رو مجبور می کنه که کاری رو که خودش می خواد انجام بده. مثلاً فرض کن کاربر تو بانک آنلاین خودش لاگین کرده باشه. مثلاً مهاجم میتونه یه لینک مخرب رو تو یه ایمیل فیشینگ بذاره که وقتی کاربر روش کلیک میکنه، یه درخواست انتقال وجه مخرب رو به بانک کاربر ارسال میکنه.
مثال کد آسیب‌پذیر:
<form action="/transfer" method="POST">
<input type="hidden" name="amount" value="1000"> <input type="hidden" name="to_account" value="attacker_account">
<button type="submit">انتقال وجه</button>
</form>
چرا خطرناکه؟
مثال کد ایمن:
<form action="/transfer" method="POST">
<input type="hidden" name="_csrf_token" value="<%= csrfToken %>"> <input type="number" name="amount" required>
<select name="to_account">
</select>
<button type="submit">انتقال وجه</button>
</form>
چطوری میشه ازش جلوگیری کرد؟
سناریو برای مشکلات امنیتی:
سناریو 1: یک مهاجم پیوندی رو تو یک ایمیل فیشینگ برای کاربر ارسال میکنه که حاوی درخواست انتقال وجه مخرب با استفاده از کد آسیب‌پذیر است.
سناریو 2: یک مهاجم یک اسکریپت مخرب رو تو یک وب‌سایت تزریق میکنه که کد آسیب‌پذیر رو برای ایجاد درخواست‌های تقلبی CSRF فراخوانی میکنه.
به نقل قول از memoryleaks.ir:
این حمله به دلیل عدم وجود هدر x-frame-options هست که سال‌های قبل خیلی توی شبکه‌های اجتماعی مثل فیسبوک کشف و اکسپلویت میشده. هنوز هم بعد گذشت چند سال، این حمله جز حملات موثر و کمتر شناخته شده‌ای هست (مطالعه این لینک و این لینک میتونه مفید باشه).
حملات Clickjacking چطور انجام میشن؟
به طور معمول، حملات Clickjacking با نمایش یه صفحه یا عنصر HTML نامرئی در داخل یه “iframe” بر روی صفحه‌ای که کاربر میبینه، انجام میشن. کاربر فکر میکنه روی صفحه‌ی قابل مشاهده کلیک میکنه، در حالی که در واقع روی یه عنصر نامرئی در صفحه‌ی دیگه‌ای که روی اون قرار گرفته، کلیک میکنه.
صفحه‌ی نامرئی میتونه یه صفحه‌ی مخرب یا یه صفحه‌ی قانونی باشه که کاربر قصد بازدید از اونو نداشته - به عنوان مثال، صفحه‌ای در وب سایت بانک کاربر که انتقال پول رو تأیید میکنه.
انواع حملات Clickjacking:
مثال حمله Clickjacking:
این مثال نشون میده که در یه حمله Clickjacking، نمی‌شه اقدام مخرب (که در این مورد در وب سایت بانک انجام شده است) رو به مهاجم ردیابی کرد، زیرا کاربر هنگام ورود قانونی به حساب خودش خود اونو انجام داده است.
روش‌های مقابله با Clickjacking
برای مقابله با Clickjacking، دو راه کلی وجود داره:
مقابله با Clickjacking با هدر X-Frame-Options
هدر X-Frame-Options بخشی از پاسخ HTTP یک صفحه وب هست که به مرورگر می‌گه آیا میتونه صفحه‌ای رو داخل تگ یا نمایش بده یا نه.
سه مقدار برای هدر X-Frame-Options مجاز هست:
استفاده از گزینه SAMEORIGIN برای مقابله با Clickjacking
هدر X-Frame-Options به ناشران محتوا اجازه میده تا از استفاده مهاجمان از محتوای خودشون در یک فریم نامرئی جلوگیری کنن.
گزینه DENY امن‌ترین گزینه هست و از هر گونه استفاده از صفحه فعلی در یک فریم جلوگیری میکنه. معمولاً گزینه SAMEORIGIN استفاده میشه، چون امکان استفاده از فریم‌ها رو فراهم میکنه، اما اون‌ها رو به دامنه فعلی محدود میکنه.
محدودیت‌های هدر X-Frame-Options
آزمایش Clickjacking - آیا سایت شما آسیب‌پذیره؟
یک راه ساده برای آزمایش آسیب‌پذیر بودن سایت شما به Clickjacking، ایجاد یک صفحه HTML و تلاش برای گنجاندن یک صفحه حساس از وب‌سایت خود در یک iframe است. اجرای کد تست روی یک سرور وب دیگر مهم است، چون این رفتار معمولی در حمله Clickjacking هست.
از کد زیر استفاده کنید که بخشی از راهنمای تست OWASP است:
<html>
<head>
<title>صفحه تست Clickjacking</title>
</head>
<body>
<p>وب سایت در برابر Clickjacking آسیب‌پذیر است!</p>
<iframe src="http://www.yoursite.com/sensitive-page" width="500" height="500"></iframe>
</body>
</html>
صفحه HTML رو در یک مرورگر مشاهده کنید و به شرح زیر صفحه رو ارزیابی کنید:
اگر کتابخانه‌ها رو از CDNهای اکسترنال غیرقابل اعتماد لود کنیم، هکرها میتونن اونا رو اونجا دستکاری کنن تا کد مخربی رو تزریق کنن که بعدش توسط کاربرای برنامه دانلود میشه.
مثلاً فرض کن یه برنامه‌ای داریم که از CDN اکسترنال برای بارگذاری کتابخانه‌ای استفاده میکنه که برای اعتبارسنجی کاربران استفاده میشه. هکر میتونه اون کتابخانه رو دستکاری کنه تا کد مخربی رو تزریق کنه که به هکر اجازه میده به اطلاعات کاربرا دسترسی پیدا کنه.
یا فرض کن یه برنامه‌ای داریم که از CDN اکسترنال برای بارگذاری کتابخانه‌ای استفاده میکنه که برای پرداخت آنلاین استفاده میشه. هکر میتونه اون کتابخانه رو دستکاری کنه تا کد مخربی رو تزریق کنه که به هکر اجازه میده پرداخت‌های کاربرا رو دزدیده یا تغییر بده.
این فقط یه مثال از خطراتیه که بارگذاری کتابخانه‌ها از CDNهای اکسترنال میتونه داشته باشه. برای کاهش این خطرات، بهتره کتابخانه‌ها رو از CDNهای داخلی یا از منابعی که قابل اعتماد هستن بارگذاری کنیم.
HTTPS downgrades یه نوع حمله سایبری هستن که امنیت برنامه‌های وب رو با تبدیل HTTPS به HTTP تهدید می‌کنن. این نوع حمله میتونه اطلاعات حساسی مثل رمزهای عبور، شماره کارت‌های اعتباری، و اطلاعات شخصی رو لو بده.
فرض کنید شما یه وب‌سایت دارید که از HTTPS استفاده میکنه. یک حمله‌کننده ممکنه یه لینک HTTP رو تو یه صفحه از وب‌سایت شما جاسازی کنه. اگر کاربر روی این لینک کلیک کنه، مرورگرش درخواستی به سرور شما ارسال میکنه که از HTTP استفاده میکنه.
سرور شما ممکنه این درخواست رو به عنوان یه درخواست HTTP اشتباه تشخیص بده و بهش پاسخ بده. حالا حمله‌کننده میتونه از این فرصت استفاده کنه تا ترافیک بین مرورگر کاربر و سرور شما رو مانیتور کنه و اطلاعات حساسی رو لو بده.
برای جلوگیری از HTTPS downgrades، باید مطمئن بشیم که تمام لینک‌های داخلی وب‌سایتمون از HTTPS استفاده می‌کنن. همچنین می‌تونیم از هدرهای امنیتی مثل Content-Security-Policy و Strict-Transport-Security استفاده کنیم.
Content-Security-Policy یه هدر HTTP هست که به مرورگرها می‌گه چه منابعی رو میتونن بارگذاری کنن. با استفاده از این هدر، می‌تونیم به مرورگرها بگیم که فقط منابع HTTPS رو بارگذاری کنن.
برای استفاده از Content-Security-Policy، باید یه تگ meta با ویژگی http-equiv به نام Content-Security-Policy به بخش head تمام صفحات وب‌سایتمون اضافه کنیم. محتوای این تگ باید یه لیست از منابع مجاز باشه.
برای مثال، برای اینکه فقط منابع HTTPS رو مجاز کنیم، باید از دستور upgrade-insecure-requests استفاده کنیم:
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">
Strict-Transport-Security یه هدر HTTP دیگه هست که به مرورگرها می‌گه برای همیشه از HTTPS برای دسترسی به وب‌سایت شما استفاده کنن.
برای استفاده از Strict-Transport-Security، باید یه هدر HTTP با نام Strict-Transport-Security به تمام صفحات وب‌سایتمون اضافه کنیم. محتوای این هدر باید شامل زمان انقضای سیاست و لیست زیردامنه‌های مجاز باشه.
برای مثال، برای اینکه برای همیشه از HTTPS استفاده کنیم و لیست زیردامنه‌های مجاز رو هم مشخص کنیم، باید از دستورات زیر استفاده کنیم:
Strict-Transport-Security: max-age=31536000; includeSubDomains
برای اینکه مطمئن بشیم که تمام مرورگرها از HTTPS برای دسترسی به وب‌سایت ما استفاده می‌کنن، می‌تونیم وب‌سایتمون رو به لیست پیش‌بارگذاری HSTS اضافه کنیم.
اگه از CDN استفاده می کنید توی بخش SSL اون CDN انی که ازش خدمات میگیرید این تنظیمات وجوود داره.
برای جلوگیری از HTTPS downgrades به APIهای وب، باید پروتکل HTTP رو از کار بندازیم. یعنی باید به کلاینت‌ها بگیم که فقط از HTTPS استفاده کنن.
برای این کار، می‌تونیم از کد زیر استفاده کنیم:
const express = require("express");
const app = express();
app.use(function (req, res, next) {
if (!req.secure && req.get("x-forwarded-proto") !== "https") {
return res.status(403).send("Please use HTTPS");
}
next();
});
این کد بررسی میکنه که آیا درخواست فعلی از HTTPS استفاده میکنه یا نه. اگر از HTTPS استفاده نمیکنه، به کلاینت کد وضعیت 403 (Forbidden) رو ارسال میکنه.
در این حملات، مهاجم مخفیانه پیام‌های رد و بدل شده بین دو طرف را دریافت و احتمالاً تغییر میده. این کار به جاسوسی و انتشار اطلاعات جعلی بین قربانیان منجر میشه.
یکی از دلایل استفاده از HTTPS که توی مورد قبلی هم بهش اشاره شد، رمزنگاری اطلاعات برای جلوگیری از شنود شدنشون هست.
با اینکه هر روز بیشتر از قبل کارهامون رو آنلاین انجام می‌دیم، وب هم به عنوان یه مسیر حمله‌ی بالقوه بزرگ‌تر میشه. پس توسعه‌دهندگان جاوااسکریپت که برنامه‌های frontend می‌سازن، باید امنیت برنامه‌هاشون رو جدی بگیرن. علاوه بر این، باید از دیدگاه مهاجم‌ها هم به آسیب‌پذیری‌ها نگاه کنن تا بتونن قبل از اینکه این آسیب‌پذیری‌ها تبدیل به یه مشکل جدی بشن، جلوشون رو بگیرن.
خیلی ممنون که تا پایان مقاله همراه من بودید:) در ادامه منابعی که موقع نوشتن این مقاله استفاده کردم رو معرفی میکنم.
🔗 https://www.imperva.com/learn/application-security/clickjacking/
🔗 https://dev.to/tinymce/7-common-front-end-security-attacks-372p?ref=dailydev
🔗 https://malfind.com/index.php/2018/12/21/how-i-accidentaly-found-clickjacking-in-facebook/
🔗 https://portswigger.net/web-security/cross-site-scripting
🔗 https://www.geeksforgeeks.org/what-is-cross-site-request-forgery-csrf/
🔗 https://www.geeksforgeeks.org/reflected-xss-vulnerability-in-depth/
🔗 https://auth0.com/blog/preventing-https-downgrade-attacks/
🔗 https://www.rapid7.com/fundamentals/man-in-the-middle-attacks/
نوشته شده توسط
بنیان‌گذار ام دی کورس و MdDaily 💻 علاقه مند به دنیای نرم‌افزار آزاد 👨💻 Golang & Flutter
Mahan
Load Balancer ها در معماری وب نقشی اساسی دارن. چونکه اجازه میدن بار بین مجموعه ای از backendها توزیع بشه. این باعث مقیاس پذیری بیشتر خدمات میشه و در …
ادامه مطلب
Mahan
یه سوال مصاحبه طراحی سیستم داریم که توش باید یه ابزار کوتاه کننده URL مثل TinyURL یا Bitly رو از صفر طراحی کنیم. همه چی رو از الزامات طراحی و معماری و …
ادامه مطلب