آموزش استفاده از 5 هدر امنیتی ( HTTP Security Header ) در وب سایت
انیشتین یه ضرب المثل داره که میگه: "زندگی مثل دوچرخه سواریه ، برای اینکه تعادلت رو حفظ کنی ، باید به حرکت کردن ادامه بدی" این ضرب المثل رو میشه برای امنیت یک وب سایت هم بکار برد. اگر بخواید دست از ایمن سازی سایتتون بکشین ، به مرور این حرکت کند میشه و سایتتون آسیب پذیر میشه ! پس واسه حفظ امنیت سایت همیشه باید تلاش کنین . هدرهای امنیتی HTTP یکی از بخش های مهم در تامین امنیت وب سایت هستن. با پیاده سازی و استفاده از این هدرها شما جلوی حملاتی مثل : XSS ، Code Injection ، Clickjacking و ... رو میتونین بگیرین .
دوره های شبکه، برنامه نویسی، مجازی سازی، امنیت، نفوذ و ... با برترین های ایران
سرفصل های این مطلب
منظور از هدرهای امنیتی Http یا (Http security Headers) چیست ؟
وقتی که کاربر وارد سایت میشه ، سرور از طریق هدرهای پاسخگویی (HTTP Response Headers) پاسخ را ارسال میکند. این هدرها نحوه ی تعامل و برقراری ارتباط با سایت رو به مرورگر میگه .ما میتونیم با استفاده از این هدرها به افزایش امنیت سایتمون کمک کنیم. در ذیل 5 تا از هدرهای امنیتی مهم رو بررسی میکنیم.
1. HTTP Strict Transport Security (HSTS)
فرض کنیم که ما سایتی با نام example.com داریم و شما SSL رو فعال کردین و از HTTP کوچ کردین به HTTPS. خیلی هم عالی ! اما این پایان کار شما نیست . اگر هنوز هم سایت شما از طریق HTTP قابل دسترس هست و یا asset ها از طریق HTTP قابل دسترس باشه ، پس هنوز کار شما به اتمام نرسیده . اینجاست که هدر HSTS میاد وسط که وُلُم بره روی صد :)) در ابتدا یه توضیح کوتاه در مورد HSTS میدم:
این هدر یک خط مشی یا Policy هست که ازطریق Header برای مرورگر ارسال میشه و مرورگر رو اجبار میکنه تا تمام ارتباط ها و درخواست های ارسالی به سایت رو بصورت HTTPS انجام بده . این مسئله جلوی مواردی مثل Cookie Hijacking رو میگیره.خوب همونطور که در بالا توضیح دادم ، اگر از این هدر استفاده بشه ، مرورگر موظف میشه تمام درخواست های ارسالی به سایت ما رو بصورت HTTPS بفرسته و عملا ارسال درخواست های HTTP منتفی میشه ، در صورتی که قصد دارین از این هدر استفاده کنین به شکل زیر میتونین مشخصش کنین:
Strict-Transport-Security: max-age=<expire-time>
Strict-Transport-Security: max-age=<expire-time>; includeSubDomains
Strict-Transport-Security: max-age=<expire-time>; preload
اگر قصد استفاده از این هدر رو دارین ، نکات زیر رو حتما در نظر داشته باشین:
- حتما بایستی SSL برای سایتتون داشته باشین
- اگر سایتتون دارای Subdomain هست ، بایستی از ssl wildcard جهت پوشش اونها استفاده کنین.
- حتما درخواست های HTTP رو از طریق redicretion به HTTPS منتقل کنین
- پیشنهاد گوگل برای max-age ، دو سال هست (برای اینکه بتونین سایتتون رو تو preload list قرار بدین بایستی حداقل 1 سال رو تنظیم کنین یعنی 31536000 ثاینه)
- هدرهای مربوط به preload و Subdomain حتما قید بشه.
یه مسئله ای که الان بایستی براتون سوال شده باشه این هست که این preload چیه !؟Preload یا preload list ، لیستی از سایتهایی هست که موارد مرتبط با HSTS رو رعایت میکنن و بصورت hardcode در مرورگهایی مثل firefox و chrome قرار دارن و اگر سایتتون توی لیست مربوطه باشه ، بصورت پیش فرض به عنوان hsts شناخته میشه. اگر سایتتون پیش نیازهای لازم رو داره ، میتونید از طریق سایت https://hstspreload.org ، سایتتون رو ثبت کنین.اگر از ASP.NET MVC یا ASP.NET Webform استفاده میکنین میتونین با استفاده از کد زیر، این مورد رو روی سایتتون پیاده سازی کنین:
protected void Application_BeginRequest(Object sender, EventArgs e)
{
switch (Request.Url.Scheme)
{
case "https":
Response.AddHeader("Strict-Transport-Security", "max-age=31536000; includeSubDomains; preload");
break;
case "http":
var path = "https://" + Request.Url.Host + Request.Url.PathAndQuery;
Response.Status = "301 Moved Permanently";
Response.AddHeader("Location", path);
break;
}
}
یا در ASP.NET Core در تابع Configure ، از UseHsts و UseHttpsRedirection استفاده کنین:
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
}
else
{
app.UseExceptionHandler("/Error");
app.UseHsts();
}
app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseRouting();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
endpoints.MapRazorPages();
});
}
2. Content Security Policy (CSP)
این هدر که مورد توصیه ی W3C هم هست و توسط مرورگرهای جدید هم پشتیبانی میشه از حملاتی مثل XSS و clickjacking جلوگیری میکنه . هدر CSP این امکان رو به مالکین وب سایت میده تا بتونن مشخص کنن که منابعی مثل کدهای JavaScript ، CSS و Html Frame ها ، وب ورکر (Web worker) ها ، Font ها ، تصاویر و ... امکان اجرا یا بارگذاری بروی وب سایت رو دارن و اگر دارن از چه منابعی امکان پذیر هست ؟ نحوه ی تعریف این هدر به شکل زیر هست :
Content-Security-Policy: <policy-directive1>;<police-directive2>
همینطور میتونین از طریق meta هم policy ها رو مشخص کنین. مثلا:
<meta http-equiv="Content-Security-Policy" content="<policy-dir1>;<policy-dir2>; " />
خوب حالا منظور از policy-directive چی هست ؟ لیستی هست که میتونین برای مثلا img مشخص کنین که src attribute از کجا میتونه تصاویرش رو درخواست بده ؟ یا media یا font. لیست زیر شامل مواردی میشه که در حال حاضر پشتیبانی میشه:
child-src
connect-src
font-src
frame-src
img-src
manifest-src
media-src
object-src
prefetch-src
script-src
script-src-elem
script-src-attr
style-src
style-src-elem
style-src-attr
worker-src
خوب یک دایرکتیو با نام default-src هم داریم اگر ، هر کدوم از موارد بالا در policy های ما تعریف نشده باشه ، بصورت پیش فرض از policy تعیین شده برای default-src استفاده میکنه . مثال زیر رو در نظر بگیرین:
Content-Security-Policy: default-src http://*.tosinso.com
در تعریف بالا ما مشخص کردیم که تمام درخواست ها مثلا برای style یا javascript از منبعی که مربوط به tosinso.com یا زیردامنهاش باشه قابل بارگذاری باشه و غیرازاون ، امکان بارگذاری هیچ فایلی رو در سایت نداریم .
Content-Security-Policy: style-src ‘self’
یا در مثال بالا ، امکان بارگذاری فایلهای css تنها از طریق منبعی که صفحه ازش بارگذاری شده هست امکان پذیره. یعنی اگر ما tosinso.com رو زدیم ، فقط فایلهای css یی که از طریق tosinso.com قابل ارائه باشن رو میتونیم در صفحه استفاده کنیم. برای مطالعه ی بیشتر میتونین اینجا کلیک کنین و بیشتر در موردش مطالعه داشته باشین.
3. Cross Site Scripting Protection (X-XSS)
همونطور که از نام این هدر مشخص هست ، این هدر از سایت در مقابل حملات Cross-Site Scripting محافظت میکنه. فیلترهای XSS بصورت پیش فرض بروی مرورگرهای Chrome، IE و Safari فعال هست. این فیلتر امکان بارگذاری و نمایش صفحه در مرورگر رو زمانی که یک حمله XSS شناسایی بشه میگیره. نحوه ی تعریف و استفاده:
X-XSS-Protection: 0
X-XSS-Protection: 1
X-XSS-Protection: 1; mode=block
X-XSS-Protection: 1; report=<reporting-uri>
به 4 طریق بالا میشه از این هدر استفاده کرد. حالا هر حالت رو باهم بررسی میکنیم.در حالتی که مقدار صفر سِت بشه ، عملا این ویژگی غیرفعال میشه ، در حالتی که مقدار 1 سِت باشه ، میشه عملکرد پیش فرض که فعال میشه و اگر XSS یی تشخیص داده بشه توسط خود مرورگر Sanitize (حذف بخشهای ناامن) میشه . در حالتی که مقدار 1 سِت باشه و mode=block هم تعیین بشه، بجای Sanitize کردن بخشهای ناامن، بطور کلی بارگذاری صفحه متوقف میشه . اگر report مقدار دهی بشه که در حال حاضر فقط در مرورگرهای مبتنی بر Chromium پشتیبانی میشه، میتونین یک آدرس رو مشخص کنین که مرورگر بعد از Sanitize کردن ، یک گزارش به آدرس تعیین شده ارسال کنه .
4. X-Frame-Options
این ویژگی امکان اینکه بتونن محتوا و سایت شما رو با استفاده از Iframe در سایتشون نمایش بدن میگیره . در واقع این مسئله میتونه از Clickjacking جلوگیری کنه.نحوه ی استفاده:
X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN
X-Frame-Options: ALLOW-FROM https://example.com/
حالا هر مورد رو باهم بررسی میکنیم:
- اگر مقدار DENY تعیین بشه ، عملا سایت مربوطه در داخل Iframe نمیتونه نمایش داده بشه.
- اگر SAMEORIGIN تعیین بشه ، فقط سایت میتونه در Iframe هایی نمایش داده بشه که از خود سایت تعریف شده باشه.
- مورد سوم هم Obsolote شده و دیگه پشتیبانی نمیشه . (صرفا برای اینکه بگیم قبلا بود در لیست آورده شده)
این نکته رو هم در نظر داشته باشین که از طریق metatag ها نمیتونین از این ویژگی استفاده کنین .
5. X-Content-Type-Options
این هدر به مرورگر میگه که MimeType یی که از طریق ContentType مشخص شده رو در نظر بگیره . در واقع این هدر از Mime type sniffing جلوگیری میکنه .نحوه ی تعریف و استفاده:
X-Content-Type-Options: nosniff
امیدوارم که مطالب مورد استفاده تون قرار بگیره.هرگونه نشر و کپی برداری با ذکر نام و منبع و نویسنده بلامانع است.
نویسنده: علی شکرالهی