DEV Community: Richard Feldman

What would you pay for type checking?

Richard Feldman — Mon, 10 Feb 2020 14:24:10 +0000

Here’s a statement that shouldn’t be controversial, but is anyway: JavaScript is a type-checked language.

I’ve heard people refer to JavaScript as “untyped” (implying that it has no concept of types), which is odd considering JS's most infamous error—“undefined is not a function”—is literally an example of the language reporting a type mismatch. How could a supposedly “untyped” language throw a TypeError? Is JS aware of types or isn't it?

Of course, the answer is that JavaScript is a type-checked language: its types are checked at runtime. The fact that the phrase “JavaScript is a type-checked language” can be considered controversial is evidence of the bizarre tribalism we’ve developed around when types get checked. I mean, is it not accurate to say that JavaScript checks types at runtime? Of course it's accurate! Undefined is not a function!

Truly Untyped Languages

Assembly language does not have “undefined is not a function.”

This is because it has neither build time nor runtime type checking. It’s essentially a human-readable translation of machine code, allowing you to write add instead of having to handwrite out the number corresponding to an addition machine instruction.

So what happens if you get a runtime type mismatch in Assembly? If it doesn’t check the types and report mismatches, like JavaScript does, what does it do?

Let’s suppose I’ve written a function that capitalizes the first letter in a lowercase string. I then accidentally call this code on a number instead of a string. Whoops! Let’s compare what would happen in JavaScript and in Assembly.

Since Assembly doesn't have low-level primitives called “number” or “string,” let me be a bit more specific. For “number” I’ll use a 64-bit integer. For “string” I’ll use the definition C would use on a 64-bit system, namely “a 64-bit memory address pointing to a sequence of bytes ending in 0.” To keep the example brief, the function will assume the string is ASCII encoded and already begins with a lowercase character.

The assembly code for my “capitalize the first letter in the string” function would perform roughly the following steps.

Treat my one 64-bit argument as a memory address, and load the first byte from memory at that address.
“Capitalize” that byte by subtracting 32 from it. (In ASCII, subtracting 32 from a lowercase letter’s character code makes it uppercase.)
Write the resulting byte back to the original memory address.

If I call this function passing a “string” (that is, a memory address to the beginning of my bytes), these steps will work as intended. The function will capitalize the first letter of the string. Yay!

If I call this function passing a normal integer…yikes. Here are the steps my Assembly code will once again faithfully perform:

Treat my one 64-bit argument as a memory address, even though it’s actually supposed to be an integer. Load the first byte from whatever memory happens to be at that address. This may cause a segmentation fault (crashing the program immediately with the only error information being “Segmentation fault”) due to trying to read memory the operating system would not allow this process to read. Let’s proceed assuming the memory access happened to be allowed, and the program didn’t immediately crash.
“Capitalize” whatever random byte of data we have now loaded by subtracting 32 from it. Maybe this byte happened to refer to a student's test score, which we just reduced by 32 points. Or maybe we happened to load a character from the middle of a different string in the program, and now instead of saying “Welcome, Dave!” the screen says “Welcome, $ave!” Who knows? The data we happen to load here will vary each time we run the program.
Write the resulting byte back to the original memory address. Sorry, kid - your test score is just 32 points lower now.

Hopefully we can all agree that “undefined is not a function” is a significant improvement over segmentation faults and corrupting random parts of memory. Runtime type checking can prevent memory safety problems like this, and much more.

Bytes are bytes, and many machine instructions don’t distinguish between bytes of one type or another. Whether done at build time or at runtime, having some sort of type checking is the only way to prevent disaster when we’d otherwise instruct the machine to interpret the bytes the wrong way. “Types for bytes” was the original motivation for introducing type checking to programming, although it has long since grown beyond that.

Objective Costs of Checking Types

It’s rare to find discussions of objective tradeoffs in the sea of “static versus dynamic” food fights, but this example actually illustrates one.

As the name suggests, runtime type checking involves doing type checking…at runtime! The reason JavaScript wouldn’t cause a segmentation fault or corrupt data in this example, where Assembly would, is that JavaScript would generate more machine instructions than the Assembly version. Those instructions would record in memory the types of each value, and then before performing a certain operation, first read the type out of memory to decide whether to proceed with the operation or throw an error.

This means that in JavaScript, a 64-bit number often takes up more than 64 bits of memory. There’s the memory needed to store the number itself, and then the extra memory needed to store its type. There’s also more work for the CPU to do: it has to read that extra memory and check the type before performing a given operation. In Python, for example, a 64-bit integer takes up 192 bits (24 bytes) in memory.

In contrast, build time type checking involves doing type checking…at build time! This does not have a runtime cost, but it does have a build-time cost; an objective downside to build-time type checking is that you have to wait for it.

Programmer time is expensive, which implies that programmers being blocked waiting for builds is expensive. Elm’s compiler builds so fast that at NoRedInk we’d have paid a serious “code’s compiling” productivity tax if we had chosen TypeScript instead—to say nothing of what we’d have missed in terms of programmer happiness, runtime performance, or the reliability of our product.

That said, using a language without build-time checking will not necessarily cause you to spend less time waiting. Stripe’s programmers would commonly wait 10-20 seconds for one of their Ruby tests to execute, but the Ruby type checker they created was able to give actionable feedback on their entire code base in that time. In practice, introducing build-time type checking apparently led them to spend less time overall on waiting.

Performance Optimizations for Type Checkers

Both build time and runtime type checkers are programs, which means their performance can be optimized.

For example, JIT compilers can reduce the cost of runtime type checking. JavaScript in 2020 runs multiple orders of magnitude faster than JavaScript in 2000 did, because a massive effort has gone into optimizing its runtime. Most of the gains have been outside the type checker, but JavaScript’s runtime type checking cost has gone down as well.

Conversely, between 2000 and 2020 JavaScript’s build times have exploded—also primarily outside type checking. When I first learned JavaScript (almost 20 years ago now, yikes!) it had no build step. The first time I used JS professionally, the entire project had one dependency.

Today, just installing the dependencies for a fresh React project takes me over a minute—and that’s before even beginning to build the project itself, let alone type check it! By contrast, I can build a freshly git-cloned 4,000-line Elm SPA in under 1 second total, including installing dependencies and full type checking.

While they may improve performance overall, JIT compilers introduce their own runtime costs, and cannot make runtime type checking free. Arguably Rust‘s main reason for existence is to offer a reliable and ergonomic programming language which does not introduce the sort of runtime overhead that come with JIT compilers and garbage collectors.

Build time type checkers are also programs, and their performance can also be optimized.

We often lump build-time type checking performance into the bucket of “compilation time,” but type checking isn’t necessarily the biggest contributor to slow builds. For example, in the case of Rust, code generation is apparently a much bigger contributor to compile times than type checking—and code generation only begins after type checking has fully completed.

Some type checkers with essentially equivalent type systems build faster than others, because of performance optimization. For example, the 0.19.0 release of Elm did not change the type system at all, but massively improved build times by implementing certain performance optimizations which (among other things) made part of type inference take O(1) time instead of O(log(n)) time.

Type Systems Influence Performance

Type system design decisions aren’t free! At both build time and runtime, type checking performance is limited by the features of the type system itself.

For example, researchers have developed type inference strategies that run very fast, but these strategies rely on some assumptions being true about the design of the type system. Introducing certain subtyping features can invalidate these strategies, so offering such features lowers the ceiling on how fast the compiler can be—and for that matter, whether it can offer type inference.

It’s easy to quip “you could guarantee that at build time using ________ types” (fill in the blank with something like linear types, refinement types, dependent types, etc.) but the impact this would have on compilation times is less often discussed.

If your language introduced a given type system feature tomorrow, what would the impact be on compile times? Has anyone developed a way to check those types quickly? How much value does a given feature need to add to compensate for the swordfighting downtime it brings along with it?

Runtime type checkers are subject to these tradeoffs as well. Python and Clojure have different type systems, for example. So do Ruby and Elixir, and JavaScript and Lua. The degree to which their performance can be optimized (by JIT compilers, for example) depends in part on the design of these type systems.

Because it’s faster to check some type system features at runtime than at build time, these forces combine to put performance caps on languages which add build time checking to type systems which were designed only with runtime type checking in mind. For example, TypeScript’s compiler could run faster if it did not need to accommodate JavaScript’s existing type system.

What Would You Pay?

Except when writing in a truly untyped language like Assembly, we’re all paying for type checking somewhere—whether at build time, at runtime, or both. That cost varies based on what performance optimizations have been done (such as build-time algorithmic improvements and runtime JITs), and while type system design choices can restrict which optimizations are available, they don’t directly cause performance to be fast or slow.

