آنچه دیگران می خوانند

افزایش امنیت سایت با کدهای header در htaccess.

بوسیله ساتین در ۱۶ اردیبهشت ۱۴۰۰

این هدر ها اکثر در وب سرور قابل تنظیم هستند . من توی این پست به وب سرور apache و ngnix اشاره خواهم کرد. امیدوارد که برای شما هم مفید باشد.

افزایش امنیت سایت با htaccess.

فهرست مطالب

افزایش امنیت سایت با htaccess.
The security headers

۱- X-XSS-Protection

برای جلوگیری از حملات XSS این header رو اضافه میکنیم که باعث میشه وقتی مرورگر متوجه وجود این حمله در صفحه بشه، از نمایش اون قسمت جلوگیری کنه.

این هدر سازگاری با اکثر مرورگر ها را هم دارد. اکثر وب سایت های بزرگ مانند google , facebook … از این هدر استفاده میکنند.

# X-XSS-Protection
<IfModule mod_headers.c>
 Header set X-XSS-Protection "1; mode=block"
</IfModule>

تنظیمات هدر X-XSS-Protection در apache

Header set X-XSS-Protection “1; mode=block”

بعد از اعمال تعییرات apache خود را ریستارت کنید

تنظیمات هدر X-XSS-Protection در nginx (در بلاک http)

add_header X-XSS-Protection “1; mode=block”;

فقط کافیه این کد رو در سرورهای آپاچی داخل فایل htaccess. قرار بدید.

۲- X-Frame-Options

با استفاده از این header ما اجازه فریم کردن صفحه رو در جای دیگه نمیدیم. به عبارت دیگه، این header باعث میشه صفحه شما داخل تگهای frame – iframe – object غیر قابل بارگذاری در سایت های دیگه بشه.

# X-Frame-Options
<IfModule mod_headers.c>
 Header always append X-Frame-Options SAMEORIGIN
</IfModule>

هدر X-Frame-Options برای جلوگیری از حملات Clickjacking هست.

۳ مقدار برای این هدر در نظر گرفته شده است که به ترتیب : SAMEORIGIN,DENY,ALLOW-FROM می باشند

SAMEORIGIN = همه وب سایت ها قادر خواهند بود وب سایت شما رو در iframe لود کنند

DENY = هیچ وب سایتی قادر نخواهد بود وب سایت شما را توسط iframe لود کند

ALLOW-FROM = اجازه میدهد وب سایت هایی که شما مشخص کرده اید ، وب سایت شما را در iframe لود کنند.

تنظیم هدر X-Frame-Options در apache

Header always append X-Frame-Options SAMEORIGIN

تنظیم هدر X-Frame-Options در nginx

add_header X-Frame-Options “SAMEORIGIN”;

بعد از اعمال تغییرات ngnix خود را ریستارت کنید

۳-Content Security Policy (CSP)

CSP یکی از مهمترین header ها برای جلوگیری از حملات هست (+ مزایای دیگه). با استفاده از این header شما میتونید تعیین کنید که محتواهایی که در سایت وجود دارن از چه منابعی حق بازگذاری شدن رو دارن. مثلا میتونید تعریف کنید که عکس های موجود در صفحه شما فقط میتونن از سایت خودتون + imgur.com بارگذاری بشه یا اسکریپت ها فقط از سایت خودتون + google حق دارند بارگذاری بشن. عالیه نه؟

مثال:

<IfModule mod_headers.c>
 Header set Content-Security-Policy "default-src 'self'; font-src 'self' *.gstatic.com; img-src *"
</IfModule>

تو این مثال ما تعیین کردیم که

فونت های ما میتونن از سایت خود ما + گوگل بارگذاری بشن
تصاویر میتونن از هر جایی بارگذاری بشن
در موارد تعیین نشده (مثل script-src, style-src, media-src و…) فقط میتونن از سایت ما بارگذاری بشن چون default-src رو روی ‘self’ تنظیم کردیم.

برای جلوگیری از حملات XSS, clickjacking, code injection از CSP استفاده می شود. این هدر بر روی تمامی مرورگر ها قابل اجرا نمی باشد.

تنظیم هدر Content Security Policy در apache

