|
|
Posted by "Kristen G. Thorson" on 09/29/03 11:25
Dan Trainor wrote:
>Hello once more, all -
>
>I was wondering if it's at all possible to redirect a user to a remote
>site, while passing HTTP AUTH credentials somehow.
>
>I've been tinkering around with making a secure login gateway, and the
>first server that they log in to would negotiate the login sequence, but
>the system would have to preserve HTTP USER and HTTP PASSWD to be passed
>to the remote site, as to be backwards compatible with existing HTTP
>AUTH-based systems.
>
>I'd rather not use http://user:pass@site.com, however. There's got to
>be a different way. I understand that the user's browser is the actual
>element in which the username and password are stored for HTTP auth. Is
>there a way to "inject" or "update" this information without any
>interaction from the visitor him/herself?
>
>Thanks again!
>-dant
>
>
>
A few weeks ago, I was asked the same question, due to new M$ security
feature:
http://support.microsoft.com/kb/834489
The authenticated site is third party and cannot change their login
process or type, so that's why HTTP authentication cannot be turned into
something else. The idea is that someone can make
user:password@domain.com look like this:
www.microsoft.com%01@evil.com
which would make poor unsuspecting people think they were going to
microsoft.com. The real problem is described here:
http://www.microsoft.com/technet/security/bulletin/MS04-004.mspx and
http://support.microsoft.com/?id=833786
If you hover your mouse over the link before this security update was
applied, you should only see "www.microsoft.com", not the entire link
url because of the %01 character. So, obviously, the whole thing has to
be disabled!
Okay, so then I looked into an AJAX-type thing, wondering if the browser
would cache authentication if I passed it in a Javascript call. I gave
it a shot, but kept getting script syntax errors. Apparently the same
security update that disabled authentication in the url disabled it in
the XMLHTTP open method:
http://www.codingforums.com/archive/index.php/t-45348.html
The workarounds MS described in 834489 (two of which are "tell them to
enter the user name and password" and "don't do it at all". shoot me.)
are all MS specific, and it'd be nice to find a method that would work
on all (most) browsers.
This is where I ended my research, but hopefully it will keep some other
poor soul from having to wade through the MS knowledge base battling
vague references to vulnerabilites and security holes. Good luck, and
please let me know what your solution is.
kgt
Navigation:
[Reply to this message]
|