Programming involves weighing lots of tradeoffs, and it’s often challenging to anticipate at the beginning of a project what will cause problems later. “The build runs too slowly” and “the application runs too slowly” are both serious problems to have, and which programming language you choose puts a cap on how much you can improve either.

We all have different tolerances for how much we’re willing to pay for this checking, and what we expect to get out of it. It’s worth thinking critically about these tradeoffs, to make conscious decisions rather than choosing the same technology we chose last time because it’s familiar.

So the next time you’re starting a project, think about these costs and benefits up front. What would you pay for type checking?

Thanks to Brian Hicks, Christoph Hermann, Charlie Koster, Alexis King, and Hillel Wayne for reading drafts of this.

Tour of an Open-Source Elm SPA

Richard Feldman — Mon, 08 May 2017 07:47:20 +0000

People often ask me if I can point them to an open-source Elm Single Page Application so they can peruse its code.

Ilias van Peer linked me to the Realworld project, which seemed perfect for this. They provide a back-end API, static markup, styles, and a spec, and you build a SPA front-end for it using your technology of choice.

Here's the result. I had a ton of fun building it!

4,000 lines of delicious Elm single page application goodness

Fair warning: This is not a gentle introduction to Elm. I built this to be something I'd like to maintain, and did not hold back. This is how I'd build this application with the full power of Elm at my fingertips.

I gave a talk at Elm Europe about the principles I used to build this, and I highly recommend watching it! It's called Scaling Elm Apps.

If you're looking for a less drink-from-the-firehose introduction to Elm, I can recommend a book, a video tutorial, and of course the Official Guide.

Routing for User Experience

I went with a routing design that optimizes for user experience. I considered three use cases, illustrated in this gif:

The use cases:

The user has a fast connection
The user has a slow connection
The user is offline

Fast Connection

On fast connections, I want users to transition from one page to another seamlessly, without seeing a flash of a partially-loaded page in between.

To accomplish this, I had each page expose init : Task PageLoadError Model. When the router receives a request to transition to a new page, it doesn't transition immediately; instead, it first calls Task.attempt on this init task to fetch the data the new page needs.

If the task fails, the resulting PageLoadError tells the router what error message to show the user. If the task succeeds, the resulting Model serves as the initial model necessary to render 100% of the new page right away.

No flash of partially-loaded page necessary!

Slow Connection

On slow connections, I want users to see a loading spinner, to reassure them that there's something happening even though it's taking a bit.

To do this, I'm rendering a loading spinner in the header as soon as the user attempts to transition to a new page. It stays there while the Task is in-flight, and then as soon as it resolves (either to the new page or to an error page), the spinner goes away.

For a bit of polish, I prevented the spinner from flashing into view on fast connections by adding a CSS animation-delay to the spinner's animation. This meant I could add it to the DOM as soon as the user clicked the link to transition (and remove it again once the destination page rendered), but the spinner would not become visible to the user unless a few hundred milliseconds of delay had elapsed in between.

Offline

I'd like at least some things to work while the user is offline.

I didn't go as far as to use Service Worker (or for that matter App Cache, for those of us who went down that bumpy road), but I did want users to be able to visit pages like New Post which could be loaded without fetching data from the network.

For them, init returned a Model instead of a Task PageLoadError Model. That was all it took.

Module Structure

We have over 100,000 lines of Elm code in production at NoRedInk, and we've learned a lot along the way! (We don't have a SPA, so our routing logic lives on the server, but the rest is the same.) Naturally every application is different, but I've been really happy with how well our code base has scaled, so I drew on our organizational scheme when building this app.

Keep in mind that although using exposing to create guarantees by restricting what modules expose is an important technique (which I used often here), the actual file structure is a lot less important. Remember, if you change your mind and want to rename some files or shift directories around, Elm's compiler will have your back. It'll be okay!

Here's how I organized this application's modules.

The `Page.*` modules

Examples: Page.Home, Page.Article, Page.Article.Editor

These modules hold the logic for the individual pages in the app.

Pages that require data from the server expose an init function, which returns a Task responsible for loading that data. This lets the routing system wait for a page's data to finish loading before switching to it.

The `Views.*` modules

Examples: Views.Form, Views.Errors, Views.User.Follow

These modules hold reusable views which multiple Page modules import.

Some, like Views.User, are very simple. Others, like Views.Article.Feed, are very complex. Each exposes an appropriate API for its particular requirements.

The Views.Page module exposes a frame function which wraps each page in a header and footer.

