HTML5 security lite
Agenda
Introduction to HTML5
Introduction to hackers world
Client side storages
Offline web application
Same origin policy
Cross origin resource sharing
Introduction – HTML5
Hypertext Markup Language version 5
HTML5 Provides new features to web
applications, which introduce new security
issues
HTML5 Overview
Client side storages
Offline web application
Same origin policy
Cross origin resource sharing
Unit Cross document messaging
Agenda: Sandboxing
Click jacking
Client Side Storage
HTML5 allows websites to store data in the
browser, this ability is useful for:
Saving large local data (which is impossible by the cookies)
Saving user’s selections between pages without sending
them to the server
Creating cached pages and dynamically filling them in the
client with the content from the client storage
Saving the user settings (such as font size) without any
identification
Client Side Storage
Demo
Server-side shopping cart
http://victim-site.com:2000/html5/cart/web_2.0.php
Client-side shopping cart
http://victim-site.com:2000/html5/cart/web_html5.php
Client Side Storage
Types:
Local storage
Session storage
IndexedDB
Web SQL
Offline web application
Local Storage vs. Cookie
Local Storage Cookie
Maximum size Some MB * 4 KB
Content sent Not sent With any request
Can be accessed from Any window Any window
Deleted after Never (manually) Fixed time
Range Whole site Per directory
HttpOnly Flag No Yes
* IE8 supports up to 10kb
Local Storage vs. Session Storage
Local storage Session storage
Maximum size 10-15 MB 5 MB
Can be accessed from Any window Only the same window
Deleted after Not deleted Window is closed
Local storage:
http://victim-site.com:2000/html5/cart/web_html5.php
Session storage
http://victim-site.com:2000/html5/cart/web_html5_session.php
SQL Storage – Indexed DB
IndexedDB
API for client-side storage
Object oriented
Store and retrieve objects which are indexed
with a ‘key’
Used for high performance searches
No limits on a single database item's size
SQL Storage – Web SQL
Standard SQL
tx.executeSql('INSERT INTO table (id, text,
comment) values (1,”xxx”,”yyyy”)', []);
Demo – Offline twitter / Offline blog
http://victim-site.com:2000/html5/tweet_reader/
http://victim-site.com:2000/html5/offline_blog/
Offline Web Application
A web application can send information to the
client about which files are needed for working
offline
Once loaded, the application can be used offline
The client recognizes the offline mode and loads
the data from the cache
http://victim-site.com:2000/html5/offline_blog/
Client Side Storage
Risks:
Private/Sensitive data can be stolen
Data can be tampered
Attack vectors:
Physical access
Malicious java script
Using HTTP (unencrypted) protocol
Using Cross Site Scripting (XSS) attack
Client Side Storage
Should not store sensitive data
PII [Private Identifiable Information]
Passwords
Health
Keys
An attacker who will have access to the
computer later can extract those data
Delete from storages
If you store something private (which you
shouldn’t do…) use a timer to delete:
setTimeout('window.sessionStorage.removeItem("us
erId")', 60000)
Delete also in case of moving to a
different website or closing the tab:
window.unload =
window.sessionStorage.removeItem("userId")
Storage attacks – Tampering data
Goals
Change user’s action
Set a new shipping address
Denial of Service
In case of data parsing crash
Set the font size to 0px
Run malicious java script (Stored XSS)
In case of improper output encoding
http://victim-site.com:2000/html5/offline_twitter/
Storage attacks – Tampering data
Mitigation
Don’t trust user’s data
Perform input validation
Perform output encoding
Client Side – SQL Injection
Use Prepared Statements:
tx.executeSql('INSERT INTO table (id, text,
comment) values (?,?,?)', [x.id,x.text,x.comment]);
Don’t build dynamic queries:
Cross Origin Resource Sharing
The old methods of embedding external data
are:
IFRAME
<iframe src=“//another.com/home.htm”></iframe>
Stupid block
You have no control over content / style
JSONP
<script src=“//another.com/data.js?callback=run”></script>
You run the script from another domain on your site!
It’s not a really natural way.
Cross Origin Resource Sharing
Until now it wasn’t possible to read pages
from another site, because of SOP
restriction
Same Origin Policy
With HTML5 – it is possible!
Using the header:
Access-Control-Allow-Origin
Cross Origin Resource Sharing
Origin header in the request
Origin header in the response
Cross Origin Resource Sharing
Distributed Denial of Service (DDoS)
◦ Browsers can send requests from any domain to any
domain.
◦ XSS will be very useful for DDoS attacks.
http://online.attacker-site.com/html5/CORS/HTML5_Denial_of_Service_Tester.htm
Mitigation
Exit early if the origin hasn’t got permission
If( isset($_SERVER['HTTP_ORIGIN']))
exit;
If($_SERVER['HTTP_ORIGIN'] != 'http://trusted.site')
exit();
<% Response.AddHeader("Access-Control-Allow-Origin","*") %>
header('Access-Control-Allow-Origin: http://trusted.site');
Cross Origin Resource Sharing
Universal Allow
◦ Any site can read your site.
◦ Data may should have limited access only to
customer’s IP address
◦ Internal websites
◦ Dev version
Cross Origin Resource Sharing
Do not use the wildcard (*):
Access-Control-Allow-Origin: *
Set the allowed domains:
HTTP/1.1 200 OK
Content-Type: text/html
Access-Control-Allow-Origin: http://demo.appsec-labs.com
Only use in relevant pages!
Check the origin before executing
Used against DDoS
It doesn’t replace the regular authorization
Cross Origin Resource Sharing
Browser will send cookies along with the request,
only if the request is set to send “credentials”:
cor.open('GET', url);
cor.withCredentials = "true";
cor.send();
Server answers with the header:
Access-Control-Allow-Credentials: true
If server doesn't answer the credentials header
(or answers false), the page will not load.
Access-Control-Allow-Origin can’t be * if
credentials are marked as true.
Cross Origin Resource Sharing
Risks:
Stealing user’s data
Perform actions on-behalf the user
DDoS - Distributed Denial of Service
Access to intranet website from a remote website
Cross Origin Resource Sharing
Those dangerous headers allow other domains to
perform actions / read data from your website:
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: Content-Type
Summary
HTML5 adds features that allow new browser
capabilities.
In this presentation we have demonstrated innovative
ways for attackers to exploit & utilize these
capabilities for malicious purposes.
Perform input validation & output encoding also in
client!!
Use relevant headers to protect against attacks
