Chapt# 5 OWASP: SQL Injection

and XSS
Open Web Application Security Project
(OWASP)
• The Open Web Application Security Project (OWASP) is an
open community dedicated to enabling organizations to
develop, purchase, and maintain applications that can be
trusted.

• OWASP Top 10 Application Security Risk

 Unchecked User Input
Input Sources Vulnerabilities
Parameter manipulation SQL Injection
URL manipulation HTTP response splitting
Header manipulation Cross-site scripting
Cookie poisoning Path traversal
Command injection

When input is not properly sanitized before use, a

variety of vulnerabilities are possible.
What is SQL Injection?

• It is a kind of web application attack where user supplied input

coming from:
• URL: www.abc.com?id=1
• Login forms: username=John Doe
• Other elements such as cookie, HTTP headers

is manipulated so that vulnerable application

executes SQL commands injected by attacker.
Methods of Injection

• Injection into source code of website

• Injection into the URL

SQL Injection
• SQL injection attacks are a type of injection attack, in which
SQL commands are injected into data-plane input in order to
effect the execution of predefined SQL commands.

• Consists of insertion or "injection" of a SQL query via the

input data from the client to the application

• A successful SQL injection exploit can:

• Read sensitive data from the database
• Modify database data (Insert/Update/Delete)
• Execute administration operations on the database (such as
shutdown the DBMS)
• Recover the content of a given file present on the DBMS file
system
• In some cases issue commands to the operating system.
Attacks

• Injection can result in:

• Data loss or corruption
• Lack of accountability or denial of access
• Can lead to complete host takeover
• All data can be stolen, modified, or deleted
Preventions
• Preventing injection requires keeping untrusted data separate
from commands and queries.

• Types of Preventions:
1. Use a safe API which avoids the use of the interpreter
entirely or provides a parameterized interface.
2. Carefully escape special characters using the specific
escape syntax for that interpreter.
3. Positive or “white list” input validation, but this is not a
complete defense as many applications require special
characters in their input.
How it works and why
• “The vulnerability happens when user input is either incorrectly
filtered for string literal escape characters embedded in SQL
statements or user input is weakly typed and unexpectedly executed.”

• String literal escape characters are characters that initiate different

controls in a program (authenticate, end program, etc.). If a program
is incorrectly filtered it will not reject other characters such as (#, <, >,
=, *, etc.)

• Weak-typed means the software was written in a language that does

not support memory safety, type safety, static type safety, or dynamic
type safety. Java is strongly typed, however C++ is weakly typed and it
is what SQL is written in. Hence why SQL is a popular target.
Step One: Casing
• Find a website with a URL that looks like one of the following
example:
• http://www.hackingstuffs.com/items.php?id=5

• Look for the “php?id=5” note: can be any number after the = sign.

• Now type an invalid string literal escape character after the last
character in the URL, in this case after the “5”. An apostrophe ‘ or
pound sign # are recommended.

• If the site produces and error such as “syntax error” or “error on

line 23” or any similar error, the website you found is vulnerable
to an SQL injection. If an error is not produced, search for a new
website.
Example Attack Scenarios
Scenario #1: An application uses untrusted data in the construction of the
following vulnerable SQL call:

String query = "SELECT \* FROM accounts WHERE custID='" +

request.getParameter("id") + "'";

Scenario #2: Similarly, an application’s blind trust in frameworks may result in

queries that are still vulnerable, (e.g., Hibernate Query Language (HQL)):

