重定向相關的安全隱患

重定向相關的安全隱患

隱患來源:

Web應用中有時會重定向至外界指定的URL。典型的案例爲,在登錄頁面的參數中指定URL,登錄成功後再重定向至該URL。

比如:使用以下URL登錄Googe後,就會重定向到continue=指定的URL(此處爲Gmail)。

https://www.goole.com/accounts/ServiceLogin?continue=https://mail.goole.com/mail/

重定向處理時產生的安全隱患有如下幾種,而且他們都會招致被動攻擊。

  • 自由重定向漏洞
  • HTTP消息頭注入漏洞

自由重定向安全隱患

自由重定向漏洞概要:

有些Web應用中提供了能夠重定向到參數指定的URL的功能,該重定向功能就被稱爲重定向器(Redieector)。

其中,能夠重定向至任意域名的重定向叫做自由重定向(Open Redirect)。自由重定向可能會導致用戶在不知情的情況下被帶到其他域名的網站,從而遭受到釣魚式攻擊(Phishing)。

爲了防範自由重定向漏洞,應該重新評估“外界能夠指定重定向目標URL”的功能是否真的不可或缺,並儘可能將重定向的目標固定。如果實在不能固定重定向的目標,就需要將重定向的目標限制在允許的域名範圍內

自動重定向漏洞總覽:

產生地點:

  • 能夠重定向至外界指定的URL的地方。

影響範圍:

  • 影響範圍並非僅限於Web應用中的某個頁面,通過釣魚式攻擊被竊取重要信息後,Web應用的用戶就會遭受損失。

影響類型:

  • 將用戶誘導至釣魚網站,使其輸入重要信息。
  • 冒充設備驅動程序或更新補丁來散佈病毒。

影響程度:

  • 中~大

用戶參與程度:

  • 很大,點擊鏈接並且輸入信息。

對策概要:

  • 固定重定向目標
  • 採用白名單機制,將重定向目標限定在允許的域名範圍內。

安全隱患的產生原因:

自由重定向漏洞產生的原因有以下兩點。

  1. 重定向的目標URL能夠由外界指定。
  2. 沒有對重定向的目標域名進行校驗。

以上兩點是AND條件,也就是說只有同時滿足這兩點時纔會形成自由重定向漏洞,因此,只要使其中一項無法滿足,也就消除了安全隱患。

解決對策:

自動重定向漏洞的根本性防範策略有以下三項,實施時任選其一即可。

  1. 固定重定向的目標URL
  2. 使用編號指定重定向的目標URL
  3. 校驗重定向的目標域名。

HTTP消息頭注入

HTTP消息頭注入概要:

HTTP消息頭注入漏洞是指在重定向或生成Cookie等基於外部傳入的參數輸出HTTP響應頭時所產生的安全隱患。輸出響應消息頭時,攻擊者通過在參數中插入換行符,就可以在受害人的瀏覽器上實現如下操作:

  1. 任意添加下響應消息頭
  2. 僞造響應消息體。

HTTP請求報文格式:

POST /form/entry  HTTP/1.1 
Connection: Keep-alive
Content-Type: application/X-www-form-urlencoded
Content-Length: 16
空行
name=make&age=18

在HTTP請求頭部中,每行用換行來隔開,一個空行後表示後面爲正文內容。

針對HTTP消息頭注入漏洞實施的攻擊就叫做HTTP消息頭注入攻擊。

響應頭中的換行符有特殊意義。 如果在輸出過程中南沒有對外界指定的換行符進行處理,就會導致HTTP消息頭注入漏洞的產生。

Web應用中若存在HTTP消息頭注入漏洞,就會造成如下影響。

  • 生成任意Cookie
  • 重定向至任意URL(重定向至外部網站)
  • 更改頁面顯示內容(顯示僞造頁面)
  • 執行任意JavaScript而造成與XSS同樣的損害。

換行符(%0D%0A)。

Apache從CGI腳本中南接收的消息頭中如何有多個Location消息頭,Apache就會只將最後一的Location消息頭作爲響應返回,因此,原來的超重定向目標就會作廢,而被換行符後面指定的URL取而代之。

HTTP消息頭注入也會將其稱爲CRRF注入或者HTTP響應截斷攻擊。

HTTP注入安全隱患的產生原因:

HTTP響應頭信息能夠以文本格式逐行定義消息都,也就是說消息頭之間互相以緩和符相隔。而如果攻擊者惡意利用該特性,在指定重定向目標URL或者Cookie值的參數中插入換行符,且該換行符又被直接作爲響應輸入的話,就會產生HTTP消息頭注入漏洞。

解決對策:

對策1:不將外界參數作爲HTTP響應消息頭輸出:

絕大多數情況下,經過重新進行設計評估後,都能夠做到不將外界參數作爲HTTP響應消息頭輸出。Web應用中會用到輸出HTTP響應消息頭的典型功能爲重定向和生成Cookie,而只要遵循以下方針,就能大幅度減少直接將外界參數作爲消息頭輸出的機會。

  • 不直接使用URL指定重定向目標,而是將其固定或者通過編號等方式來指定。
  • 使用Web應用開發工具提供的會話變量來移交URL

因此,在設計階段就應該儘量不把外界參數作爲HTTP響應消息頭輸出。而如果無論如何都必須將外界參數輸出到HTTP響應消息頭中的話,可以通過如下方式來處理。

由專門的API來進行重定向或生成Cookie的處理:

CGI腳本中能夠使用print等語句直接記述HTTP響應頭,但是使用這種方法需要嚴格遵守HTTP和Cookie等標準規格,否則就可能會導致安全隱患等Bug產生。

所以可以使用各種編程語言提供的API來處理。

語言 生成Cookie 重定向 輸出響應消息頭
PHP setcookie/setrowcookie 無(利用header) header
Perl+CGI.pm CGI::Cookie redirect header
Java Servlet HttpServletResponse#addCookie HttpServletResponse#sendRedirect HttpServetResponse#setHeader
ASP.NET Respone.Cookie.Add Respone.Redirect Response.AppendHeader

對策2:檢驗生成消息頭的參數中的換行符:

針對換行符的處理方法右如下兩種。

  1. URL中含有換行符就報錯
  2. 將Cookie中的換行符進行百分號編碼

學習過程中筆記的記錄與資料整理。


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章