URL查詢字符串的安全性問題（ASP.NET）

如果一個按鈕，做了一個後用戶點擊（可以說是具有用戶名和密碼後），並且這些憑據得到成功驗證。如果我做了一個重定向到一個完全不同的應用程序（所以我不能攜帶會話等），我使用GET與查詢字符串的用戶名和密碼的時候（我甚至可以使用基本的加密是否有幫助，但不管），然後它進入的頁面，我檢查，以確保它從我預計它來自網頁來了，從查詢字符串拉值，把它們放在一個會話變量，然後做一個重定向到同一頁（去除查詢字符串值，以便它們不能被用戶查看）。這一切都發生在同一臺服務器上的SSL上。URL查詢字符串的安全性問題（ASP.NET）

有人能指出有人攔截此方案中的用戶名和密碼的安全漏洞？

來源

2009-04-15 EdenMachine

如果您正在使用SSL，沒有人可以攔截請求。問題實際上與客戶本身有關。這不是一個真正的好主意，把用戶名和密碼在GET請求（即使是加密的），因爲：

URL可以很容易地複製並粘貼到別人。
如果用戶點擊一個鏈接外，該URL將被髮送引薦。
XSS攻擊可以用來劫持URL。

來源

2009-04-15 22:05:36

感謝您的答覆。我知道這通常不被推薦，但我想知道哪裏是安全漏洞。客戶端應該永遠不會看到查詢字符串，因爲重定向發生在服務器上，我在清除URL到達客戶端之前，對吧？ – EdenMachine 2009-04-15 22:08:23

瀏覽器將會看到該URL，甚至可能會將其緩存。至少，我建議你設置一個cookie（與domain =其他網站），而不是在querystring中傳遞值。 – 2009-04-15 22:10:32

邁赫達德已經給出了一些問題，這裏有一些其他：

當一個GET請求中使用的用戶名和密碼會在用戶瀏覽器的歷史記錄/緩存清晰可見。
的用戶名/密碼組合可能會出現在你的服務器登錄過。

另外：想想使用'鹽漬'哈希密碼，而不是隻存儲它的明文（如果不是這種情況）。新增：作爲邁赫達德正確評論：...即使在鹽漬哈希的情況下，它仍然容易受到重放攻擊...

編輯：

@EdenMachine：我想你應該谷歌「跨站身份驗證」和喜歡 - 這將是‘有些’難以實現，但會（在正確完成）完成更安全（也無縫）。例如鏈接：http://aspalliance.com/1513_Cross_Site_Authentication_and_Data_Transfer.all

來源

2009-04-15 22:12:18 ChristopheD

URL查詢字符串的安全性問題（ASP.NET）

回答

相關問題