desec-io
log PII cleanup
- Action tokens may be part of URLs which get logged. Make sure no PII is recoverable from them (e.g. email addresses).
We log URLs on the www container. URLs may or may not lead to API endpoints.
Non-api:
- Things like https://desec.io/signup/[email protected] (with pre-filled email field). Possible solutions: a) use internal state instead of URL, b) don't log non-API requests. -- Why would we need to log static page requests?
API: There are only two cases where URLs contain non-generic information:
- Authenticate action URLs (e.g. email verification). The URL contains the encrypted verification token which by itself is not PII, but can be used to trigger actions. For the actions implemented right now, it gets invalidated by its use, but that may be different for future actions. -- Should we redesign this somehow?
- dynDNS updates can be authenticated via query parameters, in which case the
passwordparameter (actually an API token) will be logged. Removing it before logging is a hassle, and not logging updates requests is problematic for debugging and defense. As users have other options (header auth), I'm inclined to say this is ok.
Possible solutions: a) use internal state instead of URL, b) don't log non-API requests. -- Why would we need to log static page requests?
It may be possible to move these parameters behind a # in the URL to instruct the browser to not send it to the server. Not sure where these URL come from, anyway. When filling out the form on the desec.io home page and clicking 'signup', it does not send such a request to the server. (Also note that the domain type parameter is sent as a query parameter in the URL, as in https://desec.io/signup/[email protected]?domainType=dynDNS)
Authenticate action URLs (e.g. email verification). The URL contains the encrypted verification token which by itself is not PII, but can be used to trigger actions. For the actions implemented right now, it gets invalidated by its use, but that may be different for future actions. -- Should we redesign this somehow?
I'm not sure this situation can be improved: to move the parameters to the HTTP request body, we could move the code behind a #, load some javascript in the browser, and then send a request using JS. However, currently links work without JS support, which I like. If not using JS, on the other hand, I believe the parameters must be part of the URL.
One solution for all three issues would be to generally not log query parameters. Not sure if that's a good idea, though.
Possible solutions: a) use internal state instead of URL, b) don't log non-API requests. -- Why would we need to log static page requests?
It may be possible to move these parameters behind a
#in the URL to instruct the browser to not send it to the server. Not sure where these URL come from, anyway. When filling out the form on the desec.io home page and clicking 'signup', it does not send such a request to the server.
Yes, the window location is generated by JavaScript without reload. However, if you reload the page while such a URL is displayed, it will be sent to the server. (Similarly, if you take a look through your browsing history, and click on the corresponding entry.)
I like the # approach.
Authenticate action URLs (e.g. email verification). The URL contains the encrypted verification token which by itself is not PII, but can be used to trigger actions. For the actions implemented right now, it gets invalidated by its use, but that may be different for future actions. -- Should we redesign this somehow?
I'm not sure this situation can be improved: to move the parameters to the HTTP request body, we could move the code behind a
#, load some javascript in the browser, and then send a request using JS. However, currently links work without JS support, which I like. If not using JS, on the other hand, I believe the parameters must be part of the URL.
I agree.
We have been using non-hashtag URLs since c07c4ead4, which is late 2019. Changing to hashtag-URLs is possible, and also supported by the next vue.js router version, but seems to be somewhat discouraged.
A naive change would likely break our existing webapp URLs.
@Rotzbua Would you like to take a stab at this, to move the email address of things like https://desec.io/signup/[email protected] behind the URL anchor #?