Effective security boundaries require conclusive checks (data is or is not valid) with well-defined outcomes (access is or is not granted). Yet the passage between boundaries is fraught with danger. As the twin-faced Roman god Janus watched over doors and gates -- areas of transition -- so does the twin-faced demon of insecurity, TOCTOU, infiltrate web apps.

This demon's two faces watch the state of data and resources within an app. They are named:

• Time of check (TOC) -- When the data is inspected, such as whether an email address is well formed or text contains a <script> tag. Data received from the browser is considered "tainted" because a malicious user may have manipulated it. If the data passes a validation function, then the taint may be removed and the data permitted entry deeper into the app.
• Time of use (TOU) -- When the app performs an operation with the data. For example, inserting it into a SQL statement or web page. Weaknesses occur when the app assumes the data has not changed since it was last checked. Vulns occur when the change relates to a security control.

Boundaries protect web apps from vulns like unauthorized access and arbitrary code execution. They may be enforced by programming patterns like parameterized SQL statements that ensure data can't corrupt a query's grammar, or access controls that ensure a user has permission to view data.

We see security boundaries when encountering invalid certs. The browser blocks the request with a dire warning of "bad things" might be happening, then asks the user if they want to continue anyway. (As browser boundaries go, that one's probably the most visible and least effective.)

Ideally, security checks are robust enough to prevent malicious data from entering the app. But there are subtle problems to avoid in the time between when a resource is checked (TOC) and when the app uses that resource (TOU), specifically duration and transformation.

One way to illustrate a problem in the duration of time between TOC and TOU is in an access control mechanism. User Alice has been granted admin access to a system on Monday. She logs in on Monday and keeps her session active. On Tuesday her access is revoked. But the security check for revoked access only occurs at login time. Since she maintained an active session, her admin rights remain valid.

Another example would be bidding for an item. Alice has a set of tokens with which she can bid. The bidding algorithm requires users to have sufficient tokens before they may bid on an item. In this case, Alice starts off with enough tokens for a bid, but bids with a lower number than her total. The bid is accepted. Then, she bids again with an amount far beyond her total. But the app failed to check the second bid, having already seen that she has more than enough to cover her bid. Or, she could bid the same total on a different item. Now she's committed more than her total to two different items, which will be problematic if she wins both.

In both cases, state information has changed between the TOC and TOU. The resource was not marked as newly tainted upon each change, which let the app assume the outcome of a previous check remained valid. You might apply a technical solution to the first problem: conduct the privilege check upon each use rather than first use (the privilege checks in the Unix sudo command can be configured as never, always, or first use within a specific duration). You might solve the second problem with a policy solution: punish users who fail to meet bids with fines or account suspension. One of the challenges of state transitions is that the app doesn't always have omniscient perception.

Transformation of data between the TOC and TOU is another potential security weakness. A famous web-related example was the IIS "overlong UTF-8" vulnerability from 2000 -- it was successfully exploited by worms for months after Microsoft released patches.

Web servers must be careful to restrict file access to the web document root. Otherwise, an attacker could use a directory traversal attack to gain unauthorized access to the file system. For example, the IIS vuln was exploited to reach cmd.exe when the app's pages were stored on the same volume as the Windows system32 directory. All the attacker needed to do was submit a URL like:

https://iis.site/dir/..%c0%af..%c0%af..%c0%af../winnt/system32/cmd.exe?/c+dir+c:\\

Normally, IIS knew enough to limit directory traversals to the document root. However, the %c0%af combination didn't appear to be a path separator. The security check was unaware of overlong UTF-8 encoding for a forward slash (/). Thus, IIS received the URL, accepted the path, decoded the characters, then served the resource.

Unchecked data transformation also leads to HTML injection vulnerabilities when the app doesn't normalize data consistently upon input or encode it properly for output. For example, %22 is a perfectly safe encoding for an href value. But if the %22 is decoded and the href's value created with string concatenation, then it's a short step to busting the app's HTML. Normalization needs to be done carefully.

TOCTOU problems are usually discussed in terms of file system race conditions, but there's no reason to limit the concept to file states. Reading source code can be as difficult as decoding Cocteau Twins lyrics. But you should still review your app for important state changes or data transformations and consider whether security controls are sufficient against attacks like input validation bypass, replay, or repudiation:

• What happens between a security check and a state change?
• How are concurrent read/writes handled for the resource? Is it a "global" resource that any thread, process, or parallel operation might act on?
• How long does the resource live? Is it checked before each use or only on first use?
• When is data considered tainted?
• When is it considered safe?
• When is it normalized?
• When is it encoded?

January was named after the Roman god Janus. As you look ahead to the new year, consider looking back at your code for the boundaries where a TOCTOU demon might be lurking.

BayThreat held its 2012 conference this December in Sunnyvale, CA. Yes, I was sorely disappointed it wasn't actually in Sunnydale (with a 'd').

My colleagues, @sshekyan and @tukharian, and I gave an overview on the security of WebSockets. The presentation slides are available now.

Reading slides is always a hazardous approach to understanding a presentation. You may be completely lost because you don't have the benefit of background given during the talk, miss key points conveyed orally, or misunderstand comments. When a recording is available I'll add a link to it.

In the meantime, here's a rough script for the introduction of the topic. (Usually I try to just jot down a handful of notes, but this post needed some more words. Keep in mind the intro is supposed to clock well under 10 minutes. It's brief by intent.)

