XSS risks caused by browser differences 1

Resolution Sequence Problems
In fact, everything is the same. It is not necessarily the web world, the frontend and backend interpreted language, or the HTTP header. There is a resolution order problem, from top to bottom, from left to right, from right to left. Once the order can be disturbed, security problems may occur. Such as character set encoding, content-type, and tag attribute type.

The following is the body of the question :)

Differences in standard implementation
Browsers all want to dominate the world. Some standards are implemented in different ways, which leads to some differences. If programmers do not realize these differences, they may introduce security risks. There are many such parts. Recently, we found the difference in the resolution of this address by browsers:
! @ $ % "> Http: // www.0 × 37. com: 8989/test. php? C = '"' <>! @ $ % ^ * () {} []:;.,? ~

When sending a request, capture the packet and find the default behavior of the browser:
FireFox
GET/test. php? C = % 27% 22% 60% 3C % 3E! @ $ % ^ * () {} []:;.,? ~ HTTP/1.1
Chrome
GET/test. php? C = '% 22' % 3C % 3E! @ $ % ^ * () {} []:;.,? ~ HTTP/1.1
IE Kernel
GET/test. php? C = '"' <>! @ $ % ^ * () {} []:;.,? ~ HTTP/1.1

What's the difference? Recently, our scanner found some mainstream group buying XSS, which was found during analysis. This difference causes XSS to succeed in Some browsers, but some fail. Due to XX, the case cannot be given. However, experienced people may doubt it, because % 27 is only urlencode, and the original characters before urlencode are normally output. Therefore, I suspect that this difference should not be attributed to browsers. It should also be related to the specific code design of these group buying networks.

Another difference in character sets

Http: // www.0 ×37. com: 8989/test. php? C = Hello

The page is UTF-8 encoded by default.

When sending a request, capture the packet and find the default behavior of the browser:
FireFox
GET/test. php? C = % C4 % E3 % BA % C3 HTTP/1.1
Dubyte encoding. Why does FF select this?
Chrome
GET/test. php? C = % E4 % BD % A0 % E5 % A5 % bd http/1.1
This is the most direct manifestation of UTF-8 and urlencode.
IE
GET/test. php? C = Hello HTTP/1.1
I didn't do any encoding. IE is very strange.

Today, when pan finds this XSS of a Group Buying Network, it is strange that the XSS only works on Chrome. In the past, Chrome handled Chinese in this scenario by taking the UTF-8 route to meet the target website. It is also a group purchase network ..

They are all magical XSS. Sleepy ~ We are still working overtime, so there is a bit of chaos in writing. Let's take a look. : P