This technique is often done by different software tools. The main idea of it is that the system is trying to get a password match using the valid ID by attempting to login again and again. The most common example of the security technique against this kind of attack is account blocking for some period of time. This is used by such mailing services as Yahoo! or Hotmail. The user has a number of consecutive attempts (mostly 3 ones) to login the account. If these attempts fail, the system blocks the account for a while (the time of blocking varies from 30 minutes to 24 hours).
How to test: The first thing to do is to verify if the mechanism of account suspension is valid and working good. It is simple to check: the tester must try to login the account with invalid user IDs or passwords to make sure that the application successfully blocks the account which is being attempted to login with invalid registration data. If so, the application is secure about any kind of brute-force attack. In other case, there is a security vulnerability that must be reported.
The security aspects described below and also the ones we were talking about in the first part of the article should be taken both for web and desktop apps. The following aspects are related only to web applications.
SQL Injection And Cross Site Scripting (XSS)
These are the names of two similar hacking attempts, so we are going to discuss them together. The thing is that malicious scripts are often used by hackers for manipulating the website. That’s why if you want your site to be secure, you need some ways to immune against such problems. Actually, there are several ones. First, all the input fields must be limited by the number of symbols in order to prevent the attempts of inputting any script there. For example you should limit the field “Last Name” by 30 symbols, but not 255. Objectively there are some fields where large information input is needed. For such kind of fields the data should be checked and validated before it is saved in the application. Besides in such fields any HTML or script tags should be disallowed. Moreover, in order to prevent XSS attacks, the system should reject any script redirects from all the untrusted and unknown apps.
How to test:The first thing to do is to get sure that all the lengths of all the fields are limited and implemented. Also the tester must get sure that defined length strikes off any script or tag input. Each of these aspects are easy to check, for example, if the defined length of the field is 20 and your input data is “<p>ghjgjghjgjhlkjejfmgmdngjrgk”, than you can verify both of the issues. The last thing to check is that the application doesn’t support anonymous access.