• Get application security done the right way! Detect, Protect, Monitor, Accelerate, and more…
  • Google’s announcement that they’re done with flash was the last nail in Flash’s coffin.

    Even before that, celebrity technocrats like Steve Jobs openly spoke against Flash.

    With the demise of flash and rise of HTML5 a new era has been ushered in that features better looking and better functioning websites that are compatible with mobiles and PCs alike.

    Transferring data and receiving it has also become much more straightforward than before.

    However, it presents its unique challenges that need to be won.

    The advantage with this is that html5 takes cross-browser support and functionality to a whole new level.

    Certain browsers don’t support individual site elements, and it’s frustrating to have to change the site elements to keep up with appearances.

    HTML5 discards that requirement since all modern browsers support.

    Cross-origin Resource Sharing

    Cross-origin resource sharing (CORS) is one of the most influential features of html5 and also one that bodes the most possibilities for mistakes and hacker attacks.

    CORS defines headers to help enable sites to define origins and facilitate contextual interactions.

    With html5 CORS mutes the fundamental security mechanism on browsers called the Same Origin Rule.

    Under the same origin policy, a browser can allow a webpage to access data from a second webpage only if both web pages have the same origin.

    What is an origin?

    An origin is a combination of URI scheme, host name, and port number. This policy prevents malicious scripts from executing and accessing data from web pages.

    CORS relaxes this policy by enabling different sites access to data for allowing contextual interaction.

    This can lead a hacker to get his hands on sensitive data.

    For instance,

    If you’re logged into Facebook and remain logged in and then visit another site, then it’s possible that the attackers can steal information and do anything they wish to your Facebook account by taking advantage of the relaxed cross-origin policy.

    On a slightly more tepid note, if a user is logged into his banking account and forgets to log out the hacker could get access to the user’s credentials, his transactions or even create new transactions.

    Browsers by storing user details leave session cookies open for exploit.

    Hackers can also meddle with the headers to trigger unvalidated redirects.

    Unvalidated redirects can happen when browsers accept untrusted input. This, in turn, forwards a redirect request. The untrusted URL can be modified to add an input to the malicious site and hence launch phishing scams by providing URLs that appear identical to the actual site.

    Unvalidated redirect and forward attacks can also be used to maliciously craft a URL that would pass the application’s access control check and then forward the attacker to privileged functions that they would typically not be able to access.

    Here’s what developers should take care of to prevent these things from happening.

    • Developers should ensure that URLs are passed to open. If these are cross-domain, then it can be vulnerable to code injections.
    • Also, pay attention if the URLs are relative or if they specify a protocol. A relative URL doesn’t specify a protocol, i.e., we wouldn’t know if it starts with HTTP or https. The browser assumes that both are true.
    • Don’t rely on the Origin header for Access Control checks as they can be easily spoofed.

    How do you know if CORS is enabled on a particular domain?

    Well, you can use developer tools in the browser to examine the header.

    Cross-domain Messaging

    Cross-domain messaging was previously disallowed in browsers to prevent cross-site-scripting attacks.

    This also prevented legitimate communication between websites from happening which made the bulk of cross-domain messaging now.

    Web messaging allows different APIs to interact with ease.

    To prevent cross-scripting attacks here’s what developers should do.

    They should state the expected origin of the message

    • The origin attributes should always be cross-checked and data verified.
    • The receiving page should always check the origin attribute of the sender. This helps verify that the received data is indeed sent from the expected location.
    • The receiving page should also perform input validation to ensure data is in the required format.
    • Exchanged messages should be interpreted as data not code.

    Better Storage

    Another feature of html5 is it allows for better storage. Instead of relying on cookies to keep track of user data, the browser is enabled to store data.

    HTML5 allows for storage across multiple windows, has better security and retains data even after closing a browser. Local storage is possible without browser plugins.

    This spells different sort of troubles.

    Developers should take care of the following things to prevent attackers from stealing information.

    • If a site stores user’s passwords and other personal information then it could be accessed by hackers. Such passwords if not encrypted can be easily stolen via web storage APIs. Hence it’s highly suggested that all valuable user data is encrypted and stored.
    • Additionally, many malware payloads have already started scanning browser caches and storage APIs to find information on users like transactional and financial information.

    Concluding thoughts

    HTML5 offers excellent opportunities for web developers to modify and make things much more secure.

    The bulk of the work in providing a secure environment falls on the browsers though.

    If interested to learn more then check out “Learn HTML5 in 1 hour” course.