Cross-Site Request Forgery (requires user verification)

 應(yīng)用程序

WASC分類：Authorization: Insufficient Authorization

參考： http://www./projects/threat/classes/insufficient_authorization.shtml

錯(cuò)誤級(jí)別：

         中等（Medium）

風(fēng)險(xiǎn)：

         可以偷盜或者操作用戶Session和Cookie，這樣攻擊者可以扮演一個(gè)合法的客戶進(jìn)行操作。

造成原因：

       應(yīng)用程序調(diào)用了不足夠的安全方法

技術(shù)說(shuō)明：

       CSRF是這種攻擊：能夠使得攻擊者冒充受害者。主要是網(wǎng)站未對(duì)原始鏈接進(jìn)行適當(dāng)?shù)尿?yàn)證。

攻擊的嚴(yán)重程度依賴于網(wǎng)站的功能，在一個(gè)搜索網(wǎng)站上發(fā)生的CSRF攻擊要明顯小于轉(zhuǎn)賬或者用戶信息修改頁(yè)面。

       攻擊者強(qiáng)迫受害者瀏覽器向受害網(wǎng)站發(fā)起一個(gè)請(qǐng)求。如果用戶登錄了受害者站點(diǎn)，請(qǐng)求將自動(dòng)的采用用戶的認(rèn)證（像cookie、用戶IP、以及其他一些Browser認(rèn)證的功能）。這樣，攻擊者使用用戶的身份做自己的事情。換句話說(shuō)，受攻擊的網(wǎng)站無(wú)法采取正確的方式來(lái)驗(yàn)證用戶執(zhí)行的動(dòng)作。

       迫使受害者發(fā)起一個(gè)不想要的請(qǐng)求有多種方式：

Ø  通過(guò)郵件等方式給受害者發(fā)送惡意鏈接

Ø  在黑客自己的網(wǎng)站上放置受攻擊網(wǎng)站的鏈接（通過(guò)圖片或Frame等做成熱鏈接）

Ø  在論壇中放置指向攻擊網(wǎng)站的鏈接

Ø  使用Cross-Site Scripting 或者 Link injection等方式，自動(dòng)將瀏覽器重定向到受害網(wǎng)站

If the attacker uses a Link Injection vulnerability on the vulnerable site itself he or she increases the likelihood of the user being authenticated to the site, and by that increases the likelihood of the attack to succeed.

例如：使用以上任何方法，攻擊者可以誘使受害者點(diǎn)擊頁(yè)面，該頁(yè)面包含

<img src="http://bank/transfer?destination=John&money=1000" style=‘visibility:hidden‘>

這將使受害者的瀏覽器自動(dòng)發(fā)出請(qǐng)求together with the current credentials of the browser 。如果銀行站點(diǎn)易受 CSRF（Cross-Site Request Forgery (requires user verification)） 攻擊，這將從受害者帳戶中轉(zhuǎn)1000元到John的帳戶中。

Cross-Site Request Forgery 攻擊也稱作：CSRF（讀音 see-serf），XSRF，Cross-Site Reference Forgery、One-Clike Attach 和 Session Riding。

系統(tǒng)是否易受CSRF攻擊可以通過(guò)以下方式驗(yàn)證：

1.        檢查 可受攻擊的鏈接不包含攻擊者難以猜測(cè)的參數(shù)

2.      檢查 可受攻擊的你阿姐執(zhí)行起來(lái) willingly

包含敏感操作的應(yīng)用，請(qǐng)求可以直接執(zhí)行用戶不知曉的，被認(rèn)作為可受到 CSRF 攻擊

