هدرهای امنیتی HTTP چیست و چگونه از آنها استفاده می کنید؟

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

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

اگر یک وب‌سایت راه‌اندازی می‌کنید یا به‌عنوان یک توسعه‌دهنده وب قصد دارید، هدرهای امنیتی HTTP برای شما ارزشمند هستند، زیرا نقش فعالی در امنیت کاربر و وب‌سایت دارند.

HTTP Strict-Transport-Security (HSTS) چیست؟

HTTP Strict Transport Security (HSTS) کاربران را مجبور می کند برای هر درخواستی که در مرورگر خود می کنند از HTTPS استفاده کنند. این یک راه محکم برای مبارزه با حملات سایبری مانند کاهش رتبه و تضمین امنیت همه ترافیک است.

فعال کردن HSTS بسیار آسان است. گفتگوی بین مشتری و سرور را در نظر بگیرید. هنگامی که سعی می کنید از طریق مرورگر خود به یک سایت دسترسی پیدا کنید، شما مشتری هستید. سایتی که می خواهید باز کنید به سرور بستگی دارد. هدف شما این است که به سرور بگویید “من می خواهم این سایت را باز کنم”. این یک عملیات درخواستی است. از طرف دیگر سرور در صورت داشتن شرایط مورد نظر شما را به سایت هدایت می کند.

در مورد این نمونه پرچم سربرگ HTTP این را در نظر داشته باشید:

Strict-Transport-Security: max-age=16070200;

وقتی این پرچم را به اطلاعات سرصفحه پاسخ HTTP اضافه می کنید، تمام درخواست های تولید شده توسط کاربر به HTTPS تبدیل می شوند. هرچه کاربر در اینجا بنویسد، مرورگر به طور خودکار پروتکل را به عنوان HTTPS ارزیابی می کند و یک اتصال امن برقرار می کند.

نحوه استفاده از HSTS

به جای اضافه کردن تمام این اطلاعات هدر HTTP در لایه کد، می توانید این کار را در Apache، IIS، Nginx، Tomcat و دیگر برنامه های وب سرور انجام دهید.

برای فعال کردن HSTS در آپاچی:

LoadModule headers_module modules/mod_headers.so
<VirtualHost *:443>
    Header always set Strict-Transport-Security "max-age=2592000; includeSubDomains"
</VirtualHost>

برای فعال کردن HSTS در Nginx:

add_header Strict-Transport-Security max-age=2592000; includeSubdomains

برای فعال کردن HSTS با IIS web.config:

<system.webServer>
   <httpProtocol>
       <customHeaders>
           <add name="Strict-Transport-Security" value="max-age=63072000"/>
       </customHeaders>
   </httpProtocol>
</system.webServer>

برای کاربران Cloudflare

Cloudflare با سرویس SSL بدون کلید خود، سرویس HTTPS رایگان را برای همه فراهم می کند. قبل از درخواست برای پیش بارگذاری HSTS، باید بدانید که گواهی شما متعلق به شما نیست. بسیاری از سایت‌ها از گواهینامه‌های SSL استفاده می‌کنند، زیرا آنها یک راه ساده برای حفظ امنیت داده‌ها هستند.

با این حال، Cloudflare اکنون از ویژگی HSTS پشتیبانی می کند. می‌توانید تمام ویژگی‌های HSTS، از جمله بارگذاری پیش‌بار، را از طریق رابط وب Cloudflare بدون مشکل در تنظیمات روی سرور وب، فعال کنید.

X-Frame-Options چیست؟

X-Frame-Options یک هدر امنیتی است که توسط تمام مرورگرهای مدرن پشتیبانی می شود. هدف X-Frame-Options محافظت در برابر سرقت کلیک مانند Clickjacking است. همانطور که از نام آن پیداست، در مورد کار یک قاب درون خطی آسیب پذیر است که به عنوان iframe نیز شناخته می شود. اینها عناصری در یک سایت هستند که صفحه HTML دیگری را در سایت “والد” جاسازی می کنند، بنابراین می توانید از محتوای منابع دیگر در سایت خود استفاده کنید. اما مهاجمان از iframe تحت کنترل خود استفاده می کنند تا کاربران را مجبور به انجام اقداماتی کنند که نمی خواهند.

به همین دلیل، باید از یافتن iframes در سایت توسط مهاجمان جلوگیری کنید.