The `Data.*` modules

Examples: Data.User, Data.Article, Data.Article.Comment

These modules describe common data structures, and expose ways to translate them into other data structures. Data.User describes a User, as well as the encoders and decoders that serialize and deserialize a User to and from JSON.

Identifiers such as CommentId, Username, and Slug - which are used to uniquely identify comments, users, and articles, respectively - are implemented as union types. If we used e.g. type alias Username = String, we could mistakenly pass a Username to an API call expecting a Slug, and it would still compile. We can rule bugs like that out by implementing identifiers as union types.

The `Request.*` modules

Examples: Request.User, Request.Article, Request.Article.Comments

These modules expose functions to make HTTP requests to the app server. They expose Http.Request values so that callers can combine them together, for example on pages which need to hit multiple endpoints to load all their data.

I don't use raw API endpoint URL strings anywhere outside these modules. Only Request.* modules should know about actual endpoint URLs.

The `Route` module

This exposes functions to translate URLs in the browser's Location bar to logical "pages" in the application, as well as functions to effect Location bar changes.

Similarly to how Request modules never expose raw API URL strings, this module never exposes raw Location bar URL strings either. Instead it exposes a union type called Route which callers use to specify which page they want.

The `Ports` module

Centralizing all the ports in one port module makes it easier to keep track of them. Most large applications end up with more than just two ports, but in this application I only wanted two. See index.html for the 10 lines of JavaScript code they connect to.

At NoRedInk our policy for both ports and flags is to use Value to type any values coming in from JavaScript, and decode them in Elm. This way we have full control over how to deal with any surprises in the data. I followed that policy here.

The `Main` module

This kicks everything off, and calls Cmd.map and Html.map on the various Page modules to switch between them.

Based on discussions around how asset management features like code splitting and lazy loading have been shaping up, I expect most of this file to become unnecessary in a future release of Elm.

The `Util` module

These are miscellaneous helpers that are used in several other modules.

It might be more honest to call this Misc.elm.

Other Considerations

With server-side rendering, it's possible to offer a better user experience on first page load by using cookie-based authentication. There are security risks on that path, though!
If I were making this from scratch, I'd use elm-css to style it. However, since Realworld provided so much markup, I ended up using html-to-elm to save myself a bunch of time instead.
There's a beta of elm-test in progress, and I'd like to use the latest and greatest for tests. I debated waiting until the new elm-test landed to publish this, but decided that even in its untested form it would be a useful resource.

I hope this has been useful to you!

And now, back to writing another chapter of Elm in Action.

Defense Against the Dark Arts: CSRF Attacks

Richard Feldman — Mon, 17 Apr 2017 03:42:39 +0000

After an unspecified "werewolf incident" we have become the new maintainer of the hogwarts.edu web app.

Our first day on the job begins with Professor Dumbledore approaching us, explaining that his official hogwarts.edu account has recently begun sending mysterious messages such as "Potter sux, Malfoy rulez" to all the students.

As Dumbledore has an administrator account, this security hole could lead to much worse problems than pranks. He's asked us to fix the vulnerability before someone exploits it to cause more serious damage.

1. Authentication

The first thing we do is look at the server-side code that handles posting messages. It's very simple. Here's what it does:

Listen for a HTTP request to "hogwarts.edu/dumbledore/send-message?to=all_students&msg=blahblah"
Send "blahblah" (or whatever the msg parameter was set to) from @dumbledore to all students.

There's no attempt to check whether the request actually came from the owner of the @dumbledore account, meaning any attacker can send a HTTP request to hogwarts.edu/dumbledore/send-message and it will be treated as legitimate. Possibly our werewolf predecessor thought this would be fine.

To prevent this from happening in the future, we introduce an authentication system.

First we add a Secret Authentication Key to each user's account, which we randomly generate when the user logs in and delete when they log out.

We've heard that cookies have security problems, so we don't go down that road. Instead, when the user logs in, we record this key in localStorage and have some JavaScript code include it as a header called "secret-authentication-key" in our (legitimate) HTTP requests.

Next we add a step to our server-side logic to verify the key. Our new process:

Listen for a HTTP request to "hogwarts.edu/dumbledore/send-message?to=all_students&msg=blahblah"
Check for a header called "secret-authentication-key" and make sure it matches the Secret Authentication Key we stored in the database for the @dumbledore account. If it doesn't match, reject the request.
Send "blahblah" (or whatever came after the msg parameter) from @dumbledore to all the students.

