by profession owe money
Yesterday spent the time to look at wide character of the problem, only to find that prior understanding has been wrong.
%df' is a PHP escape（open GPC, with the addslashes function, or icov, etc., a single quotation mark is combined with the backslash\
Where\hex is %5C, Well, now %df\' = %df%5c%2 7
In fact, this also nothing, but the question is, how to treat each of these 3 characters?
Depends on the spooler's default encoding, includes GBK for all wide character encoding, specifically see neeao large cattle blog on the fuzz results, looks like there are 4 encoding will have problems? Herein, for convenience the angle just say GBK is on.
MYSQL with GBK encoding, it will think that %df%5c is a wide character, that is,“缞”
Now %df\' = %df%5c%2 7=缞'
%df’ -- action %df\' = %df%5c’ = 缞'
%df is not only a character, should be% 8 1-%FE between any of the one can be.
Single quotation marks in the injection definitely is a good thing, in particular, many programmers rely excessively on GPC or addslashes for escaping. Theoretically, as long as the database connection code set GBK or default encoding is GBK, and now programs are everywhere injection vulnerabilities. In fact, this transformation inXSSand other areas also play a huge role in PHP and Linux daemon when combined, may also cause command injection）
You can refer to test methods to replace the original and 1=1 ）：
%df%2 7 or 1=1/*
%df%2 7 or 1=2/*
However, in the actual environment, I Google for a long time, find a few portals to the injection point, are not open GPC, directly will be able to note, is kj large cattle to despise after a very awkward stop this repetitive homogenization of manual labor.
The understanding of this vulnerability should not go to see 80sec of the vulnerability announcement, or the last time that what summary.
I think the security focus of the article says more clearly: