Difference between QA & QC

By meaning, quality assurance is the method of verifying or determining whether product or services meet or exceed customer satisfaction. It has five cycle plus they be “Plan, do, check and act”. Quality assurance team plans on how to produce a product or service that will meet a customer appreciation or satisfaction at the end of the day or releasing the product. After planning, execution takes place and deliverables are checked for conformity or variance.

Quality control on the other hand is a process employed to ensure a certain level of quality in a product or service. Test Engineers comes under QC because the responsibility of QC Group are to Test the application before deliver it to client. QC performs Validation that includes actual testing like Functional, Regression, and Sanity and so on.

QA group is the Process oriented and has the responsibility verify and implement that the Process are followed or not. QA are Proactive. QA perform verification that includes Inspection, walkthrough, Audit and so on.
QA and Testing both make software better. QA enhance the quality via a progress of development process, the related methods & systems and Testing enhances it via finding defects and enabling improvements/corrections.

Quality Assurance makes sure you are doing the right things, the correct way.
Quality Control makes sure the result of what you’ve done is what you expected.
Generally, QA and QC (Test Engineers) both are separate group and both different functioning.

XSS - Cross Site Scripting

Cross site scripting (XSS) flaws are a relatively common issue in web application security. 
Cross-Site Scripting attacks are a type of injection problem, in which malicious scripts are injected into the otherwise benign and trusted web sites. Cross-site scripting (XSS) attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user in the output it generates without validating or encoding it.
An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by your browser and used with that site. These scripts can even rewrite the content of the HTML page.

Cross-Site Scripting (XSS) attacks occur when:

• Data enters a Web application through an untrusted source, most frequently a web request.
• The data is included in dynamic content that is sent to a web user without being validated for malicious code.

Black Box testing and example

One way to test for XSS vulnerabilities is to verify whether an application or web server will respond to requests containing simple scripts with an HTTP response that could be executed by a browser. For example, Sambar Server (version 5.3) is a popular freeware web server with known XSS vulnerabilities. Sending the server a request such as the following generates a response from the server that will be executed by a web browser:

http://server/cgi-bin/testcgi.exe?<SCRIPT>alert(“Cookie”+document.cookie)</SCRIPT>

The script is executed by the browser because the application generates an error message containing the original script, and the browser interprets the response as an executable script originating from the server. All web servers and web applications are potentially vulnerable to this type of misuse, and preventing such attacks is extremely difficult.

Example 1:
Since JavaScript is case sensitive, some people attempt to filter XSS by converting all characters to upper case, rendering Cross Site Scripting utilizing inline JavaScript useless. If this is the case, you may want to use VBScript since it is not a case sensitive language.

JavaScript:
<script>alert(document.cookie);</script>
VBScript:
<script type="text/vbscript">alert(DOCUMENT.COOKIE)</script>

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.

Next: SQL Injection

SQL Injection

Before going to SQL-INJECTION we should know about SQL and Databases.

Database - Database is nothing but collection of data. In website point of view, database is used for storing user ids,passwords,web page details and more.
For Example -

Oracle
DB servers
MySQL(Open source)
MSSQL
MS-ACCESS
Postgre SQL(open source)
SQLite

SQL:
SQL is nothing but Structured Query Language. In order to communicate with the Database ,we are using SQL query. We are querying the database so it is called as Query language.

What is SQL Injection ?
      The goal of SQL injection is to insert arbitrary data, most often a database query, into a string that’s eventually executed by the database. The insidious query may attempt any number of actions, from retrieving alternate data, to modifying or removing information from the database.
      This is a hacking method that allows an unauthorized attacker to access a database server. It is facilitated by a common coding blunder. The program accepts data from a client and executes SQL queries without first validating the client’s input. The attacker is then free to extract, modify, add, or delete content from the database. In some circumstances, he may even penetrate past the database server and into the underlying operating system.
      Hackers typically test for SQL injection vulnerabilities by sending the application input that would cause the server to generate an invalid SQL query. If the server then returns an error message to the client, the attacker will attempt to reverse-engineer portions of the original SQL query using information gained from these error messages.

What an Hacker can do ?
ByPassing Logins
Accessing secret data
Modifying contents of website
Shutting down the My SQL server

1) Finding Vulnerable Website:

We can find the Vulnerable websites(hackable websites) using Google Dork list. Google dork is searching for vulnerable websites using the google searching tricks. There is lot of tricks to search in Google. But we are going to use "index.php?" command for finding the vulnerable websites.
Some Examples:
index.php?action=
index.php?content=

How to use?
copy one of the above command and paste in the google.com and hit enter.
You can get list of web sites.
We have to visit the websites one by one for checking the vulnerability. Lets start..
Click on first website http://www.amsn.ro/index.php?action=2

2) Check the Vulnerability:
In order to check the vulnerability ,add the single quotes(') at the end of the url and hit enter. There should not space between the number and single quotes.
for ex. http://www.amsn.ro/index.php?action=2'
You get Google Dork List from here

Note : If the page remains in same page or showing that page not found or showing some other webpages. Then it is not vulnerable.
If it showing any errors which is related to sql query,then it is vulnerable.

Lets see more examples,

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

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

SELECT * FROM Users WHERE User_Name = ‘anup’ AND Password = ‘amit’;

If the tester would enter anup’– as UserName and no Password, the SQL statement would become:

SELECT * FROM Users WHERE User_Name = ‘anup’– AND Password = ‘amit’;

If the tester does not know about the user name In such a case, the tester could try common user names like admin or administrator. If none of these users exist in the database, the tester could enter anup’ or ‘x’=’x as strUserName and amit’ or ‘x’=’x  as strPassword. This would cause the SQL statement to become like the one below.

SELECT * FROM Users WHERE User_Name = ‘anup’ or ‘x’='x’ AND Password = ‘amit’ or ‘x’=’x’;

Since ‘x’=’x’ condition is always true, the result set would consist of all the rows in the Users table.

If the tester would enter anup’; 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 = ‘anup’; DROP table users_details;’ –‘ AND Password = ‘amit’;

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.

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.

Read more on Cross Site Scripting

Security Testing Of Web Applications

1) Verify that all Usernames and Passwords are encrypted and they transferred over secured connection like https:// (Secured transaction).

Security testing is the process that determines that “The confidential data should be stay confidential”, security testing of web applications is very important. In web application users can perform only those tasks that they are authorized to perform.

While doing security testing some key points should be considered-
2) Verify information stored in COOKIES. It should not be in readable format.
3) Verify all HTTP methods.
4) Verify user session ends when user log off. Verify memory leak and buffer overflow.
5) Error messages should be generic. Whereas it should not mention specific error like “Invalid username” or “Invalid password”.
6) Password should be at least 8 characters long containing at least one number and one special character.
7) Username should not be like “administrator” or “admin”.
8) Application login page should be locked upon few unsuccessful login attempts.
9) Custom error messages should be displayed to end user in case of web page is crash.
10) All files must be scanned before uploading to server.
11) Sensitive data should not be passed in urls while communicating with different internal modules of the web application.
12) Verify application for 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).
13) Verify application for CROSS SITE SCRIPTING. (XSS- 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).
14) Important input validations should be done at server side instead of JavaScript checks at client side.
15) Verify that all applications and database versions are up to date.
16) Verify memory leakage and buffer overflow.
17) Verify if incoming network traffic is scanned to find Trojan attacks.
18) Firewall – Make sure entire network or computers are protected with Firewall. Firewall can be a software or hardware to block unauthorized access to system. 
19) Verify if reset password functionality is secure.

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.