Browser differences not only bring about "XSS risks"

5up3rh3iblog

Let's first read xeyeteam's article 《XSS risks caused by differences in browser urlencode policiesAnd Mr. Yu's blog 《XSS risks caused by browser differences 1Is anotherStandard questions...

When Ryat sees this article, he feels the same way, as mentioned in my previous blog 《Arbitrary boblog variable Overwrite VulnerabilityThis problem occurs during the test:

"Start 』
// Go. php

$ Q_url = $ _ SERVER ["REQUEST_URI"];
@ List ($ relativePath, $ rawURL) = @ explode (/go. php/, $ q_url );
$ RewritedURL = $ rawURL;
...
$ RewriteRules [] = "/page/([0-9] +)/([0-9] + )/? /";
// This regular expression looks very rigorous, but it does not use ^ and $ to limit the beginning and end [it may be to adapt to the needs of the program] :)
...
$ RedirectTo [] = "index. php? Mode = \ 1 & page = \ 2 ";
...
Foreach ($ RewriteRules as $ rule ){
If (preg_match ($ rule, $ rewritedURL )){
$ Tmp_rewritedURL = preg_replace ($ rule, <. $ RedirectTo [$ I]. <, $ rewritedURL, 1 );
// Match and replace $ rewritedURL, and use <to mark the matched part
// After such processing, $ tmp_rewritedURL is divided into three parts:
// I. First <previous part
// Ii. Part between two <
// Iii. The second part <
$ Tmp_rewritedURL = @ explode (<, $ tmp_rewritedURL );
$ RewritedURL = ($ tmp_rewritedURL [2])? False: $ tmp_rewritedURL [1];
// The main purpose of this Code is to solve the problem that the regular expression restrictions are not strict enough.
// The programmer wants to remove I and iii through this code so that $ rewritedURL only retains ii
// Note that restrictions on iii are also imposed here. According to the programmer's idea, this part of iii should not exist :)
// The Key to this part of the code logic is <this character, but unfortunately we can inject it at will <: p
Break;
}
$ I + = 1;
"End 』

During the testing of this vulnerability, this problem directly affects the testing process of Ryat cattle. Finally, the program is submitted to complete the process...

So I will roughly YY the reason why the author used the <variable processing: 'I wonder if the author of bob mistakenly believes that <"in request_url should be encoded, so he can use <to separate it with confidence'

Of course, this is our subjective decision !!

This story illustrates a problem. The difference in the browser's "urlencode policy" can lead to the programmer's "illusion" and lead to tragic results! This is the same as html "target = _ blank>Security problems caused by different language formats"Has the same effect :)