Cross Site Scripting Defense Presentation

Cross-site scripting
defense
Presented by
Sarker Iftekhar Alam
Yemi Aladeokin
Igbape Maro

Outline
 Introduction to XSS
 Conditions for Cross site scripting
 Cross site scripting key players
 Types of XSS
 How to test for cross site scripting
 Defending against Cross site scripting
 XSS prevention rules summary
 Conclusion

Introduction to XSS
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

Cross-Site Scripting
Cross site scripting (XSS) vulnerability is mainly caused by the failure of web
applications in sanitizing user inputs embedded in web pages.
To add to this, many other attack methods, such as Information Disclosures,
Content Spoofing and Stolen Credentials could all be side-effects of an XSS attack.
CONDITIONS FOR CROSS-SITE SCRIPTING
 A Web application accepts user input
 The input is used to create dynamic content
 The input is insufficiently validated

Cross-Site Scripting – Key Players
 An Attacker
• Anonymous Internet User
• Malicious Internal User
 An organization`s web server (i.e. Web application)
• External (e.g.: Shop, Information, CRM, Supplier)
• Internal (e.g.: Employees Self Service Portal)
 A Client
• Any type of customer
• Anonymous user accessing the Web-Server

Cross-Site Scripting – Key Players
Denial-of-Service
 Crash Users`Browser, Pop-Up-Flodding, 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

Type of XSS
Stored or Persistent XSS:
 Data provided by a client is first stored on the server such as a database
or file system and later displayed to the users. This scenario usually
requires a particular kind of vulnerable application, particular one that
involves storing data in a database.
 Persistent XSS is less frequent but the damage can be more devastating
because once the payload is stored, it has the potential of infecting all
of the visitors to the vulnerable web page.
 Persistent XSS is also referred to as Type 2 XSS because the attack is
carried out via two requests: one for injecting malicious code and
having it stored on the web server, and the other for when victims load
HTML pages containing the payload.
 Typical goals of Persistent XSS attacks: Cookie theft and Data theft

Example:
Forums / message boards
Once a forum is identified as vulnerable, attackers may open a new topic and insert malicious
scripts in the topic title or body. They can also tag the topic using popular keywords so that the
topic is a popular search result. The content of the forum post will be stored by the server. When
the victims browse topics or search for certain keywords, they may reach the infected topic. When
the topic loads, its contents will be sent to the victim’s browser and the payload may be executed.
Alternatively, attackers may build tools that automatically post malicious scripts in replies on
popular / sticky topics, send private messages containing the payload to forum members, etc..

Defending Against Persistent / Stored
XSS
a) Server-side
 Validate User Input
The best way to prevent Persistent XSS is to make sure that all user input is properly
validated before it gets stored permanently on the web server,
 Sanitize static contents
A second line of defense, make sure that the static content presented to users is
also sanitized.
b) Client-side
 Disable JavaScript
Users cannot take any particular actions in order to prevent such an attack, other
than disabling JavaScript within their browser (disabling JavaScript is not seen as an
adequate solution since several websites require it to function properly).
 Update web browsers
The only thing that can help in this case is using secure and up to date web
browsers, with XSS filters turned on and hope for the best

Types of XSS
Reflected XSS: n a reflected cross-site scripting attack, the user unwittingly
sends code to a web server which then "reflects" that code back to the user's
browser, where it is executed and performs a malicious act
Typical goals: Session Hijacking, Bypassing access control and Malware
Attack
Session hijacking process:
 Hacker sends link to victim, link contain XSS
 Victim views page via XSS link supplied by attacker
 XSS code executes on victims browser and sends cookie to attackers
server
 Cookie is stolen. The attacker can then hijack the victims session

Type of XSS
DOM-based vulnerabilities
 DOM XSS is a type of attack which relies on inappropriate handling, in
the HTML page, of the data from its associated DOM.
 Among the objects in the DOM, there are several which the attacker
can manipulate in order to generate the XSS condition, and the most
popular, from this perspective, is the document.url,
document.location and document.referrer objects.
 The Document Object Model is a convention for representing and
working with objects in an HTML document (as well as in other
document types)

Defending against DOM XSS attacks
 The DOM XSS attack is difficult to detect by server-side attack
detection and prevention tools, because usually the malicious payload
does not get to the server and hence cannot be sanitized in the
server-side code, like in the case of other XSS attacks.
 Sanitization and prevention techniques apply, but in this case the
code review as well as the implementation of sanitization
functionality needs to be performed on the client-side code.
 Avoiding client-side sensitive actions such as rewriting or redirection,
using client-side data;
 Using intrusion prevention systems which are able to inspect inbound
URL parameters and prevent the inappropriate pages to be served.

How to test for Cross site scripting
 Make notes of all the pages that display input originating from current
or other users.
 Test by injecting malicious JavaScript to see if they are ultimately
displayed back to the user.
 Carry out an examination of the code to ensure that the application
data is HTML encoded before it is rendered to users.

Defending Cross Site Scripting
 Appropriate output encoding or avoidance of thread input
* The contextual output encoding or escaping method is the major
defense mechanism to stop cross site scripting.
* HTML entity encoding
* Javascript escaping
* CSS escaping

Defending Cross Site Scripting (contd.)
 Securely authenticating untrusted HTML input
Many forums and webmail like to allow users to implement some
of the structures that html provides.
 It could be limited subset of html markup
 It prevent switching into any execution context
HTML sanitization engine must run during untrusted html content
accessing to ensure that it does not contain any xss.

 Cookie based Security
Many web applications rely on session cookies for authentication
between individual HTTP requests, and because client-side
scripts generally have access to these cookies and its easy to
steal the session cookies. To mitigate this threat:-
* Attach the session cookies to the IP address of the user who
actually login.
* Allow only that IP who can access that session only.
* Can be use HttpOnly flag which allows a web server to set a
cookie that is unavailable to client-side scripts

 HTTPOnly Cookie Flag
Microsoft Developers defines HTTPOnly as additional flag included in
set-cookie HTTP response header. Using this flag mitigates risk of client
side scripting.
When client access any website, website server sets this HTTPOnly. It
can only be set if browsers supports it if not browser ignores it.

Scanning Service
* Scanning web application with the scanner such as The Zed Attack
proxy (ZAP) , the client receives detailed information on how it was
performed and thus has a chance to fix the issues before the same attack
is attempted by someone else.

After scanning , it can provide the details vulnerabilities of the web
application with the solution and the risk level . This will help to identify
and fix the problem easily.

XSS Prevention Rules Summary
Context Code Sample Defence
HTML Body <body> DATA </body> HTML Escape
Convert & to &amp
Convert < to &lt
Convert > to &gt
Convert " to &quot
Convert ' to &#x27
Convert / to &#x2F
HTML Attributes <div attr=DATA> </div> escape all characters with the HTML
Entity &#xHH; format, include spaces
except alphanumeric.
GET or POST
parameter
<a href=”DATA”> </a> Replace space with +
Escape every character except
alphanumeric with % followed by two
digit HEX code
JavaScript
Variable
<script>alert(“DATA”)</script> Escape all characters with Unicode
escaping format. uXXXX
Avoid backslash encoding
CSS value <div style=”height:DATA”> </div> CSS escaping supports XX and
XXXXXX (CSS hexadecimal encoding).
HTML Body (HTML
data type)
<div> DATA</div> Using libraries like AntySamy, HTML
Sanitizer

Cross Site Scripting Defense Presentation

More Related Content

What's hot

Viewers also liked

Similar to Cross Site Scripting Defense Presentation

Recently uploaded

Cross Site Scripting Defense Presentation