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 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.