1 Hello, BayThreat. Hello, WebSockets.

2 The length of time we have to cover WebSockets is about the same as a saturday morning cartoon from the 80s. So, we'll skip the commercial breaks and, kind of like Voltron, bring together a bunch of ideas and observations about this cool, new protocol.

3 In the past, web apps have found many legitimate use cases for persistent connections and two-way communication. HTTP doesn't support this in any efficient or optimal way for continuous traffic. Trying to get this done with long polling, XHR, or DOM tricks are all workarounds, and like the plans of a cartoon villain (Skeletor, Hordak, Cobra Commander), they never seem to work like you want them to. (Mumra)

4 That doesn't mean there aren't good techniques for two-way communication, they just aren't as good as they could be in terms of bandwidth or handling non-text data.

HTML5 introduced Server-Sent Events to accommodate most long-polling scenarios in which the browser just needs to wait for incoming data. For example, stock quotes, tweets, or some other data for which the browser is a passive observer rather than an active participant.

5 Which brings us to RFC 6455, WebSockets. It's a way to encapsulate almost any protocol on top of RFC 2616 (HTTP) without being as messy as RFC 1149.

6 There are two major components to WebSockets. The communication protocol, which is designed to have low overhead and low complexity. And the JavaScript API, which is designed to be a simple interface for the browser. Send with the send() method, receive with the onmessage() method, and then just an open(), close(), and onerror() method to round out the object.

7 So, let's take at look at how the browser sets up a WebSocket connection. First, it goes through a challenge-response handshake. The challenge is 128 random bits (that's a 16d8 for any role-players out there -- about 2 1/2 flamestrikes for you 1st ed. AD&D clerics).

8 Next, the server responds. The response is a hash of the client's challenge plus a GUID defined by the RFC. The response also includes a "Connection: Upgrade" header so the two end points know to stop talking HTTP and start talking WebSockets. A while ago Carnegie Mellon & Google did a study with Chrome users and discovered that many proxies would strip that Connection header -- thus killing the handshake process. However, wss: connections (that is, WebSockets over SSL/TLS) were mostly immune to interference from proxies. So, not only will you create a more secure connection, you'll be more likely to create the connection in the first place.

9 An important thing to understand about the handshake is that it proves the server speaks the protocol. That's it. It's not a cryptographic handshake to prove identity or trust. And another point, the handshake isn't supposed to start within mixed content. Also, the browser is supposed to limit pending connections to one per origin in order to prevent connection floods.

10 Once the browser and server complete the handshake, they switch from HTTP to sending WebSocket data frames. A data frame's overhead can be as low as two bytes -- flags and a length. The maximum overhead is 14 bytes, so we're still talking an order of magnitude improvement over something like XHR or vanilla HTTP.

Two notable parts of a data frame are the variable length fields and the mask.

11 The length of a payload is indicated by 7, 16, or 64 bit values. A length is supposed to be represented by its shortest form. However, if you think of similar situations like overlong UTF-8 encoding you can imagine how variable-length fields might be a source of problems in terms of bypassing detection mechanisms or sneaking across security boundaries. And, of course, you have the potential for buffer abuse. You could submit a data frame that declares a few gigs of payload but only carries a few bytes. If you have a server that pre-allocates memory based on payload lengths alone (without, for example, even validating the frame), then it'd be an easy DoS. In other instances the server might experience a buffer over- or under-run.

12 Data masking is an aspect of WebSockets that's transparent to the user. It's intended to prevent WebSockets from being a vector for cross-protocol attacks. For example, you wouldn't want WebSocket data to corrupt a proxy cache by impersonating HTML content, nor would you want a WebSocket to start spitting out EHLO commands to an SMTP server in order to spam the internet. (By the way, the handshake is also a countermeasure.)

