This webinar, presented by Security Innovation's own, Senior Security Instructor and Engineer, Kevin Poniatowski, examines HTML5 security in-depth and arms development teams with techniques they can apply immediately to proactively address security in their code.

1. 1
HTML5 Security
The Promise & The Peril
Presented by:
Kevin Poniatowski,
Sr. Security Engineer & Trainer

2. 2
About Security Innovation
• For over 13 years, we have been securing or helping secure software in
the toughest environments:
• Application Security Expertise:
o 15 years research on vulnerabilities
o Security testing methodology adopted by SAP, Symantec, Microsoft, and McAfee
o Authors of 18 books; 10 co-authored with Microsoft
• Over 1 million licensed users of our training solutions
• Gartner MQ leader (3 years in a row!)

3. 3
Agenda
HTML5 Features & Risk
• Security Implications of HTML5
• Implementing Countermeasures throughout the SDLC
Agenda

4. 4
HTML5 - Technical Overview
HTML5 gives developers the ability to create websites that function
more like desktop applications
• Applications can function without Internet connectivity
• Custom data attributes removes the need for in-line JavaScript
Parsing is more tightly defined in HTML5
• Different browsers are more likely to behave the same now
• Less opportunity for “undefined behavior”
• Code should be easier to read and maintain

5. 5
HTML5 Overview – Major Benefits
Allows the separating of code from content
• Complexity is the enemy of Security!
• This is called using Unobtrusive JavaScript –
more later
Users no longer have to use Flash
• Malicious Flash files have been a security issue
for years.
• Native built in support using the <video> and
<audio> tags.
• No more flash issues in the browser
• Even browsers that don’t support JavaScript can
still read all web pages.

6. 6
Risks of HTML5
• Browser vendors rush to implement features that are not
security‐ ready
• Enlarged attack surface due to a large quantity of new code
and features
• Increased burden on browsers due to increased the
number of features handled client side instead of server
side
• Developers must learn how to implement HTML5 specific
features securely
• Risk is transferred to applications, even those that do not
use HTML5

7. 7
Geolocation
• Does not require GPS (Wi-Fi, IP address, cell towers, …)
• Coordinates accessible via JavaScript: (and XSS)
• Latitude
• Longitude
• Heading
• Speed
• Anyone with a motive now knows exactly:
• Who user is
• Where users are
• What user is doing
• Who user is doing it with
• Exploiting a vulnerability gets hackers access to all
this data

8. 8
Local Storage
• Benefits:
• Lots of space to persist data!
• Developers control when it is sent to the server.
• Data does not expire, unlike cookies.
• Protected by the Same Origin Policy
• Risks:
• More assets to steal using XSS
• The potential of client-side SQL Injection

9. 9
Agenda
• HTML5 Features & Risk
Security Implications of HTML5
• Implementing Countermeasures throughout the SDLC
Agenda

10. 10
Sandboxing Untrusted Content in iFrames
• By default, the sandbox enables extra restrictions
• Content is treated as being from a unique origin
• Cannot access DOM of parent page
• Forms, scripts, and plugins are disabled
• Links cannot target other browsing contexts
• Cannot access cookies or Local Storage
• This reduces the threat of a malicious iframe, such as a third
party advertisement, from attacking users
• Features that use triggers and plugins are also blocked.
<iframe sandbox=""> Applies all restrictions available to iframe sandbox

11. 11
Same-Origin Policy (SOP)
• HTML5 features depend on a security concept known as SOP
• By default, a web browser uses SOP to isolate all elements on a
page with distinct origins to restrict information sharing across
origins
• Limitations
• Inconsistent, limited, or buggy client implementations leave coverage gaps
• Complexity and embedded nature of HTML5 content exposes it to new
vulnerabilities
• Ineffective against:
• XSS originating from the same domain
• ARP spoofing, DNS spoofing, and man‐in‐the‐middle (MiTM) attacks
• Poor development practices negate the benefits of SOP

12. 12
Cross-Site Scripting
• XSS attacks exploit the browser’s trust of content from the
server
• Can the browser discern if <script> is from an attacker?
• There is no intrinsic separation of code from content
So how can we protect against Cross Site Scripting (XSS)?
<a href="" onclick="alert('Hello world')">Link</a>
Is this script from the application or an attacker?

