Editor’s note: Mike Shema is director of engineering at Qualys, a provider of cloud security and compliance solutions. Mike is also author of the recently published book “Hacking Web Apps: Detecting and Preventing Web Application Security Problems.” Contact him here.
HTML5 reinvigorates a technology that’s been driving web content for more than 20 years. Notably, modern browsers can still render the majority of decades-old sites still lingering from the web’s early days, but modern sites expect browsers to be a significantly more powerful platform than their predecessors. Facebook tried to push these computing boundaries even further with a pure HTML5 mobile app, but discovered there are certain limitations that come with a billion or so users. Some problems are nice to have.
The new standard also pushes security boundaries. Sites won’t immediately benefit just by adding a <!doctype html> declaration to their pages. Instead, they can improve security by adopting features that control how the browser shares or interprets content from different sources. Other features allow the browser to store more data, a great improvement over cookies, but careless use of these features has consequences for security and privacy.
Cross-Origin Resource Sharing – Border Control
Browser security largely rests on the Same Origin Policy (SOP) to strictly separate content based on its source. It’s intended to keep sites from interfering with each other. However, it hasn’t made much of an impact on browser attacks like HTML injection (aka cross-site scripting), cross-site request forgery (CSRF), clickjacking, or malware. SOP even hampers legitimate kinds of site architectures, leading devs to create inelegant, less secure workarounds.
Cross-Origin Resource Sharing (CORS) presents a way to lift this barrier that, for example, helps sites use different domains for APIs, user-generated content, or security-sensitive actions in order to create a more flexible separation of duties. And it does this without forcing an all-or-nothing decision on trust.
Flexibility is the key point here. CORS relies on server-side response headers to inform the browser which other sites may have read access to its content, meaning a site could peek into another’s HTML or view the JSON data inside a response. A web app must explicitly bequeath this trust; just because a browser requests it doesn’t mean it will receive permission to weaken the SOP.
CORS influences read access within the browser — it’s a browser security boundary, not a server-side one. Be wary about giving away trust to all origins. This makes sense for an API, but not for pages that you expect to protect from CSRF attacks. CORS has the means to define the duration of a trust declaration, and what methods or headers a browser may include when crossing origins. Keep these values to the minimum required for the site to work, rather than opening up all things to all browsers.
iFrame Sandboxes — Here Be Dragons
iFrame sandboxes take a different approach to controlling how a browser should trust content. They still apply to security inside the browser (as opposed to the server), but the focus has shifted from sharing content to restricting what that content may do.
The sandbox attribute may hold several possible values (i.e. allow-scripts, allow-forms, allow-same-origin, allow-top-navigation, allow-popups). The values are mostly self-explanatory and imply what the iFrame’s default behavior will be if they’re omitted. A sandboxed iFrame will not:
- Execute scripts, a boon to mitigating HTML injection attacks
- Submit forms, a further countermeasure against attacks like CSRF or clickjacking
- Navigate the browser to a new page, preventing unexpected redirects and some types of phishing and malware attacks
- Open pop-up alerts, once again countering some with phishing or CSRF attacks
- Instantiate plugins or trigger HTML5′s autofocus and autoplay events
iFrames already served as a sort of quarantine for pages before HTML5. With the sandbox, browsers can better mitigate the impact of potentially malicious content. It’s a great fallback measure when a server-side security filter fails. It doesn’t mean you no longer have to inspect data for potential attacks; it means users with HTML5-aware browsers might be less impacted when you miss something.
Browser-Based Storage — Data Sans Frontiers
New decades bring new buzzwords, and “Big Data” promises to fight its way to popularity. Modern web sites deal with Big Data — terabytes of information about their users — and push more types of computing to the cloud, only to be accessed solely by the browser.
HTML5 inverts some of this trend by offering up APIs like Local Storage and IndexedDB that let web apps store large amounts of data in the browser; they’re cookies on steroids, with the same security and privacy concerns. Here security needs to focus equally on access to (via the SOP) and values of data being stored.
Anything stored in the browser is just one cross-site scripting attack away from being stolen. And there’s nothing to stop a virus or malware from pulling the Local Storage files off a compromised system. This means Local Storage is a great place for caching content or saving non-sensitive user data. But it’s a terrible place for storing passwords, credit card numbers or anything else that should be safely encrypted or tucked away under the security of a server-side data store.
Browser-based storage increases the flexibility of apps to collect and manipulate data by shifting some processing burden from servers to the browser. But it doesn’t shift the burden of security. It adds a whole new requirement for it — one that involves the value of data rather than just its access.
Here, There, Everywhere
HTML5 strives to sustain the browser as a first-class computing environment. With it developers are creating complex, desktop-like apps and games using JavaScript to drive APIs that are (or should be) uniform across browsers, operating systems and devices. Along the way, it’s important to acknowledge where an HTML5 security feature is relevant and where it isn’t.
There’s nothing inherent to CORS that determines whether shared content is safe content. A vulnerability in one site could leak a cross-site scripting attack into another. Sandboxed iFrames help the browser mitigate attacks from potentially malicious content. They add a level of granularity that’s missing from the SOP, but only for browsers that support it. Browser storage provides megabytes of space for an app to place users’ data. Yet a dev that places a plain text password into browser storage is violating long-standing security practices.
Browsers are taking incremental steps toward a more secure web ecosystem. We’ll forever be plagued by cross-site scripting, but emerging standards like Content Security Policy (think of it as a combination of CORS and iFrame sandboxes) might severely dampen it. The CORS-related headers mitigate some kinds of CSRF attacks. Application can set the X-Frame-Options header to get rid of an entire class of attack – clickjacking. Yet for all cases, the browser must support the feature.
The browser is a hostile place. Keep this in mind when you start adopting HTML5. Its features may help you keep data safer within the browser, but they need your help to keep data safe once it travels through the wild realms of servers and databases.
No comments:
Post a Comment