Software Testing Practices, Test Methodologies and Test Competency Services


Welcome to the world of Software Testing & Best Test Practices.

All you wanted to know about Software Testing, Test Practices, Test Methodologies and building the Test Competency Services !!


Wednesday, October 24, 2012

Top 10 ways to conduct Security Testing on web applications

1. Finding the /admin/ interface by "Fuzzing" or "Guessing" technique

In this, as testers; we need to find the admin path for the URL. The path names should not be easily guessable like,

http://example.com/admin/
http://example.com/admin.aspx
http://example.com/login
http://example.com/administrator
http://example.com/admin.php

The guessing keeps on going. Out of 10 e-commerce websites, I have seen people using very easily guessable path names for admin interface. Other sites belonged to "Content Management Systems", "Health Care", "e-Ticketing" and others.

Now, what's the fix here?

First of all, admin interface should not be publicly allowed to be accessed. There need to be white-list of IP addresses or hosts which can access the path. Also, have the admin path name in such a fashion that, it is not easily guessable and have it in totally different path which could be like http://example.com/jKMe23292mMjs/luKseqA/LogMeInAsAdmin -- You might want to change "LogMeInAsAdmin" to something else which is not easy to guess.

You got to instruct the spiders from indexing this URL. So, do not make a mistake of considering this pathname in the sitemap.XML file. It will be a disaster!

2. Forgot Password being used as spam machine

Often I see, Forgot Password code is written in a sloppy way or security layers are not built for the feature. Here is a vulnerability that you could use on most of the available websites -
You got to go to Forgot Password webpage
You will see an input text field where you can enter an e-mail address
Now, repeat the above 2 steps and you can keep sending e-mails to the same address again and again

This could result in spamming where attacker enters the target e-mail address which might belong to anyone and keeps them sending bulk e-mails which makes the customer look at it as, spamming which is pathetic.

Now, the developer might ask you a question; "Come on, man! Who has time to keep sending 100 or 1000 e-mails by submitting the form again and again".

