OL-Server vulnerable to DNS Rebinding attacks.

[pwn1sher]

The Rest API spawned on port 5000 isn't validating the Host header , as such the server is vulnerable to DNS Rebinding attacks.

Impact :
By tricking users into visiting a website, it will be possible to perform all Rest Calls on behalf of user from the attackers website, bypassing the same origin policy using DNS rebind. Few actions that the attacker can perform are invoking/running functions, read stats etc. There is also a /debug API but currently not configured, attacker can also invoke debug and do stuff based on implementation of the debug functionality.

[tylerharter]

I'm assuming this is just an issue if the worker isn't behind a load balancer? Directly exposing the worker might also be a use case (though I guess less common) -- feel free to implement the cross-origin check in a PR if you think it is important and you would like to do that (otherwise I can leave this open and eventually do it too).

[pwn1sher]

Ideally something like this would be a fast patch, before going to proper regex checks or implementing auth.

if r.Host == "localhost:5000" || r.Host == "127.0.0.1:5000"

Its upto you if you want to implement this on other API's like pid, status, stats etc. But its definitely suggested to implement this on RunLambda as this handling the invoking of functions. Currently its possible for attacker to run functions on victim's OL setup without his knowledge.

[NicoleG25]

Is there any plan to address this vulnerability?
Note that it appears that CVE-2019-20329 was assigned to this issue.

[tylerharter]

I'm happy to review a PR if somebody wants to implement it --otherwise I'll probably give this more careful consideration next summer when I have more cycles to work on OL.

I think of OL is analogous to AWS Lambda, which to the best of my knowledge doesn't directly implement what is being suggested. Any cross-site checks would be implemented by API Gateway, right? This should also be configured on a per-API basis (different tenants may have different preferences about what cross-site requests are allowed).

Currently, if somebody wanted to use OL for something in production, I think they would first need to implement something analogous to API Gateway as a layer in front of OL. I'm not opposed to rolling some API Gateway-like features into OL directly, to simplify this and get OL closer to being production-ready. I just haven't had time to pursue that yet.