افزایش امنیت سایت با کدهای header در htaccess.
این هدر ها اکثر در وب سرور قابل تنظیم هستند . من توی این پست به وب سرور apache و ngnix اشاره خواهم کرد. امیدوارد که برای شما هم مفید باشد.
افزایش امنیت سایت با htaccess.
فهرست مطالب
۱- 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 استفاده نمایید.
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
https://www.sslshopper.com
https://gf.dev/tests/7paltzu5z0b
ساتین
سلام من این کدها رو اعمال کردم ولی بازم قسمت سلامت سایت این ارور ها رو نمایش میده مشکلش از چیه