|
|
| (75 intermediate revisions by 10 users not shown) |
| Line 1: |
Line 1: |
| − | = Introduction = | + | __NOTOC__ |
| | + | <div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div> |
| | | | |
| − | = HTML 5 =
| + | The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]! |
| | | | |
| − | == Browser Securability Chart ==
| + | Please visit [https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Security_Cheat_Sheet.html HTML5 Security Cheat Sheet] to see the latest version of the cheat sheet. |
| − | | |
| − | 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).
| |
| − | *Keep in mind that CORS does not prevent the requested data from going to an un-authenticated location - it's still important for the server to perform usual [[Cross-Site Request Forgery (CSRF)|CSRF]] prevention.
| |
| − | | |
| − | == 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) ==
| |
| − | | |
| − | [[http://blog.whatwg.org/whats-next-in-html-episode-2-sandbox]]
| |
| − | | |
| − | == Web Messaging ==
| |
| − | Web Messaging provides a means of messaging between documents from different origins in a way which is generally safer than JSON-P, however, there are still some recommendations to keep in mind:
| |
| − | *When posting a message, explicitly state the expected origin as the second argument to <tt>postMessage</tt> rather than <tt>*</tt> in order to prevent sending the message to an unknown origin after a redirect or some other means of the target window's origin changing.
| |
| − | *The receiving page should '''always''':
| |
| − | **Check the {{origin}} attribute of the sender to verify the data is originating from the expected location, and
| |
| − | **Perform input validation on the {{data}} attribute of the event to ensure it's in the desired format
| |
| − | | |
| − | == 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 =
| |
| − | | |
| − | Mark Roxbury - mark.roxberry [at] owasp.org
| |
| − | | |
| − | Krzysztof Kotowicz - krzysztof [at] kotowicz.net
| |
| − | | |
| − | [[Category:How_To]] [[Category:Cheatsheets]]
| |
