Web Security Testing Part I
Security attacks are lethal!
For All web pages which carry confidential data like password, Secret answer for security question should be submitted via HTTPS(SSL).
Password & security answer needs to be masked with input type = password.
Server Side Validation for form. Use “Firebug” and “TamperData” to perform this test (You can tamper for minimum length of password, set only new password without old password >> You got to remove the old password element from Firebug from the client-side and then submit it <<)
Check for SQL Injection for any page in your application that accepts user-supplied information to access a database.
A login form, signup form, or “forgot password” form is a good start.
A dynamic page that uses URL variables such as ID (product information pages are good for this).
Test for XSS by searching application for a page that takes user input and outputs it directly to a webpage. Common examples: Forums, Comments, Wikis, Review. Also, check for CSRF.
Set of rules for setting a password should be same across all the modules like Registration form, Change password, and Forgot password. If these rules differ than hacker might exploit it through brute force method. Example: If the registration form does not validate for password minimum length as 8 chars but while changing password from user profile it validates for minimum length or vice versa. Now, as registration form accepts password which are less than 8 chars it becomes easy for hacker to apply brute-force method.
Password setting rules
Alphabets + Numeric + Special Characters
Any other format that makes it resistant to attacks
Forgot Your Password
There need to be a restriction on number of forgot password requests sent per day or in “X” hours interval or have a captcha so that automated requests are not sent (To automate the requests you could use “ReloadEvery” add-on which is to be used on http://example.com/user/forgot-password/)
The URL has to expire on one use after being used to set new password.
The token associated with the URL should not be guessable or there should be any pattern which could be easily cracked.
If the URL is not used within “X” hours then it has to expire (Example: Once the URL is generated, if it is not used then it has to expire after “72 hours”)
When new token is generated the old ones should expire even if they are not used.
Example.com should not send the password via e-mails by resetting automatically. There has to be URL which should be used by end-user to set new password of his / her choice.
While typing secret answer in Forgot Password the secret answer needs to be masked (Secret Answer is also part of authentication which is similar to password, shoulder surfing or auto-complete stuff could be dangerous here compromising the end-user account).
Once the password is set, you might want to take end-user to logged in state or requesting him / her to login now with the hyperlink (I, personally would recommend taking to login page and requesting him / her to login with new password)
CAPTCHA images should not reveal absolute path names. Usage of web services is a good idea, just like reCaptcha.
Do not have cyclic fashion captcha images. Like 1 to 100 and then again 1 to 100. Easy to crack. It is good to have some algorithm which generates huge number of captcha images using image libraries.
Usage of background noise in the image, different textures, and different angle of displaying the characters might be a good idea to make it difficult for some captcha cracking programs like http://free-ocr.com/ and few others.
Audio to text converters – Use some of these software(s) and see whether they are able to crack the audio captcha or not.
CAPTCHA should refresh on every wrong entry. Keeping it static might be vulnerable to brute force attack for captcha to bypass it.
There needs to be server-side validation for CAPTCHA entry. Use Firebug to Inspect Captcha element and then just delete it from client-side. Then, just fill the form without captcha and submit it. If it gets submitted, then there is no server-side validation which is a high risk one. It’s equivalent to not having captcha.
CAPTCHA with question and answers in plain text and mathematical functions questions in plain text are not recommended in my opinion.
Combinations of uppercase / lowercase alphabets, numerical, special characters could be used to increase the brute force combinations for CAPTCHA which would turn out to be very difficult to crack CAPTCHA quickly. Hackers usually do not employ brute force for so many numbers of combinations; rather they would hire a human to bypass the captcha manually. Well, yes. There are CAPTCHA breaking services.
Saving list of questionnaire for CAPTCHA in JS file is easily vulnerable as all the questions could be retrieved easily and assertions could be easily added using some automation tool like Selenium and bypass CAPTCHA. I had seen this vulnerability in check-in service web application Gowalla or Foursquare – I do not really remember which one exactly.