SQL Injections and Domain Security

In 2005, a MySpace user named ‘Samy‘ decided to make his profile more popular. He realized he could make anyone who visits his profile send him a friend request simply by writing a self-replicating script. After a user visited his page, the script was copied to the visitor’s page, and so on. The ball started rolling and within a day he had more than 1 million friends. This may seem like a funny little story, but the guy did go to jail for it. No one really suffered, but would the attack contain a more ‘evil’ script, those 1 million users could have had deeper issues than having an extra friend.

The story is related to XSS-type of attacks against web applications, described further on. In preparation for one of my final exams, I figured it would be a good idea to try and explain two of the main topics I am studying. As the title points out, the topics are SQL injections and domain security.

SQL Injections

What is SQL?

SQL stands for Structured Query Language and is one of the widely-used languages for managing relational database management systems. The language is divided into different elements: clauses, expressions, queries, and statements. It is mainly used for the following:

  • executing queries against a database
  • retrieving data from a database
  • inserting\updating\deleting records in a database
  • creating and setting databases\tables\stored procedures\views in a database

SQL Language differentiates between two syntax groups. Some of the most commonly-used keywords used in SQL are: UPDATE (for updating data), SELECT (for retrieving data), INSERT INTO (for inserting new data), DELETE (for deleting data). These are a part of a sub-set of SQL syntax also referred to as Data Manipulation Language (DML).

Data Definition Language (DDL) is the second subset of SQL vocabulary, which is used to define structures and databases. Common keywords are: CREATE (creates a structure), ALTER (modifies a structure), DROP (deletes a structure).

Let’s see SQL work in practice. Here we have a database ‘db’ with a table ‘users’:

UserID FirstName FavoritePizza Password Active
1234 Tom Pepperoni password1 1
2222 Jim Cheese iLikeApples 0
3214 Max I don’t eat carbs 2222333344441111 1

We use the above mentioned keywords for performing queries to achieve our goal, for instance:

SELECT Password
FROM users
WHERE UserID = 1234;

The statement would return ‘Password=password1’.

For a deeper understanding of SQL, take a look at w3schools.

SQL Injections

We can already suspect that SQL injections have to do with injecting SQL commands into a vulnerable application. This is one of the most prominent vulnerabilities across web applications, as it requires the designer to construct database queries with this potential vulnerability in mind.

Let’s say that we have a webpage ‘www.vulnerable.site’ taking user input into two fields: ‘$userID’ and ‘$password’, hence it is a login form. We also assume that this is being handled on backend by passing the input in directly into an SQL query, looking like this:

$SQLquery = "SELECT UserID, Password, Active FROM users WHERE UserID='"

There are a lot of things wrong with this, but it will serve well as an example. Being a very vulnerable statement, an adversary could leverage this vulnerability without flexing their muscles too much. If they wanted to login as any user from the database through the form on our webpage, they would simply need to enter a simple string into the field asking for a username:

'or 1=1 --

What this query does is it a) closes the string, b) gives a tautology argument 1=1, and c) comments out the rest of the query. So when the server receives this query, it will be passed into the DB engine as:

SELECT UserID, Password, Active FROM users WHERE UserID='' or 1=1

The returned values will contain UserID, Password, and Active fields from ALL users in the database. Not something you would want to have happen.

If you like pictures, here is an example of how to make people hate a web application:

SQL injection example

From the above example, we can conclude that having a function passing input directly in a query is especially bad.

Prevention Tactics

There are many good (and not so good) techniques for making sure that queries don’t get manipulated into executing something they are not intended to. For instance:

  • Whitelisting/blacklisting the input:
    • Blacklisting can cause more headache due to the amount of use cases.
    • Whitelisting is a preferred choice.
  • Escaping the input:
    • For instance: escape quotation marks, etc.
    • Does not solve second order SQL injections if not escaped properly.
  • Prepared statements and binding variables:
    • Language-specific solution.
    • Creates static queries with bind variables (placeholders), which can be processed to ensure input validity


To prevent data leaks from database, if the adversary happens to get to the data in some way, it is helpful to know of some mitigation techniques

  • Prevent schema leaks:
    If an attacker knows the structure of the database he is trying to break in, it can help them greatly towards achieving the goal. To prevent this, never return detailed errors.
  • Least-privilege principle
    Create a hierarchy among user types; do not give a user more permissions than required
  • Encrypt sensitive data
  • Apply security policies to the DB server and host OS

Web Application Security

Domain Security

This section discusses how domains function, how they are protected, and how they are vulnerable.

All modern browsers today use Dynamic HTML (DHTML), which is an overarching term for a set of technologies used to create representations of web sites. One of commonly combinations used is:

  • HTML; static markup language
  • CSS; presentation language
  • JavaScript; client-side scripting language
    • *PHP; server-side scripting language
  • *DOM; document object module