Header set Content-Security-Policy “script-src ‘self’;”

تنظیم هدر Content Security Policy در nginx

add_header Content-Security-Policy “script-src ‘self’;”;

۴-X-Content-Type-Options

با استفاده از این header شما از Content-sniffing جلوگیری میکنید. با این کار شما فقط اجازه میدید که تگهای scriptو style با MIME type های قابل قبول اجرا بشن و در غیر اینصورت بلاک میشن.

# X-Content-Type nosniff
<IfModule mod_headers.c>
 Header set X-Content-Type-Options nosniff
</IfModule>

برای جلوگیری از حملات MIME از هدر X-Content-Type-Options استفاده میکنیم. این هدر به مرورگر میگه file type های مجاز را ارسال/دریافت کند.

این هدر فقط یک آپشن دارد که nosniff می باشد.

تنظیم هدر X-Content-Type-Options در apache

Header set X-Content-Type-Options nosniff

تنظیم هدر X-Content-Type-Options در nginx

add_header X-Content-Type-Options nosniff;

۵-HTTP Strict Transport Security

HSTS این امکان رو به ما میده که فقط اجازه دسترسی به وبسایت رو از طریق اتصال امن براقرار کنیم و تنها زمانی باید اینکارو بکنیم که برای وبسایت گواهی نامه متعبر SSL خریداری کرده باشیم.

<IfModule mod_headers.c>
Header set Strict-Transport-Security "max-age=31536000" env=HTTPS
</IfModule>

هدر HTTP Strict Transport Security اطمینان حاصل میکند که تمامی درخواست های مرورگر به HTTPS ارسال میشود.

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

تنظیم HTTP Strict Transport Security در apache

Header set Strict-Transport-Security “max-age=31536000; includeSubDomains; preload”

بعد از اعمال تعییرات apache خود را ریستارت کنید

تنظیم هدر HTTP Strict Transport Security در nginx (در بلاک server و قسمت ssl)

add_header Strict-Transport-Security ‘max-age=31536000; includeSubDomains; preload’;

بعد از اعمال تغییرات ngnix خود را ریستارت کنید

۶ – X-Permitted-Cross-Domain-Policies

با استفاده از این هدر شما میتونید جلوگیری کنید از اینکه وب سایت هایی دیگه فایل هایی مانند pdf , flash , … رو از سایت شما توی سایت خودشون نمایش بدن.

خب این هدر واقعا برای همه مفید نیست . برخی دوس دارن فایل هاشون بنا به دلایل بازاریابیشون پخش بشه . اما اون دسته افرادی که دوس ندارن فایل هاشون از وب سایت های دیگه لود بشه میتونن از هدر X-Permitted-Cross-Domain-Policies استفاده کنن.

البته این هدر میتونه مقادیر مختلفی قبول کنه مثلا تمامی درخواست ها رو رد کن یا تمام درخواست ها رو قبول کن و اجازه بده فایل ها خونده بشه از وب سایت های دیگه
یا اینکه فقط فرمت خاصی از فایل ها رو اجازه دانلود بدین از وب سایت های دیگه.

تنظیم هدر X-Permitted-Cross-Domain-Policies در apache

Header set X-Permitted-Cross-Domain-Policies “none”

تنظیم هدر X-Permitted-Cross-Domain-Policies در nginx

add_header X-Permitted-Cross-Domain-Policies none;

۷ . سرآیند Referrer Policy

سرآیند referrer به وب‌سرور اجازه می‌دهد تا تشخیص دهد کاربران از چه سایت‎‌هایی به سمت این وب‌سایت آمده‌اند. این اطلاعات برای تحلیل، مشخص کردن تعداد ورود و یا بهینه‌سازی مورد استفاده قرار می‌گیرند. به طور مثال Google Analytics از این معیارها برای تشخیص این موضوع که ترافیک از کجا آمده است استفاده می‌کند. این موضوع برای یک وب‌سایت در جهت تحلیل ترافیک مفید است اما در حقیقت حریم شخصی بازدیدکنندگان را نقض می‌نماید. زیرا این سرآیند می‌تواند تاریخچه‌ی جستجوی کاربر را آشکار سازد. سرآیند Referrer Policy به یک وب‌سایت اجازه می‌دهد که مقدار سرآیند referer را در لینک‌ها، جدای از صفحات کنترل نماید.
سرآیند Referer

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