13. 13
Content Security Policy (CSP)
• Least‐privilege approach where server can whitelist which domains are a valid
source for an executable script; all other sources of JavaScript are disabled
<script> alert(‘inline scripts are disabled'); </script>
<img src="csp.png"
onload="alert('event-handling attributes disabled');" />
• Requires adhering to development best practices
• Compared to SOP, provides finer‐grained control over web content to better
detect and prevent XSS attacks, mitigate clickjacking attacks, and help enforce
HTTPS connections.
• Can report policy violations back to server
• Browsers that do not support CSP still benefit from this

14. 14
Cross-Origin Resource Sharing (CORS)
• JavaScript can make requests to ANY domain but not always
allowed to read the response from an XMLHttpRequest
• Header injection attacks become more interesting

15. 15
CORS & CSP
• CORS and CSP work together
• CORS allows XMLHttpRequest to go to any domain
• CSP provides a way to whitelist for which domains requests
are allowed
• CORS provides a way to whitelist which responses can be
read
• CSP protects the content from potentially malicious JavaScript
in the response

16. 16
Privacy Issues
• With space for more data, the risk of developers storing HIPAA
or PCI protected data in the browser is increased
• Instead of cookie data being deleted when a session expires,
data stored locally may now be persistent and accessible by
JavaScript
• Geolocation data is considered sensitive by many people, so
this new API could be abused if not used with security in mind
• Web messaging allows for the potentially insecure
transmission of information from one domain to another

17. 17
Agenda
• HTML5 Features & Risk
• Security Implications of HTML5
Implementing Countermeasures throughout the SDLC
Agenda

18. 18
Mitigating Geolocation Risks
• Request user location only when necessary and over encrypted
connections
• Never share, retransmit, or store location information without
the user’s consent
• Allow users to delete stored location information
• Disclose exactly how location information will be used
• Inform users when location access is granted, and provide a
mechanism for revoking access

19. 19
Web Messaging Security
• Always check the origin in the message receiving code
• Only allow messages from a specific whitelist of domains
• Ensure that the message goes to the intended recipient
• Always treat messages as untrusted. Strictly validate data and
data types
• Always treat messages as data or plaintext
• Never pass messages to eval() or insert data into the DOM via
innerHTML

20. 20
CORS Security
• Browser Side
• Avoid using user input for URLs passed to XMLH pRequest.
• Strictly validate user input that affects the URL
• Always access remote resources via HTTPS when browsing
from HTTP origins

21. 21
CORS Security
• Server Side
• Check the Origin, Host, and Referer headers.
• Be aware that headers can be spoofed and implement access
controls.
• If a request modifies data, includes cookies, or has other
significance, use its nonce field for protection against CSRF attacks.
• Never allow GET or OPTIONS requests to modify or affect data.
• When limiting access to specific origins, use a whitelist for validation.
Do not return the submitted origin in the response headers.
• Be aware of HTTP response splitting attacks and validate server
headers as necessary.

22. 22
Local Storage Best Practices
• Never store sensitive, private, or authentication‐related data in local storage.
• Use cookies with the HTTPOnly flag set for session tokens; never use local storage.
• Treat all data retrieved from local storage as user input; always validate it as if it were
untrusted.
• Consider same‐origin policies and use TLS as an additional layer of server identification.
• Never use local storage on domains that host content from other users in different
subdirectories.
• Isolate locally stored static content by using a unique domain separate from the main
application.
• Regularly refresh stored content with trusted content from the server.
• Clear offline storage values that are no longer needed.

23. 23
Content Security Policy Best Practices
• Use TLS whenever possible to prevent tampering with CSP headers
• Do not allow the allowsEval, allowsInlineScript, or allowsInlineStyle
directives because they disable protections.
• Be as specific as possible with origins for each resource type. Never use a
single asterisk to match anything.
• Always provide a default‐src directive to ensure that all policies have a
default setting if one is not already specified.
• Never include unsafe‐inline or data as origins because both of these allow
XSS code to be included in the document itself.
• When using violation reports, use nonces to verify their authenticity.
Configure the reporting script with controls to prevent abuse.

24. 24
Implementing Secure iFrames
• Use sandbox attribute for untrusted content, even for content that originates from your
own site.
• Enable the minimal number of required features for each iframe.
• Avoid using the seamless attribute for untrusted content as it treats it as if it were part of
the parent document.
• Never use allow‐scripts together with allow‐ same‐origin when the embedded document
has the same origin as the parent document.
• This allows the script to remove the sandbox attribute.
• When serving content intended for use only in an iframe, use the text/html‐sandboxed
MIME type.
• Use the X‐Frame‐options HTTP headers for content that should never appear in a frame.

25. 25
Requirements Phase
• All data must be defined for the developers
• Sensitive data must be explicitly called out so
that the risk of it being stored in the browser is
very low
• Consider abuser stories instead of only
focusing on user stories

26. 26
Design Phase
• A secure design separates code from content
• Create a threat model for each feature
• Use third-party components only if they have
been vetted by security team

27. 27
Implementation Phase
• Due to the potential risk of Client Side SQL Injection due to
HTML5’s use of local storage, developers must use
parameterized queries.
• Remember that all input is considered malicious until
validated!
• Any output of web application that originated from another
user must be sanitized.
• A layered defense to protect against XSS should be
implemented.

28. 28
Testing Phase
Security testing must be performed to mitigate the risk of at
minimum, common vulnerabilities in HTML5:
• Cross-site Scripting
• Insecure Direct Object Reference
• Sensitive Data Exposure

29. 29
Deployment Phase
• While not a part of the HTML5 standard, securely using CORS
(Cross Origin Resource Sharing) and CSP (Content Security
Policy) are HIGHLY recommended.
• If used incorrectly or misconfigured, these important layers of
defense could actually make the HTML5 application less
secure!

30. 30
Conclusion
• HTML5 offers end users and development
teams many powerful features, but make
sure you and your teams are aware of the
risks.
• HTML5 still makes developers responsible
for writing secure code, so it must be
tested to avoid easy to find issues.
• Be sure to leverage tools for low hanging
fruit, and manual techniques for
vulnerabilities that elude tools/

31. 31
How Can Security Innovation Help?
• Classroom and Computer-Based Training
• 100+ for all major roles, technologies and platforms
• Creating Secure HTML5 Code
• Software Security Assessments
• All Software Application types at any phase
• Platform and language-specific remediation guidance
• Secure SDLC Assessment
• Analyze against industry best practices and provide roadmap of
change
• CMD+CTRL Capture the Flag Training
• Banking, HR, Retail and Mobile applications

32. 32
Questions?Questions?

33. 33
https://www.securityinnovation.com/knowledge-center/webinars
Thank You!
To learn more secure coding techniques, please check out our
Developer Training Bundle: http://bit.ly/2tuXTsh
8 Specialized Web 2.0 courses, including:
• Creating Secure HTML5 Code
• OWASP Top 10 – Threats & Mitigations
• And more!