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