URL查询字符串安全问题（ASP.NET）

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.

如果用户单击发布帖子的按钮(假设它在帖子中有UserName和Password),那么这些凭据将成功通过身份验证。如果我重定向到一个完全不同的应用程序(所以我不能进行会话等),我在查询字符串中使用GET和用户名和密码(如果有帮助,我甚至可以使用基本加密),然后当它到达页面,我检查以确保它来自我期望它来自的页面,从查询字符串中提取值,将它们放在会话变量中然后重定向回到同一页面(删除查询字符串)值因此用户无法查看。这一切都发生在同一台服务器上的SSL上。

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

有人可以指出在这种情况下拦截用户名和密码的人的安全漏洞吗?

2 个解决方案

#1

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:

如果您使用SSL,则没有人可以拦截请求。问题实际上是客户端本身。将用户名和密码放入GET请求(甚至加密)并不是一个好主意,因为:

URL can be easily copied and pasted to someone else.

可以轻松地将URL复制并粘贴到其他人。

If a user clicks an outside link, the URL will be sent as the referrer.

如果用户单击外部链接,则URL将作为引用者发送。

XSS attacks can be used to hijack the URL.

XSS攻击可用于劫持URL。

#2

Mehrdad already gives some problems, here are some others:

Mehrdad已经提出了一些问题,以下是其他一些问题:

When used in a get request the username and password will be plainly visible in the users browser's history / cache.

在get请求中使用时,用户浏览器的历史记录/缓存中将明显显示用户名和密码。

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

另外:考虑为密码使用“盐渍”哈希,而不是仅仅存储明文(如果情况不是这样)。补充:正如Mehrdad正确评论:...即使在盐渍哈希的情况下,它仍然容易受到重播攻击......

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

@EdenMachine:我认为你应该谷歌搜索“跨站点身份验证”等等 - 这将“有点”难以实现,但是(如果正确完成)将更安全(也无缝)。示例链接:http://aspalliance.com/1513_Cross_Site_Authentication_and_Data_Transfer.all

#1