علی شکرالهی
بنیانگذار توسینسو و توسعه دهنده

آموزش استفاده از 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

امیدوارم که مطالب مورد استفاده تون قرار بگیره.هرگونه نشر و کپی برداری با ذکر نام و منبع و نویسنده بلامانع است.

نویسنده: علی شکرالهی


علی شکرالهی
علی شکرالهی

بنیانگذار توسینسو و توسعه دهنده

علی شکرالهی، بنیانگذار TOSINSO ، توسعه دهنده وب و برنامه نویس موبایل، مهندسی نرم افزار از دانشگاه آزاد اسلامی واحد کرج ، بیش از 15 سال سابقه ی فعالیت های حرفه ای و آموزشی

08 فروردین 1399 این مطلب را ارسال کرده

نظرات