Application Access
It 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.
There are three main aspects in data security.
The first one is:
the particular user should view or utilize only the data he is supposed
to view and use. This option is also provided by roles and rights, for
example the company’s telesales manager can only view the data about the
available stock, but he doesn’t have any access to the information
about how much raw materials was bought for production.
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 Attack
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.
