This presentation will provide you the deep knowledge of the Cross-Site Scripting and SQL Injection with the remediation and prevention measures.

1. Presented By:
VISHAL KUMAR
(CEH | CHFI | CISE | MCP)
Deep understanding on Cross-Site Scripting
and SQL Injection

2. CROSS SITE SCRIPTING
Outline
Introduction to XSS
Conditions for Cross site scripting
Cross site scripting – Risk and Damage
Types of XSS
Defending against Cross site scripting
Practice

3. CROSS SITE SCRIPTING
 Cross-site scripting (XSS) is a code injection attack that allows an attac
ker to execute malicious JavaScript in another user's browser.
 The attacker does not directly target his victim. Instead, he exploits a v
ulnerability in a website that the victim visits, in order to get the websit
e to deliver the malicious JavaScript for him. To the victim's browser, t
he malicious JavaScript appears to be a legitimate part of the website, a
nd the website has thus acted as an unintentional accomplice to the atta
cker.
1. Introduction to XSS
SattirxSecurity Preferred

4. CROSS SITE SCRIPTING
Scripting: Web Browsers can execute commands
 Embedded in HTML page
 Supports different languages (JavaScript, VBScript, ActiveX, etc.)
 Most prominent: JavaScript
“Cross-Site” means: Foreign script sent via a server to a client
 Attacker makes Web-Server deliver malicious script code
 Malicious script is executed in Client’s Web Browser
Attack:
 Steal Access Credentials, Denial-of-Service, Modify Web pages
 Execute any command at the client machine
1. Introduction to XSS
SattirxSecurity Preferred

5. CROSS SITE SCRIPTING
2. CONDITIONS FOR CROSS-SITE SCRIPTING
 A Web application accepts user input:
 Many web application accept the inputs from the user like search string,
 The input is used to create dynamic content
 The input is insufficiently validated
SattirxSecurity Preferred

6. Cross-Site Scripting
3. Risk Involve in Cross-Site Scripting
Denial-of-Service
 Crash Users 'Browser, Pop-Up-Floodding, Redirection
Access to authentication credentials for Web application
 Cookies, Username and Password
 Normal users (Personal data, Business data, Misuse of account)
 High privileged users (Control over Web application, web server and database)
Access to User`s machine
 Use ActiveX objects to control machine
 Upload local data to attacker`s machine
Spoil public image of company
SattirxSecurity Preferred

7. CROSS SITE SCRIPTING
4. Types of Cross Site Scripting - XSS
While the goal of an XSS attack is always to execute malicious JavaScript in the victim's
browser, there are few fundamentally different ways of achieving that goal. XSS attacks
are often divided into three types:
1. Persistent or Stored XSS, where the malicious string originates from the website's d
atabase.
2. Reflected XSS, where the malicious string originates from the victim's request.
3. DOM-based XSS, where the vulnerability is in the client-side code rather than the se
rver-side code.
SattirxSecurity Preferred

8. CROSS SITE SCRIPTING
4.1 Persistent or Stored XSS
SattirxSecurity Preferred

9. CROSS SITE SCRIPTING
4.1 Persistent or Stored XSS
1. The attacker uses one of the website's forms to insert a malicious string into the web
site's database.
2. The victim requests a page from the website.
3. The website includes the malicious string from the database in the response and sends
it to the victim.
4. The victim's browser executes the malicious script inside the response, sending the vi
ctim's cookies to the attacker's server.
SattirxSecurity Preferred

10. CROSS SITE SCRIPTING
4.2 Reflected XSS
In a reflected XSS attack, the malicious string is part of the victim's request to the website. T
he website then includes this malicious string in the response sent back to the user. The diagra
m below illustrates this scenario:
SattirxSecurity Preferred

11. CROSS SITE SCRIPTING
4.2 Reflected XSS
1. The attacker crafts a URL containing a malicious string and sends it to the victim.
2. The victim is tricked by the attacker into requesting the URL from the website.
3. The website includes the malicious string from the URL in the response.
4. The victim's browser executes the malicious script inside the response, sending the victim's
cookies to the attacker's server.
SattirxSecurity Preferred

12. CROSS SITE SCRIPTING
4.3. DOM-based XSS
DOM-based XSS is a variant of both persistent and reflected XSS. In a DOM-based XSS attack, the
malicious string is not actually parsed by the victim's browser until the website's legitimate JavaScript i
s executed. The diagram below illustrates this scenario for a reflected XSS attack:
SattirxSecurity Preferred

13. CROSS SITE SCRIPTING
4.3. DOM-based XSS
1. The attacker crafts a URL containing a malicious string and sends it to the victim.
2. The victim is tricked by the attacker into requesting the URL from the website.
3. The website receives the request, but does not include the malicious string in the response.
4. The victim's browser executes the legitimate script inside the response, causing the malicio
us script to be inserted into the page.
5. The victim's browser executes the malicious script inserted into the page, sending the victi
m's cookies to the attacker's server.
SattirxSecurity Preferred

14. CROSS SITE SCRIPTING
5. Defending against Cross site scripting
Recall that an XSS attack is a type of code injection: user input is mistakenly interpreted as mali
cious program code. In order to prevent this type of code injection, secure input handling is need
ed. For a web developer, there are two fundamentally different ways of performing secure input
handling:
1. Encoding, which escapes the user input so that the browser interprets it only as data, not as
code.
1. Validation, which filters the user input so that the browser interprets it as code without mal
icious commands.
SattirxSecurity Preferred

15. CROSS SITE SCRIPTING
5. Defending against Cross site scripting
While these are fundamentally different methods of preventing XSS, they share several commo
n features that are important to understand when using either of them:
 Context: Secure input handling needs to be performed differently depending on where in a p
age the user input is inserted.
 Inbound/outbound: Secure input handling can be performed either when your website receiv
es the input (inbound) or right before your website inserts the input into a page (outbound).
 Client/server: Secure input handling can be performed either on the client-side or on the se
rver-side, both of which are needed under different circumstances.
SattirxSecurity Preferred

16. CROSS SITE SCRIPTING
5.1. Encoding
Encoding is the act of escaping user input so that the browser interprets it only as data, not as
code. The most recognizable type of encoding in web development is HTML escaping, which conv
erts characters like < and > into &lt; and &gt;, respectively.
The following pseudocode is an example of how user input could be encoded using HTML escapin
g and then inserted into a page by a server-side script:
If the user input were the string <script>...</script>, the resulting HTML would be as follows:
SattirxSecurity Preferred

17. CROSS SITE SCRIPTING
5.1. Encoding
Because all characters with special meaning have been escaped, the browser will not parse any p
art of the user input as HTML.
SattirxSecurity Preferred

18. CROSS SITE SCRIPTING
5.2. Validation
Validation is the act of filtering user input so that all malicious parts of it are removed, without
necessarily removing all code in it. One of the most recognizable types of validation in web devel
opment is allowing some HTML elements (such as <em> and <strong>) but disallowing others (such
as <script>).
There are two main characteristics of validation that differ between implementations:
 Classification strategyUser: input can be classified using either blacklisting or whitelisting.
 Validation outcomeUser: input identified as malicious can either be rejected or sanitized.

19. SQL Injection
Outline
Introduction to SQL Injection
How SQL Injection Work
What’s the worst an attacker can do with SQLi?
Types of SQL Injection
Prevention against SQL Injection
Practice

20. SQL Injection
1. Introduction to SQL Injection
SQL Injection (SQLi) refers to an injection attack wherein an attacker can ex
ecute malicious SQL statements (also commonly referred to as a malicious payl
oad) that control a web application’s database server (also commonly referred
to as a Relational Database Management System – RDBMS). Since an SQL Inje
ction vulnerability could possibly affect any website or web application that ma
kes use of an SQL-based database, the vulnerability is one of the oldest, most
prevalent and most dangerous of web application vulnerabilities.
By leveraging an SQL Injection vulnerability, given the right circumstances, an
attacker can use it to bypass a web application’s authentication and
SattirxSecurity Preferred

21. SQL Injection
1. Introduction to SQL Injection
authorization mechanisms and retrieve the contents of an entire database. SQL Injection can al
so be used to add, modify and delete records in a database, affecting data integrity.
To such an extent, SQL Injection can provide an attacker with unauthorized access to sensitive
data including, customer data, personally identifiable information (PII), trade secrets, intellectu
al property and other sensitive information.
SattirxSecurity Preferred

22. SQL Injection
2. How SQL Injection works
In order to run malicious SQL queries against a database server, an attacker must first find an i
nput within the web application that is included inside of an SQL query.
In order for an SQL Injection attack to take place, the vulnerable website needs to directly inc
lude user input within an SQL statement. An attacker can then insert a payload that will be inclu
ded as part of the SQL query and run against the database server.
The following server-side pseudo-code is used to authenticate users to the web application.
SattirxSecurity Preferred

