Proxy ? based powerful attack on http-server caught in wild. Can force out of memory

I run http-server primarily for SPA with proxy redirect. I prefer to just use http-server directly without an NGINX or some other firewall for my projects.

Environment Versions

1. OS Type : Debian GNU/Linux 9.13 (stretch)
2. Node version: v14.18.1
3. http-server version: v13.0.2

Steps to reproduce

1. make a request (POST, GET, etc) such that the url = ‘/?/?/?/?/?.. (repeated for about a hundred times) …/?/?/api’
2. This will force http-server to end up using all the available memory
3. sample start http-server ./web -o -c-1 -p 8080 --proxy http://localhost:8080?"

Suggestion

1. I would propose a PR that links to this issue that deflects against this simple but powerful attack. that uses url.slice(0,4) === '/?/?' The more advanced way to handle this is to not use regex (intensive) but an indexOf analysis so we can parse legitamate query variables vs an actual attack.

Request thoughts and interest in handling this attack? I can propose an precise curl command and repository to demonstrate. Let me know.

Have an immediate fix i implemented here before we even touch parse. https://github.com/rook2pawn/http-server/commit/6645278d947e888c991ab27847bafae327970be1

[johannesloetzsch]

Thanks to everyone working on this issue 😃

I was running into the same problem, when using the Catch-all redirect with any other request method than GET. All it takes to reproduce it is:

curl -X POST http://localhost:8080

In my opinion it is a major bug, preventing http-server to be used an productive systems for SPAs before this is fixed.

Working solution for me is serving the SPA via 404.html as described in the README.md:

cp index.html 404.html

However, this impacts the returned HTTP status code to be 404 instead of 200.

I see 3 different solutions for the bug to be resolved:

1. Fix the implementation, so that the --proxy option can be used for arbitrary request methods
2. Provide a new commandline option (called e.g. --spa or --fallback) that serves index.html instead of returning 404
3. Merge the mitigation suggested by @rook2pawn

When help is wanted to implement 1. or 2., let me know…

[rook2pawn]

@kade-d I made one small change here that stops this request before it takes any computational power.

It only uses String.slice and equality so this is very efficient and has kept my http-server up since I’ve implemented this fix on my own fork.