Vulnerability Wiki

1. Vulnerability Name

Cookie without HttpOnly


Vulnerability Description

This HTTPOnly attribute is used to help prevent attacks such as cross-site scripting, since it does not allow the cookie to be accessed via a client side script such as JavaScript. Note that not all browsers support this functionality. Cookies with HTTPOnly attribute not set: If the HTTP-Only attribute is not set, then the cookie can be accessed and manipulated in the script. The sensitive information contained in the cookie can be sent to a hacker's computer or Web site with script.


Vulnerability Solution

To avoid access and manipulation of cookies in the script, the HTTPOnly attribute should be set for the cookie. A server could help mitigate this issue by setting the HTTPOnly flag on a cookie it creates, indicating the cookie should not be accessible on the client. If a browser that supports HttpOnly detects a cookie containing the HttpOnly flag, and client side script code attempts to read the cookie, the browser returns an empty string as the result. This causes the attack to fail by preventing the malicious (usually XSS) code from sending the data to an attacker's website.


2. Vulnerability Name

Click-Jacking Vulnerability


Vulnerability Description

Clickjacking, also known as a "UI redress attack", is when an attacker uses multiple transparent or opaque layers to trick a user into clicking on a button or link on another page when they were intending to click on the the top level page. Thus, the attacker is "hijacking" clicks meant for their page and routing them to other another page, most likely owned by another application, domain, or both. Using a similar technique, keystrokes can also be hijacked. With a carefully crafted combination of stylesheets, iframes, and text boxes, a user can be led to believe they are typing in the password to their email or bank account, but are instead typing into an invisible frame controlled by the attacker.


Vulnerability Solution

There are two main ways to prevent clickjacking: <ol> <li>Sending the proper browser response headers that instruct the browser to not allow framing from other domains</li> <li>Employing defensive code in the UI to ensure that the current frame is the most top level window</li> </ol> For more information on Clickjacking defense, please see the the <a href='https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet' target='_blank'>Clickjacking Defense Cheat Sheet</a>.


3. Vulnerability Name

Missing cache control for HTTPS content


Vulnerability Description

<strong><u>How can the browser cache be used in attacks?</u></strong> The browser has a capability to temporarily store some of the pages browsed. These cached files are stored in a folder, like the Temporary Internet Files folder in the case of Internet Explorer. When we ask for these pages again, the browser displays them from its cache. This is much faster than downloading the page from the server. Let's consider the particular scenario where a user has logged in to an application with username and password. The user browses the different pages which contain sensitive information. Let's suppose a page with the user's credit card information gets cached in the browser and the user logs out of the application. Now suppose the attackers access the same machine and searches through the Temporary Internet Files, they will get the credit card details. The attackers do not need to know the username and password of the user to steal the information.


Vulnerability Solution

The <a href='http://en.wikipedia.org/wiki/List_of_HTTP_header_fields#Responses' target='_blank'>Response Headers</a> sent from the server has some <a href='http://condor.depaul.edu/dmumaugh/readings/handouts/SE435/HTTP/node24.html' target='_blank'>Cache Control Directives</a> that can be set from your code. These directives control the caching of content on any cache. The directives to be set are Cache-Control : no-cache, no-store and Expires: 0. But since legacy HTTP 1.0 servers do not support the Cache-Control headers, universally, Pragma: no-cache header should be used, too. The no-cache directive in a response indicates that the response must not be used to serve a subsequent request i.e. the cache must not display a response that has this directive set in the header but must let the server serve the request. The no-cache directive can include some field names; in which case the response can be shown from the cache except for the field names specified which should be served from the server. The no-store directive applies to the entire message and indicates that the cache must not store any part of the response or any request that asked for it. Learn more about Caches <a href='http://www.mnot.net/cache_docs/' target='_blank'>here</a>.