#nodesecurity

Node.js 0.8.20 was just released and contains a security fix for response splitting.

Response splitting is when a user controlled value (such as a query string parameter) containing new line characters is put in to a header of the response. The injection of additional carriage returns gives an attacker control of the response allowing injection of content into the headers and body.

Let's take a look at the simple example @charliesome provided in the pull request when he initially reported the issue.

var http = require("http"),          url  = require("url"); http.createServer(function (req, res) {   var queryData = url.parse(req.url, true).query;   res.writeHead(302, { "Location": queryData.redirect });   res.end();}).listen(1337, "127.0.0.1");

Using this properly a request and response would look like this. Request:

GET /?redirect=http://liftsecurity.io HTTP/1.1 Host: 127.0.0.1:1337 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:18.0) Gecko/20100101 Firefox/18.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Connection: keep-alive

Response:

HTTP/1.1 302 Moved Temporarily Location: http://liftsecurity.io Date: Sat, 16 Feb 2013 01:51:27 GMT Connection: keep-alive Content-Length: 0

Note: there is no body to the response.

Charlie's example malicious request injects a marquee but it could be any script or body, even other headers.

Request:

GET /?redirect=%0D%0AContent-Length:%2033%0D%0A%0D%0A%3Ch1%3E%3Cmarquee%3Eowned%3C/marquee%3E%3C/h1%3E%0D%0A HTTP/1.1 Host: 127.0.0.1:1337 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:18.0) Gecko/20100101 Firefox/18.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Connection: keep-alive

Response:

HTTP/1.1 302 Moved Temporarily Location: Content-Length: 33 <h1><marquee>owned</marquee></h1> Date: Sat, 16 Feb 2013 01:54:08 GMT Connection: keep-alive Transfer-Encoding: chunked 0

The modified redirect includes a content-length header and a new "malicious" body.

Even though this patch addresses this vulnerability it's best practice to always properly santize any user provided data before sending it on, be that a browser, a database or some other system.

Want to keep up on node.js security related issues, follow us on twitter at @nodesecurity

In the security industry there is a lot of “Hey you, software developer / project! You screwed up on x, go fix it.” and then the “researcher” moves on to another target.

  The problem with this for the researcher (at least from my experience) is that the "high" from finding vulnerabilities just doesn’t last that long and if you're the type of person who wants to make the world better, it leaves you feeling like your only contribution to the world is pointing and laughing at others' mistakes.

  I’ve been searching for and developing ways to take more of a positive, constructive approach within the security industry. Over time, I’ve come to the conclusion that my place is to not contribute to the security industry directly, but to software developers.

  At ^Lift we try hard to make positive contributions to developers knowledge, understanding, and value of security—and we're always aiming to find different and better ways to do this.

  Sometimes just a little attempt can go a long way toward making a positive impact. Let’s look at a recent attempt to report a vulnerability in a different way.

  In npm vulnerability reported with a pull request

npm is a major part of the node.js ecosystem. The security and integrity of this system is pretty important to a lot of developers out there. Our parent company &yet relies heavily on it, so it's a pretty good target for us to care about.

  After finding that the new npmjs.org site did not implement cross-site request forgery tokens, it was possible for me to hijack a user account by submitting changes to a logged in user's profile and resetting their password. A pretty typical way to take over an account. Having this access means you can publish updates to packages that user has access to.

  Instead of just releasing the information publicly, or reporting the issue and saying “go fix it yourself”, I made an attempt to fix the problem and submitted a pull request.

  Isaac Schlueter's response

While Isaac did not necessarily like my pull request's implementation, the problem got fixed, the csrf-lite library was created to help developers implement CSRF protection, and our most recent exchange regarding Node security brought light to the topic from a different angle.

  I was curious to find out how he felt about how I had reported the issue—and if taking things a step further than just a bug report was really a better approach. I emailed him and asked him for his thoughts.

  I loved his comments:

  I think the publicity of an exploit report should be inverselyproportionate to the danger multiplied by the fixing cost.

  That is, if something is very dangerous, or very costly to fix, then it should *definitely* be reported in private.  For example, imagine if there was a bug in node causing an exploit that would let an attacker execute arbitrary JS code on any node http server that parses the query string. That'd require a release, and then everyone to upgrade to that release, which takes a few weeks at the very least. That should definitely be reported privately so that we can fix it, verify that it's fixed, release the fix, and THEN disclose it publicly.  This is how you handled the npm password hash issue, which was quite tricky to fix, and I think it was the right approach. High danger, high fixing cost = very private.

  The danger of CSRF is quite a bit lower.  You have to get someone to actually click a button, which isn't all that hard, but also isn't nothing.  The fix is pretty straightforward, just stash a token and then verify it later, and it can be fixed in one place without having to get a bunch of people to update anything.  So, low danger, easy fix.  In that case, a pull request is exactly right.  It's much more considerate than just tweeting or blogging about how "npmjs.org sux teh secrutiy fail lulz!" which is sadly a pretty common approach.  I had some issues with your specific fix, but if I didn't have the time to whip up a standalone module, I could have just pulled your change, and that would have plugged the exploit.  So, the cost to fix was even *lower* because you actually supplied a patch.

  Sometimes there are issues that aren't necessarily security-related, but are still gnarly harmful bugs.  There was an issue where the `n` library would attempt to `rm -rf ~/` if you did a certain invalid command.  In that case, a very public report was absolutely the right approach (and TJ did the right thing, fixing it fast, and alerting everyone he could about it), but some of the people reporting it still reacted with outrage, as if they'd never fucked up a computer before, even though the bug never even affected them.

  Like any bug, I think a good rule of thumb is to think about what you'd prefer if it was your site that someone was reporting, and assume that the fixing costs might be a bit higher than they appear at first, especially if there are a lot of moving parts