將輸入的字符串驗證爲URL - 值得安全嗎？

在我寫的一個Web應用程序中，我爲登錄的訪問者提供輸入URL的機會，以便將他們上傳的圖片作爲鏈接返回到他們的網站。將輸入的字符串驗證爲URL - 值得安全嗎？

我要驗證字符串輸入，以確保它是一個URL，但正在考慮的解決方案的複雜性在那裏後，我想，也許這是沒有必要的。

然而，是否有我可能通過不這樣做缺少任何安全隱患？（我正在考慮有效URL可能包含惡意腳本或類似情況的情況）。

來源

2012-06-09 John Doe

此功能似乎是Cross-Site Request Forgery (CSRF) attack的完美示例，上傳者鏈接到觸發CSRF攻擊的網頁。

爲了減輕CSRF攻擊的風險，確保與現場效果的行爲不能被攻擊網站進行預測。這通常是通過所謂的令牌來完成的，該令牌是您的網站和登錄訪問者只知道的隨機值。

來源

2012-06-09 17:59:07 Gumbo

我瞭解CSRF了重要的警告，我想整個實現它，雖然我不知道有我的web應用程序採取任何可能被利用作爲這樣的 - 它僅僅顯示了鏈接的照片回原始博客或任何頁面。用戶上傳圖片，鏈接他們的始發頁面和鏈接標題。我想我想知道如何讓這個儘可能安全。我不希望鏈接成爲CSRF陷阱。如果這樣做存在一般風險，那麼或許我不能保證安全，並且不能手動檢查每個鏈接，這是不可行的。 –

@JohnDoe除非無法預測操作參數，否則（經過身份驗證的）用戶在您的頁面上可以執行的任何操作也可以由攻擊站點代表受害者僞造。 – Gumbo

那麼，假設我使用會話令牌匹配方法來阻止我的表單中的CSRF（並且PDO準備好後續數據庫插入語句），是否還有其他任何允許訪問者發佈鏈接的潛在問題（表面上顯示其照片的來源）？ –

正確驗證的URL是不平凡的。您可以get close，但它仍不一定涵蓋RFC所允許的一切。只要你不是評估作爲輸入的URL，運行html_escape（）或你的框架的等效應該是一個足夠的預防措施，以保護您的網站免受隨意的字符串惡作劇。

您可能需要研究的框架，瞭解什麼預防措施，如果有的話，你需要對跨站點腳本，SQL注入，以及其他相關的問題。大多數可能出錯的東西都會涉及到無標籤的輸入，但是你的里程可能會有很大的不同。

保護用戶如果您期望100％的安全性，可能不是一個合理的設計目標。畢竟，網絡並不是一個受保護的沙箱。

來源

2012-06-09 18:06:22

對不起 - 你是什麼意思的_「只要你不評價的URL作爲輸入...」？ –

@JohnDoe它的意思是：「永遠不要通過** eval **或相關方法運行unsanitized輸入，並且不要將用戶輸入視爲有效的代碼。」 –

我從不使用'eval（）'，我總是嘗試驗證用戶輸入。我的問題是想知道我是否應該試圖確定一個URL **是否是一個URL。您的深入示例似乎表明，這可能不是100％。 –

URL的安全問題與它們的有效性有關（儘管爲了捕獲錯誤而進行基本檢查是很好的做法，當然，您需要使用與數據相同的輸入驗證和輸出轉義代碼一般）;這與危險的URL方案有關。

最值得注意的是javascript: URL並非真正的位置，而是腳本內容注入鏈接它們的頁面，導致跨站點腳本漏洞。還有其他計劃有類似的問題。最好的辦法是僅允許已知的方案，例如檢查字符串是以http://還是https://開頭。

來源

2012-06-11 11:28:54 bobince

會檢查字符串是以「http：//」還是「https：//」開頭？沒有辦法將腳本或類似內容嵌入到開始那樣的字符串中？也許我應該知道「其他計劃」！謝謝！ –

沒有辦法將腳本嵌入到HTTP/HTTPS URL中，當然，當您將該URL注入更廣泛的上下文中時，仍然需要進行正確的轉義以確保內容不會脫離上下文（例如，放入文檔時HTML轉義）。然而，有一個令人討厭的鮮爲人知的問題，URL中的分號可能會導致解析器僅在IE中對進行混淆，這可能會導致跨站腳本。最好避免元刷新。 – bobince

將輸入的字符串驗證爲URL - 值得安全嗎？

回答

相關問題