Is it possible to protect client logs from “log injections” from the end users? Let’s say I’m using Chrome Dev Tools and type throw new Error("I'm evil...");
That would end up in my server logs even though it’s not from my original js-code.
1 Like
whitelist_urls would help, but at a certain point we can’t prevent people from sending data. has this been a problem for you?
No, not yet - I’m just trying to do a threat analysis, as it opens up a way to get weird stuff into logs (not produced by the application itself)…
It seems using the the dev tools console does not send data, even without whitelisting. On the other hand, anyone could you curl or whatever to send correctly formatted “errors” to the collecting endpoint, right? Could possibly be handled by CSRF tokens, Access-Control-Allow-Origin etc, but as you point out - there will always be a way to fake all this, I guess.
There’s never going to be a way to prevent users from doing it. If you did see the problem you can add the IP address of the client to the blocklist in your project settings.
I know Sentry is offered as a SaaS, so I was wondering how they protect their service from a slowloris attack, for example, or any other kind of DDoS attack. Rate limits and whitelists are controled by each application. They can’t base their protection on this. Is it done at the cloud service layer? Maybe using a reverse proxy strategy…