登錄到登錄表單中提供的URL後將用戶重定向到什麼安全問題？

我在我的網站上有一個會員區域，如果用戶沒有登錄，他們會被重定向到登錄網址，其中？redirect = [CURRENT_URL]，一旦他們成功登錄，他們就會重定向回[CURRENT_URL]。登錄到登錄表單中提供的URL後將用戶重定向到什麼安全問題？

這種方法的潛在安全問題是什麼，如何預防它們以及有哪些替代方案？

例如惡意用戶可以通過重定向鏈接鏈接到我的網站，該另一個網站是否能夠竊取我用戶的登錄cookie？這種方法可以在我的網站上運行任意的JavaScript嗎？

來源

2011-06-08 Charles Ma

如果當前URL不刪節，你會受到

XSS（偷餅乾，注射腳本）
響應頭拆分

等

如果您知道當前的URL是一個常量並且沒有參數，所以它沒有風險。只要您根據用戶輸入添加參數或創建網址，就會出現技巧性問題。

XSS的一個小例子：

說你的網址可以通過用戶輸入注入查詢字符串。然後從什麼說

的redirectUrl = 「yoursite.jsp somevariable =？」警報（ '惡意軟件'）「）; 或的redirectUrl =」阻止他們？yoursite.jsp somevariable = 「警報（document.cookies）」）;

並竊取您的cookie或執行其他邪惡的java腳本。

響應分裂比較複雜。基本上如果你可以注入一個CRLF，你可以做一些非常糟糕的事情。

Wikipedia對這個漏洞有一個體面的解釋 - 還有其他的你可以通過谷歌搜索http響應分裂。

我已經排除了最明顯的攻擊，即如果用戶可以控制網址，他們可以進入一個類似你的網站，並說服用戶輸入信用卡，憑證等。例如，如果你是一家銀行，有人可以注入

的redirectUrl =「http://myfakebank.com」

，並複製了你的網頁，天哪，用戶將高興地說：「當然，我會reeenter我的憑據」

來源

2011-06-08 05:41:19 MJB

謝謝，MJB。你能更具體一點嗎？以及我可以做些什麼來防止這種XSS或標題拆分攻擊？ – 2011-06-08 05:55:28

最好的治療方法當然不允許用戶提供的輸入。否則，輸入和輸出驗證非常重要。不要允許像＆=％＃< >'「以下的任何字符。通常更喜歡WHITELIST策略 - 只允許允許被允許的字符。但是，這很難應用於真實因爲其中一些字符必須被應用，在這種情況下，URL標準化和驗證庫是有用的。強烈建議閱讀http://www.owasp.org關於響應拆分的信息，XSS和CSRF – MJB 2011-06-08 06:48:50

登錄到登錄表單中提供的URL後將用戶重定向到什麼安全問題？

回答

相關問題