In light of COVID-19 precaution measures, we remind that all ImmuniWeb products can be easily configured and safely paid online without any human contact or paperwork.

Total Tests:
Stay in Touch

Weekly newsletter on AI, Application Security & Cybercrime


Your data will stay confidential Private and Confidential

Killing XSS and CSRF on web server layer

Tuesday, May 17, 2016 By Read Time: 5 min.

Existing and new web security technologies based on actively developed RFCs propose new approaches to common web vulnerabilities remediation.


Introduction

Vulnerable web applications have led to numerous data breaches, including such famous ones as Panama’s Mossack Fonseca, Ashley Madison or the recent breach of QNB bank compromised via SQL injection vulnerability. Many modern business-critical web applications are still vulnerable to SQL injections, despite that this class of vulnerabilities was discovered more than a decade ago. Cross Site Scripting (XSS) vulnerabilities can also be easily found on almost every large website within a few minutes, not even speaking about more complicated CSRF flaws.

Currently we are observing a small shift of web security technologies to user browser and web server layers. Probably, cybersecurity industry has realized that web applications will always remain the weakest link and decided to remediate the risks with a different approach.

In this blog post we will briefly revise existing and new techniques aimed to prevent some exploitation vectors of such vulnerabilities as Cross Site Scripting and Cross Site Request Forgery.


Http-only cookie flag

First implemented in 2002 by Microsoft Internet Explorer developers for IE 6 SP1, the Http-only flag prevents cookie from being accessed via a client-side JavaScript. Currently supported by all modern browsers, the flag prevents classic XSS attack vectors aimed to steal your cookies.

In addition to Http-only flag, secure coding best practices also suggest to bind cookies to client’s IP address or some unique browser’s parameters to make them useless in case of theft.

However, it’s important to highlight that Http-cookies can only prevent cookie theft via XSS, but cannot protect vulnerable website users from other vectors of XSS, such as drive-by-download malware delivery or phishing.

Moreover, keep in mind that Http-only cookies can still be stolen if remote web server supports insecure HTTP TRACE or TRACK methods.


Secure cookie flag and Strict-Transport-Security HTTP header

When a web application is accessible both via HTTP and HTTPS protocols, an attacker may force logged-in victim to send an HTTP request to the website and intercept cookies with authentication or any other sensitive data (e.g. when using public Wi-Fi network).

The Secure flag will prevent browser from sending cookies to the web application via unencrypted HTTP protocol, making traffic interception quite useless. However, keep in mind that the Secure flag cannot prevent a great variety of MITM attack vectors that can lead to total compromise of victim’s device.

An alternative to the Secure cookie flag is the implementation of the Strict-Transport-Security HTTP header, forcing the browser to use the HTTPS protocol only.


Content-Security-Policy HTTP Header

HTTP headers sent by a web server or web application can prevent many exploitation vectors of XSS. The HTTP Content-Security-Policy header is one of them. If correctly configured, the header provides reliable protection against the vast majority of XSS attacks.

It is based on the standard called ‘Content Restrictions’ that was initially developed and proposed by Robert Hansen in 2004. Instead of versions, the standard has so-called levels: the most recent level is the third one, while the majority of browsers currently support the second one.

Content-Security-Policy header clearly defines from which locations (URLs) different type of external content such as scripts, fonts, images, CSSs or embed objects (e.g. Java applets, ActiveX, audio and video files) can be loaded on a web page. For example, it can restrict execution of JS located on a remote server, preventing inclusion of malicious JS code from a remote server.

The header can also be configured to restrict usage of all inline JavaScript, making all XSS attack vectors inefficient. However, such severe restriction will probably break around 80% of legitimate functionality of any modern website.

We shall also keep in mind that such vulnerabilities as CRLF injection can allow attackers to by-pass the security policy and execute arbitrary scripting code or load malicious remote content.


X-XSS-Protection and X-Frame-Options HTTP Headers

These two HTTP headers are pretty mature, but still efficient against some of the XSS attacks vectors and clickjacking.

The X-XSS-Protection header is currently supported by Internet Explorer, Chrome and Safari (WebKit). It prevents reflected XSS from being executed in the user browser. The filtering is implemented on the client side by either removing malicious scripting code from the page passed via HTTP GET parameters, or by completely blocking the page – depending on the header’s directive.

The X-Frame-Options header can restrict to load website content in iframes on remote websites, making more complicated some XSS attack vectors that require victim to stay on the vulnerable website (e.g. via invisible iframe). The header also prevents various types of clickjacking attacks.


SameSite Cookie Attribute (Flag)

The SameSite cookie attribute is one of the most recent techniques aimed to prevent CSRF attacks. Based on the RFC6265 draft, it indicates to browser that a cookie shall not be sent across different domains. Practically speaking this means that traditional exploitation vectors of classic CSRF will not work anymore.

The attribute can have two values: ‘lax’ and ‘strict’. If set to ‘lax’, cookie still may be sent across different domains but only via GET, HEAD, OPTIONS and TRACE methods, which are considered secure by the RFC draft. Such browser behavior assumes that no action (e.g. adding users or changing content) shall be implemented via these methods, and shall be performed via POST requests only. Therefore, in some cases attackers may still be able to exploit the CSRF (e.g. when a sensitive action is performed via HTTP GET request).

The ‘strict’ value goes further, and restricts sending cookie via any HTTP methods across domains, disabling almost all vectors of CSRF attacks. However, such configuration can also break many websites that have legitimate functionalities using third-party cookies.

Keep in mind that the SameSite attribute does not protect you against some exotic cases of CSRF, for example when a web application authentication is based only on HTTP Basic authentication. Or a pretty frequent case within large companies: a web application that does not require cookie-based authentication but is accessible only from a local network – in this case the SameSite attribute will not prevent CSRF attack neither.

Also, the SameSite flag does not protect against XSS attacks that can be used to bypass this CSRF restriction afterwards. This is why the above-mentioned Http-only and Secure flags remain very useful.

At the moment of this blog post release, the SameSite cookie attribute is not yet supported by any [stable release of] modern browsers, however Google Chrome shall enable its support in its next stable release. Firefox and Opera also promise to implement its support shortly.


__Secure- and __Host- cookies prefixes

Based on the very recent RFC6265 draft, cookie name prefixes limits the ways in which cookies may be abused.

The __Secure- prefix in cookie name instructs the browser to ignore cookie if Secure flag is not set. Honestly, at the moment we don’t see any practical usage of the __Secure- prefix.

The __Host- prefix is more sophisticated and requires cookie to:

  • Have Secure flag set
  • Have Path attribute set to “/”
  • Have empty “Domain” attribute

This can potentially reduce the scope of some attacks when a legitimate cookie can be set by an attacker. An example can be various subdomains that can alter cookies for the main domain. If one subdomain gets compromised or is somehow else is controlled by an attacker, it can be used to set malicious cookies for the main website domain. The __Host prefix can reliably prevent such attack scenarios.

Here are some examples of cookies that will not be processed by the browser (such cookie just won’t be saved) if cookie name starts with __Host- prefix:

Set-Cookie: __Host-SID=12345
Set-Cookie: __Host-SID=12345; Secure
Set-Cookie: __Host-SID=12345; Domain=example.com
Set-Cookie: __Host-SID=12345; Domain=example.com; Path=/
Set-Cookie: __Host-SID=12345; Secure; Domain=example.com; Path=/

And here is an example of a cookie that will be accepted and used by the browser:

Set-Cookie: __Host-SID=12345; Secure; Path=/

Both prefixes are currently supported by the stable version of Chrome browser. FireFox and others promise to enable this feature in the near future as well. Dropbox has already implemented this interesting feature to protect their users.


Testing web server security, HTTP headers and cookies

At High-Tech Bridge, in addition to our SSL server test, we provide free web server security test that you can use to test your web server, its HTTP headers and web application cookies for all of the above-mentioned security features and mechanisms. Enjoy & stay secure!


High-Tech Bridge Security Research Team regularly writes about web and mobile application security, privacy, Machine Learning and AI.

User Comments
Add Comment

View Products Ask a Question