cross site scripting defense presentation
TRANSCRIPT
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 webapplications 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 PlayersDenial-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 databaseor file system and later displayed to the users. This scenario usuallyrequires a particular kind of vulnerable application, particular one thatinvolves storing data in a database.
Persistent XSS is less frequent but the damage can be more devastatingbecause once the payload is stored, it has the potential of infecting allof the visitors to the vulnerable web page.
Persistent XSS is also referred to as Type 2 XSS because the attack iscarried out via two requests: one for injecting malicious code andhaving it stored on the web server, and the other for when victims loadHTML 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
XSSa) 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 unwittinglysends code to a web server which then "reflects" that code back to the user'sbrowser, where it is executed and performs a malicious act
Typical goals: Session Hijacking, Bypassing access control and MalwareAttack
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 attackersserver
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.
Defending Cross Site Scripting (contd.)
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
Defending Cross Site Scripting (contd.)
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.
Defending Cross Site Scripting (contd.)
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.
Defending Cross Site Scripting (contd.)
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 SummaryContext Code Sample Defence
HTML Body <body> DATA </body> HTML Escape
Convert & to &
Convert < to <
Convert > to >
Convert " to "
Convert ' to '
Convert / to /
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
Q & A