Your answer could be this, "Attacker would automate HTTP requests and keep sending the e-mails" repeatedly. You can demonstrate this automation by using iMacros (Go to http://add-ons.mozilla.org/ and download "iMacros"). Once downloaded, record the flow of "Forgot Password" web-page | Enter e-mail address | And submit the form - Then you got to stop the recording session. Then loop it how many ever time you want; if you say 1000 loop time(s) then 1000 e-mails would be sent. So, while you sip the coffee, the target e-mail address is victimized with lots of e-mails in inbox.

This could also be an attack on SMTP server.

Now, what's the fix?
CAPTCHA could be shown after 3 or 5 attempts to send e-mails using same e-mail address. There are chances of bounced e-mails; in this case we got to give some attempts without CAPTCHA. CAPTCHA would help in stopping these automated attacks.

Or else, put an upper limit on sending e-mails within 24 hours. If there are 10 e-mails sent for same e-mail address, then you can say; "Please try after 24 hours from now as you have exceeded your requests for the day already."

3. Application Caching Bug - BlackMagic BackMagic

Do not be scared, I am not talking about some BlackMagic Mantra here. It's just the humor stuff by using strikethrough *Grins*.

You can remember "Application Cache" test as "BackMagic" (It need not be new terminology and interviewers, please do not treat this as technique - It is just a humor thing and for my reference). What is the test exactly?

You login to your web application with your credentials and browse different web-pages which are shown to only for the logged in end-users. Now, finally you logout and let us say you are landed on homepage or any other web-page used in the re-direction based on the decision taken by business folks. Now, you just need to click on "Back" button of your web browser and see if you are taken to the pages which you browsed previously when you were logged in. That's the bug.

The fix here is to disable application caching or clearing the cache once the logout action is invoked.

The risk here is, when people logout and just do not close the web browser. Next user just comes in and clicks on "Back" and looks at all the information which violated the privacy policy set by your organization.

Now, again there are 2 variants of it,
You can click "Back" and just view web-pages which were browsed recently.
You can click "Back" and view the web-pages and also perform actions like "Change e-mail address", "Edit Personal Details" and so on.

Second one could be disaster. Be careful.

4. Directory Listing - Access to Treasure

When Directory Listing is not disabled, you could go through the all the directory structure which includes sub-directories and files. Example could be: http://example.com/images/ -- Try accessing your web application with directories and see if Directory Listing is enabled. It should be set to off if there is no business reason behind it.

Example:


One tip to testers is: Do not conclude on saying, "Directory Listing is Off" by just navigating to one directory. You must understand that, there is way to set On / Off to particulate set of directories. So, you got to have an automation solution if there are lots of directories and then run it and give a report of which directory has listing on and which is off.

5. Form server side tests - Unleashing the power of Firebug

I know that you always stopped when the form text fields,

a. Did not allow you to type more than 20 characters or any "X" number of characters and you thought it is the ultimate boundary.

b. Did not allow you to enter specific characters in the text field (Example: Asterisk symbol, @ symbol, less than, greater than symbols etc.)

c. And many other reasons because of client-side validation rules set by your Javascript or any Javascript framework like jQuery etc.

Now, that's one of the test that you did but, you did not go deeper and see if the client-side validation could be by-passed and submit the values to the database.

Here, I will show you, how you can bypass the text field boundary and enter more characters and submit the form. Well, if your application gives you an error for entering more characters after you by-pass client side validation, then it's good news; which means server side validation is being done. If the form is submitted with those many characters which are not intended by the business then, it's a bad news (No server-side validation implemented).

Here is how you can do it,

Install Firebug add-on in your Mozilla Firefox web browser (URL: http://addons.mozilla.org/)
Open your website and navigate to the form. Example text fields would be: FirstName, LastName, MiddleName etc.
Now, go to any text field and right-click on it. Choose "Inspect Element" option just like below,



You see that, I performed right-click on "E-mail address" text field and chose "Inspect Element with Firebug". Once I do that, Firebug opens and you will see something like this as below,



There is a maxlength attribute which is set to 100 which means; the client-side boundary is 100 characters and once you reach that, even if you type anything (Say 101th character), it doesn't get displayed.

Now, you can edit this by just double-clicking on the 100 value and just editing it to 300 or any other value or you can just make it NULL. Now, you will be able to enter more than 100 characters. After entering more than 100 characters, submit the form by entering valid data in all other fields of the form so that the test is successful. Wohoo! You learned how to do server side validation tests now. I hope that makes you feel proud. This could be done for any form in your web application. Now, your test coverage can give a different confidence to your customer and you as you include "Server Side Tests" in your test ideas.

6. Account Lockout Policy and CAPTCHA in Login

Can I use brute force mechanism on your web application's login and crack the password? Well, most of the websites I have seen do not have Account Lockout Policy or CAPTCHA shown after "X" number of invalid attempts. This will be a cool stuff for hackers who can exploit by deploying their brute force suite on the login to crack the password. To avoid this, you need to challenge the user with CAPTCHA after "3" or "5" invalid attempts to login using the same username. However; there is one more attack called as "Shot-gun style" (Let us not talk about this for a while).

You can try using wrong login attempts at Gmail and later you are asked to enter CAPTCHA so that you do not employ brute force tools to crack the password. That's how you can implement even for your web application login. Or else there is another way where you lock the account for 24 hours or so (This depends on the decision the business has taken). Locking of account after "X" number of invalid attempts is "Account Lockout Policy" (Policy will define the way of working when account is locked out). You can try HDFC bank internet banking where your account gets locked out if you enter 3 or 5 invalid IPIN.

Finally, I want to finish this article saying; "You got be explorer, if you are just ending up doing specific set of steps and stop there; then it is hard or impossible for you to gain that mind-set of hacking & skill-set of hacking".

7. HTTPS re-direction - Developer forgot to put a re-direction

First question would be where do we need HTTPS to be used? The answer is; wherever you think confidential data is being sent over the wire, you got to use HTTPS to encrypt the data and send over the wire. Now, let us say: Checkout web-page has HTTPS when you click on "Checkout" button. However; forcibly remove HTTPS and just use HTTP for the Checkout web-page URL. If the web-page loads checkout in HTTP web-page then it's vulnerability. Voila!

The fix for this considering security is, re-direct HTTP to HTTPS even when HTTP is used forcibly.

8. Token Expiry Test - Expire the token or you get expired *Grins*

Let us say, you are testing a web application where you have Forgot Password or Activation e-mail sent with a unique token URL which need to be used in order to proceed further. We will pick forgot password URL at moment, what you got to test is - Use your own e-mail address in Forgot Password. Once you receive the e-mail in your inbox / spam / junk / bulk folder, use the link and then you will be taken to your web application where you set new password. Now, after setting new password; re-use the same link and try setting the new password again. If you are able to set two new passwords using the same link then the token has not expired and it is security vulnerability. Hackers and attackers can just use brute force mechanism to generate the URL and use it.

If you don't kill the token on one use, then it will kill you. Disaster!

9. SSL Tests from SSLShopper.com

You can visit http://sslshopper.com/ and perform the SSL tests. Well, this works only for the web applications which are on the production and are accessible by public. You might want to explore and find out similar tools to support for your intranet based applications. Also, learn about SSL / HTTPS about their working and what kind of tests you can derive based on the learning.

10. Mantra Browser - http://getmantra.com/

Well, here exists awesome add-on(s) that you can use to perform tests and run automated checks for your web application. This really rocks and is one of my favorite ones.

There are so many web browser add-on(s) which will rock your day for sure in the area of "Security Testing" / "Penetration Testing".

No comments: