Tag Archives: web security

WebSecurity: Importance of HTTP Headers & In-Depth Security

There is a number of HTTP response headers that you should use to increase the security of your web application. They are referred to as HTTP security headers.

Once implemented, HTTP security headers restrict modern browsers from running into easily preventable vulnerabilities. They also provide yet another, additional layer of security by helping to mitigate security vulnerabilities and prevent attacks (like XSSClickjacking, information leakage, etc.). But it is important to mention that HTTP security headers are not intended to replace proper, secure code.

HTTP STRICT TRANSPORT SECURITY

HTTP Strict Transport Security (HSTS) is a mechanism that prevents user-agents (a browser or any kind of program designed for communication with a particular server) from browsing a website via an unencrypted connection in case an encrypted connection can be established, and only using a trusted certificate.

If the request is communicated through an unencrypted channel, it can be captured and tampered with by an attacker. The attacker then can steal or modify any information transmitted between the client and the server or redirect the user to a phishing website. So, the first goal of HSTS is to ensure traffic is encrypted, so it instructs the browser to always use HTTPS instead of HTTP.

Usually, browsers allow users to ignore TLS errors and continue browsing potentially insecure websites. With HSTS enabled, the user will be unable to skip the browser warning and continue. The second important goal of HSTS is to make sure that the traffic is encrypted using a trusted and valid certificate.

When HSTS response header signals the browser that the certain domain must be requested only using HTTPS, the browser saves this domain to the HSTS list and keeps it there for the timeframe specified in max-age directive of the Strict-Transport-Security header.

There are two cases when HSTS doesn’t provide proper protection:

  • when the user hasn’t browsed to the website before and is making his very first request to this website over HTTP,
  • when existing HSTS data has already expired.

X-XSS-PROTECTION

Some modern browsers have built-in XSS protection mechanisms that can be used as an additional layer of security against Reflected XSS. The main problem with that is that all of the browsers implement built-in XSS filtering differently, so to add more control to the process and make sure that the loading of a page with the malicious content will be blocked, the X-XSS-Protection header is needed.

X-XSS-Protection header is an optional HTTP header that performs XSS filtering by defining the anti-XSS mechanism behavior: from sanitizing the page by blocking injected Javascript to preventing page rendering and reporting the violation.

By default, browsers that support XSS filtering have it enabled. Though it can be disabled, this is considered a bad practice; often, if an application requires XSS protection to be disabled in order to function properly, it is an indication that the application is quite likely vulnerable to XSS.

Please note that only using the X-XSS-Protection header will not protect your application from XSS, but this header will make an important input in your defense-in-depth strategy and make it more robust.

CONTENT-SECURITY-POLICY: X-FRAME-OPTIONS

X-Frame-Options header a defines if the webpage can be rendered inside an <iframe><frame><applet><embed> or <object> tags. Depending on the directive, this header either specifies the list of domains that can embed the webpage, or allows the page to be embedded only inside pages of the same origin, or totally prohibits embedding of a webpage.

The main purpose of the X-Frame-Options header is to protect against ClickjackingClickjacking is an attack when the vulnerable page is loaded in a frame inside the malicious page, and the users are tricked into interaction with buttons and other clickable UI elements (e.g. unknowingly clicking “likes” or downloading malicious files) of a vulnerable page without their knowledge.

Sample Code Snippet

HTTP/1.1 200 OK
Date: Thu, 21 Mar 2019 09:05:07 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 0
Connection: close
Cache-Control: max-age=600
Content-Security-Policy: script-src 'self' *.followcybersecurity.com 'unsafe-inline' 'unsafe-eval'  www.google-analytics.com; img-src 'self' *.followcybersecurity.com
Expires: Thu, 21 Mar 2019 09:15:06 GMT
Location: https://followcybersecurity.com
strict-transport-security: max-age=31536000
Vary: Accept-Language, Accept-Encoding
x-content-type-options: nosniff
X-Frame-Options: DENY
X-Robots-Tag: noodp
x-xss-protection: 1; mode=block  

Web Security: Importance of Strict-Transport-Security in any website

Abstract

The HTTP Strict-Transport-Security response header (often abbreviated as HSTS) lets a web site tell browsers that it should only be accessed using HTTPS, instead of using HTTP.

The HTTP Strict Transport Security header informs the browser that it should never load a site using HTTP and should automatically convert all attempts to access the site using HTTP to HTTPS requests instead.

The Strict-Transport-Security header is ignored by the browser when your site is accessed using HTTP; this is because an attacker may intercept HTTP connections and inject the header or remove it. When your site is accessed over HTTPS with no certificate errors, the browser knows your site is HTTPS capable and will honor the Strict-Transport-Security header.

Read more in

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security

Web Security: WHICH SECURITY RISKS DO CORS IMPLY?

What is CORS?

The first step in understanding CORS is knowing how some security features of web browsers work. By default, web browsers do not allow AJAX requests to servers other than the site you’re visiting. This is called the same-origin policy and it’s an important part of the web security model. In fact, the same-origin policy is deployed to over a billion devices all over the world and has proven to have a solid track record in terms of exploitation.

A Security Risk

Now imagine your mail-sending API is in api.yourwebsite.com. This is where it gets a little trickier because the same-origin policy will block the AJAX request. You want to enable AJAX requests from yourwebsite.com and one way to do that is using CORS.

In your mail-sending API, api.yourwebsite.com, you decided to let everyone access your API instead of only yourwebsite.com. Is this harmful?

Well, it depends on how you implemented the authentication for mail sending. If you are using authentication based on session cookies, you probably shouldn’t allow CORS requests by everyone. A malicious website can issue e-mail sending requests to api.yoursebsite.com via an AJAX request without the specific permission of your user.

If the user has valid session cookies in their browser, they will be used to authenticate on api.yoursebsite.com and that would lead to unwanted e-mail sending.

Read more in

https://mobilejazz.com/blog/which-security-risks-do-cors-imply/

Web Security: Chrome cookies & security updates.

Google to kill third-party Chrome cookies in two years

Google doesn’t want to block third-party cookies in Chrome right now. It has promised to make them obsolete later, though. Wait – what?

The search engine giant gave us the latest update this week in the journey towards what it says will be a more private, equitable web. It announced this initiative, known as the Privacy Sandbox, in August 2019. It wants to make the web more private for users, it said.

The discussion about online ads and privacy revolves around cookies because they’re what support many predatory advertising models today. It works like this: you visit a website and it puts a small file on your hard drive. This cookie contains information about the session – when you visited, what you looked at, what IP address you came from, and so on.

Some companies use these purely to remember you when you go back so that you don’t have to sign in again. Those are first-party cookies, and they’re a great way to make the web more convenient.

Google Chrome to start blocking downloads served via HTTP

Google has announced a timetable for phasing out insecure file downloads in the Chrome browser, starting with desktop version 81 due out next month. Known in jargon as ‘mixed content downloads’, these are files such as software executables, documents and media files offered from secure HTTPS websites over insecure HTTP connections.

This is a worry because a user seeing the HTTPS padlock on a site visited using Chrome might assume that any downloads it offers are also secure (HTTP sites offering downloads are already marked ‘not secure’). Read more in

References

How to secure your web content?

In any web application security, apart from user information security like user credentials, personal information and payment details etc. It must very important to take care user content whether it is user specific personalized sensitive content or content which is being shared with third-party services.

Following are the must-read articles to put some level of security in web content:

Properly configuring server MIME types

There are several ways incorrect MIME types can cause potential security problems with your site. This article explains some of those and shows how to configure your server to serve files with the correct MIME types.

HTTP Strict Transport Security

The Strict-Transport-Security:HTTP header lets a website specify that it may only be accessed using HTTPS.

HTTP access control

The Cross-Origin Resource Sharing standard provides a way to specify what content may be loaded from other domains. You can use this to prevent your site from being used improperly; in addition, you can use it to establish resources that other sites are expressly permitted to use.

Content Security Policy

An added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft to site defacement or distribution of malware. Code is executed by the victims and lets the attackers bypass access controls and impersonate users. According to the Open Web Application Security Project, XSS was the seventh most common Web app vulnerability in 2017.

The X-Frame-Options response header

The X-Frame-Options: HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame>. Sites can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites.

Securing Your Site using Htaccess

It is the best way to secure your site using the .htaccess file. You can blacklist IPs, restrict access to certain areas of website, protect different files, protect against image hotlinking, and a lot more.