Software industry has achieved a solid recognition in this age. In the recent decade, however, cyber-world seems to be even more dominating and driving force which is shaping up the new forms of almost every business. Web based ERP systems used today are the best evidence that IT has revolutionized our beloved global village.

These days, websites are not meant only for publicity or marketing but these have been evolved into the stronger tools to cater complete business needs. Web based Payroll systems, Shopping Malls, Banking, Stock Trade application are not only being used by organizations but are also being sold as products today.

This means that online applications have gained the trust of customers and users regarding their vital feature named as SECURITY. No doubt, the security factor is of primary value for desktop applications too. However, when we talk about web, importance of security increases exponentially. If an online system cannot protect the transaction data, no one will ever think of using it. Security is neither a word in search of its definition yet, nor is it a subtle concept. However, I would like to list some complements of security.

Examples of security flaws in an application:

1) A Student Management System is insecure if ‘Admission’ branch can edit the data of ‘Exam’ branch
2) An ERP system is not secure if DEO (data entry operator) can generate ‘Reports’
3) An online Shopping Mall has no security if customer’s Credit Card Detail is not encrypted
4) A custom software possess inadequate security if an SQL query retrieves actual passwords of its users

Security Testing Definition:
Now, I present you a simplest definition of Security in my own words. “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.

Desktop and Web Security Testing:
A desktop application should be secure not only regarding its access but also with respect to organization and storage of its data. 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). 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.

I hope this foreword is enough and now let me come to the point. Kindly accept my apology if you so far thought that you are reading about the subject of this article. Though I have briefly explained software Security and its major concerns, but my topic is ‘Security Testing’. In order to know further details of security aspects, kindly refer to – Web application security testing article.

I will now explain how the features of security are implemented in software application and how should these be tested. My focus will be on Whats and Hows of security testing, not of security.

Security Testing Techniques:

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, e.g.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: In order to test this, thorough testing of all roles and rights should be performed. 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. 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. 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. 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.

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.

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.

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.

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.

If you enjoy reading this article please make sure to share it with your friends. Please leave your questions/tips/suggestions in the comment section below and I’ll try to answer as many as I can.

---------------------
I just wanted to thank you for subscribing to SoftwareTestingHelp.com. This blog is a success because of you and your support. Here's to your success!

As always, I appreciate your valuable comments. Visit below link to post your comment:
How to Test Application Security – Web and Desktop Application Security Testing Techniques

Thank you so much! ---------------------
Recommended: TestLodge - Online test case management tool - Web based test case management software allowing you to manage your test plans, requirements, test cases and test runs with ease.

The characteristics of a Banking application are as follows:

• Multi tier functionality to support thousands of concurrent user sessions
• Large scale Integration , typically a banking application integrates with numerous other applications such as Bill Pay utility and Trading accounts
• Complex Business workflows
• Real Time and Batch processing
• High rate of Transactions per seconds
• Secure Transactions
• Robust Reporting section to keep track of day to day transactions
• Strong Auditing to troubleshoot customer issues
• Massive storage system
• Disaster Management.

The above listed ten points are the most important characteristics of a Banking application.

Banking applications have multiple tiers involved in performing an operation. For Example, a banking application may have:

1. Web Server to interact with end users via Browser
2. Middle Tier to validate the input and output for web server
3. Data Base to store data and procedures
4. Transaction Processor which could be a large capacity Mainframe or any other Legacy system to carry out Trillions of transactions per second.

If we talk about testing banking applications it requires an end to end testing methodology involving multiple software testing techniques to ensure:

• Total  coverage of all banking workflows and Business Requirements
• Functional aspect of the application
• Security aspect of the application
• Data Integrity
• Concurrency
• User Experience

Typical stages involved in testing Banking Applications are shown in below workflow which we will be discussing individually.

1) Requirement Gathering:

Requirement gathering phase involves documentation of requirements either as Functional Specifications or Use Cases. Requirements are gathered as per customer needs and documented by Banking Experts or Business Analyst. To write requirements on more than one subject experts are involved as banking itself has multiple sub domains and one full fledge banking application will be the integration of all. For Example: A banking application may have separate modules for Transfers, Credit Cards, Reports, Loan Accounts, Bill Payments, Trading Etc.

2) Requirement Review:

The deliverable of Requirement Gathering is reviewed by all the stakeholders such as QA Engineers, Development leads and Peer Business Analysts. They cross check that neither existing business workflows nor new workflows are violated.

3) Business Scenario Preparations:

