2010-08-10 32 views
2

我一直在瀏覽OWASP前10名,以深入瞭解每種特定類型的漏洞。我已經走到最後一個項目,Unvalidated URL Redirects。我理解這次襲擊;這樣的網絡釣魚方案現在看起來完全明顯,我已經在OWASP中閱讀了它。我很難理解的是,爲什麼這種重定向風格首先出現。爲什麼打開重定向URL?

必須有一定的優勢(S)到包括重定向URL作爲參數的URL

example.com/go.php?url=newpage.php

,而不是使用許多其他可能的重定向方案。即使url參數是動態生成的,它是否仍然可以通過POST發送,以防止創建惡意URLS?爲什麼Google允許任何人發送「我很幸運」的重定向網址,比如this one,它會轉到Stack Overflow?

回答

1

現在這個問題已經有點老了,但是我仍然會爲你回答它,以防你仍然好奇,或者完全忘記它。 :)

下面是兩種最常見的用例將重定向,我能想到的參數:

  1. 由於監控或警告用戶,當他們離開網站的一種方式。在想要跟蹤趨勢和用戶流量的網站上,比如Twitter的網址縮寫,或Google搜索跟蹤,這可以用來找出用戶下一步要去的地方。網站也可能會仔細檢查網址並檢查它是否安全,或僅向用戶提供一個「離開頁面」,警告他們離開域名。

  2. 要記住用戶的意圖是在他們被轉移之前。例如,用戶可能試圖直接訪問他們的帳戶頁面,但他們需要重定向到登錄頁面才能登錄。一旦成功,用戶將被引導回他們最初嘗試訪問的頁面,而不是默認頁面,從而幫助連續性。

在第二種情況下,預期的URL確實可以作爲隱藏參數或作爲cookie傳遞。但是,這兩種技術仍然可能容易受到濫用,就像OWASP識別的一樣......除了可能將URL作爲會話變量存儲在服務器端的情況。

+0

重定向是可以理解的,但爲什麼不使用PUSH請求來阻止與可信域生成惡意鏈接? – grossmae 2011-12-03 09:50:19

+0

啊,這就是網址縮寫在傳回一個簡潔的URL之前應該做的事情,是的?或者,如果他們不這樣做,他們應該在實際重定向用戶之前實時驗證URL。 – BoffinbraiN 2011-12-05 18:03:59

+0

我真的不相信這是URL shortener的責任來驗證URL的(如果甚至可能的話)。這些URL自然不應該被信任。但是,如果您可以在Google的域名前創建一個與Google域名的鏈接以訪問任何網站,那麼對我而言,這就是Google的安全問題。 – grossmae 2011-12-07 07:11:20