The browser applies a mask to all outgoing WebSocket frames. It's not encryption. The 32-bit "key" for the mask is included in the data frame. In other words, you're essentially sending the "decryption" key along with the message. The user isn't able to influence or access the mask from the JavaScript API.

(As and aside, I created this figure with a dozen or so lines of a Scapy script; which speaks to how simple the protocol is to parse.)

13 The browser controls a few other things that are kept out of view from the JavaScript API. It handles "ping" and "pong" frames for connection keep-alives. It's also supposed to limit the verbosity of error reporting to prevent WebSockets from being a better host or port "scanner" than previous techniques like using XHR or src attributes of img or iframe tags.

14 Finally, remember that upgrading a connection from HTTP to WebSockets loses a certain amount of security context. The handshake itself carries information like Authentication headers, cookies, CORS, and the Origin header. However, you have to be careful about how you track and maintain this context after switching protocols. Imagine a simple chat application. It's one thing to have a session cookie identify a user's HTTP connection. But if your chat protocol relies solely on strings or JSON structures to identify the sender and recipient of messages, then it's probably a short step to spoofing messages unless you remember to enforce server-side controls on the user's state and chat interactions.

With that groundwork out of the way, let's turn the channel to more educational programs on the security of WebSockets.

... end part I ...

And with that we've exhausted the article. Keep an eye on this site for more updates on WebSocket security.

Friends, Romans, coding devs, lend me your eyes. I've created an HTML Injection Quick Reference (HIQR). More details here.

It's not in iambic pentameter, but there's a certain rhythm to the placement of quotation marks, less-than signs, and alert functions.

For those unfamiliar with HTML injection (or cross-site scripting in the Latin Vulgate), it's a vuln that can be exploited to modify a web page in a way that changes the DOM or executes arbitrary JavaScript. In the worst cases, the app delivers malicious content to anyone who visits the infected page. Insecure string concatenation is the most common programming error that leads to this flaw.

Imagine an app that allows users to include <img> tags in comments, perhaps to show off cute pictures of spiders. Thus, the app expects image elements whose src attribute points anywhere on the web. For example:

<img src="https://web.site/image.png">

If users were limited to nicely formed https links, all would be well in the world. (Sort of, there'd still be an issue of what content that link pointed to, whether obscene, copyrighted, malware, multi-GB images that would DoS browsers or sites they're sourced from, and so on. But those are threat models for a different day.)

There's already trouble brewing in the form of javascript: schemes. For example, an attacker could inject arbitrary JavaScript into the page -- a dangerous situation considering it would be executing within the page's Same Origin Policy.

<img src="javascript:alert(9)">

Then there's the trouble with attributes. Even if the site restricted schemes to https: an uncreative hacker could simply add an inline event handler. For example:

<img src="https://&" onerror="alert(9)">

Now the attacker has two ways of executing JavaScript in their victim's browsers -- javascript: schemes and event handlers.

There's more.

Suppose the app writes anything the user submits into the web page. We'll even imagine that the app's developers have decided to enforce an https: scheme and the tag may only contain a src value. In an attempt to be more secure, the app writes the user's src value into an <img> element with no event handlers. This is where string concatenation rears its ugly, insecure head. For example, the hacker submits the following src attribute:

https:">alert(9)

The app drops this value into the src attribute and, presto!, a new element appears. Notice the two characters at the end of the line, ">, these were the intended end of the src attribute and <img> tag, which the attacker's payload subverted:

<img src="https:">alert(9)>">

A few more tweaks to the payload, such as creating some <script> tags, and the page is fully compromised.

HTML injection attacks become increasingly complex depending on the context of where the payload is rendered, whether characters are affected by validation filters, whether regexes are used to deny malicious payloads, and how payloads are encoded before being placed on the page.

SPQR (Senātus Populusque Rōmānus) was the Latin abbreviation used to refer to the collective citizens of the Roman empire. Read up on HTML injection and you'll become SPQH (Senātus Populusque Haxxor) soon enough.

Here are the slides for my presentation, Mitigating JavaScript Mistakes Using HTML5, at this year's RSA Europe.

The goal is to show that the move towards more complex web apps demands more complex JavaScript, which in turn creates more potential for security bugs. Yet rather than audit every line of deployed JavaScript, we can apply controls like Cross-Origin Request Sharing, HTML5 sandboxes, and Content Security Policy headers to improve the security of apps within the browser. These countermeasures don't fix server-side code, but they do help reduce the impact to users when hackers try to exploit vulns within a web site.