Query HQLQuery = session.createQuery("FROM accounts WHERE

custID='" + request.getParameter("id") + "'");

In both cases, the attacker modifies the ‘id’ parameter value in their browser to
send: ' UNION SLEEP(10);--. For example:
http://example.com/app/accountView?id=' UNION SELECT
SLEEP(10);--

This changes the meaning of both queries to return all the records from the
accounts table. More dangerous attacks could modify or delete data or even invoke
stored procedures.
Step Two: Choose method of injection
• There are many ways to launch an SQL injection. Here are two common
ones.

• SQL Tag Injection: Type a pound sign (#) into the websites URL followed
by malicious code. SQL tags use a format like this:

• #TABLE1_SELECT_ROW2ksd9204255nazx

• If you know SQL than you can give the table commands remotely,
including pasting in source code for viruses.

• This method is more flexible and allows a wider range of options, yet for
simplicity sake we will use a second option.

• The second option: a generic SQL injection.

Step Three: Find a login/admin page
• Look for a page with a URL similar to the following:
• http://www.hackingstuffs.com/login.php
• http://www.hackingstuffs.com/admin_login.php
• You can also use an SQL injection tool to help you
find the login page, some examples being Absinthe,
Havij, or sqlmap. We will not cover the use of tools
however.
• Now it is time to launch the SQL Injection attack.
Havij, SQLmap
Step 4: Launching the Attack
• Type any of the following on the
username and password section of
the login page
• 1′ OR ’1′=’1
• 1 OR 1=1
• 1’1
• 1 AND 1=1
• 1 EXEC SP_ (or EXEC XP_)
• 1′ AND 1=(SELECT COUNT(*)
FROM tablenames); –
• If none of the codes work, look for
more by searching “SQL Injection
Codes”
Step 5: Malicious Activity
• You are now in the system and have successfully hacked a website.
Congratulations! At this point, you may want to leave (if you are only
hacking to learn that is).

• You now have full reign over an SQL database. What you do with the
database is up to you. You can access and edit the database like any
other user, except that you have to hack in again (unless you inject a
script that opens a backdoor to the database you can use).
• For more information on what you can do once inside, refer to the
following:
• http://www.unixwiz.net/techtips/sql-injection.html
How to Defend?
How to avoid SQL Injection

• As long as injected SQL code is syntactically correct,

tampering cannot be detected programmatically.

• Therefore, you must validate all user input and

carefully review code that executes constructed SQL
commands in the server that you are using.
Some tips:
• Filter and validate all input data

• Separating code from data by making use of

prepared and stored procedures

• Making use of escape characters

1. Filter out character like single quote, double quote,
slash, back slash, semi colon, extended character
like NULL, carry return, new line

a. input from users

b. parameters from URL
c. values from cookies

2. Convert all numeric values into integer before

parsing into SQL statement.
Cross-Site Scripting (XSS)
• XSS flaws occur whenever an application takes untrusted data
and sends it to a web browser without proper validation or
escaping.

• XSS allows attackers to:

• Execute scripts in the victim’s browser which can hijack
user sessions
• Deface web sites
• Redirect the user to malicious sites
Attacks

• Attackers can execute scripts in a victim’s browser:

• To hijack user sessions
• Deface web sites
• Insert hostile content
• Redirect users
• Hijack the user’s browser using malware
Definition
• Cross-Site Scripting (XSS) is type of computer security
vulnerability typically found in Web applications.

• XSS enables attackers to inject client-side script into Web

pages viewed by other users.

• A cross-site scripting vulnerability may be used by attackers

to bypass access controls such as the same origin policy.

• XSS attacks can be used for a variety of purposes:

stealing cookies/accounts/PII, defacing websites, injecting
worms, malware attacks, DOS attacks, bypassing restriction,
session hijacking, phishing attacks, etc.
Types of XSS
• Stored: The Persistent or Stored XSS attack occurs when the
malicious code submitted by attacker is saved by the server in the
database, and then permanently it will be run in the normal page.

• Reflected: The injected code will be send to the server via HTTP
request. The server embed the input with the html file and return
the file (HTTP Response) to browser. When the browser executes
the HTML file, it also execute the embedded script.

• DOM (Document object model): Allows client-side-scripts to

dynamically access and modify the content, structure, and style of
a webpage via the document of the DOM.
Like server-side scripts, client-side scripts can also accept and
manipulate user input with the help of DOM.
Step One
• Finding Vulnerable Websites:
• A better option than just searching random websites
is using google dorks from exploit database.

• Use search terms such as "?search=" or ".php?q="

or “ 1337”

•
 Step Two
• Testing the Exploit:
• First find a data entry point, like a search box or a
username/password field.

• Type a String into the field and click view source. Look for
something like “<p>Hello myString </p>” this is the format we
want to see.

• Check to see if the input is sanitized by typing in “<script>” and

clicking view source.

• If you see something like the String example, the website is

vulnerable. If we see something like this “&lt;script&gt” than
the website is not vulnerable.
Step Three
• Using the Exploit:
• As a final test of whether the exploit will work, type
in a JavaScript command such as
“<script>alert(‘myString')</script>” into the data
field.

• If a pop-up appears that reads “myString” than you

can further exploit the website.
Preventions
• Preventing XSS requires keeping untrusted data separate
from active browser content.

• Types of Preventions:
1. Encoding – Escaping any character a user enters before
displaying it
2. Whitelisting – Only allow certain characters (e.g. A-Z and
0-9) to be entered
3. Blacklisting – Not allowing a user to enter sequences such
as <script> or <and>
References
• https://www.owasp.org/index.php/Top_10
• https://www.owasp.org/index.php/SQL_Injection
• https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
• http://www.unixwiz.net/techtips/sql-injection.html
• https://www.owasp.org/index.php/Testing_for_Cross_site_scripting
• https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
• http://msdn.microsoft.com/en-us/library/a2a4yykt(v=vs.85).aspx