Application AccessIt doesn’t matter if it is website of desktop application – all the options in access security are implemented by “Roles and Rights Management”. This is often has to be done implicitly when covering functionality: for example, the receptionist in the hospital is hardly concerned about the medical tests in the lab because his job is to register patients appointments. That’s why he has no access to the menus, forms and other information related to lab tests as his Role in the Hospital Management System is “Receptionist”.
How to test the access security? When testing this point of the security options all of the Roles should be checked. Tester should create the accounts with all possible Roles. Then he needs to use all of these accounts in order to be sure that every role has an access only to its own forms, menus and screens. If any access conflict is found, this issue should be logged with complete security.
The second aspect is about how the data is stored in the database. You should understand that all the data which is sensitive must be encrypted in order to make it secure. Especially encryption should be very strong for such an important and sensitive data like passwords to user accounts, numbers of credit cards and other business information.
The third aspect is actually an extension of the second one. It is related to the information flows. When the flow of the sensitive data described above occurs in the application, the proper security level must be provided. It doesn’t matter if the information flow is between different modules of the application of between different apps, the data must be safely encrypted in order to protect it.
It’s not actually necessary to say that all the above aspects should be properly tested before using the application. First, the tester should query the DB for passwords to user accounts, clients billing info and other sensitive data. Then he should verify that all this data is thoroughly encrypted being stored in the database. The proper data encryption should also be checked when transmitting it between different forms and screens. After that the tester should verify if the data is successfully decrypted after reaching the destination. The sensitive information like accounts passwords shouldn’t be displayed within the submission form in any understandable format.
Brute-Force AttackThis 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.