Cookies Continued...part 3

Now since we have a general idea of Cookies, it's time to reverse engineer them. But before we do this, we must first understand how to provide "a secure method of session management". In other words, how do we keep our cookie safe? Well, the first step is to make the data "hard-to guess" or unpredictable. In doing this, we are making it hard to forge the cookie which makes it harder to break into another user's session. To make it unpredictable, we have to create random values or cryptography.  Second step is to make it tamper resistance. Having a cookie with a parameter isAdmin and value "no" is not smart. It is extremely easy to temper with and change the "no" to  a "yes".  A better way of doing it is encrypting the  parameter and value.  Third step would to make sure the cookie does expire at a certain point. Make the cookie only exists in the time period that it should. Lastly, for important cookies, make sure to use the secure flag so transmission of the cookie can only occur in an encrypted channel.

If an application follows the above guidelines when generating cookies, it will be extremely difficult for hackers to temper with the cookies. Unfortunately, some cookies are not this safe and that is why reverse engineering can be done. The basic premise is that we get a handful of cookies from a website and look for patterns.  When collecting cookies, make sure the website is in the same state for all cookies collected. For example, if the first cookie collected was right after authentication, then the rest of the cookies of the sample as to be collected at the same time.  It is also important to note down the time when the cookie was collected. As stated in the last post, the time the cookie was created can be part of the cookie value.

When looking to reverse engineer a cookie, it is good to know the value of type or types. Many times, a cookie can hold numerous values of different types.  Below is an example of a cookie.

ID=5a0acfc7ffeb919:CR=1:TM=1120514521:LM=1120514521:S=j3am5KzC4v01ba3q

In the next post, we'll break down what each part of the cookie means.

Cookies Continued...pt2

So our first step is cookie collection. In here we're trying to figure out to answer some basic questions such as :

• "how many cookies does the application create?"
• The way I did this is by first clearing all the cookies in my browser, and then visiting the application. Then, I check the cookie list.  Doing this tells me about all the cookies created when accessing the application.

• "which parts of the application generates a cookie?"
• Go to different parts of the web application and check the browser to see if any cookies are created.

• "which parts of the application causes a modification of the cookie?".
• Same as above - when we're messing around with the application, see if the status of any of the cookies has changed.

Our next step is to analyze the cookie. For example, look at the session ID of multiple cookies. Are they just linearly made? Are they random? Does duplicates exists?  We can also examine the value of the cookie. Often times, developers make the mistake of storing actual sensitive data in the cookie. What their actually suppose to do is store a generic value and reference the real data using the generic value. Some developers store real data in cookies and just encode various methods like Hex, Base64, or MD5. What they fail to understand is that these strings can easily be decoded and the real data can be seen by unwanted eyes.

If  tokens are in fact encoded, they could contain multiple sets of data in one long string. For example, if the token is 32 bit string, the first 16 bits could represent something static like a username or IP address and the next 16 bits could by dynamic. If this second 16 bit string changes incrementally, this could represent a date or time for each access.  One way to verify this is access the site at the same time using different browsers and using the same username/IP address. In that case, the cookies from each browser should be almost the same. 

Session Management Testing & Cookies

Session Management is how web application maintains and controls all user-interaction within the application. From authentication and logging off  - sessions are used to control all interactions between clients & servers. Client-server sessions are identified through a unique token often referred to as a Session ID or Cookie. Just like everything else on the web, sessions can be exploited and one such way is by using the created session by an authorized to our advantage.

If session IDs/Cookies are created in a predictable way, we can easily duplicate a valid cookies to "hijack the sessions of legitimate users".

So, first why are cookies used? Their used because they are an easy way to keep track of a client through multiple requests. It's how companies keep details about a certain client.  Cookies will last until they expire or they are destroyed (by server or client). OWASP describes the main advantages of as giving "a state to a stateless protocol like HTTP".  They store vital information for websites and thus can be a target for hackers.  The list below describes the patter for "cookie hacking".

1. Collect information about the cookie. Make sure to get a good sample

2. Perform cookie reverse engineering - in other words, try to figure out the cookie generation algorithm.

3. Manipulate cookies - once we figure out the algorithm, we can try to forge a valid cookie to attack the server.

Since the topic of Cookies and sessions is broad, I want to limit the size of my posts - I will continue on in the next post.

Authentication Testing - Testing for Bypassing Authentication Schema

Although for most applications, authentication leads to access -  there are certain cases were an intruder can just bypass the login page and directly access the "private" information.   This can be done through four different ways. Direct Page Request, Parameter Modification, Session ID Prediction, & SQL Injection.  Direct page requests occurs when the code checks for authentication only on the login page. Every other page in the administrator's does not check user credentials and thus can be accessed by just putting in the URL in the browser.  The second way to bypass authentication is through a modification of the URL parameter.  Some times, web apps uses fixed value parameters to signify a successful authentication.  So for example, we can easily change http://domain.com/admin/index.php?authentication=no  to authentication=yes. Then after resubmitting the data to the server, we should be in the admin panel.  The third way of bypassing authentication is through predicting an admin's session ID. Some web apps uses Session ID's as a means to manage authentication. The problem with this is that sometimes these session ID's just increases linearly which means it is easy to predict. We can get the correct session ID by using a bruteforce attack. Lastly, SQL Injection is another way of bypassing authentication. Due to the popularity of the topic, this will be covered in a future post.