解決方式：

         為了避免CSRF攻擊，所有的請(qǐng)求必須包含唯一的標(biāo)識(shí)，攻擊者無(wú)法猜測(cè)這個(gè)標(biāo)識(shí)符。

         一個(gè)建議的方式是將 用戶的sessionid作為cookie一部分。 應(yīng)用程序檢查2者是否一致，如果不一致，拒絕該請(qǐng)求。

         任何秘密的東西：攻擊者難以猜測(cè)或者無(wú)法獲取的，都可以替代sessionid，作為標(biāo)識(shí)。

         這將阻止攻擊者發(fā)出一個(gè)看上去合法的請(qǐng)求

Cross-Site Request Forgery (requires user verification)

Application

WASC Threat Classification

Authorization: Insufficient Authorization

http://www./projects/threat/classes/insufficient_authorization.shtml

CVE Reference(s)

N/A

Security Risks

It is possible to steal or manipulate customer session and cookies, which may be used to impersonate a legitimate user, allowing the hacker to view or alter user records, and to perform transactions as that user

Possible Causes

Insufficient authentication method was used by the application

Technical Description

Cross-Site Request Forgery (CSRF) is an attack that allows a hacker to perform an action on the vulnerable site on behalf of the victim. The attack is possible when the vulnerable site does not properly validate the origin of the request.

The severity of this vulnerability depends on the functionality of the affected application, for example, a CSRF attack on a search page is less severe than a CSRF attack on a money-transfer or profileupdate pages.

The attack is performed by forcing the victim‘s browser to issue an HTTP request to the vulnerable site. If the user is currently logged-in to the victim site, the request will automatically use the user‘s credentials (like session cookies, user‘s IP address, and other browser authentication methods). Using this method, the attacker forges the victim‘s identity and submits actions on his or her behalf. In other words, the vulnerable site does not take the proper measures to validate that the user indeed wanted to perform the specific action.

Forcing the victim to send the unintended request can be done in numerous ways:

Ø  Sending the victim a malicious link to the vulnerable application via email.

Ø  Putting a hot-link (like an image or frame) to the vulnerable site on the hacker‘s web page.

Ø  Posting a link to the vulnerable site in a public forum.

Ø  Using Cross-Site Scripting or Link Injection vulnerabilities in the site (or another site) and automatically redirecting the browser to the vulnerable site.

If the attacker uses a Link Injection vulnerability on the vulnerable site itself he or she increases the likelihood of the user being authenticated to the site, and by that increases the likelihood of the attack to succeed.

For example, using any of the above described options, an attacker can lure the victim to view a page containing:

       <img src="http://bank/transfer?destination=John&money=1000" style=‘visibility:hidden‘>

This will cause the victim‘s browser to automatically request the URL together with the current credentials of the browser. If this banking site is vulnerable to CSRF, it will transfer 1000 dollars from the victim‘s account to John‘s bank account according to the application logic.

The Cross-Site Request Forgery attack is also known as CSRF (pronounced C-Serf), XSRF, Cross-Site Reference Forgery, One-Click Attack and Session Riding.

You can verify that your application is vulnerable to CSRF by:

[1] Checking that the vulnerable link/request does not include a parameter that is hard for an attacker to guess

[2] Checking that the vulnerable link/request performs an operation that should only be performed willingly

An application that contains a sensitive action, which can be accessed directly by a request that the user submitted unknowingly, is considered vulnerable to CSRF.

General Fix Recommendations

       In order to avoid CSRF attacks, every request should contain a unique identifier, which is a parameter that an attacker cannot guess.

       One suggested option is to add the session id taken from the session cookie and adding it as a parameter. The server must check that this parameter matches the session cookie, and if not discard the request. The reason an attacker

cannot guess this parameter is the "same origin policy"  that applies to cookies, so the attacker cannot forge a fake request that will seem real to the server.

       Any secret that is hard to guess and is not accessible to an attacker (i.e. not accessible from a different domain) can be used instead of the session id. This will prevent an attacker from crafting a seemingly valid request.

References and Relevant Links

Cross-site request forgery wiki page

"JavaScript Hijacking" by Fortify

Cross-Site Request Forgery Training Module