Mantra to catch security issues – Repeat the test 10 times and note down every parameter

Sometimes, to identify security flaws in our applications, we don’t need a tool. By repeating a simple test multiple times, we can easily find the security flaws in our application. Following are a few ways to find security flaws by the mantra:

Session ID Sequence

Generally, a Session ID will be created once after the user logs in to a website and used to maintain session or state for that particular user interacting with website.

A few web servers generate these session Ids just by incrementing a static number instead of using a complex method or algorithm which generates random session Ids. These kind of security issues can be found easily by testing a scenario repeatedly.

When a test is executed for the first time, note down the session id parameter value. Repeat the steps for 10 times. If you observe that the session ID is being increased by a static number or some predicted randomness, then it’s easy to crack and your web application is at risk.

Captcha sequence

Captcha, an image with different alphanumeric characters is used to differentiate human and robots while logging in to the websites.

It is really easy to notice the pattern of the captcha if we repeat the test. If we note down the captcha each time the test is executed, it’s easy to find if captcha’s follows a particular pattern or algorithm. Check and see if you can predict a patters between words. Another way – Repeat your test for 100 times. One predicted randomness is to have 100 captchas and then rotate them randomly. Definitely crackable, right?

Number of login attempts 

Write a test to login with wrong credentials. Repeat the test. After a particular login attempts, if the application login is still active, then it’s a major security flaw and can be broken by brute force attacks. If there are different login attempts, the web application should block authentication for a few hours and then block completely after a specific number of attempts.

Security issues can be easily found by following the mantra – Repeat the tests and try to find a pattern. Isn’t this the way hacking works?

Image references:
http://tr1.cbsistatic.com/hub/i/2013/08/05/1b80a46a-99ff-4c01-a4a8-36c5e6be326a/Kill%20Captcha.png

How do we test our SQL queries?

For most QA engineers, testing a SQL query involves writing a query and checking the output. Well this is definitely the first step but only a first step in checking the correctness of a query. Take an example:

Select * from customer where cust_num>10 and cust_name LIKE '%berdeen%' order by cust_num,cust_name;

Sounds like a simple query with a where clause.

This simple query involves several challenges which are also termed as phases to process which fetches data in fraction of seconds from tables having humongous data.

SQL processing actually involves several stages of parsing, optimization, row source generation, and execution of a SQL statement. There needs to be a check at all these stages and that’s how we do our SQL testing. Let’s look at each of these phases and what we test at each phase.

·        Parsing 

This state involve in syntax and semantic check for correctness of statement

Syntax validation must check each SQL statement for syntactic validity

Example :

               SELECT * FORM customer…;

              

ERROR at line 1:: FROM keyword not found where expected

Semantic validation checks and determines whether a statement is meaningful, for example, whether the objects and columns in the statement exist.

Example :

SELECT * FROM nonexistent_table;

SELECT * FROM nonexistent_table

              *

ERROR at line 1:: table or view does not exist

We need to have the tests to check the parser, not always the correct query. So the first step is done where we test the parser with accurate and inaccurate queries.

·        Optimization

The query optimizer (called simply the optimizer) is built-in database software that determines the most efficient method for a SQL statement to access requested data. The optimizer attempts to generate the best execution plan for a SQL statement. The best execution plan is defined as the plan with the lowest cost among all considered candidate plans. The cost computation accounts for factors of query execution such as I/O, CPU, and communication. Because the database has many internal statistics and tools at its disposal, the optimizer is usually in a better position than the user to determine the best method of statement execution. For this reason, all SQL statements use the optimizer and lot of algorithms are involved in this process.

Example:

Consider above sql statement where if we define index on the cust_num then optimizer will generate a query plan based on the index and the restrictions placed on the data fetching. Here in the above query we intend to sort the data on cust_num and cust_name .But optimizer with its intelligence takes the index column that is cust_num and fetch the data in the sorted order from the index column during fetching of data rather than sorting it again once the data is completely fetched .This will make query execute faster.

So always check how optimizer has optimized your queries. We are covering performance aspects of the query along with functionality by doing this, two birds for a shot.

·        Fetching the data

During execution, the SQL engine executes the query plan for fetching the data from the specified. In the above sql query sql execution consider the index column and get the data in sorted order based on cust_name which will indeed doesn’t need to sort the generated data as during the time of fetching the data it comes in sorted order.

Here we are finally testing for correctness of the results.

Any SQL query testing involves all these three functions and your testing is complete only when you test them all. If not, you are leaving large holes in your testing.

Why do customer find bugs even after our extensive testing

Everything is interconnected in this world. Take butterfly effect as an example. The butterfly effect (coined by Edward Lorenz) is the sensitive dependence on initial conditions in which a small change in one state of a deterministic nonlinear system can result in large differences in a later state. An another example from the same article - The randomness of the outcomes of throwing dice depends on this characteristic to amplify small differences in initial conditions—the precise direction, thrust, and orientation of the throw—into significantly different dice paths and outcomes, which makes it virtually impossible to throw dice exactly the same way twice.

Now coming back to our world of software – In a small subsystem, it’s easy to predict the results of an action. Provide a specific input and the result will always be consistent. Now think of bigger subsystems with many connected systems passing through different layers. The precise amount of data, load, network and the parameters might cause something to fail. A software update to a different subsystem can cause failure somewhere else. A series of small changes can influence the output. This is why customers find bugs that we miss. In a closed room, it’s easy to predict the result of an action, like bouncing a ball. In an open world, it depends on many criteria’s, like the direction of wind, the UFO’s that might suddenly fly through and many more possibilities.

What do we need to do to find customer bugs? Switch from testing a smallest unit of code to test scenarios, switch your testing from smaller input and output to large customer like apps, switch from tests that run for an hour to 24*7 tests, switch to bigger subsystems where many pieces are interconnected, where there is sensitive dependency and you can see the butterfly effect. Call us if you still see issues from customers after this :)

Integrating TestNG with Eclipse

TestNG is a testing framework developed for JAVA programming language. The “NG” means for “Next Generation”. The goal of designing TestNG is to cover different types of testings like functional, unit, integration, end-to-end etc.

               There is a TestNG plug-in for eclipse, which allows us to run the tests from Eclipse and monitor the scripts execution easily.

Follow the below steps to integrate TestNG with Eclipse.

Step -1: Menu -> Help -> Install New Software

Step -2: "Install" wizard will open upon clicking "Install New Software". Now click on "Add" button in "Install" wizard.

Enter “TestNG” for “Name” field and for “Location” provide value as http://beust.com/eclipse

Click “OK” button.

Step – 3: Continue the installation by clicking “Next” button until finish the TestNG installation.

Once the installation is done, we can check installation is completed properly or not by following below steps:

1. Open eclipse.
2. Click on Menu -> New -> Project
3. Expand "Java" under 'Show View" wizard, we get "TestNG".

Now, we can create TestNG project for writing the testcases.

Fore more information refer link http://testng.org