In this stage QA Engineers derive Business Scenarios from the requirement documents (Functions Specs or Use Cases); Business Scenarios are derived in such a way that all Business Requirements are covered. Business Scenarios are high level scenarios without any detailed steps, further these Business Scenarios are reviewed by Business Analyst to ensure all of Business Requirements are met and its easier for BAs to review high level scenarios than reviewing low level detailed Test Cases.

4) Functional Testing:

In this stage functional testing is performed and the usual software testing activities are performed such as:

Test Case Preparation:
In this stage Test Cases are derived from Business Scenarios, one Business Scenario leads to several positive test cases and negative test cases. Generally tools used during this stage are Microsoft Excel, Test Director or Quality Center.
Test Case Review:
Reviews by peer QA Engineers
Test Case Execution:
Test Case Execution could be either manual or automatic involving tools like QC, QTP or any other.

5) Database Testing:

Banking Application involves complex transaction which are performed both at UI level and Database level, Therefore Database testing is as important as functional testing. Database in itself is an entirely separate layer hence it is carried out by database specialists and it uses techniques like

• Data loading
• Database Migration
• Testing DB Schema and Data types
• Rules Testing
• Testing Stored Procedures and Functions
• Testing Triggers
• Data Integrity

6) Security Testing:

Security Testing is usually the last stage in the testing cycle as completing functional and non functional are entry criteria to commence Security testing. Security testing is one of the major stages in the entire Application testing cycle as this stage ensures that application complies with Federal and Industry standards. Security testing cycle makes sure the application does not have any web vulnerability which may expose sensitive data to an intruder or an attacker and complies with standards like OWASP.

In this stage the major task involves in the whole application scan which is carried out using tools like IBM Appscan or HP WebInspect (2 Most popular tools).

Once the Scan is complete the Scan Report is published out of which False Positives are filtered out and rest of the vulnerability are reported to Development team for fixing depending on the Severity.

Other Manual tools for Security Testing used are: Paros Proxy, Http Watch, Burp Suite, Fortify tools Etc.

Apart from the above stages there might be different stages involved like Integration Testing and Performance Testing.

In today’s scenario majority of Banking Projects are using: Agile/Scrum, RUP and Continuous Integration methodologies, and Tools packages like Microsoft’s VSTS and Rational Tools.

As we mentioned RUP above, RUP stands for Rational Unified Process, which is an iterative software development methodology introduced by IBM which comprises of four phases in which development and testing activities are carried out.

Four phases are:
i) Inception
ii) Collaboration
iii) Construction and
iv) Transition
RUP widely involves IBM Rational tools.

In this article we discussed how complex a Banking application could be and what are the typical phases involved in testing the application. Apart from that we also discussed current trends followed by IT industries including software development methodologies and tools.

In case you have queries, comments or any unanswered questions please post it below I will be happy to answer those.

Like this post? Subscribe to get new articles via RSS or Email.

---------------------
I just wanted to thank you for subscribing to SoftwareTestingHelp.com. This blog is a success because of you and your support. Here's to your success!

As always, I appreciate your valuable comments. Visit below link to post your comment:
How to Test Banking Applications

Thank you so much! ---------------------
Recommended: TestLodge - Online test case management tool - Web based test case management software allowing you to manage your test plans, requirements, test cases and test runs with ease.

Each bug listed in this resource can lead to serious software vulnerabilities if not fixed. The top 25 security bugs list will help programmers to avoid some common but serious coding mistakes. For software testers list will be useful as a security testing checklist for Internet as well as for testing desktop application.

Here are few top security vulnerabilities discussed in detail in this article:

•  Improper input validation
•  Improper escaping of output or encoding
•  SQL injection
•  Cross-site scripting
•  Race conditions
•  Information leak in error messages
•  Error while transmitting sensitive information
•  Memory leak
•  External control of critical data and file paths
•  Improper initialization
•  Improper authorization
•  Client side security checks

I think, the most common security vulnerability mistake developers make is “Client side enforcement of server side security”.

Check out below article so that you can at least help developers for improving their code standards

Top 25 common programming Errors

---------------------
I just wanted to thank you for subscribing to SoftwareTestingHelp.com. This blog is a success because of you and your support. Here's to your success!

As always, I appreciate your valuable comments. Visit below link to post your comment:
Top 25 common programming bugs every tester should know

Thank you so much! ---------------------
Recommended: TestLodge - Online test case management tool - Web based test case management software allowing you to manage your test plans, requirements, test cases and test runs with ease.

Many applications use some type of a database. An application under test might have a user interface that accepts user input that is used to perform the following tasks:

1.    Show the relevant stored data to the user e.g. the application checks the credentials of the user using the log in information entered by the user and exposes only the relevant functionality and data to the user

2.    Save the data entered by the user to the database e.g. once the user fills up a form and submits it, the application proceeds to save the data to the database; this data is then made available to the user in the same session as well as in subsequent sessions

Some of the user inputs might be used in framing SQL statements that are then executed by the application on the database. It is possible for an application NOT to handle the inputs given by the user properly. If this is the case, a malicious user could provide unexpected inputs to the application that are then used to frame and execute SQL statements on the database. This is called SQL injection. The consequences of such an action could be alarming.

The following things might result from SQL injection:

1. The user could log in to the application as another user, even as an administrator.

2. The user could view private information belonging to other users e.g. details of other users’ profiles, their transaction details etc.

3. The user could change application configuration information and the data of the other users.

4. The user could modify the structure of the database; even delete tables in the application database.

5. The user could take control of the database server and execute commands on it at will.

Since the consequences of allowing the SQL injection technique could be severe, it follows that SQL injection should be tested during the security testing of an application. Now with an overview of the SQL injection technique, let us understand a few practical examples of SQL injection.

Important: The SQL injection problem should be tested only in the test environment.

If the application has a log in page, it is possible that the application uses a dynamic SQL such as statement below. This statement is expected to return at least a single row with the user details from the Users table as the result set when there is a row with the user name and password entered in the SQL statement.

SELECT * FROM Users WHERE User_Name = ‘” & strUserName & “‘ AND Password = ‘” & strPassword & “’;”

If the tester would enter John as the strUserName (in the textbox for user name) and Smith as strPassword (in the textbox for password), the above SQL statement would become:

SELECT * FROM Users WHERE User_Name = ‘John’ AND Password = ‘Smith’;

If the tester would enter John’– as strUserName and no strPassword, the SQL statement would become:

SELECT * FROM Users WHERE User_Name = ‘John’– AND Password = ‘Smith’;

Note that the part of the SQL statement after John is turned into a comment. If there were any user with the user name of John in the Users table, the application could allow the tester to log in as the user John. The tester could now view the private information of the user John.

What if the tester does not know the name of any existing user of the application? In such a case, the tester could try common user names like admin, administrator and sysadmin. If none of these users exist in the database, the tester could enter John’ or ‘x’=’x as strUserName and Smith’ or ‘x’=’x  as strPassword. This would cause the SQL statement to become like the one below.

SELECT * FROM Users WHERE User_Name = ‘John’ or ‘x’='x’ AND Password = ‘Smith’ or ‘x’=’x’;

Since ‘x’=’x’ condition is always true, the result set would consist of all the rows in the Users table. The application could allow the tester to log in as the first user in the Users table.

Important: The tester should request the database administrator or the developer to copy the table in question before attempting the following SQL injection.

If the tester would enter John’; DROP table users_details;’—as strUserName and anything as strPassword, the SQL statement would become like the one below.

SELECT * FROM Users WHERE User_Name = ‘John’; DROP table users_details;’ –‘ AND Password = ‘Smith’;

This statement could cause the table “users_details” to be permanently deleted from the database.

Though the above examples deal with using the SQL injection technique only the log in page, the tester should test this technique on all the pages of the application that accept user input in textual format e.g. search pages, feedback pages etc.

SQL injection might be possible in applications that use SSL. Even a firewall might not be able to protect the application against the SQL injection technique.

I have tried to explain the SQL injection technique in a simple form. I would like to re-iterate that SQL injection should be tested only in a test environment and not in the development environment, production environment or any other environment. Instead of manually testing whether the application is vulnerable to SQL injection or not, one could use a web vulnerability scanner that checks for SQL injection.

Related: Couple of months back Inder wrote an interesting article on “Security testing of web application“  Have a look at it for more details on different web vulnerabilities.

---------------------
I just wanted to thank you for subscribing to SoftwareTestingHelp.com. This blog is a success because of you and your support. Here's to your success!

As always, I appreciate your valuable comments. Visit below link to post your comment:
SQL Injection – How to Test Web Applications against SQL Injection Attacks

Thank you so much! ---------------------
Recommended: TestLodge - Online test case management tool - Web based test case management software allowing you to manage your test plans, requirements, test cases and test runs with ease.

Introduction

As more and more vital data is stored in web applications and the number of transactions on the web increases, proper security testing of web applications is becoming very important. Security testing is the process that determines that confidential data stays confidential (i.e. it is not exposed to individuals/ entities for which it is not meant) and users can perform only those tasks that they are authorized to perform (e.g. a user should not be able to deny the functionality of the web site to other users, a user should not be able to change the functionality of the web application in an unintended way etc.).

