Hardening HTTP Security Headers via .htaccess
Before discussing about Hardening Security HTTP Headers via .htaccess, I will give a brief explanation of the Content Security Policy.
What is The Content Security Policy?
Content Security Policy itself is one component of the hardening http security headers. And now I will discuss what needs to be set on http headers so the server more secure. I will try in wordpress on Apache Web Server. In this tutorial I will write any functions as well as how to apply via .htaccess.
- Content Security Policy (CSP)
CSP helps us to prevent the exploitation of the type of script execution xss and some other kinds of ignorant external js overlay etc. For application, adjust to your Website. by default CSP code like this:
But encountered many problems such as Tracking Analytics, Webmasters, Google Index, Bing, etc.
code ‘unsafe-inline’ ‘unsafe-eval’ let plugins are installed by giving permission to index your website, for more detail, please refer to the CSP or Developers Google, because each different website application.
- HTTP Strict Transport Security
The website has always been very dependent on 301/302 redirect to take the user from browsing over HTTP to HTTPS. By default to HTTP browser when you type an address like asepms.com. HSTS allows you to tell the browser that you always want users to connect using HTTPS instead of HTTP.
This is useful each bookmark, This ensures that the connection can not build through insecure HTTP connections that could be vulnerable to attack, link or address types of users will be forced to use HTTPS, even if they specify HTTP. For application like this:
The X-Frame-Options header (RFC), or XFO, protecting your visitors against clickjacking attacks. An attacker can load an iframe on their site and set up your site as a source, for example: <iframe src=”https://www.asepms.com”></iframe>
Using some nasty CSS, they can hide in the background of your site and create multiple layers of searching for the original. When your visitors click on what they think is a malicious link, they are actually clicking on a link on a Web site in the background. That probably does not seem so bad until we realized that the browser will execute the request in the context of the user, which can include those who are logged in and authenticated to your site, the threat is hidden right in front of you.
XSS Protection already supported defult for modern browsers. But if you add this rule to the http-headers, then the older browser will be forced to block the attacks xss. This header is used to configure the built in reflective XSS protection found in Internet Explorer, Chrome and Safari (Webkit).
This tweaking may be very useful for sites online shopping and internet banking. public-key-pin tell the web browser to link public keys with specific web server to prevent MITM attacks are dangerous. To know your public key pin, create your HPKP hash here, and analyse your HPKP here.
Then set to .htaccess like this:
This prevents Internet Explorer and Google Chrome do the sniffing of the types of files that we access. This reduces the risk of users upload unauthorized files to our server. Such as manipulating the file name example: (image.jpg), which was granted and executed as a backdoor or SQL Injection normally. Applying .htaccess:
Spec for Policy Steering has been a W3C Candidate Recommendation since January 26, 2017 and can be found here but going to cover everything in this blog to save the trouble. Steering policies issued through HTTP response header with the same name, Steering-policy.
The empty string
An empty string value in the header Referring policy indicates that the site does not want to establish a Steering Policy here and browser must retreat to a Policy Steering established through other mechanisms elsewhere. This can include HTML <meta> element, attribute referrerpolicy on elements such as <a> and <link> or rel = “noreferrer” keywords in the tag <a> well.
Issuing this policy effectively will have an impact, but only confirms that the site has been deliberately omitted it. You can even set your Steering Policy through the header Content Security Policy, if you like, for application like this:
This will not allow information to be sent when the scheme downgrade occurs (user navigates from HTTPS to HTTP).
After all it gives a chance, you can do testing on how secure the response http-headers you through one of the following links:
As we know, do hardening of the servers that we manage is important. It is very helpful to prevent attacks from those who are not responsible. Okay so brief tutorial this time, if there is asked please comment or join the forum asepms.com, maybe useful.
Source by Scotthelme.co.uk
Latest posts by Asep Ulchre (see all)
- Hardening HTTP Security Headers via .htaccess - February 24, 2017
- Troubleshooting Load Analytics on Content Security Policy via .htaccess - February 17, 2017
- How to Create a Network LAN (Local Area Network) on Windows - February 16, 2017