Dedicated to all those services opened to browsers and the backend servers that support them.
Jamie.R wrote:This guide is written with newbie’s in mind to show them some of the basic concepts when testing web applications and trying to bring them up to speed on testing web applications. It’s not designed to be a one stop solution but a way to explain some of the basic information and give them materials to go and find out more for themselves.
In order to test web applications there are three tools that I use every single time. I use Firefox as my testing browser with foxy proxy plugin, Burp suit as my proxy and Google chrome for searching browsers, as I don’t want any Google searches affecting what’s in burp suit as the client may wish to see the burp suit logs.
Starting the test
Once I have good idea about the site I start by looking for default pages. For example if it’s a contents management site like Word press, Drupal or any other popular site, I tend to download the files and quickly set it up in a Lamp, WAMP or MAMP environment this way I can see what the default settings are as well as how the files are structured. This gives me a good idea of where to look in the application I am testing. Can I access an admin page? Or is there a backup of the default admin login detail? This all needs to be investigated to see what you can and cannot access and help map the application.
If the application is not using a CMS then I start by trying to access common files like robots.txt and then try to view any pages listed in that. If there are not any robots files, I then try default pages like admin.php, account.php so on. At this point you could use the spider feature in burp suit to try and get a much better idea of the application or use Dirbuster to try brute force on any hidden directories.
Once this has all been done you should have a really good understanding of the application. What it does, how it was build and maybe even some small issues to report like internal path, information disclosure etc. Having a good idea of how the application was built, this is an essential to understand as if you trying to exploit an SQL injection. If you know the developers have followed a certain naming pattern, you can take an educated guess they have done the same in their database this will make exploiting it easier if you find SQL injections on the site.
Starting the attack
We have a really good understanding of the site and the inner workings and so it’s time to start finding issues with the site.
If the website has a login page then I first create an account, during this process I see if I can use a weak password like the character ‘A’. If I can then this is an issue and would report it to the client as they should be using at least 9-20 characters with a mixture of upper, lower, numbers and symbols for the password. After I have registered with the site I attempt to login to the site looking for any errors messages. I want to make sure that the errors are not given any information away like “This passwords does not match the username” As an attacker this then tells me that I have a valid username so I can enumerate user.
This is where you can inject into the page; you can find this with an error message, which is the most common place, just like the example below. The reason this is an issue is it lets anyone write anything on your site so it’s a great tool to use with social engineer. We could write a message encode it then send it to a customer, they would then ring the number and we could try to get account information from them.
Example Error injection
http://testsite.com/page/sign-in?error=Please call tech support 0800 000 000
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 <plaintext> 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. You can also use <script>alert (“XSS”) </script> 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. An example of this would be if a site was using a script to search the input data and only once you have done this then you could try <script><script >alert (“XSS”) </script</script> What would happen here is the script would search for <script> tags but as it only runs once it would remove the first <script> tags leaving the second. 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:
http://testsite.com/page/sign-in?error= ... /script%3E
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.
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
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.
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.
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.
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.
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 http://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.
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
I hope people fine this useful feel free to add more if you think I have missed anything and would love to get any feedback.
Users browsing this forum: No registered users and 2 guests