aw-server icon indicating copy to clipboard operation
aw-server copied to clipboard

API needs authentication or to stop using POST

Open lahwran opened this issue 1 year ago • 4 comments

Arbitrary websites can request localhost urls unless they have the appropriate headers, and this only protects against some request types. Specifically, POST is not blocked by a lack of an Access-Control-Allow-Origin header. ActivityWatch does not appear to have one, so the browser should block requests from webpages loaded from remote urls.

$ curl -vv -H "Origin: http://attacker.com" http://localhost:5600
*   Trying 127.0.0.1:5600...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 5600 (#0)
> GET / HTTP/1.1
> Host: localhost:5600
> User-Agent: curl/7.68.0
> Accept: */*
> Origin: http://attacker.com
> 
* Mark bundle as not supporting multiuse
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Server: Werkzeug/2.1.2 Python/3.9.14
< Date: Mon, 26 Jun 2023 15:13:41 GMT
< Content-Disposition: inline; filename=index.html
< Content-Type: text/html; charset=utf-8
< Content-Length: 1683
< Last-Modified: Mon, 26 Sep 2022 19:14:27 GMT
< Cache-Control: no-cache
< Date: Mon, 26 Jun 2023 15:13:41 GMT
< Connection: close

https://about.gitlab.com/blog/2021/09/07/why-are-developers-vulnerable-to-driveby-attacks/

lahwran avatar Jun 26 '23 15:06 lahwran

We have CORS setup with flask_cors so this should not be possible. Either something has changed in newer aw-server versions, or you are running you aw-server with custom origins enabled (you can do that either with an CLI argument or by enabling it in the config file for aw-server).

https://github.com/ActivityWatch/aw-server/blob/df76a778596cb65dcca174c1f80a5ff04077c829/aw_server/server.py#L80

Can you reproduce it with aw-server-rust as well? We are using rocket_cors in aw-server-rust, worked a few months ago at least.

I'm unfortunately on vacation and dont have a laptop with me, so I can't reproduce ATM.

johan-bjareholt avatar Jun 26 '23 16:06 johan-bjareholt

Looking at that source file, I notice that the CORS headers are only configured for the /api/* endpoints.

That should probably be fixed.

ErikBjare avatar Jun 26 '23 18:06 ErikBjare

I don't see any fixable bug in CORS, and my report may have been misleading; what I'm reporting is that the lack of authentication means having correct CORS configuration does not block POST, and so authentication is needed. But I also might have misunderstood CORS. I'll double check on latest.

lahwran avatar Jun 26 '23 19:06 lahwran

No, I think you're right.

I've thought through this before (a long time ago) and came to the conclusion it was not a (significant) issue, at the time.

I still think there's not much of an issue in our case (except maybe a low-severity disk-spam/DoS vuln), but you are right: other origins can make cross-site POST requests, they just won't see the response. (https://security.stackexchange.com/questions/183981/why-dont-browsers-block-cross-site-posts-by-default)

I'm sick right now, so don't have the brain power for security mindset. But we should look into if we can remedy this. (check Origin header server-side?)

Thank you for raising this issue again, always appreciate an extra set of eyes on security.

Edit: asked ChatGPT too just for reference. I think it covers the issue pretty well: https://chat.openai.com/share/2a9730d7-e762-4075-8b49-2c6ebc4a3d7b

ErikBjare avatar Jun 27 '23 20:06 ErikBjare