I'll continue to post more articles here that expand and explain the slides. For example, the references to BeEF are intended to show the relation of variable scope, objects, prototypes, and hijacking content within JavaScript in a sort of hack-the-hacker approach. Since BeEF relies heavily on JavaScript, it's a nice way to explore concepts with a real-life scenario that could attack any site, rather than show the concepts against some fake sites.

And thanks in advance to all who attended.

John Carpenter fans know the only way you'll escape from New York is if Snake Plissken is there to get you out. When it comes to web security, don't bother waiting for Kurt Russell's help. You're on your own.

And if you're dealing with escape characters in JavaScript strings, you'll want to make sure your application is a maximum security environment.

Imagine an app with a search function. It takes a form field named q and, instead of reflecting the search term in the field's value, it updates the value attribute with a one-line JavaScript call. Normally, you'd expect an app to just rewrite the <input> field like so:

<input id="searchResult" type="text" name="q" value="abc">

It's not necessarily a bad idea to update the element's value with JavaScript. Building HTML with string concatenation is a notorious vector for XSS. Writing the value with JavaScript might be more secure than rebuilding the HTML every time because the assignment avoids several encoding problems. This works if you're keeping the HTML static and trading JSON messages with the server.

On the other hand, if you move the server-side string concatenation from the <input> field to a <script> tag, then you've shifted the XSS problem to a different vector. In our target app, the <input> field's value was delimited with quotation marks ("). The JavaScript code uses apostrophes (') to delimit the string, as follows:

<script>
document.getElementById('searchResult').value = 'abc';
</script>

Rather than strip apostrophes from the search variable's value, the developers decided to escape them with backslashes. Here's how it's expected to work when a user searches for abc'.

document.getElementById('searchResult').value = 'abc\\'';

Escaping the payload's apostrophe preserves the original string delimiters, prevents the JavaScript syntax from being manipulated, and blocks HTML injection attacks -- so it seems.

What if the escape is escaped? Perhaps by throwing a backslash of your own into a search term like abc\\'.

document.getElementById('searchResult').value = 'abc\\\\'';

The developers caught the apostrophe, but missed the backslash. When JavaScript tokenizes the string it sees the escape working on the second backslash instead of the apostrophe. This corrupts the syntax, as follows:

//              ⬇ end of string token
value = 'abc\\\\'';
//               ⬆ dangling apostrophe

From here we just start throwing HTML injection payloads against the app. JavaScript interprets \\ as a single backslash, accepts the apostrophe as the string terminator, and parses the rest of our payload.

https://web.site/search?q=abc**\\';alert(9)//**

document.getElementById('searchResult').value = 'abc\\\\';alert(9)//';

JavaScript's semantics are lovely from an attacker's perspective. Here's an example payload using the String concatenation operator (+) to glue the alert function to the value:

https://web.site/search?q=**abc\\'%2balert(9)//**

document.getElementById('searchResult').value = 'abc\\\\'+alert(9)//';

Or we could try a payload that uses the modulo operator (%) between the String and our alert.

abc\\'%alert(9)//

Maybe the developers added the alert function to a denylist, e.g. a regex for alert\(, by checking for an opening parenthesis. In that case, call the function via the window object's property list. This makes it look like an innocuous string to naive regexes:

abc\\'%window["alert"](9)//

What happens if the denylist contained the word alert altogether? Build the string character by character:

abc\\'window[String.fromCharCode(0x61,0x6c,0x65,0x72,0x74)](9)//

By now we've turned an evasion of an escaped apostrophe into an exercise in obfuscation and filter bypasses. These examples focused on all the permutations of escape sequences in JavaScript strings. Check out the HIQR for more anti-regex patterns and JavaScript obfuscation techniques.

A few additional tips when defending against the payloads:

• In code reviews, be suspicious of string concatenation. Use safer methods to bind user-supplied data to HTML.
• If you create output encoding methods rather than relying on frameworks like React, make sure they match the DOM context where the data will be written.
• Normalize data before operating on it, whether this entails character set conversion, character encoding, substitution, or removal.
• Apply security checks after normalization, preferring inclusion lists over exclusion lists -- it's a lot easier to guess what's safe than assume what's dangerous.

Normalization is an important first step. Any time you transform data you should reapply security checks. Snake Plissken was never one for offering advice. Instead, think of The Hitchhiker's Guide to the Galaxy and recall Trillian's report as the Infinite Improbability Drive powers down (p. 61):

...we have normality, I repeat we have normality....Anything you still can't cope with is therefore your own problem.

Good luck with normality and trying to correctly escape data. Security isn't a certainty, but one thing is, at least according to Queen -- there's "no escape from reality."