Now when we try to send phony messages as Dumbledore, the server rejects them for lacking the proper authentication key. When Dumbledore himself logs in and tries to send them himself, it works. Huzzah!

2. Cookies

The day after we roll out this new authentication scheme, Professor Snape apparates with a complaint. When he visits hogwarts.edu/snape/messages to view his private messages, there's now a brief loading spinner before his messages show up. Snape demands that we put it back to the old way, where the messages loaded immediately.

Why did we add the loading spinner? Well, we realized hogwarts.edu/snape/messages was also unsecured, so naturally we secured it with our new "secret-authentication-key" header.

The trouble is, when Snape visits hogwarts.edu/snape/messages the browser doesn't know how to send that custom header in that initial HTTP request to the server. Instead, the server sends back some HTML containing a loading spinner and some JavaScript. The JavaScript reads the key out of localStorage and makes a second request (this time setting the "secret-authentication-key" header), which is finally allowed to fetch Snape's messages from the server.

While that second request is processing, all Snape sees is that rage-inducing spinner.

We fix this usability problem by replacing our custom "secret-authentication-key" header with the Cookie header. Now when Snape logs in, we no longer use localStorage - or for that matter any JavaScript at all - to store the key. Instead, our server puts a "Set-Cookie: key_info_goes_here" header in the response; the browser knows that when it sees a Set-Cookie header on a HTTP response, it should persist the key on Snape's machine, in the form of a cookie.

Now whenever Snape's browser makes a HTTP request to hogwarts.edu, it will automatically send the contents of that cookie in a Cookie header. This is true even for the original HTTP GET request it makes when Snape visits hogwarts.edu/snape/messages - meaning that now our server can authenticate him right there on that first request, and serve the messages in the first response without needing a second HTTP roundtrip.

Here's our new process:

Listen for a HTTP request to "hogwarts.edu/snape/send-message?to=all_students&msg=blahblah"
Check for a header called "Cookie" and make sure it matches the Secret Authentication Key we stored in the database for the @snape account. If it doesn't match, reject the request.
Send "blahblah" (or whatever came after the msg parameter) from @snape to all the students.

Performance problem solved!

3. Cookie GET Vulnerabilities

Wasn't there some reason we hadn't used cookies in the first place? Oh, right. Security concerns.

Sure enough, the day after we roll out our cookie-based solution, Professor McGonagall turns up with a strange story. Just after she visited Draco Malfoy's blog, her official hogwarts.edu account sent another of those "Potter sux, Malfoy rulez" messages to all students. How could this have happened?

Although cookies solved our performance problem, they also opened us up to a new angle of attack: Cross-Site Request Forgeries, or CSRF attacks for short. (Commonly pronounced "C-Surf.")

Viewing the HTML source code of Draco's blog, we notice this:

<img src="http://hogwarts.edu/mcgonagall/send-message?to=all_students&msg=Potter_sux">

As soon as Professor McGonagall visited his blog, her browser did what it always does when it encounters an <img>: send a HTTP GET request to the URL specified in its src. Because the browser is sending this request to hogwarts.edu, it automatically includes Professor McGonagall's stored authentication cookie in the Cookie header. Our server checks to see if the cookie matches - which of course it does - and dutifully posts the malicious message.

Argh!

Avoiding this form of CSRF attack is one reason it's important that all our GET requests do not result in our server taking any important actions. They should be pretty much read-only, give or take perhaps some logging.

We can fix this by adding a new second step to our list:

Listen for a HTTP request to "hogwarts.edu/mcgonagall/send-message?to=all_students&msg=blahblah"
If it is not a POST request, reject it.
Check for a header called "Cookie" and make sure it matches the Secret Authentication Key we stored in the database for the @mcgonagall account. If it doesn't match, reject the request.
Send "blahblah" (or whatever came after the msg parameter) from @mcgonagall to all the students.

Great! Now the <img> CSRF attack no longer works, because <img> only ever results in GET requests to load the src. Professor McGonagall should be able to visit Draco's blog again with no problem.

4. Cookie POST Vulnerabilities

Unfortunately, a few days later, Draco has found a workaround. He replaced the <img> tag with a form instead:

<form method="POST" action="http://hogwarts.edu/mcgonagall/send-message?to=all_students&msg=Potter_sux">

