views:

199

answers:

6

If I am on a website#1, and I enter my username/pwd for website#2 on a login page that is on website#1, and website#1, behind the scenes, makes a httpwebrequest to website#2 and posts to the login page. If I then navigate to website#2, should I be logged in?

website#2 uses formsauthentication and I call a httpHandler that is on website#2 and pass it the username/password via the querystring.

Should this work?

+1  A: 

What you're trying to do is called Single Signon. The way you're doing it, posting values from one site to another, probably won't work because you're using the same technique a hacker might use to trick user into sharing their login information. It's called a cross-site request forgery attack. IIS is configured not to allow that.

Generally, you need a central authentication system that both sites use to share login information. This can be done in several ways, including a shared database-based login system. Google "asp.net single sign on" for more ideas.

Dave Swersky
IIS does NOT prevent XSS attacks! XSS attacks are prevented by the Browser only, and that can be turned off by the user. Because he is doing the request on the Server, IIS will dutifully allow the request as though it were coming from any normal client. A hacker would use JavaScript embedded into a page in order to make a request behind the scenes to another site and attempt to impersonate the user by using their cookies. Making requests server side from one domain to another is just normal everyday stuff.
Josh
That's why I said Cross-Site Request Forgery (CSRF) NOT Cross-Site Scripting (XSS.)
Dave Swersky
I appologize since I meant to put CSRF down as an acronym, but if you will look at what I described it is in fact a Cross Site Request Forgery. The argument still stands.
Josh
A: 

This could work, depending on the security measures in place on website #2. For a secure website, this would fail.

I would recommend against this purely on the basis of good security and good coding/design practices.

If you are unclear what security measures stop this, you should probably educate yourself so you can prevent the same issues on your own site. See http://www.owasp.org/index.php/Top_10_2007

A: 

While this can be done on some cases, in the form of an HTTP request with POST parameters, you will not be authenticated once you browse to site #2.

This is because, generally, these sites store a cookie on your end and these are domain-based, which means that even if you grabbed that and stored it yourself from site #1, the cookie name would not match site #2.

Additionally, site #2 may not be easy to authenticate against and this is usually a security concern that developers are aware of. This can be considered an attempt of XSS as well.

In case you're simply doing this for yourself, I'd recommend LastPass and save most of your info in it.

Please reconsider your goals and how to achieve them, this is not the way.

Edit: Link text.

andre
A: 

Since both your sites are using FormsAuthentication you can easily configure both of them to share FormsAuthentication encryption schemes.

This will allow you to do Cross Application Authentication automatically :)

Josh
+1  A: 

Do site #1 and #2 want their users to have single sign on? If so, read up on single sign on. It's a bigger project than can be addressed here. There is a good book on it though from Wrox : http://www.amazon.com/Professional-ASP-NET-Security-Membership-Management/dp/0764596985/ref=cm_lmf_tit_10

Or are we imagining something sinister?
If we are imagining something sinister, then evil site #1 would collect the credentials, then automate a browser on the server side to start checking to see if site #2 uses the same password and user combination. Then the server would have an authenticated session. This wouldn't give the user who accessed site #1 an auth cookie, the HttpWebRequest object on the server would get the auth cookie. Site #2 couldn't really do anything to prevent this because a browser request from one computer looks much alike a browser request from another. A well crafted attack would spoof all elements of the browser's request so that it looks like it came from a browser instead of a primitative HttpWebRequest object, which may not even set the user-agent.

Site #2 should stop using passwords and user Id or use 2 factor ID if they are concerned abut this, or do something that requires javascript for logon because spoofing a browser that is executing javascript is harder than spoofing a browser that just sends and receives http requests and responses.

MatthewMartin
+1  A: 

There are too many security issues trying to auto-authenticate between sites. There needs to be a central security provider that both sites belong to so that hand off is completed securely.

We use CA's Siteminder for cross site authentication. Effectively, web 1 creates a unique session id on the siteminder server and passes any credentials and info to it. Siteminder invokes web2 and passes the information by means of session variables. Web 2 retrieves the data from the session and uses it. There's much more going on there but that's the just of it.

To do something like this, I would strongly consider using an out of the box solution as generally coding up custom security generally falls short.

asp316