Web Security Vulnerabilities On Clickjacking And Security HTTP Headers And Information Leakage

This article demonstrates common security concerns and vulnerabilities of an application. Along with this, we will discuss some remediation techniques. Some of the common concerns including:

1. Clickjacking/UI Redress
2. Missing Security Related HTTP Headers
3. Information Leakage

Clickjacking/UI Redress

The affected internet-facing web applications contain some pages which would allow themselves to be nested in an untrusted external frame. This leaves the application vulnerable to an attack known as “clickjacking”.

UI Redress or clickjacking is a vulnerability class that permits a malicious user the ability to execute an action on a target website. The malicious user can load a target website within a transparent iFrame, over the top of a malicious website within the same browser session that the authenticated application is running in. The iFrame would purport to be executing an action on what appeared to be a completely different website but would in fact be executing an action on the target website. It is capable of doing this by aligning a button or other such clickable item with that of one that exists on the overlaid target website. In this way, the authenticated user can be duped into executing an action unwittingly. This technique allows the attacker to circumvent defenses against cross-site request forgery and may result in unauthorized actions.

Remediation Technique 

The use X-Frame-Options Deny/Same Origin Header values is recommended across the application. In addition, frame-ancestors directives can be used in a Content-Security-Policy HTTP response header to indicate whether or not a browser should be allowed to render a page. Examples include:

• Content-Security-Policy: frame-ancestors 'none';
• This prevents any domain from framing the content. This setting is recommended unless a specific need has been identified for framing.
• Content-Security-Policy: frame-ancestors 'self';
• This only allows the current site to frame the content.
• Content-Security-Policy: frame-ancestors 'self' '\*.somesite.com' 'https://myfriend.site.com';

This allows the current site, as well as any page on somesite.com (using any protocol), and only the page myfriend.site.com, using HTTPS only on the default port (443/TCP) Additional protection can be gained through the use of a unique nonce cookie value that is required to be validated server-side prior to any dangerous or sensitive action being performed. If support for a legacy browser is required, frame-busting code should be implemented in application pages that perform vital actions. In this instance, we would also recommend confirmation pages be implemented to ensure users are made aware of any potential changes.

Missing Security Related HTTP Headers

HTTP response headers which could be used to enhance the security posture of the web application were not used.

The HTTP protocol specifies several HTTP headers that can enable client-side browser protections. These protections include defenses against cross-site scripting, SSL downgrade, and type confusion attacks. These headers do not necessarily protect the server, rather, they enable additional protections for the web browser by instructing it to handle the HTTP session in a certain manner. This helps to improve the handling of client data and session management. The missing security-related HTTP headers are,

• The HTTP Strict-Transport-Security (HSTS) HTTP header is used to instruct the browser to only access a web application over a secure connection and for how long to remember this restriction (twelve months is recommended), thereby forcing continued use of a secure connection. Web browsers will usually only honors this header when delivered over a trusted, secure connection.
• The X-Content-Type-Options HTTP header can be used to prevent web browsers from using content sniffing to discover a file’s MIME type. This header, when set, can help protect against cross-site scripting attacks.
• The Content-Security-Policy (CSP) HTTP header is a mechanism for controlling which external sites can host sources of executable scripts used by a web application and how these resources may behave. A CSP compatible browser will then only execute scripts received from those allowed listed domains, ignoring all other scripts including inline scripts and event-handling HTML attributes.

Using this HTTP header can provide defense in depth from XSS, content injection, and session riding attacks, but any implementation requires a degree of planning to minimize conflicts between policy and actual application behavior.

Remediation Technique

The highlighted security-related HTTP headers should be reviewed and, if deemed appropriate, included in all responses sent by the web application. The response HTTP headers could be set at either the application or web server level however care should be taken as some of the headers could limit application functionality. Ideally, all changes made should be implemented in a test environment before being deployed to production.

Information Leakage

Sometimes applications were found to leak server software information and version number via its HTTP headers.

Often when a connection is made to an application listening on a network port, a banner or an HTTP header can be revealed. These banners can present information such as the vendor name, application name, or version number to the connecting client. Occasionally the banner can contain other information including the server time, network interfaces, authentication types, and hostnames. A malicious user can use the information gathered from banners and HTTP headers to specifically target exploits against services and rule out other attacks which are not likely to produce an outcome. This may increase the likelihood of success and minimize the chance of detection by intrusion detection devices. It could also reduce the tell-tale signs of an attack by reducing the “noise” on event logs. Also, information leakage is often seen as an indication that a service has not been fully hardened which may generate unwanted attention. This is of particular concern for Internet-facing services.

Remediation Technique

Service banners, error/default pages, and HTTP headers should be removed or modified so that they do not leak the server type and version number in the information presented to an anonymous client.

In the next article, we will discuss a couple of more security issues like Log out Does Not Invalidate Session, Vulnerable SSL/TLS Protocols, Cookie without HttpOnly Flag Set, etc.

Happy Reading!