Hi, nice write up (also I need to check secutils).
I've encountered this issue but I don't think "redirect after login" is where you're most at risk to find it for two reasons :
It's pretty easy to secure (only allow redirections to your own domain). You donlt even need to do this at the application level : You can use your reverse proxy or WAF to inspect every response, make sure redirects are always the same domain as the request, and block everything else.
I wouldn't even put this in the URL to begin with. I'd just store the intended route (not even the full URL) in a session so I don't have to pass it as a param from page to page if the user also has to create an account, validate it and so on.
Where I did encounter the issue is when some clients (in a b2b app) required us to redirect users to their users to a document on their own site (not ours) and keep track of who clicked the link. So we basically built a redirect route that would accept an url as a param, log that thebuser clicked the url and redirect them... And here we can't check that the domain is the same because it won't be. I think the best approach in this case is to do something like a url shortener : store the redirect urls in a database and just pass the id as a param (but you still have to either disable the reverse proxy rule I mentionned in point 1, or keep track of every authorized redirect domain and update the config accordingly).
Kibana Platform Security at @elastic • Open-source toolbox for security-minded engineers at http://secutils.dev • Free ETF research tools at http://azbyte.xyz
Location
Berlin, Germany
Work
Creator of the open-source toolbox for security-minded engineers - http://secutils.dev
It's pretty easy to secure (only allow redirections to your own domain). You donlt even need to do this at the application level : You can use your reverse proxy or WAF to inspect every response, make sure redirects are always the same domain as the request, and block everything else.
Yep, in a simple case with a single deployment model, you can do that on the proxy level. However, you'd need to write an integration test against your real proxy to ensure your configuration works as expected after your initial setup. Otherwise, at some point, it will likely break during an upgrade, domain or sub-domain change, or some other proxy configuration refactoring. So, it might not be as cheap and easy as it seems at first.
The second reason to implement this on the application level is if you support multiple deployment models. For example, for Secutils.dev, I want to accommodate both on-premises setups (with or without WAFs, reverse proxies, etc.) and my own SaaS, where I do have a reverse proxy. In this case, I want Secutils.dev to work consistently everywhere and place as little deployment burden on on-premises users as possible.
I wouldn't even put this in the URL to begin with. I'd just store the intended route (not even the full URL) in a session so I don't have to pass it as a param from page to page if the user also has to create an account, validate it and so on.
It could work too, I think it's a matter of taste. I usually prefer not to create sessions (or any other server-side persistent data) for unauthenticated users to reduce the chance of unauthenticated DDoS attacks. You can add some acrobatics with client-side localStorage/sessionStorage, but using different mediums to store pieces of the session would be even more complicated.
And here we can't check that the domain is the same because it won't be.
I assume you also maintain a list of whitelisted domains on a per-customer/global level at least, right? If so, the attack surface might not be that big to seriously worry about it. Also, since we usually only care about security for users using browsers, a whitelist can also be bound to the HTTP Referer header (assuming the resources where links are located populate that header).
I think the best approach in this case is to do something like a url shortener
Yeah, that's another form of mapping based on whitelisted domains and outbound redirects.
but you still have to either disable the reverse proxy rule I mentionned in point 1, or keep track of every authorized redirect domain and update the config accordingly
That's another reason to consider doing this on application level, by the way.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi, nice write up (also I need to check secutils).
I've encountered this issue but I don't think "redirect after login" is where you're most at risk to find it for two reasons :
It's pretty easy to secure (only allow redirections to your own domain). You donlt even need to do this at the application level : You can use your reverse proxy or WAF to inspect every response, make sure redirects are always the same domain as the request, and block everything else.
I wouldn't even put this in the URL to begin with. I'd just store the intended route (not even the full URL) in a session so I don't have to pass it as a param from page to page if the user also has to create an account, validate it and so on.
Where I did encounter the issue is when some clients (in a b2b app) required us to redirect users to their users to a document on their own site (not ours) and keep track of who clicked the link. So we basically built a redirect route that would accept an url as a param, log that thebuser clicked the url and redirect them... And here we can't check that the domain is the same because it won't be. I think the best approach in this case is to do something like a url shortener : store the redirect urls in a database and just pass the id as a param (but you still have to either disable the reverse proxy rule I mentionned in point 1, or keep track of every authorized redirect domain and update the config accordingly).
Hey,
Thanks for the comment!
Yep, in a simple case with a single deployment model, you can do that on the proxy level. However, you'd need to write an integration test against your real proxy to ensure your configuration works as expected after your initial setup. Otherwise, at some point, it will likely break during an upgrade, domain or sub-domain change, or some other proxy configuration refactoring. So, it might not be as cheap and easy as it seems at first.
The second reason to implement this on the application level is if you support multiple deployment models. For example, for Secutils.dev, I want to accommodate both on-premises setups (with or without WAFs, reverse proxies, etc.) and my own SaaS, where I do have a reverse proxy. In this case, I want Secutils.dev to work consistently everywhere and place as little deployment burden on on-premises users as possible.
It could work too, I think it's a matter of taste. I usually prefer not to create sessions (or any other server-side persistent data) for unauthenticated users to reduce the chance of unauthenticated DDoS attacks. You can add some acrobatics with client-side localStorage/sessionStorage, but using different mediums to store pieces of the session would be even more complicated.
I assume you also maintain a list of whitelisted domains on a per-customer/global level at least, right? If so, the attack surface might not be that big to seriously worry about it. Also, since we usually only care about security for users using browsers, a whitelist can also be bound to the HTTP Referer header (assuming the resources where links are located populate that header).
Yeah, that's another form of mapping based on whitelisted domains and outbound redirects.
That's another reason to consider doing this on application level, by the way.