23. SQL Injection
2. How SQL Injection works
The above script is a simple example of authenticating a user with a username and a password ag
ainst a database with a table named users, and a username and password column.
SattirxSecurity Preferred

24. SQL Injection
2. How SQL Injection works
The above script is vulnerable to SQL Injection because an attacker could submit malicious inpu
t in such a way that would alter the SQL statement being executed by the database server.
A simple example of an SQL Injection payload could be something as simple as setting the passw
ord field to password’ OR 1=1.
This would result in the following SQL query being run against the database server.
SattirxSecurity Preferred

25. SQL Injection
2. How SQL Injection works
Once the query executes, the result is returned to the application to be processed, resulting in
an authentication bypass. In the event of authentication bypass being possible, the application w
ill most likely log the attacker in with the first account from the query result — the first accou
nt in a database is usually of an administrative user.

26. SQL Injection
3. What’s the worst an attacker can do with SQL?
SQL is a programming language designed for managing data stored in an RDBMS, therefore SQL can
be used to access, modify and delete data. Furthermore, in specific cases, an RDBMS could also run
commands on the operating system from an SQL statement.
Keeping the above in mind, when considering the following, it’s easier to understand how lucrative a s
uccessful SQL Injection attack can be for an attacker.
 An attacker can use SQL Injection to bypass authentication or even impersonate specific users.
 One of SQL’s primary functions is to select data based on a query and output the result of that
query. An SQL Injection vulnerability could allow the complete disclosure of data residing on a
database server.
SattirxSecurity Preferred

27. SQL Injection
3. What’s the worst an attacker can do with SQL?
 Since web applications use SQL to alter data within a database, an attacker could use SQL
Injection to alter data stored in a database. Altering data affects data integrity and could
cause repudiation issues, for instance, issues such as voiding transactions, altering balances
and other records.
 SQL is used to delete records from a database. An attacker could use an SQL Injection vuln
erability to delete data from a database. Even if an appropriate backup strategy is employed,
deletion of data could affect an application’s availability until the database is restored.
 Some database servers are configured (intentional or otherwise) to allow arbitrary executio
n of operating system commands on the database server. Given the right conditions, an attac
ker could use SQL Injection as the initial vector in an attack of an internal network that sits
behind a firewall.
SattirxSecurity Preferred

28. SQL Injection
4. Types of SQL Injection (SQLi)
SQL Injection can be used in a range of ways to cause serious problems. By levering SQL Inject
ion, an attacker could bypass authentication, access, modify and delete data within a database.
SQL Injection can be classified into three major categories –
1. In-band SQLi,
 Error-based SQLi
 Union-based SQLi.
2. Inferential SQLi and
 Blind-boolean-based SQLi
 Blind-time-based SQLi
3. Out-of-band SQLi
SattirxSecurity Preferred

29. SQL Injection
4.1. In-band SQL injection (Classic SQLi)
In-band SQL Injection is the most common and easy-to-exploit of SQL Injection attacks. In-ban
d SQL Injection occurs when an attacker is able to use the same communication channel to both l
aunch the attack and gather results.
The two most common types of in-band SQL Injection are Error-based SQLi and Union-based
SQLi.
 Error-based SQL injection
 Error-based SQLi is an in-band SQL Injection technique that relies on error messages thr
own by the database server to obtain information about the structure of the database. In
some cases, error-based SQL injection alone is enough for an attacker to enumerate an ent
ire database. While errors are very useful during the development phase of a web applicati
on, they should be disabled on a live site, or logged to a file with restricted access instead.
SattirxSecurity Preferred

30. SQL Injection
4.1. In-band SQL injection (Classic SQLi)
 Union-based SQL injection
 Union-based SQLi is an in-band SQL injection technique that leverages the
UNION SQL operator to combine the results of two or more SELECT statem
ents into a single result which is then returned as part of the HTTP response.
SattirxSecurity Preferred

