views:

236

answers:

2

If a user clicks on a button that does a post (lets say it has UserName and Password in the post) and those credentials get authenticated successfully. If I did a redirect to a completely different application (so I can't carry session, etc) and I use a GET with the Username and Password in the querystring (I could even use basic encryption if that helps but regardless) and then when it gets to the page, I check to make sure it came from the page I expected it to come from, pull the values from the querystring, put them in a session variable and then do a redirect back to the same page (removing the querystring values so they can't be viewed by user). This all happens over SSL on the same server.

Can someone point out the security holes of someone intercepting the UserName and Password in this scenario?

+4  A: 

If you are using SSL, noone can intercept the request. The problem is actually with the client itself. It's not really a good idea to put username and passwords in a GET request (even encrypted), because:

  1. URL can be easily copied and pasted to someone else.
  2. If a user clicks an outside link, the URL will be sent as the referrer.
  3. XSS attacks can be used to hijack the URL.
Mehrdad Afshari
Thanks for the reply. I do know it's generally not recommended but I wanted to know *where* the security hole is. The client should never actually see the querystring because the redirects happen on the server and I clean up the URL before it gets to client, right?
EdenMachine
The browser will see the URL and might even cache it. At least, I suggest you set a cookie (with domain=the other Web site) instead of passing values in querystring.
Mehrdad Afshari
"because the redirects happen on the server", this is not correct. The server basically sends a HTTP response that tells the client to go to the other page.
Mehrdad Afshari
At what point does the URL with the querystring values reach the client? There are two server-side redirects that happen before it gets to the client the first redirect adds the User/Pass and the second redirect removes the User/Pass before sending to client, right?
EdenMachine
"The server basically sends a HTTP response that tells the client to go to the other page." - hmm, I wasn't aware of this - I thought the server handles all these before sending. *scratches head now* =\
EdenMachine
`Response.Redirect` just sends the URL (with QueryString) to the browser with a specific HTTP status code. Its completely up to the browser to control the redirect.
Mehrdad Afshari
IIRC correctly probably 'Server.Transfer' does not send http redirect headers to the clients, but has several disadvantages of its own.
ChristopheD
Server.Transfer does not work across AppDomains. Basically, it's not much more than calling the Page.ProcessRequest method on the other page. I believe Server.Transfer in for good old classic ASP days. Not many reasons you'd use it in ASP.NET.
Mehrdad Afshari
Thanks - I have a clear picture now!
EdenMachine
@EdenMachine: If you chose to go with the cookie solution, make sure its encrypted and set its HttpOnly property to true
Mehrdad Afshari
+3  A: 

Mehrdad already gives some problems, here are some others:

  • When used in a get request the username and password will be plainly visible in the users browser's history / cache.
  • The username / password combination will probably show up in you server logs too.

Also: think about using 'salted' hashes for the passwords instead of just storing it plaintext (if that's not the case already). Added: As Mehrdad correctly comments: ...even in case of salted hash, it's still vulnerable to replay attacks...

Edit:

@EdenMachine: I think you should google for 'Cross Site Authentication' and the likes - this will be 'somewhat' harder to implement but will (when done correctly) be done more secure (and also seamless). Example link: http://aspalliance.com/1513_Cross_Site_Authentication_and_Data_Transfer.all

ChristopheD
And even in case of salted hash, it's still vulnerable to replay attacks.
Mehrdad Afshari
Indeed, good point!
ChristopheD
I'll add this to my answer...
ChristopheD
Thanks - I appreciate the help!
EdenMachine