He also put some JavaScript on the page which silently submits this <form> as soon as the page loads. As soon as Professor McGonagall visits the page, her browser submits this form - resulting in a HTTP POST which automatically includes the cookie as usual - and our server once again posts the message.

Double argh!

In an effort to make things a bit more difficult, we change the msg and to fields from URL query parameters to requiring that this information be sent via JSON in the body of the request. This fixes the problem for another day or two, but Draco quickly gets wise and puts the JSON in a <input type="hidden"> inside the form. We're back to square one.

We consider changing the endpoint from POST to PUT, since <form> only supports GET and POST, but semantically this clearly makes more sense as a POST. We try upgrading to HTTPS (doesn't fix it) and using something called "secure cookies" (still doesn't fix it), and eventually stumble upon OWASP's list of other approaches that do not solve this problem before finally finding something that does work.

5. Enforcing Same Origin

OWASP has some clear recommendations on how to defend against CSRF attacks. The most reliable form of defense is verifying that the request was sent by code running on a hogwarts.edu page.

When browsers send HTTP requests, those requests include at least one (and possibly both, depending on whether it was an HTTPS request and how old the browser is) of these two headers: Referer and Origin.

If the HTTP Request was created when the user was on a hogwarts.edu page, then Referer and Origin will begin with https://hogwarts.edu. If it was created when the user was viewing a non-hogwarts.edu page such as Draco's blog, then the browser will dutifully set the Referer and Origin headers to the domain of his blog rather than hogwarts.edu.

If we require that Referer and Origin be set to hogwarts.edu, we can reject all HTTP requests that originated from Draco's blog (or any other third-party site) as malicious.

Let's add this check to our algorithm:

Listen for a HTTP request to "hogwarts.edu/mcgonagall/send-message"
If it is not a POST request, reject it.
If the Origin and/or Referer headers are present, verify that they match hogwarts.edu. If neither is present, per OWASP's recommendation, assume the request is malicious and reject it.
Check for a header called "Cookie" and make sure it matches the Secret Authentication Key we stored in the database for the @mcgonagall account. If it doesn't match, reject the request.
Send a message from @mcgonagall based on the JSON in the request body.

Great! Now if a request comes from outside the browser, it won't have the necessary Cookie header, and if it comes from inside the browser by way of Draco Malfoy's malicious blog, it won't pass the Referer / Origin Same Origin header check.

Importantly, we should not perform this Same Origin check on all requests.

If we did it on all GET requests, for example, then no one could link to hogwarts.edu pages from different websites, as they would be rejected for having a different Referer! We only want to do this Same Origin check for endpoints that no one should ever be able to access from outside a hogwarts.edu page.

This is why it's so important that GET requests be essentially "read-only" - anytime we have to skip this Same Origin check, Draco can use the <img> trick from earlier to cause the endpoint's logic to run. If all that logic does is return information, then the result will be nothing more than a broken-looking <img> on Draco's blog. On the other hand, if the result is that messages get sent from the current user's account, that means an attacker can potentially use CSRF to send messages from the current user's account!

6. Second Line of Defense

Although OWASP does not list any known ways an attacker could circumvent this Same Origin Check defense (other than a successful Cross-Site Scripting attack, which must be defended against separately, as such an attack can circumvent any number of CSRF countermeasures), they still recommend "a second check as an additional precaution to really make sure."

One good reason to have a second check is that browsers can have bugs. Occasionally these bugs result in new vulnerabilities which attackers exploit, and it's always possible that someone might someday uncover a vulnerability in a popular browser allowing them to spoof the Origin and Referer headers.

Having a second line of defense means that if our first line of defense becomes suddenly compromised, we already have a backup defense in place while browser vendors work on patching the vulnerability.

The easiest to implement of OWASP's recommended supplemental defense measures is Custom Request Headers. Here's how it works.

When the browser sends HTTP requests via XMLHttpRequest (aka XHR aka AJAX Request) they are forced to obey the Same-origin Policy. In contrast, HTTP requests sent via <form>, <img>, and other elements have no such restriction. This means that even though Draco can put a <form> on his blog which submits a HTTP request to hogwarts.edu, he can't have his blog use an XHR to send requests to hogwarts.edu. (That is, unless we've explicitly configured hogwarts.edu to enable Cross-Origin Resource Sharing, which of course we haven't.)

Great! Now we know that if we can be sure that our request came from a XHR rather than something like a <form> or <img>, it must have originated from hogwarts.edu (assuming a valid Cookie header, of course) regardless of what the Origin or Referer headers say.

