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

reflected XSS

Popular science type paper, big Daniel skipped. --:

With the development of Web 2.0 technology, more and more computing work is put into the client side, which leads to many security vulnerabilities due to the negligence of programmers. XSS belongs to a relatively common type. In the past few years, XSS was not paid much attention to, but now, with the increasing harm of XSS vulnerabilities, such as XSSWORM in the school and baidu space a while ago, its harm has also attracted everyone's attention.

There are three types of XSS: reflective XSS, persistent XSS, and DOMXSS. In contrast, the latter two types are much more convenient to use than the former. Even many people think that reflective XSS is chicken ribs, because it is very inconvenient to use, but in today's rapid development of safety technology, chicken ribs have also become chicken wings. Let's see what reflective XSS is.

What is reflective XSS?

XSS is also known as CSS(CrossSiteScript), Cross-Site Scripting ***. It refers to malicious hackers inserting malicious html code into a Web page, and when a user browses the page, the html code embedded in the Web will be executed, thus achieving the special purpose of malicious hackers.

So what is reflective XSS?

such as "http://www.jpl.nasa.gov/about_JPL/maps.cfm? departure=lax%22%3Cimg%20src=k.png%20onerror=alert(%22XSSed%20by%20sH%22)%20/%3E"This requires deceiving the user to click on the link to trigger XSS is reflective XSS, such as XSS posted in the forum is persistent XSS.

Non-persistent XSS(Reflected cross-site scribing) is what we usually call reflective XSS, and it is also the most commonly used and widely used method. It does this by sending someone a URL with malicious script parameters, and when the URL is opened, the specific malicious code parameters are parsed and executed by HTML. It is characterized by non-persistence, and must be caused by the user clicking on a link with a specific parameter.

Persistent cross-site scripting (XSS) means that malicious script code is stored in the database, when other users browse the web page normally, the site reads illegal data stored by illegal users from the database, and the malicious script code is executed. This type of *** usually appears in places like message boards.

Many people despise non-persistent XSS (reflective XSS) very much, thinking that this kind of XSS can only rely on deceptive means to deceive clicks in order to make ** normal implementation. There have been several ways to make reflective XSS durable. For example, use applet, use flash AS script, use IE Ghost page,CrossIframeTrick and so on.

Common ways to use reflective XSS

Since it is "you need to trick users into clicking on links to trigger XSS," isn't it the only way to fool users with reflective XSS? A few years ago, this might have been the case, but now, it was time to stage a good show of chicken ribs turning into chicken wings!

[1]deceive

I have to say that this is the simplest and most effective way to use it, but there are strict requirements for the ability to fool, otherwise users will not be so easy to hook up. Second, users now have a certain sense of security, and it is not so easy to deceive. Take the link above as an example. Because it is a cross-site NASA website, you can send a message like "NASA announces the latest UFO photos" and add our link to some astronomy enthusiast group. Since it's a NASA link (even elementary school kids know what NASA does now), I think there's a part of the population that believes that clicking on it gets us there, and this reflective XSS is triggered. But what if it wasn't? Please look down.

[2]ClickJacking

At the OWASP conference a few years ago, Clickjacking was brought up. In short, Clickjacking goes something like this:

1. When you click on a link or button, you are actually clicking somewhere else (hijacking links)

2. Javascript is not necessary, so noscript is not blocked, but if there is javascript, things will be easier.

3.*** is based on DHTML.

4. Need *** some control over the page

So, we only need to hijack the user's click to our link, and Clickjacking can cross domains ~

Specific application examples are available under Google.

[3]Combined with CSRF technology

CSRF is a kind of forged client request **, CSRF English full name is CrossSiteRequestForgery, literally means cross-site forged request. This kind of *** method was proposed by foreign security personnel in 2000, and it was not noticed at home until the beginning of 2006.

It is a good way to exploit reflective XSS in combination with CSRF technology, which can make these poorly exploited XSS vulnerabilities extremely powerful. For specific examples, please refer to cosine's "XSS*** based on CSRF"(http://huaidan.org/archives/2561.html), which will not be described in detail here.

[4]CrossIframeTrick