DHTML technologies interaction

How these work together in DHTML is pretty straight-forward: scripting languages can dynamically change the DOM, which consists of variables defined in static markup languages (upon a successful page load).

An important entity to mention at this point is Same-origin policy. It prevents scripts from accessing properties of documents from different origins. What this means is that a script on ‘www.page.com’ (let’s call it origin page for future references) will not be able to access properties of a DOM on ‘www.page2.com’, however, it has access to other sub-domains, such as ‘www.page.com/sub/domain’. Following are three ways an origin page can compromise the same-origin policy.

  1. ‘www.page.com’ can include a link to ‘www.page2.com’, or it can have an embedded frame that will open it, but it can’t control its DOM (or the other way around)
  2. Should the origin page contain a script for loading data from a different domain, e.g.: ‘www.page2.com’ It will execute a script from the targeted site, while originating from the origin site (this can be a big issue in XSS).
  3. Finally, the origin page can also send requests to an external server, by embedding a form in HTML and calling it via a script.

Browsers usually store or ‘cache’ cookies and/or HTTP authentication credentials. Both of these depend on the type of user-specific browser settings, as well as agnostic browser settings. We will see how these can be compromised in further on as we dive into two attack patterns.


Yum. Nope, not when it comes to XS-type attacks. HTTP cookie, internet cookie, cookie, is data stored (cached) in memory by your web browser for the duration of browser’s lifetime. This data is shared among browsers. There are many different types but the one we are interested in are authentication cookies, which serve as a popular means for convenient authentication mechanisms some web applications put in place. While cookies are an easy solution for a lot of problems, they can cause many as well. Enter XSRF and XSS.

Cross-Site Request Forgery (XSRF | CSRF)

XSRF Timeline

The big picture here is that a malicious site (let’s call it ‘www.malicious.site’) can initiate HTTP requests to our site (‘www.site.com’), which uses cookie authentication, without user’s knowledge. In rough, it exploits the trust a certain site has in the victim.

Let’s say Bob visits malicious site. The site can send a request to our website (where Bob has an account and a stored authentication cookie, stored by the browser), attempt to use the cached cookie for authenticating as Bob, and, if successful, change his password for instance. There are a lot of things that have to go right here (for instance knowing the correct endpoint that receives the request, as well as counting on the authentication cookie to be valid), but the example shows a way XSRF are used in. Malicious site will not be able to read the properties of our site, but it will have the ability to send a write request (hence, changing the password).

From this we see the implication that XSRF attacks are of a static nature. However, they can be a precursor to a XSS attack – Samy.

Cross-Site Scripting (XSS | CSS)

XSS Timeline

We talk about XSS when an adversary attempts to have their malicious script execute on our web application. Sounds worrying. The two types of XSS are:

  • Reflected: injected script returns parameters in a request immediately
  • Stored: script is delivered to the victim when a certain condition is met, or after some time

In this case the web application must be vulnerable for script injection in some way, for instance: our site contains a search bar that does nothing to sanitize the input, enabling an attacker to input special characters. This would enable him to manipulate a link to look like this:


If the attacker sends this link to someone, it will take them to ‘www.site.com’, but it will also run the script ‘cookiestealer.js’ from ‘www.malicious.site’. This script would be able to steal victim’s authentication cookie. potentially making a lot of issues for the victim.

The above is a very rudimentary example, a more sophisticated scenario would involve injecting a more complex scripts with a more sophisticated goal. Modifying web pages would be another more dangerous side effect, since attacker could potentially manipulate DOM, which would not change the URL, would not cause a certificate mismatch, and would be hard to tell whether the modification of DOM was made by someone other than the owner.

Apart from XSRF and XSS, there are many other types of


While the above are serious attacks, they are usually hard to execute against even semi-well protected web applications. Things to consider regarding XSRF are:

  • Inspecting ‘Referer’ headers
    • Specifies the URI of origin
    • Not reliable in practice, because they can be forged or hidden
  • Creating a user-specific key for validation
    • Prompt user for a pre-defined key (password) when server-side changes are to be made
  • Using ‘Action’ (STP) tokens for validation
    • use a special token in hidden fields of valid forms (e.g. the ones that are actually to be sent)
    • or just bind the action token to a cookie
  • Implementing own methods for distinguishing valid requests
  • Use POST over GET

For safeguarding against XSS, think of the following:

  • Output encoding/input escaping
    • HTML/JS/CSS escaping
  • Don’t send untrusted data to browsers
  • Whitelisting

‘or 1=1 —

Cool, let’s stop here. It did the job – I went over a big chunk of material for the exam. It was a bit lengthy, so thank you for your time!

p.s.: Don’t go poking around the Web to see if you can execute a script or an SQL query. That’s quite illegal.



One thought on “SQL Injections and Domain Security

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s