Web App for newbi PART 2

XSS (Cross site Scripting)
The first attack I intend to try is XSS. I look for both stored and reflected XSS. The way I like to test for XSS is using the tag I will place this into any form field and if there is a possible XSS it will break the page and turn the HTML into text. This means when you view the page instead of seeing a GUI you see the HTML. There are also lots of other ways to test for XSS. The paces you want to test XSS are post variables, get, cookies variables, and HTTP headers. XSS is mainly used for phishing attacks as well as stealing cookies and a cool tool to check out its beef project. A lot of site setup filtering to prevent this by replacing any dangerous characters, there are ways to get pass these filters depending on how they are setup. There are also lots of ways to bypass filters using encoding or different types of tags like HTML5 tags but this post as well as DOM based XSS attacks.

Example Get XSS with URL encoding:

Additional Resources:

Broken Authentication
A great way to test broken authentication is to find out the URL for something you should only have access to if you were logged in. If you can then go straight to this page without signing in, this indicates broken authentication. Another problem with authentication is if you can guess the session ID you could potentially gain access by guessing or brute forcing the session ID.

Additional Resources:

SQL Injections
SQL Injections is a massive subject in fact there are dedicated books on it. When testing the application I want to try to get, post, headers and cookies fields. If it’s running MYSQL I tend to just use a; or ‘to break the code, then I can build on this or use SQLMAP to try to exploit the database. This does depend on what database is being used. There are also two types of injection error based and blind, Error based is easy to exploit where blind does take a bit of skill. Error bases is easy to identify as you get some sort of MySQL error relating to the code you have now broken by placing a ‘into the query.

We have a box that allows us to supply a name we are going to supply a ‘ this will then be inserted into the query below.
Select name from table where name = “$name”;
What we do is break this query by supplying the ‘so it becomes Select name from the table where name = “’”; this should cause an error as this is not valid syntax.

This is a really basic example of SQL injections

Additional Resources:

Storing Password
If we can we want to try to identify how the passwords or credit cards are being stored in the database. The simplest way to do this is if the application has reset password you can use this and see if you get your password back in plain text. If you do get your passwords in plain text this means they are being stored in plain text or they are using an encryption that is easy to reverse. This is more common than you think it should be. In fact a major retailer in the UK has just admitted they are storing passwords in plain text.

Additional Resources:

I think every site I have tested is vulnerable to this attack method. The simplest way to explain this is overlaying a website on top of another website. This happens a lot on Facebook where users think they are clicking like but they really clicking the box behind that is sending a message to all of your friends.

Additional Resources:

I have never really used brute forcing techniques when testing web applications. I always got told that if you need to brute force then you missed something. If I come across a login page I will maybe try a small amount of brute forcing like admin:admin, admin:password and administrator:sitename But no more than say around ten attempts. I also want to see if I get locked out at all, to see if I can’t login after a certain amount of times, as this would be an issue in some situations but most clients accept this as a small risk and don’t care about it.
You can use tools like Burpsuit for brute forcing as well as hydra most browser also have plugins that you can use to try and get access to the application.

Additional Resources:

When testing a website we want to make sure that all sensitive data is sent using SSL. And it’s using a good chipher so anything above 128 would do. We also want to make sure that the certificate has not expired or there are any other issue with it.

Additional Resources:

Sites that allow file uploads sometimes do not use filtering on the file type, this means that you can upload picture.php that contains a PHP backdoor. You can then view this page by going to www.exmaplesite.com/picture.php from here depending on your back door you can run commands on the box like cat /etc/shadow. There are many web backdoors contained in backtrack as well as a great site called pentestmonkey.co.uk. Another trick you can try is to rename the file, if the site has some sort of filtering in place, for example picture.jpg.php this is because most scripts will search the line for a .jpg extension. It will say does this line contact a .jpg and the answer is yes so this would let you upload the file and bypass any filter as if we tried to upload picture.php it would not find the .jpg and not allow us to upload the file.

CSRF Cross site request forgery
This is a bit of a tricky one to explain but let’s see if we can explain it as simple as possible. CSRF is when you are logged into one site for example Amazon and then you are using another website called eveilhcker.com. You click a button on this site that you think will register you to the site and it does but at the same time it makes a request to Amazon on your behalf telling Amazon that you want to buy a book, using the one click buy feature. So what’s happened now is that you’re registered to evilhacker.com but you also brought a book that you are totally unaware of as it’s all happened in the background.

The last stage of the test that I like to run is Nessus this just helps me to identify any other issues that I may have missed. Once this has been done I try and confirm any issues it has found before reporting them to the client.

When we provide the report to the customer we want to make sure that all issues have a really good explanation on how to fix the problems. We also want to make some general recommendations, like making sure CMS are updated and you force the user to use strong passwords.

Other Attacks
There are lots of other attack vectors for application including session fixation, local file includes, remote file includes and Ajax attack to name a few. As this is not a step by step guide if you want to learn more about these types of attack I would recommend web applications the best book I think you can get is the Web Applications Hacker Hand book. If you really interested in learning more about web apps, a course I really recommend is elearnsecurity and their labs on web applications. The people behind the book above also offer a web course but this cost around $7 per hour.

Another really good resource is the OWASP web application security testing cheat sheet


Leave a Reply