This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "HTML 5 Cheat Sheet"
From OWASP
(Initial outline) |
|||
| Line 1: | Line 1: | ||
| − | = Introduction | + | = Introduction = |
| − | |||
| − | = | + | = HTML 5 = |
| − | |||
| − | |||
| − | == | + | == Browser Securability Chart == |
| − | + | There are a few sites charting browser capabilities as they related to the HTML 5 / CSS 3 standard. I have not seen any that mention security. There may not be a need for it, but e.g. 'sandbox' will be ignored in down browsers, but which HTML 5 compliant browsers support it. If there are differences in implementations, my assumption is that there will be differences in security configuration / settings. | |
| − | == | + | == Cross Origin Resource Sharing == |
| − | + | Validate URLs passed to XMLHttpRequest.open, current browsers allow these URLS to be cross domain. | |
| + | *Ensure that URLs responding with Access-Control-Allow-Origin: * do not include any sensitive content or information that might aid attacker in further attacks. Use Access-Control-Allow-Origin header only on chosen URLs that need to be accessed cross-domain. Don't use that header for the whole domain. | ||
| + | *Take special care when using Access-Control-Allow-Credentials: true response header. Whitelist the allowed Origins and never echo back the Origin request header in Access-Control-Allow-Origin.<br> | ||
| + | *Allow only selected, trusted domains in Access-Control-Allow-Origin header. Prefer whitelisting domains over blacklisting or allowing any domain (either through * wildcard or echoing the Origin header content). | ||
| − | == | + | == Input Validation == |
| − | == | + | == Local Storage (a.k.a. Offline Storage, Web Storage) == |
| − | == | + | == WebDatabase == |
| − | |||
| − | == | + | == WebSockets == |
| − | |||
| − | + | *Drop backward compatibility in implemented client/servers and use only protocol versions above hybi-00. Popular Hixie-76 version and olders are outdated and insecure. | |
| − | + | *While it is relatively easy to tunnel TCP services through WebSockets (e.g. VNC, FTP), doing so enables access to these tunneled services for the in-browser attacker in case of a Cross-Site-Scripting attack. These services might also be called directly from a malicious page or program. | |
| + | *The protocol doesn't handle authorisation and/or authentication. Application-level protocols should handle that separately in case sensitive data is being transferred. | ||
| + | *Endpoints exposed through ws:/ protocol are easily reversible to plaintext. Only wss:// (WebSockets over SSH) should be used for protection against Man-In-The-Middle attacks | ||
| + | *Spoofing the client is possible outside browser, so WebSockets server should be able to handle incorrect/malicious input. Always validate input coming from the remote site, as it might have been altered. | ||
| + | *When implementing servers, check the Origin: header in Websockets handshake. Though it might be spoofed outside browser, browsers always add the Origin of the page which initiated Websockets connection. | ||
| + | *As WebSockets client in browser is accessible through Javascript calls, all Websockets communication can be spoofed or hijacked through Cross-Site-Scripting. Always validate data coming through WebSockets connection.<br> | ||
| − | = | + | == Geolocation == |
| − | |||
| − | = | + | == Use the "sandbox" attribute for untrusted content (iFrame) == |
| − | |||
| − | = Related Cheat Sheets = | + | [[http://blog.whatwg.org/whats-next-in-html-episode-2-sandbox]] |
| − | {{Cheatsheet_Navigation}} | + | |
| + | == Content Deliverability == | ||
| + | |||
| + | CDN or src links to foreign domains = know your content | ||
| + | |||
| + | == Progressive Enhancements and Graceful Degradation Risks == | ||
| + | |||
| + | The best practice now is to determine the capabilities that a browser supports and augment with some type of substitute for capabilities that are not directly supported. This may mean an onion-like element, e.g. falling through to a Flash Player if the <video> tag is unsupported, or it may mean additional scripting code from various sources that should be code reviewed. | ||
| + | |||
| + | = CSS 3 = | ||
| + | |||
| + | I haven't seen any specific to CSS 3 and it's been a while since I worried about url / !import. I think privacy leaks are the most well know - e.g. querying global history using :visited (https://bugzilla.mozilla.org/show_bug.cgi?id=147777) | ||
| + | |||
| + | = Javascript and Javascript Frameworks = | ||
| + | |||
| + | Do we have cheatsheets for Javascript (e.g. use closures, protect the global namespace) or any of the frameworks like JQuery, script.aculo.us, Prototype, Mootools | ||
| + | |||
| + | = Related Cheat Sheets = | ||
| + | |||
| + | {{Cheatsheet_Navigation}} | ||
= Authors and Primary Editors = | = Authors and Primary Editors = | ||
| − | [[Category: | + | Krzysztof Kotowicz - krzysztof [at] kotowicz.net |
| − | [[Category:Cheatsheets]] | + | |
| + | [[Category:How_To]] [[Category:Cheatsheets]] | ||
Revision as of 10:43, 9 September 2011
- 1 Introduction
- 2 HTML 5
- 2.1 Browser Securability Chart
- 2.2 Cross Origin Resource Sharing
- 2.3 Input Validation
- 2.4 Local Storage (a.k.a. Offline Storage, Web Storage)
- 2.5 WebDatabase
- 2.6 WebSockets
- 2.7 Geolocation
- 2.8 Use the "sandbox" attribute for untrusted content (iFrame)
- 2.9 Content Deliverability
- 2.10 Progressive Enhancements and Graceful Degradation Risks
- 3 CSS 3
- 4 Javascript and Javascript Frameworks
- 5 Related Cheat Sheets
- 6 Authors and Primary Editors
Introduction
HTML 5
Browser Securability Chart
There are a few sites charting browser capabilities as they related to the HTML 5 / CSS 3 standard. I have not seen any that mention security. There may not be a need for it, but e.g. 'sandbox' will be ignored in down browsers, but which HTML 5 compliant browsers support it. If there are differences in implementations, my assumption is that there will be differences in security configuration / settings.
Cross Origin Resource Sharing
Validate URLs passed to XMLHttpRequest.open, current browsers allow these URLS to be cross domain.
- Ensure that URLs responding with Access-Control-Allow-Origin: * do not include any sensitive content or information that might aid attacker in further attacks. Use Access-Control-Allow-Origin header only on chosen URLs that need to be accessed cross-domain. Don't use that header for the whole domain.
- Take special care when using Access-Control-Allow-Credentials: true response header. Whitelist the allowed Origins and never echo back the Origin request header in Access-Control-Allow-Origin.
- Allow only selected, trusted domains in Access-Control-Allow-Origin header. Prefer whitelisting domains over blacklisting or allowing any domain (either through * wildcard or echoing the Origin header content).
Input Validation
Local Storage (a.k.a. Offline Storage, Web Storage)
WebDatabase
WebSockets
- Drop backward compatibility in implemented client/servers and use only protocol versions above hybi-00. Popular Hixie-76 version and olders are outdated and insecure.
- While it is relatively easy to tunnel TCP services through WebSockets (e.g. VNC, FTP), doing so enables access to these tunneled services for the in-browser attacker in case of a Cross-Site-Scripting attack. These services might also be called directly from a malicious page or program.
- The protocol doesn't handle authorisation and/or authentication. Application-level protocols should handle that separately in case sensitive data is being transferred.
- Endpoints exposed through ws:/ protocol are easily reversible to plaintext. Only wss:// (WebSockets over SSH) should be used for protection against Man-In-The-Middle attacks
- Spoofing the client is possible outside browser, so WebSockets server should be able to handle incorrect/malicious input. Always validate input coming from the remote site, as it might have been altered.
- When implementing servers, check the Origin: header in Websockets handshake. Though it might be spoofed outside browser, browsers always add the Origin of the page which initiated Websockets connection.
- As WebSockets client in browser is accessible through Javascript calls, all Websockets communication can be spoofed or hijacked through Cross-Site-Scripting. Always validate data coming through WebSockets connection.
Geolocation
Use the "sandbox" attribute for untrusted content (iFrame)
[[1]]
Content Deliverability
CDN or src links to foreign domains = know your content
Progressive Enhancements and Graceful Degradation Risks
The best practice now is to determine the capabilities that a browser supports and augment with some type of substitute for capabilities that are not directly supported. This may mean an onion-like element, e.g. falling through to a Flash Player if the <video> tag is unsupported, or it may mean additional scripting code from various sources that should be code reviewed.
CSS 3
I haven't seen any specific to CSS 3 and it's been a while since I worried about url / !import. I think privacy leaks are the most well know - e.g. querying global history using :visited (https://bugzilla.mozilla.org/show_bug.cgi?id=147777)
Javascript and Javascript Frameworks
Do we have cheatsheets for Javascript (e.g. use closures, protect the global namespace) or any of the frameworks like JQuery, script.aculo.us, Prototype, Mootools
Related Cheat Sheets
OWASP Cheat Sheets Project Homepage
Authors and Primary Editors
Krzysztof Kotowicz - krzysztof [at] kotowicz.net
