Security : Security means that authorized access is granted to protected data
and unauthorized access is restricted.
So, it has two major aspects; first is protection
of data and second one is access to that data. Moreover, whether the
application is desktop or web based, security revolves around the two
aforementioned aspects. Let us have an overview of security aspects for both
desktop and web based software applications.
Security Testing : It is the process to determine that an
information system protects data and maintains functionality as intended.
“Security Testing helps in finding out loopholes
that can cause loss of important information”
Security Testing is Needed :
1) To ensure Input Data Validation
2) To ensure Control on internal Processing
3) To ensure Message Integrity
4) To ensure output Data Validation
Desktop and Web Security Testing
l
A desktop application should be secure not only
regarding its access but also with respect to organization and storage of its
data.
l
Similarly, a web application demands even more
security with respect to its access, along with data protection. Web developer
should make the application immune to SQL Injections, Brute Force Attacks
and XSS (cross site scripting).
l
Similarly, if the web application facilitates
remote access points then these must be secure too. Moreover, keep in mind that
Brute Force Attack is not only related to web applications, desktop software is
also vulnerable to this.
Security Testing Techniques
1) Access to Application
2) Data Protection
3) Brute-Force Attack
4) SQL Injection and XSS (cross site scripting)
5) Service Access Points (Sealed and Secure Open)
*The above three security aspects should be taken
into account for both web and desktop applications while, the following points
are related with web based applications only.
1 ) Access to Application
Whether it is a desktop application of website,
access security is implemented by 'Roles and Rights Management'. It is often
done implicitly while covering functionality,
Example : In a Hospital Management System a receptionist
is least concerned about the laboratory tests as his job is to just register
the patients and schedule their appointments with doctors. So, all the menus,
forms and screen related to lab tests will not be available to the Role of
'Receptionist'. Hence, the proper implementation of roles and rights will
guarantee the security of access.
How to Test Access to Application:
l
In order to test this, thorough testing of all
roles and rights should be performed.
l
Tester should create several user accounts with
different as well multiple roles. Then he should use the application with the
help of these accounts and should verify that every role has access to its own
modules, screens, forms and menus only. If tester finds any conflict, he should
log a security issue with complete confidence.
2) Data Protection:
There are further three aspects of data security:
l
First one is that a user can view or utilize only
the data which he is supposed to use. This is also ensured by roles and rights
e.g. a TSR (telesales representative) of a company can view the data of
available stock, but cannot see how much raw material was purchased for
production. So, testing of this aspect is already explained above.
l
The second aspect of data protection is related
to how that data is stored in the DB. All the sensitive data must be encrypted
to make it secure. Encryption should be strong especially for sensitive data
like passwords of user accounts, credit card numbers or other business critical
information.
l
Third and last aspect is extension of this second
aspect. Proper security measures must be adopted when flow of sensitive or
business critical data occurs. Whether this data floats between different
modules of same application, or is transmitted to different applications it
must be encrypted to make it safe.
How to Test Data Protection
The tester should query the database for
'passwords' of user account, billing information of clients, other business
critical and sensitive data and should verify that all such data is saved in
encrypted form in the DB. Similarly (s)he must verify that between different
forms or screens, data is transmitted after proper encryption. Moreover, tester
should ensure that the encrypted data is properly decrypted at the destination.
Special attention should be paid on different 'submit' actions. The tester must
verify that when the information is being transmitted between client and
server, it is not displayed in the address bar of web browser in understandable
format. If any of these verifications fail, the application definitely has
security flaw.
3) Brute-Force Attack
Brute Force Attack is mostly done by some
software tools. The concept is that using a valid user ID, software attempts to
guess the associated password by trying to login again and again. A simple
example of security against such attack is account suspension for a short
period of time as all the mailing applications like 'Yahoo' and 'Hotmail' do.
If, a specific number of consecutive attempts (mostly 3) fail to login
successfully, then that account is blocked for some time (30 minutes to 24
hrs).
How to test Brute-Force Attack
The tester must verify that some mechanism of
account suspension is available and is working accurately. (S)He must attempt
to login with invalid user IDs and Passwords alternatively to make sure that
software application blocks the accounts that continuously attempt login with
invalid information. If the application is doing so, it is secure against
brute-force attack. Otherwise, this security vulnerability must be reported by
the tester.
4) SQL Injection and XSS (cross site
scripting)
Conceptually speaking, the theme of both these
hacking attempts is similar, so these are discussed together. In this approach,
malicious script is used by the hackers in order to manipulate a website. There
are several ways to immune against such attempts. For all input fields of the
website, field lengths should be defined small enough to restrict input of any
script e.g. Last Name should have field length 30 instead of 255. There may be
some input fields where large data input is necessary, for such fields proper
validation of input should be performed prior to saving that data in the
application. Moreover, in such fields any html tags or script tag input must be
prohibited. In order to provoke XSS attacks, the application should discard
script redirects from unknown or untrusted applications.
SQL Injection : A SQL injection attack consists of insertion or “injection” of a SQL
query via the input data from the client to the application.
Any User-controlled parameter that gets processed
by the application might be hiding vulnerability.
This includes:
1) Application parameters in query strings (e.g., GET Requests)
2) Application parameters included as part of the body of a POST request.
3) Browser-related information (e.g., user-agent, referrer)
4) Host-related information (e.g., host name, IP)
5) Session-related information (e.g., user IDE, cookies)
Classes of SQL Injection:
1) Inband : Data is extracted using the same channel that is
used to inject the SQL code. This is the most straightforward kind of attack,
in which the retrieved data is presented directly in the application web page.
2) Out-of-band : Data is retrieved using a different channel
(e.g., an email with the results of the query is generated and sent to the
tester)
3) Inferential: There is no actual transfer of data, but the
tester is able to reconstruct the information by sending particular requests
and observing the resulting behaviour of the DB server.
How to test SQL Injection and XSS
Tester must ensure that maximum lengths of all
input fields are defined and implemented. (S)He should also ensure that defined
length of input fields does not accommodate any script input as well as tag
input. Both these can be easily tested e.g. if 20 is the maximum length
specified for 'Name' field; and input string
"<p>thequickbrownfoxjumpsoverthelazydog" can verify both these
constraints. It should also be verified by the tester that application does not
support anonymous access methods. In case any of these vulnerabilities exists,
the application is in danger.
Types of Tests that can be conducted :
The tester has to :
1) make a list of all input fields whose values could be used in crafting
a SQL query, including the hidden fields of POST request and then test them
separately.
2) Try to interfere with the query andto generate an error , He can add a
single quote (‘), (;), comments (--) or SQL keywords like ‘AND’ or ‘OR’.
3) Standard SQL injection :
1) Union query SQL injection
2) Blind SQL injection
3) Store procedure injection
Prevention of SQL injection :
Application have to:
1) Validate and to sanitize all user input
2) Never use dynamic SQL
3) Execute using an account with few privileges
4) Hash or encrypt their secrets
5) Present error messages that reveal little if no useful information to
the hacker.
Cross-Site Scripting (XSS) :
It occurs any time, raw data from attacker is
sent to an innocent user’s browser
Typical Impact:
1) Steal user’s session, steal sensitive data, rewrite web page, redirect
user to phishing or malware site.
2) Most severe: Install XSS proxy which allows attacker to observe and
direct all user’s behavior on vulnerable site and force user to other sites.
XSS attacks is used for :
1) Hijacking accounts
2) False Advertising & inserting hostile content
3) Cookie theft/poisoning & defacing websites
4) Changing of users settings
5) Conducting phishing attacks
Prevention of XSS Attack:
1) Input Validation :
A) Check if the input is what you expect
1) Do not try to check for “bad input”
B) Black list testing is no solution
1) Black lists are never complete
C) White list testing is better
1) Only what you expect will pass
2) Regular expressions
2) HTML coding: HTML coding of all input when put into output pages.
3) Cookie options mitigate the impact :
A) “httpOnly” cookies
B) “secure” cookies. Cookies are only sent over SSL.
5) Service Access Points (Sealed and Secure
Open):
Today, businesses depend and collaborate with
each other, same holds good for applications especially websites. In such case,
both the collaborators should define and publish some access points for each
other. So far the scenario seems quite simple and straightforward but, for some
web based product like stock trading, things are not so simple and easy. When
there is large number of target audience, the access points should be open
enough to facilitate all users, accommodating enough to fulfill all users'
requests and secure enough to cope with any security-trial.
How to Test Service Access Points
Let me explain it with the example of stock
trading web application; an investor (who wants to purchase the shares) should
have access to current and historical data of stock prices. User should be
given the facility to download this historical data. This demands that
application should be open enough. By accommodating and secure, I mean that
application should facilitate investors to trade freely (under the legislative
regulations). They may purchase or sale 24/7 and the data of transactions must
be immune to any hacking attack. Moreover, a large number of users will be
interacting with application simultaneously, so the application should provide
enough number access point to entertain all the users.
In some cases these access points can be sealed
for unwanted applications or people. This depends upon the business domain of
application and its users, e.g. a custom web based Office Management System may
recognize its users on the basis of IP Addresses and denies to establish a
connection with all other systems (applications) that do not lie in the range
of valid IPs for that application.
Tester must ensure that all the inter-network and
intra-network access to the application is from trusted applications, machines
(IPs) and users. In order to verify that an open access point is secure enough,
tester must try to access it from different machines having both trusted and
untrusted IP addresses. Different sort of real-time transactions should be
tried in a bulk to have a good confidence of application's performance. By doing so, the capacity of access points of
the application will also be observed clearly.
Tester must ensure that the application
entertains all the communication requests from trusted IPs and applications
only while all the other request are rejected. Similarly, if the application
has some open access point, then tester should ensure that it allows (if
required) uploading of data by users in secure way. By this secure way I mean,
the file size limit, file type restriction and scanning of uploaded file for
viruses or other security threats. This is all how a tester can verify the
security of an application with respect to its access points.