Some key terms used in security testing

Before we go further, it will be useful to be aware of a few terms that are frequently used in web application security testing:

What is “Vulnerability”?
This is a weakness in the web application. The cause of such a “weakness” can be bugs in the application, an injection (SQL/ script code) or the presence of viruses.

What is “URL manipulation”?
Some web applications communicate additional information between the client (browser) and the server in the URL. Changing some information in the URL may sometimes lead to unintended behavior by the server.

What is “SQL injection”?
This is the process of inserting SQL statements through the web application user interface into some query that is then executed by the server.

What is “XSS (Cross Site Scripting)”?
When a user inserts HTML/ client-side script in the user interface of a web application and this insertion is visible to other users, it is called XSS.

What is “Spoofing”?
The creation of hoax look-alike websites or emails is called spoofing.
Security testing approach:

In order to perform a useful security test of a web application, the security tester should have good knowledge of the HTTP protocol. It is important to have an understanding of how the client (browser) and the server communicate using HTTP. Additionally, the tester should at least know the basics of SQL injection and XSS. Hopefully, the number of security defects present in the web application will not be high. However, being able to accurately describe the security defects with all the required details to all concerned will definitely help.

1. Password cracking:

The security testing on a web application can be kicked off by “password cracking”. In order to log in to the private areas of the application, one can either guess a username/ password or use some password cracker tool for the same. Lists of common usernames and passwords are available along with open source password crackers. If the web application does not enforce a complex password (e.g. with alphabets, number and special characters, with at least a required number of characters), it may not take very long to crack the username and password.

If username or password is stored in cookies without encrypting, attacker can use different methods to steal the cookies and then information stored in the cookies like username and password.

For more details see article on “Website cookie testing”.

2. URL manipulation through HTTP GET methods:

The tester should check if the application passes important information in the querystring. This happens when the application uses the HTTP GET method to pass information between the client and the server. The information is passed in parameters in the querystring. The tester can modify a parameter value in the querystring to check if the server accepts it.

Via HTTP GET request user information is passed to server for authentication or fetching data. Attacker can manipulate every input variable passed from this GET request to server in order to get the required information or to corrupt the data. In such conditions any unusual behavior by application or web server is the doorway for the attacker to get into the application.

3. SQL Injection:

The next thing that should be checked is SQL injection. Entering a single quote (‘) in any textbox should be rejected by the application. Instead, if the tester encounters a database error, it means that the user input is inserted in some query which is then executed by the application. In such a case, the application is vulnerable to SQL injection.

SQL injection attacks are very critical as attacker can get vital information from server database. To check SQL injection entry points into your web application, find out code from your code base where direct MySQL queries are executed on database by accepting some user inputs.

If user input data is crafted in SQL queries to query the database, attacker can inject SQL statements or part of SQL statements as user inputs to extract vital information from database. Even if attacker is successful to crash the application, from the SQL query error shown on browser, attacker can get the information they are looking for. Special characters from user inputs should be handled/escaped properly in such cases.

4. Cross Site Scripting (XSS):

The tester should additionally check the web application for XSS (Cross site scripting). Any HTML e.g. <HTML> or any script e.g. <SCRIPT> should not be accepted by the application. If it is, the application can be prone to an attack by Cross Site Scripting.

Attacker can use this method to execute malicious script or URL on victim’s browser. Using cross-site scripting, attacker can use scripts like JavaScript to steal user cookies and information stored in the cookies.

Many web applications get some user information and pass this information in some variables from different pages.

E.g.: http://www.examplesite.com/index.php?userid=123&query=xyz

Attacker can easily pass some malicious input or <script> as a ‘&query’ parameter which can explore important user/server data on browser.

Important: During security testing, the tester should be very careful not to modify any of the following:

•  Configuration of the application or the server
•  Services running on the server
•  Existing user or customer data hosted by the application

Additionally, a security test should be avoided on a production system.

The purpose of the security test is to discover the vulnerabilities of the web application so that the developers can then remove these vulnerabilities from the application and make the web application and data safe from unauthorized actions.

---------------------
I just wanted to thank you for subscribing to SoftwareTestingHelp.com. This blog is a success because of you and your support. Here's to your success!

As always, I appreciate your valuable comments. Visit below link to post your comment:
An approach for Security Testing of Web Applications

Thank you so much! ---------------------
Recommended: TestLodge - Online test case management tool - Web based test case management software allowing you to manage your test plans, requirements, test cases and test runs with ease.