Final Video for Directed Study

So, I have been working on a simple guide/tutorial video on brute forcing.
It's my first time making a video and I think it turned out decently well.  Camtasia trial was used in the making of the video.

Cross Site Scripting (XSS)

 The whole idea behind XSS is that a hacker can inject client-side code into a website and when the website is viewed by other users - the code executes and harms the innocent users.  As you can guess, the main reason this type of attack occurs is due to the lack of data validation. XSS attacks can be broken down into 2 subgroups: Stored & Reflected XSS.  Stored XSS is when the malicious code is permanently stored in the website so either in the database, the actual site or  logs.  Reflected XSS relies on "tricking" the user into going to a specific "trusted" website where the malicious code could exist in error messages or even search results.

 The pie graph above tells us that XSS is #2 behind SQL Injection in terms how sites are hacked. 

note: Due to projects & presentations, I am not able to post much - however, starting next week, I will try to post a bit more about XSS & SQL Injection.

Data Validation Testing

OWASP believes the most common type of security weaknesses comes from failing to validate client input. This failure causes XSS issues, SQL Injection, interpreter injection, locale/Unicode attacks, file system attacks, and buffer overflows.  In fact, Michael Howard - the author of Writing Secure Code - once stated that "all input is evil".  Usually, the larger an application becomes, the harder it becomes to enforce validation.

I decided to do some further research on data validation and ended up reading a small article from Smashing Magazine.  This article talks about validating user submitted web data to make sure it is the correct format. Basically, Data can be either validated on the client or on the server and there pros and cons for both.  Applications validating data on the server-side uses a strong server-side language instead of a client language like JavaScript.  So, even if the client has disabled JavaScript on their browser, the data will still be validated. The disadvantage of server side validation is that it takes longer and if there are too many validations being conducted - it might bring your server to a crawl.  Client-side validation should be done if you want a "more responsive [and] visually rich validation".  Basically, the validation can take place before the form is even submitted and thus users get immediate feedback on whether the data is valid or not.  The main disadvantage is that since we're using JavaScript - a client can easily disable it and no validation will take place which means there will be incorrect data in the database. 

Session Management - CSRF Attacks

I decided to skip some of the sections about cookies and directly go to the CSRF attacks simply because I have no previous experience with these attacks and would like to know more about them. OWASP Defines these attacks as ones "which forces an end user to execute unwanted action on a web application in which he/she is currently authenticated". So basically, we trick the admin into executing harmful code. The concern with this exploit is that often times the admin does not even know he or she is being tricked into executing code.  In fact, even going to a simple and relatively safe website can cause the code to execute.  How does this work?

Let's a you get an e-mail telling you to visit a website. The website has the following code:

<img src=”https://domain.com/picture.gif” width=”0” height=”0”>

Seems harmless right?  Well, domain.com/picture.gif can easily be redirected to http://baddomain.com/badCode.

How do web prevent this from happening?

OASP Recommends the following actions.

• Logoff as soon as your done administering.

• Don't allow your browser to save usernames & passwords

• Do not use the same browser to access sensitive information as you use to surf freely on the internet.      

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.