…

Host: scotthelme.co.uk

Referer: https://twitter.com/Scott_Helme/status/760790725776830464

Upgrade-Insecure-Requests: 1

….

Referrer-Policy: no-referrer

Referrer-Policy: no-referrer-when-downgrade

Referrer-Policy: origin

Referrer-Policy: origin-when-cross-origin

Referrer-Policy: same-origin

Referrer-Policy: strict-origin

Referrer-Policy: strict-origin-when-cross-origin

Referrer-Policy: unsafe-url

Referrer Policy: no-referrer

یعنی سرآیند Referer به طور کامل حذف شده و اطلاعات سایت مبدا همرا با درخواست ارسال نخواهند شد.

Referrer Policy: no-referrer-when-downgrade

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

Referrer Policy: same-origin

ناوشگر تنها سرآیند referrer را بر روی درخواست‌هایی که از منبع یکسانی آمده‌اند تنظیم می‌نماید.

Referrer-Policy: origin

در این حالت ناوشگر، سرآیند referrer را بر روی اصل (origin) آن تنظیم می‌نماید.

Referrer Policy: strict-origin

در این حالت مثل حالت بالا عمل می‌شود با این تفاوت که اگر مبدا بر روی https باشد اطلاعاتش تنها بر روی HTTPS ارسال خواهد شد، نه HTTP

Referrer Policy: origin-when-cross-origin

ناوشگر URL را به صورت کامل برای درخواست‌هایی که منبع یکسان دارند ارسال خواهد کرد اما تنها زمانی اصل (origin) را خواهد فرستاد که دستورات cross-origin باشند.

Referrer Policy: strict-origin-when-cross-origin

این حالت مثل origin-when-cross-origin است با این تفاوت که اجازه‌ی ارسال هیچکدام از اطلاعات را در زمانی که از HTTPS به HTTP می‌رویم را نمی‌دهد.

Referrer Policy: unsafe-url

در این حالت ناوشگر URL را به صورت کامل ارسال می‌نماید.

توصیه‌ها

اینکه کدام سرآیند را انتخاب کنید بستگی به نیازهای شما دارد اما برخی نکات را بایستی در نظر بگیرید. ما یک سری پیشنهادات برای شما داریم. از unsafe-url استفاده نکنید، همچنین پیشنهاد میکنیم به جای استفاده از origin یا origin-when-cross از strict-origin و strict-origin-when-cross-origin استفاده نمایید. در این صورت جلوی نشت اطلاعات بر روی یک ارتباط غیر ایمن را تا حدودی گرفته‌اید. اگر هم اطلاعات حساسی در URL سایتتان ندارید می‌توانید از no-referrer-when-downgarde استفاده نمایید.

مشاهده تمامی ویژگی ها
ابراز مفید برای ساخت CSP

The security headers

We will explain the below security headers, and how to add them manually. When you need to know more, or are interested in more advanced security headers, visit this article.

HSTS – When this header is set on your domain, a browser will do all requests to your site over HTTPS from then on.
Upgrade-Insecure-Requests – This header is an additional method to force requests to your own domain over https://.
X-Content-Type-Options – This header will force the browser not to “guess” what kind of data is passed. If the extension is “.doc”, the browser should get a .doc file, not something else (a .exe).
X-XSS-Protection – Will stop pages from loading if a reflected cross-site scripting (XSS) attack is detected.
Expect-CT, Certificate Transparency – A Certificate Authority (the issuer of the SSL certificate) needs to log the certificates that are issued in a separate log, the CT framework., preventing fraud.
No Referrer When Downgrade header – Only sets a referrer when going from the same protocol and not when downgrading (HTTPS -> HTTP).

How to Check HTTP Security Headers for a Website

Now that, you have added HTTP Security headers to your website. You can test your configuration using the free Security Headers tool. Simply enter your website URL and click on the Scan button.

https://www.sslshopper.com

https://gf.dev/tests/7paltzu5z0b

ساتین