Let's talk about what this *** can do:

1. Cross-domain script execution (IE, Firefox)

2. Turn non-persistent XSS into persistent XSS-->!!!

3. Cross-page script execution

This *** method is rather roundabout. For details, please refer to CrossIframeTrick (http://hi.baidu.com/aullik5/blog/item/07d68eb015d72652092302b1.html).

[5]Reverse Athena---Boomerang Module with Anehta

What is Anehta? Anehta is a platform for cross-site scripting ***(XSS). Functional modularity allows developers to develop various modules for anehta individually to meet unique needs. There are many creative designs in Anehta, and the Boomerang module is one of them. Boomerang module's role is to obtain local cookies across domains, but there is an XSS on the site, regardless of the type, whether reflective XSS, or persistent XSS, can work for us.

At this time, the residual heat of the reflective XSS is fully utilized.

For specific examples, please refer to Axis Niu's "Anehta--Boomerang(Boomerang), How to Change Reflective XSS into Persistent XSS: On Cross-domain Acquisition of Cookies"(http://hi.baidu.com/aullik5/blog/item/02bccaeb018dc4d5d539c930.html), which will not be described in detail here.

DVWA(DamnVulnerable Web Application)DVWA is a set of vulnerability testing programs written in PHP+Mysql for conventional WEB vulnerability teaching and detection. Contains SQL injection, XSS, blind injection and other common security vulnerabilities.

The following is a brief description of Code Audit in terms of the three levels of reflective XSS vulnerabilities in dvwa.

First, compare low, medium, and high PHP code:

By comparing the three codes, we find that the media code adds a filter to the low code, and after submission, we find that it is filtered and converted, while the high code uses the dhtmlspecialchars () function to convert some predefined characters into HTML entities.

The predefined characters are:

&(and sign) becomes &

"(double quotes) becomes"

'(single quote) becomes'

Now let's test reflective XSS for three levels of vulnerability

In low, submit alert(/xss/) test directly without doing any verification

URL:http://192.168.111.146/dvwa/vulnerabilities/xss_r/? name=%3Cscript%3Ealert%28%27xss%27%29%3C%2Fscript%3E

In media, it's only filtered so we can bypass it.

We can submit alert ('xss ')

or alert ('xss ')

URL:http://192.168.111.146/dvwa/vulnerabilities/xss_r/? name=%3CSCRIPT%3Ealert%28%2Fxss%2F%29%3C%2FSCRIPT%3E

For high XSS, htmlspecialchars are used. I don't know if you can use any method to bypass it. If you can't bypass it, you can refer to Discuz's dhtmlspecialchars() function:)

Analysis of the working principle of Anehta boomerang module

Since Anehta's Boomerang module is mentioned, let's talk about it briefly.

How Boomerang works: We know that after the browser is XSS***, *** users can use js or other scripts to control the browser's behavior. At this time, if we force the browser to visit a page with XSS vulnerability on site B, we can continue to use XSS_B on site B to control the user's browser behavior; then the whole process is combined and simply expressed as follows:

victimBrowser--->siteA，XSS_A----redirectto---->SiteB，XSS_B-----redirectsomewhere--->.....

In IE, iframe, img and other tags are used to block local cookies. You need to use methods that do not block cookies, such as window.open, but window.open will be intercepted by IE pop-up windows, so axis Niu uses form submission in Boomerang, constructs a form, submits to siteB, and then imports an XSSB from SiteB. After obtaining cookies, you submit through the form and jump back to the original SiteA. If you use XSS_B on SiteB and redirect the page back to SiteA, then for the user, it is a simple flash, very deceptive. The whole process was like throwing a boomerang and hitting a B.

But in fact, this does not really turn reflective XSS into persistent XSS, just a *** way of reflective XSS, and there is no cross-domain, but URL redirection turned a circle, jumped a circle and came back. But it does allow reflective XSS to be fully utilized for our purposes. This kind of thinking of axis cattle is very worth learning!

This article only summarizes the common reflective XSS use methods, but are simply mentioned, so that we can think of these when you see reflective XSS (it seems to be written in detail too much--:), if there are shortcomings, please forgive me.

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.