کجا و چگونه از X-Frame-Options استفاده کنیم؟

کاری که X-Frame-Options انجام می دهد، برخی از توسعه دهندگان سعی می کنند با زبان هایی مانند جاوا اسکریپت انجام دهند. این کاملاً اشتباه نیست. با این حال، هنوز خطر وجود دارد زیرا کدهای نوشته شده در بسیاری از جنبه ها کافی نیستند. بنابراین عاقلانه است که این کار را به مرورگر اینترنتی که استفاده می کنید بسپارید.

با این حال، به عنوان یک توسعه دهنده، سه پارامتر در مورد X-Frame-Options وجود دارد:

• Deny: به طور کامل از فراخوانی صفحه در هر iframe جلوگیری کنید.
• SAMEORIGIN: از تماس هر دامنه ای غیر از دامنه خود در iframe جلوگیری کنید.
• ALLOW-FROM uri: فراخوانی iframe URI ارائه شده به عنوان پارامتر را بپذیرید. دیگران را مسدود کنید

در اینجا، ویژگی SAMEORIGIN بیشتر خودنمایی می کند. زیرا در حالی که می‌توانید برنامه‌ها را در زیر دامنه‌های مختلف خود با iframe در یکدیگر فراخوانی کنید، می‌توانید از فراخوانی آن‌ها در دامنه تحت کنترل مهاجم جلوگیری کنید.

در اینجا نمونه هایی از نحوه استفاده از SAMEORIGIN و X-Frame-Options با NGINX، Apache و IIS آورده شده است:

استفاده از X-Frame-Options SAMEORIGIN برای Nginx:

add_header X-Frame-Options SAMEORIGIN;

استفاده از X-Frame-Options SAMEORIGIN برای آپاچی:

Header always append X-Frame-Options SAMEORIGIN

استفاده از X-Frame-Options SAMEORIGIN برای IIS:

<httpProtocol>
   <customHeaders>
     <add name="X-Frame-Options" value="SAMEORIGIN" />
   </customHeaders>
 </httpProtocol>

افزودن هدر SAMEORIGIN به تنهایی امنیت بیشتری را برای بازدیدکنندگان شما فراهم می کند.

X-XSS-Protection چیست؟

استفاده از اطلاعات هدر X-XSS-Protection می تواند از کاربران در برابر حملات XSS محافظت کند. ابتدا باید آسیب پذیری های XSS در سمت برنامه را از بین ببرید. پس از ارائه امنیت مبتنی بر کد، اقدامات بیشتر، یعنی هدرهای X-XSS-Protection، در برابر آسیب‌پذیری‌های XSS در مرورگرها مورد نیاز است.

نحوه استفاده از X-XSS-Protection

مرورگرهای مدرن می توانند بارهای بالقوه XSS را با فیلتر کردن محتوای تولید شده توسط برنامه شناسایی کنند. فعال کردن این ویژگی با اطلاعات هدر X-XSS-Protection امکان پذیر است.

برای فعال کردن هدر X-XSS-Protection در Nginx:

add_header X-Frame-X-XSS-Protection 1;

برای فعال کردن هدر X-XSS-Protection در آپاچی:

Header always append X-XSS-Protection 1

برای فعال کردن هدر X-XSS-Protection در IIS:

<httpProtocol>
   <customHeaders>
     <add name="X-XSS-Protection" value="1" />
   </customHeaders>
 </httpProtocol>

برای جلوگیری از اجرای بلوک کد با حمله XSS به طور پیش فرض، می توانید از چیزی شبیه به این استفاده کنید:

X-XSS-Protection: 1; mode=block

اگر موقعیت بالقوه خطرناکی وجود دارد و می‌خواهید از ارائه همه محتوا جلوگیری کنید، باید این تغییر جزئی انجام شود.

X-Content-Type-Options چیست؟

مرورگرها تحلیلی به نام MIME Type Sniffing بر روی محتوای ارائه شده توسط برنامه وب به آنها انجام می دهند. به عنوان مثال، اگر درخواستی برای دسترسی به یک فایل PDF یا فایل PNG وجود داشته باشد، مرورگرهایی که تجزیه و تحلیل را بر روی پاسخ HTTP انجام می دهند، نوع فایل را استنباط می کنند.

