You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The code to create the redirect URL (and the back URL) appears to use the HTTP headers to construct said URLs. This is vulnerable to cache-poisoning attacks isn't it?
On a local setup I can set an 'evil' X-Forwarded-Host header and if TKTAuthLoginURL uses a relative path, it will redirect to the 'evil' host to login. This can be worked around using a fully-qualified URL for TktAuthLoginURL, but the 'back' link after the user successfully logs in still goes to the 'evil' host.
The text was updated successfully, but these errors were encountered:
The code to create the redirect URL (and the back URL) appears to use the HTTP headers to construct said URLs. This is vulnerable to cache-poisoning attacks isn't it?
http://www.skeletonscribe.net/2013/05/practical-http-host-header-attacks.html
On a local setup I can set an 'evil' X-Forwarded-Host header and if TKTAuthLoginURL uses a relative path, it will redirect to the 'evil' host to login. This can be worked around using a fully-qualified URL for TktAuthLoginURL, but the 'back' link after the user successfully logs in still goes to the 'evil' host.
The text was updated successfully, but these errors were encountered: