In-depth parsing of Cross-Site Request Forgery (II)

In the previous article, we focused on the principle of cross-site request forgery, and pointed out that some security models cannot really defend against such attacks. In the next article, we will introduce several severe CSRF vulnerabilities found on some large websites. Attackers can exploit these vulnerabilities to not only collect users' email addresses, infringes on user privacy and controls user accounts. If a Cross-Site Request Forgery Vulnerability occurs on a financial site, these vulnerabilities even allow attackers to transfer funds from users' bank accounts. To fully defend against CSRF attacks, we recommend that you modify the server. In addition, this article will introduce the characteristics of server-side solutions. If these features are lacking, CSRF protection will be unnecessary to impede typical web browsing activities. In addition, this article also introduces a client browser plug-in that protects the site from some types of CSRF attacks even if the site does not have any protection measures. Cross-Site Request Forgery is a serious Web vulnerability. We hope that you will be able to improve your awareness of CSRF attacks.

The following is a cross-site Request Forgery Vulnerability that security personnel have encountered in the real world this year in NYTimes.com, Metafilter, and YouTube.

I. Cross-Site Request Forgery Vulnerability on the website in the New York Times

This year, security personnel discovered a CSRF vulnerability on NYTimes.com, which allows attackers to obtain users' email addresses. If you are a member of NYTimes.com, any website can exploit this vulnerability to obtain your email address and send spam emails in your name.

The attack fully utilizes the "Email This" function of NYTimes.com. It allows users to send a link to a NYTimes.com article to the Email address of the specified recipient. If necessary, you can also attach a personal message. The recipient will receive an email similar to the following:

This page was sent to you by: [USER’S EMAIL ADDRESS] Message from sender: Thought you’d be interested in this. NATIONAL DESK Researchers Find Way to Steal Encrypted Data By JOHN MARKOFF A computer security research group has developed a way to steal encrypted information from computer hard disks.

To exploit this vulnerability, attackers need to try to send a request to the "Email this" page of NYTimes.com from a browser that has logged on to the user. Because the page receiving the "Email this" request does not take effective measures against CSRF attacks, you only need to try to make the user's browser send a specially crafted request to NYTimes.com, NYTimes.com will send an email to the address specified by the attacker. If an attacker specifies the recipient's email address as his own email address, he will receive an email from NYTimes.com, of course, containing a user's email address.

This weakness is easily exploited. Every article on NYTimes.com has a link to the "Email this" page, and the "Email this" page contains a form in which users can enter an Email address of the recipient. This form also contains some invisible variables, which vary with the document, so these invisible variables are unique. The following is a form example:

{form action="html">http://www.nytimes.com/mem/emailthis.html" method="POST" enctype="application/x-www-form-urlencoded"} {nput type="checkbox" id="copytoself" name="copytoself" value="Y"} {input id="recipients" name="recipients" type="text" maxlength="1320" value=""} {nput type="hidden" name="state" value="1"} {extarea id="message" name="personalnote" maxlength="512"}/textarea} {nput type="hidden" name="type" value="1"} {nput type="hidden" name="url" value="[...]"} nput type="hidden" name="title" value="[...]"} nput type="hidden" name="description" value="[...]"} .. {form}

Because NYTimes.com does not distinguish GET from POST requests, attackers can convert the form into a GET request (so that it can be used in the {mg} signature in the future ). To convert a form into a GET request, you need to append each parameter to the query string of the URL (in the form of NAME = VALUE, and separate it with the & sign ).

Once an attacker constructs a URL, he can set it to the SRC attribute of the {img} tag. If a logged-on user of NYTimes.com accesses any page containing the preceding tag, the browser uses the attacker's parameters to load the "Email this" page, and caused NYTimes.com to send an email containing the user's email address to the attacker. Attackers can store this email address for future use (for example, sending spam) or use this email address to identify visitors to their own sites. This can cause serious privacy leaks. For example, administrators of some controversial sites (such as political or illegal sites) identify their users.

Security researchers used Firefox, Opera, and Safari to verify the attack. It is invalid for Internet Explorer because of P3P. Later, the New York Times changed the page to allow only POST requests, so now it can prevent the original attack.

Ii. MetaFilter Cross-Site Request Forgery Vulnerability

This year, security researchers discovered a CSRF vulnerability in MetaFilter, which allows attackers to hijack users' accounts. MetaFilter has a "Lost Password" page that allows users to request their passwords. Enter a username on the page, and MetaFilter will send the current password of the user to the corresponding email address of the user by email. This means that, as long as an attacker can change the email address of a user, the attacker can use the "Lost Password" page to accept the user's Password, the password is used to control the user's account.

The CSRF attack discovered by researchers allows attackers to change a user's email address. To exploit this attack, attackers need to try to send a request to the user's browser to update the user's profile page. The user's email address is received as a parameter on this page. Therefore, an attacker can replace the email address sent to this page with his own address. The following provides an HTML embedded in a page to demonstrate the attack process:

{mg src="http://metafilter.com/contribute/customize_action.cfm?user_email=[ATTACKER’S EMAIL]"/}

Although this will change the email address of any logged-on user, the attacker will not know which user's account has been modified. However, attackers can use another MetaFilter function to mark other users as "contacts" (contacts ). Attackers can try to allow users to add the attackers to their contact lists without knowing them.

Researchers used Firefox to verify the attack. However, Internet Explorer cannot be used for this test due to P3P.

Iii. Cross-Site Request Forgery Vulnerability on the YouTube website

Security researchers found that almost all actions that users can perform on YouTube have CSRF vulnerabilities. If the attacker has added the video to the user's "Favorites", then he can add himself to the user's "Friend" or "Family" list, send any message as a user and mark the video as inappropriate. The video is automatically shared by the user's contact, book a "channel" for a user (a group of videos provided by a person or group) and add the video to the user's "QuickList" (a group of videos that users intend to watch in the future ). For example, to add a video to a user's

"Favorites", attackers only need to embed the following {mg} tag on any site:

{mg src="http://youtube.com/watch_ajax?action_add_favorite_playlist=1&video_ id=[VIDEO ID]&playlist_id=&add_to_favorite=1&show=1&button=AddvideoasFavorite"/}

Attackers may have used this vulnerability to increase video popularity. For example, if you add a video to a "Favorites" that has many users, YouTube will display the video as "Top Favorites" (a group of videos that have been added to a large number of Favorites. In addition to increasing the popularity of a video, attackers can also mark a video as "inappropriate" without knowing it, thus causing YouTube to delete the video.

These attacks may have been used to infringe user privacy. YouTube allows users to watch videos only by friends or relatives. These attacks cause attackers to add a user to the "Friend" or "Family" list, in this way, they can access all private videos that are originally restricted to users in the friends and relatives' tables.

Attackers can also share a video through all the user's contact lists ("Friends", "Family", and so on. "Share" means to send a video connection to them. You can also choose to add a message. This message can contain a connection, which means that attackers can force users to include a link to an aggressive website. The user who receives the message may click this connection, which enables the attack to spread viral. Researchers used Firefox to verify the attack. However, for Internet Explorer, P3P cannot be used to attack the vulnerability.

Iv. Overview of protection measures