By default, there's no way to tell that a request came from an XHR or not. A POST from a vanilla XHR is indistinguishable from a POST from a <form>. However, XHR supports a feature that <form> doesn't: configuring custom headers.

By having our our XHR set a "Content-Type: application/json" header (which is a semantically sensible header for us to send regardless, since we are sending JSON now), we will have created a HTTP request that a <form> could not have created. If our server then checks for a "Content-Type: application/json" header, that will be enough to ensure the request came from an XHR. If it came from an XHR, then it must have respected the Same-origin Policy, and therefore must have come from a hogwarts.edu page!

This method is a better Second Line of Defense than a First Line of Defense, because it can be circumvented via Flash. So we definitely shouldn't skip the Origin / Referer Same Origin check! We should use this only as an added layer of defense against a theoretical future vulnerability in Origin / Referer.

Final Process

Here's our final server-side process:

Listen for a HTTP request to "hogwarts.edu/mcgonagall/send-message"
If it is not a POST request, reject it.
If the Origin and/or Referer headers are present, verify that they match hogwarts.edu. If neither is present, assume the request is malicious and reject it.
Check for a header called "Content-Type" and make sure it is set to application/json.
Check for a header called "Cookie" and make sure it matches the Secret Authentication Key we stored in the database for the @mcgonagall account. If it doesn't match, reject the request.
Send a message from @mcgonagall based on the JSON in the request body.

This covers our current use case, but there are other things to keep in mind for potential future needs.

If someday we want to use an actual <form> ourselves (instead of an XHR), and we still want a second line of defense on top of the Same Origin check, we can use a synchronizer token.
If we still want to use an XHR but don't want to set a custom header (like Content-Type), or use a synchronizer token, we can use a double submit cookie or an encrypted token instead.
If we want to support CORS, well...then we need to totally rethink our authentication approach!

Summary

hogwarts.edu is now in much better shape. Here's what we've done:

Introduced an authentication system to prevent attackers from impersonating users.
Used cookies to do this in a way that does not require two HTTP roundtrips (with a loading spinner in between) to view pages with private information, like a page listing a user's private messages.
Defended against <img src="some-endpoint-here"> GET CSRF attacks by requiring that endpoints which make changes to things use HTTP verbs other than GET. (In this case, we used POST.)
Defended against <form> POST CSRF attacks by checking that the Origin and/or Referer headers match hogwarts.edu (and rejecting the request if neither header is present).
Added a second line of defense against future potential Origin and/or Referer vulnerabilities by requiring that the Content-Type header be set to application/json.

With all of these put together, we now have some solid defenses against the dark art of CSRF attacks!

If you found this useful, check out the book I'm writing for Manning Publications. I've put a ton of time and love into writing it!

Where Should Tests Live?

Richard Feldman — Mon, 20 Feb 2017 00:31:32 +0000

I came across a design question when working on elm-test recently:

What if you could write tests in the same file as the code they're testing?

There are a few testing systems that support this:

clojure.spec (to vastly oversimplify) lets you define tests inline in the same file as your business logic.
Rust allows putting tests in the same file as the code being tested, although the documentation recommends putting them in a separate file (without elaboration as to why).
Doctests (such as in Python, Elixir, Go, and Haskell) allow writing tests in the same file—theoretically for documentation purposes, although potentially for testing purposes instead.
EUnit in Erlang runs all functions in a given module that end in _test as tests, including business logic modules.
Racket supports inline tests.
Pyret supports "testing blocks" which can live in any source file.
Test::Inline adds support for this to Perl.

I've never used any of these, but I'm wondering how the experience would be in practice. Is it amazing? Unexciting? An outright bad idea? What are the pros and cons compared to putting tests in a separate file?

If you've tried writing tests like this before, what did you think?

I am the author of Elm in Action. Ask Me Anything!

Richard Feldman — Thu, 19 Jan 2017 18:24:15 +0000

I am Richard Feldman, author of Elm in Action and instructor of the Frontend Masters Elm Workshop. The main open-source projects I'm working on right now are elm-test and elm-css.

I work at NoRedInk, where we have 80,000 lines of Elm code in production. We introduced Elm in 2015, and since then our production Elm code has thrown a total of zero runtime exceptions. We hired Elm creator Evan Czaplicki in 2015 to continue developing the language, and we're hiring!

I'll be here until noon Pacific Time. Ask Me Anything!