31. SQL Injection
4.2. Inferential SQLi (Blind SQLi)
Inferential SQL Injection, unlike in-band SQLi, may take longer for an attacker to exploit, how
ever, it is just as dangerous as any other form of SQL Injection. In an inferential SQLi attack,
no data is actually transferred via the web application and the attacker would not be able to see
the result of an attack in-band (which is why such attacks are commonly referred to as “blin
d SQL Injection attacks”). Instead, an attacker is able to reconstruct the database structu
re by sending payloads, observing the web application’s response and the resulting behavior of
the database server.
The two types of inferential SQL Injection are Blind-boolean-based SQLi and Blind-time-bas
ed SQLi.
SattirxSecurity Preferred

32. SQL Injection
4.2. Inferential SQLi (Blind SQLi)
 Boolean-based (content-based) Blind SQLi
 Boolean-based SQL Injection is an inferential SQL Injection technique that relies
on sending an SQL query to the database which forces the application to return a di
fferent result depending on whether the query returns a TRUE or FALSE result.
 Depending on the result, the content within the HTTP response will change, or rema
in the same. This allows an attacker to infer if the payload used returned true or f
alse, even though no data from the database is returned. This attack is typically
slow (especially on large databases) since an attacker would need to enumerate a da
tabase, character by character.
SattirxSecurity Preferred

33. SQL Injection
4.2. Inferential SQLi (Blind SQLi)
 Time-based Blind SQLi
 Time-based SQL Injection is an inferential SQL Injection technique that relies on
sending an SQL query to the database which forces the database to wait for a spec
ified amount of time (in seconds) before responding. The response time will indicate
to the attacker whether the result of the query is TRUE or FALSE.
 Depending on the result, an HTTP response will be returned with a delay, or returne
d immediately. This allows an attacker to infer if the payload used returned true or
false, even though no data from the database is returned. This attack is typically sl
ow (especially on large databases) since an attacker would need to enumerate a data
base character by character.
SattirxSecurity Preferred

34. SQL Injection
4.3. Out-of-band SQL Injection
Out-of-band SQL Injection is not very common, mostly because it depends on features being en
abled on the database server being used by the web application. Out-of-band SQL Injection occ
urs when an attacker is unable to use the same channel to launch the attack and gather results.
Out-of-band techniques, offer an attacker an alternative to inferential time-based techniques,
especially if the server responses are not very stable (making an inferential time-based attack u
nreliable).
SattirxSecurity Preferred

35. SQL Injection
5. What Can Be Done to Prevent SQL Injection Attacks?
The most important precautions are data sanitization and validation, which should already be in
place. Sanitization usually involves running any submitted data through a function (such as MyS
QL's mysql_real_escape_string() function) to ensure that any dangerous characters (like " ' ") a
re not passed to a SQL query in data.
Validation: Validation is slightly different, in that it attempts to ensure that the data submitte
d is in the form that is expected, the length of a piece of data submitted is not longer than the
maximum expected length.
But sanitization and validation are far from the whole story. Here are ten ways you can help pre
vent or mitigate SQL injection attacks:
SattirxSecurity Preferred

36. SQL Injection
5. What Can Be Done to Prevent SQL Injection Attacks?
 Trust no-one: Assume all user-submitted data is evil and validate and sanitize everything.
 Don't use dynamic SQL when it can be avoided: used prepared statements, parameterize
d queries or stored procedures instead whenever possible.
 Update and patch: vulnerabilities in applications and databases that hackers can exploit usin
g SQL injection are regularly discovered, so it's vital to apply patches and updates as soon a
s practical.
 Firewall: Consider a web application firewall (WAF) – either software or appliance based – to
help filter out malicious data. A WAF can be particularly useful to provide some security pro
tection against a particular new vulnerability before a patch is available.
SattirxSecurity Preferred

37. SQL Injection
5. What Can Be Done to Prevent SQL Injection Attacks?
 Use appropriate privileges: don't connect to your database using an account with admin-leve
l privileges unless there is some compelling reason to do so. Using a limited access account is
far safer, and can limit what a hacker is able to do.
 Keep your secrets secret: Assume that your application is not secure and act accordingly b
y encrypting or hashing passwords and other confidential data including connection strings.
 Don't divulge more information than you need to: hackers can learn a great deal about dat
abase architecture from error messages, so ensure that they display minimal information. Us
e the "RemoteOnly" customErrors mode (or equivalent) to display verbose error messages on
the local machine while ensuring that an external hacker gets nothing more than the fact tha
t his actions resulted in an unhandled error.
SattirxSecurity Preferred

38. SQL Injection
Real-Time Example
1. Cross-Site-Scripting
2. SQL Injection
SattirxSecurity Preferred