3 ms·

The problem with node.js, as well as a great thing about it, is that it's still immature and evolving quickly. For example, I notice you mentioned node-paperboy

by pjscott 16y ago

The problem with node.js, as well as a great thing about it, is that it's still immature and evolving quickly. For example, I notice you mentioned node-paperboy, a handy minimalistic library for serving static files. It's nice, but buggy. If you don't specify a 404 handler function, it'll default to just keeping those connections open indefinitely. If you aren't running it behind something like nginx, there's a trivial security hole where you can encode "../" as "%2E%2E/" in your URL and get access to whatever files node has read access to. Your app seems to be safe (thanks, nginx!), and your code is good stuff, but the node world is full of pitfalls like this. (GitHub self-pimpage: since I use node-paperboy myself, I fixed the security hole and all the stability problems I could find. The patches haven't been merged into the main repo yet, but here's the fixed version: http://github.com/PeterScott/node-paperboy http://github.com/PeterScott/node-paperboy)

andrewvc 16y ago
Small world, I've contributed a fair amount of code to node-paperboy. In fact, I'm the person who forgot to check for URL encoding in paths! Thanks for finding that. I thought about the whole 404 thing, funny thing is, I didn't really think of it as a bug at the time, since I had a specific set of use cases where not specifying a 404 would have been senseless. That's the likely cause for my myopia there. However, the deal with paperboy is it's more of a starting point for writing your own file based HTTP server, not so much a drop it in and serve static files affair. It's got some other problems as well. I'd fix them, but I don't really use node.js anymore. If I were still using node here's what I'd look at with paperboy: 1. No tests (ugh) 2. I'm not sure what would happen if you tried serving a large file to a slow client (it reads in a stream based fashion, but since writing to the socket doesn't block, that memory has to go somewhere) Reads might need to be throttled. 3. It doesn't have sensible defaults, like the 404 thing. All that stuff would be trivial to look at, hopefully someone will. I myself am not a node.js developer anymore (doing a lot of eventmachine). Thanks for the patch, I'm sure felix will add it in soon enough.
- wolfhumble 16y ago
  ". . . but I don't really use node.js anymore." Why is that?
  - andrewvc 16y ago
    Node is still going through a lot of changes,and their Zeromq lib is still alpha quality.
    - pjscott 16y ago
      Specifically, the zeromq.node library uses 100% of the CPU spinning in a busy-wait loop. There are plans to switch to a more reasonable architecture, but the author hasn't had the time to actually do it yet. Wait a few months and I'm sure all this discussion will be horribly obsolete, of course.
- tlrobinson 16y ago
  Directory traversal vulnerabilities due to URL encoding issues seem to be very common, I found an identical bug in Rack::File a couple years ago (http://github.com/rack/rack/commit/488d67988ddfb7e13ad2f58272ee04809612cafe http://github.com/rack/rack/commit/488d67988ddfb7e13ad2f5827...)

by pjscott 16y ago

andrewvc 16y ago

Small world, I've contributed a fair amount of code to node-paperboy. In fact, I'm the person who forgot to check for URL encoding in paths! Thanks for finding that. I thought about the whole 404 thing, funny thing is, I didn't really think of it as a bug at the time, since I had a specific set of use cases where not specifying a 404 would have been senseless. That's the likely cause for my myopia there. However, the deal with paperboy is it's more of a starting point for writing your own file based HTTP server, not so much a drop it in and serve static files affair. It's got some other problems as well. I'd fix them, but I don't really use node.js anymore. If I were still using node here's what I'd look at with paperboy: 1. No tests (ugh) 2. I'm not sure what would happen if you tried serving a large file to a slow client (it reads in a stream based fashion, but since writing to the socket doesn't block, that memory has to go somewhere) Reads might need to be throttled. 3. It doesn't have sensible defaults, like the 404 thing. All that stuff would be trivial to look at, hopefully someone will. I myself am not a node.js developer anymore (doing a lot of eventmachine). Thanks for the patch, I'm sure felix will add it in soon enough.

wolfhumble 16y ago
". . . but I don't really use node.js anymore." Why is that?
- andrewvc 16y ago
  Node is still going through a lot of changes,and their Zeromq lib is still alpha quality.
  - pjscott 16y ago
    Specifically, the zeromq.node library uses 100% of the CPU spinning in a busy-wait loop. There are plans to switch to a more reasonable architecture, but the author hasn't had the time to actually do it yet. Wait a few months and I'm sure all this discussion will be horribly obsolete, of course.
tlrobinson 16y ago
Directory traversal vulnerabilities due to URL encoding issues seem to be very common, I found an identical bug in Rack::File a couple years ago (http://github.com/rack/rack/commit/488d67988ddfb7e13ad2f58272ee04809612cafe http://github.com/rack/rack/commit/488d67988ddfb7e13ad2f5827...)