Regarding the dangers of redirects, I think Ben is talking about open redirects, where your taking the URL or part of it from user input. If you don't validate this, an attacker can create a link that looks like a link to your site, but that actually takes the user to another site.
For example, it's very common to redirect users back to the page they were viewing when they logged in.
Let's say a user visits
yoursite.io/private
which requires login, so you redirect them to
yoursite.io/login*?next=/private*
After logging in, you take that next parameter from the URL and redirect them there.
If you're not careful to validate that that parameter starts with a single slash (which indicates that it is a path within your site), an attacker could give someone a link to
How I handle that next url: in the auth middleware, if the check fails, I store the path of the request in the session before redirecting to login. Then, in the login handler, retrieve the path from the session and redirect. That way, we're guaranteed that the path is on our site AND it can't be modified.
Nice. Thanks for sharing your approach. I have seen devs (in videos) have a catchall route for any route that doesn't match something on the server or client -> if any route is passed to domain.com/someroute that doesn't match an explicit route just goes to domain.com/ - but catching it in the next would ensure that they go to the right place and not just back to the homepage.
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.
Yes, I think caution is reasonable here. I hope to learn always from other developer approaches and patterns. Mostly, I care about why. :)
Regarding the dangers of redirects, I think Ben is talking about open redirects, where your taking the URL or part of it from user input. If you don't validate this, an attacker can create a link that looks like a link to your site, but that actually takes the user to another site.
For example, it's very common to redirect users back to the page they were viewing when they logged in.
Let's say a user visits
which requires login, so you redirect them to
After logging in, you take that
nextparameter from the URL and redirect them there.If you're not careful to validate that that parameter starts with a single slash (which indicates that it is a path within your site), an attacker could give someone a link to
which causes your server to redirect the user to
http://evil.comThanks for the description of this, Frederik! That is good to protect against. I think I've covered this risk, but I should verify.
How I handle that
nexturl: in the auth middleware, if the check fails, I store the path of the request in the session before redirecting tologin. Then, in the login handler, retrieve the path from the session and redirect. That way, we're guaranteed that the path is on our site AND it can't be modified.Nice. Thanks for sharing your approach. I have seen devs (in videos) have a catchall route for any route that doesn't match something on the server or client -> if any route is passed to
domain.com/someroutethat doesn't match an explicit route just goes todomain.com/- but catching it in the next would ensure that they go to the right place and not just back to the homepage.