Session hijacking at the application level focuses on gaining access to a host by obtaining legitimate session IDs from the victim. Essentially, a session ID is an identifier that is applied to a user’s session that allows the server or web resource to identify the “conversation” it is having with the client. So, for example, say that you’ve logged into a merchant site and are browsing the site for a book. With each page you browse to, the web server receives the request and forwards you to the next page without requiring you to repeatedly log in. The server is able to do this because it has identified your session ID and assumes it knows who you are at this point. Let’s take a look at session IDs in greater depth to gain a better understanding of the part they play in hijacking applications.
Session IDs, for our purposes, come in three flavors:
Embedded in a URL A web app uses the GET request to follow links embedded in a web page. An attacker can easily browse through the victim’s browsing history and many times gain access by simply entering the URL of a previously browsed web app.
Embedded as a Hidden Field Forms for inputting user data many times include a hidden field that is used for sending a client’s session ID. The ID is sent via the HTTP POST command when the information is submitted.
Cookies Cookies have been a potential avenue of exploit for quite some time, and they have recently taken the rap for privacy issues such as tracking shopping activity or storing users’ sensitive data. An attacker can obtain session information from cookies residing on the victim machine.