فایلی را با پسوند jpeg در نظر بگیرید که در واقع دارای محتوای Text/HTML است. پس از استفاده از پسوندها و عبور از محافظت در ماژول آپلود، فایل با موفقیت آپلود شد. فایل آپلود شده از طریق URL فراخوانی می شود و در نتیجه sniffing نوع MIME متن/HTML را برمی گرداند. محتوا را به صورت HTML ارائه می کند. در آن زمان است که آسیب پذیری XSS رخ می دهد.

بنابراین باید از تصمیم گیری مرورگرها در مورد محتوا توسط MIME Type Sniffing جلوگیری کنید. برای این کار می توانید از nosniff استفاده کنید.

هدر X-Content-Type-Options برای Nginx:

add_header X-Content-Type-Options nosniff;

هدر X-Content-Type-Options برای آپاچی:

Header always X-Content-Type-Options nosniff

هدر X-Content-Type-Options برای IIS:

<httpProtocol>
   <customHeaders>
     <add name="X-Content-Type-Options" value="nosniff" />
   </customHeaders>
 </httpProtocol>

پرچم کوکی HttpOnly چیست؟

برنامه های کاربردی وب جلسات کاربران را از طریق شناسه جلسه ردیابی می کنند. مرورگرها این را ذخیره می کنند و به طور خودکار به هر درخواست HTTP در محدوده کوکی اضافه می کنند.

با این حال، امکان استفاده از کوکی ها برای اهدافی غیر از انتقال کلید جلسه وجود دارد. هکرها می‌توانند داده‌های کاربر را با استفاده از آسیب‌پذیری XSS فوق‌الذکر یا از طریق حمله Cross-Site Request Forgery (CSRF) پیدا کنند. بنابراین کدام کوکی ها از نظر امنیت مهمتر هستند؟

می توانید اطلاعات موجود در آخرین تصویری را که در گالری تصاویر روی آن کلیک کرده اید به عنوان نمونه در نظر بگیرید. به این ترتیب ترافیک HTTP کمتر شده و بخشی از بار توسط مرورگر اینترنت کاربر با اسکریپت سمت کلاینت قابل حل است.

اینجاست که HttpOnly وارد می‌شود. در زیر نمونه‌ای از نحوه انتساب کوکی آورده شده است:

Set-Cookie: user=t=cdabe8a1c2153d726; path=/; HttpOnly

به مقدار HttpOnly ارسال شده در عملیات Set-Cookie توجه کنید. مرورگر این را می بیند و زمانی که به کوکی از طریق متغیر document.cookie دسترسی پیدا می کند، مقادیر را با پرچم HttpOnly پردازش نمی کند. پرچم دیگری که در فرآیند Set-Cookie استفاده می شود، پرچم امن است. این نشان می دهد که مقدار کوکی فقط برای درخواست های HTTPS به هدر اضافه می شود. سایت های تجارت الکترونیک معمولاً از آن استفاده می کنند زیرا می خواهند ترافیک شبکه را کاهش دهند و عملکرد را افزایش دهند.

با استفاده از این روش می توانید داده های حیاتی کاربران مانند نام کاربری، رمز عبور و اطلاعات کارت اعتباری را مخفی کنید. اما یک مشکل وجود دارد. به کاربرانی که فرآیند ورود را کامل می‌کنند، یک مقدار کوکی بدون پرچم امن اختصاص داده می‌شود. زمانی که کاربر یک درخواست HTTP به پیوندهای غیر HTTPS می دهد، می تواند کلید جلسه را داشته باشد. افزودن پرچم امن آسان است:

Set-Cookie: user=t=cdabe8a1c2153d726; path=/; Secure

چه زمانی نباید از HttpOnly استفاده کنید؟ اگر به جاوا اسکریپت تکیه می کنید، باید محتاط باشید زیرا در عوض می تواند امنیت سایت شما را کاهش دهد.

گام های کوچک برای امنیت وب گسترده تر کار می کنند

برای افزایش امنیت برنامه های تحت وب نیازی به دانش نرم افزار و سرور پیشرفته ندارید. با تغییر تنها چند خط، می توانید از برخی حملات جدی جلوگیری کنید. البته این کافی نیست. با این حال، این یک گام کوچک اما موثر برای امنیت وب سایت است. دانش بهترین پیشگیرانه است، بنابراین دانستن نکات ظریف نحوه محافظت HTTPS از داده ها در حین انتقال نیز مفید است.

منبع مقاله