Shulou(Shulou.com)06/01 Report--

Wordpress (lower version) and XSSer

Recurrence process

First, build wordpress on the virtual machine.

In the administrative user interface of wordpress, you can see that admin is the only user

Add users and grab packages using burp

Use the csrf plug-in that comes with burp

A CSRF page that can be used will be generated to change the parameters in the tag to prevent repeated parameter addition failures.

Open in browser and test

As you can see, another user was successfully added

At this point, it can be proved that the csrf vulnerability exists and that the csrf vulnerability has been successfully exploited.

So how can it be combined with XSS vulnerabilities?

Build the XSSer platform and create a new project, and write the project code according to the contents of the captured package.

Open the previously built wordpress and write the playload of the XSS project into the comment

After the message is successful, as shown in the following figure: when the administrator views the message, the XSS vulnerability will be triggered and the user creation operation will be performed.

Grab the bag to check:

Malicious code in XSS was successfully executed, adding test5 user

Repair suggestion

At present, there are three main strategies to defend against CSRF attacks:

Verify the HTTP Referer field

Add token to the request address and verify

Customize the properties in the HTTP header and verify

(1) verify the HTTP Referer field

According to the HTTP protocol, there is a field in the HTTP header called Referer, which records the source address of the HTTP request. In general, a request to access a secure and restricted page comes from the same website, such as visiting

Http://bank.example/withdrawaccount=bob&amount=1000000&for=Mallory

Http://www.gendan5.com

Users must first log in to bank.example and then trigger the transfer event by clicking the button on the page. At this point, the Referer value of the transfer request will be the URL of the page where the transfer button is located, usually the address that begins with the bank.example domain name. If a hacker wants to carry out a CSRF attack on a bank website, he can only construct a request on his own website. When a user sends a request to the bank through the hacker's website, the Referer of the request is directed to the hacker's own website. Therefore, to defend against CSRF attacks, the bank website only needs to verify its Referer value for each transfer request. If it is a domain name that begins with bank.example, the request comes from the bank website itself and is legitimate. If Referer is another website, it may be a CSRF attack by a hacker to reject the request.

However, this approach is not foolproof. The value of Referer is provided by the browser, although there are clear requirements on the HTTP protocol, but each browser may vary in the specific implementation of Referer, which does not guarantee that the browser itself does not have security vulnerabilities. Using the method of validating Referer values is to rely on third parties (that is, browsers) for security, which is not safe in theory. In fact, for some browsers, such as IE6 or FF2, there are already ways to tamper with Referer values. If the bank.example website supports IE6 browsers, hackers can set the Referer value of the user's browser to an address that begins with the bank.example domain name, so that it can be verified and CSRF attacks can be carried out.

(2) add token to the request address and verify

The CSRF attack is successful because the hacker can completely forge the user's request, and all the user authentication information in the request exists in the cookie, so the hacker can directly use the user's own cookie to pass the security authentication without knowing the authentication information. To defend against CSRF, the key is to put information in the request that a hacker cannot forge, and that information does not exist in the cookie. You can add a randomly generated token as a parameter to the HTTP request, and set up an interceptor on the server side to verify the token. If there is no token in the request or the token content is incorrect, it may be a CSRF attack and reject the request.

This method is more secure than checking Referer. Token can be generated after the user logs in and placed in the session, and then the token is taken out of the session and compared with the token in the request each time, but the difficulty of this method is how to add the token to the request in the form of parameters. For GET requests, token is appended to the request address so that URL becomes http://url?csrftoken=tokenvalue. For POST requests, add it at the end of the form so that token is added as a parameter to the request. However, in a website, there are many places where requests can be accepted, so it is troublesome to add token to each request, and it is easy to miss it. The usual method is to use javascript to traverse the entire dom tree each time the page is loaded, and add token to all the an and form tags in dom. This solves most of the requests, but it doesn't work for html code that is dynamically generated after the page is loaded, and requires programmers to manually add token as they code.

(3) customize the attributes in the HTTP header and verify

This method also uses token and validates, unlike the previous method, instead of putting token in the HTTP request as a parameter, it puts it in a custom attribute in the HTTP header. With the class XMLHttpRequest, you can add the HTTP header attribute csrftoken to all requests of this class at once, and put the token value into it. This solves the inconvenience of adding token to the request in the previous method. at the same time, the address requested through XMLHttpRequest will not be recorded in the browser's address bar, and there is no need to worry that token will be leaked to other websites through Referer.

Summary and thinking

CSRF is actually difficult to exploit simply, but it is relatively easy to exploit when combined with XSS vulnerabilities. It is not difficult to see the harm of CSRF:

Cooperating with XSS vulnerabilities can cause worms

Change user password

Change (mall) user receiving address

All users can operate, hackers can operate, as long as the construction of PoC for the victim to click. The popular point is that B performs the operations that A can perform as A, of course, B is the hacker and An is the victim, thus it can be seen that the harm of CSRF vulnerabilities is also significant and needs to be paid attention to in the security work.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.