Save 8 bytes in each libinjection_sqli_token by adjusting the struct layout. This results in each libinjection_sqli_token using 56 bytes (previously using 64); additionally, each libinjection_sqli_state now uses 544 bytes (previously 608).

As you may know SpiderLabs/ModSecurity uses libinjection. Due to historical reasons, ModSecurity source code contains part of the libInjection code. Therefore the updates are manual.

I am looking forward to upgrade ModSecurity's libInjection version but I am not sure which commit to use. Is there any specific commit that you recommend the utilization?

There is a array buffer overflow vulnerability in function parse_word of libinjection_sqli.c,if one keyword is more than 32,the sf->current->val[i] will be overflowed.Below is one new patch function.

static size_t parse_word(struct libinjection_sqli_state * sf) { char ch; char delim; size_t i; const char cs = sf->s; size_t pos = sf->pos; size_t wlen = strlencspn(cs + pos, sf->slen - pos, " {}<>:?=@!#~+-/&|^%(),';\t\n\v\f\r"\000"); size_t kwlen = wlen < LIBINJECTION_SQLI_TOKEN_SIZE ? wlen : (LIBINJECTION_SQLI_TOKEN_SIZE - 1); st_assign(sf->current, TYPE_BAREWORD, pos, wlen, cs + pos);

/* now we need to look inside what we good for "." and "`"
 * and see if what is before is a keyword or not
 */
for (i =0; i < kwlen; ++i) {
    delim = sf->current->val[i];
    if (delim == '.' || delim == '`') {
        ch = sf->lookup(sf, LOOKUP_WORD, sf->current->val, i);
        if (ch != TYPE_NONE && ch != TYPE_BAREWORD) {
            /* needed for swig */
            st_clear(sf->current);
            /*
             * we got something like "SELECT.1"
             * or SELECT`column`
             */
            st_assign(sf->current, ch, pos, i, cs + pos);
            return pos + i;
        }
    }
}

/*
 * do normal lookup with word including '.'
 */
if (wlen < LIBINJECTION_SQLI_TOKEN_SIZE) {

    ch = sf->lookup(sf, LOOKUP_WORD, sf->current->val, wlen);
    if (ch == CHAR_NULL) {
        ch = TYPE_BAREWORD;
    }
    sf->current->type = ch;
}
return pos + wlen;

}

Nick, any idea why strings (below) is flagged as SQLi?

"Select count(*) from Monitor" detected with fingerprint of 'Ef(o)' "Select * from Monitor where ID = 182517" detected with fingerprint of 'Eoknk'

This change is backwards compatible. It adds two new functions, is_sqli2() and is_string_sqli2() which take a ptr_fingerprints2_fn instead of a ptr_fingerprint_fn and an extra void* callback data argument. ptr_fingerprints2_fn is int ()(const char, void*) and the callback data passed to is_sqli() is then forwarded to the fingerprints function.

This functionality is needed in IronBee to support user defined fingerprint sets. I.e., the callback data will be used to pass in an datastructure to look the fingerprint up in.

In some IronBee rules we check all HTTP headers for SQLi. Typically you will see:

Accept: */*

This accept header value is detected as SQLi pattern "oc".

FOO & FOO --> n FOO FOO & FOO --> nnon

I can't understand why those two patterns show difference on tokenized 'FOO & FOO'. Should latter tokenized to 'nn' ?

Thanks.

Microsoft's SQL parser does this

SELECT1; --> SELECT 1; SELECT.1; --> SELECT .1;

so in a sqli like this:

'AND 1.-1LIKE.1 EXEC xp_cmdshell 'dir

libinjection gets confused by the LIKE.1 (thinks it's a single token of 'none' type).

The following payload:

'; if not((select serverproperty('isintegratedsecurityonly')) <> 1) waitfor delay '0:0:2' --

was tokenized previously into "s;To(E" and detected. After the latest change in syntax_merge_words function and addition of "a->type == TYPE_TSQL", the "To" tokens are merged into "n" token; no detection as a result. Was that the intention? Seems like a side-effect of begin-try change.

ld -shared doesn't work on mac os, ld -dynamic would work better but it seems simpler to just use CC to build it

This would need to be tested on Linux (or the original target arch).

make_parens.py has been modified to ignore ";" when an "nn" sequence has been found in a fingerprint (e.g. sTnn:). Hope this is okay. This thing is really weird, some vectors may still be not detected.

We use libinjection 3.9.2 within modsecurity 3.0.6. This is the string that causes a false positive XSS match in CRS rule 941101:

/ppfx/oNS-r3VlTC67VwnnCfx1wAd1jDbbMTSfeXRcovqQe67gIMHc8vr_T66y_0QA1rCquQ?a=V2Vidmlldw

I've compiled reader.c and that this seems to confirm the XSS match:

$ ./reader -x testfile
testfile        1       True    /ppfx/oNS-r3VlTC67VwnnCfx1wAd1jDbbMTSfeXRcovqQe67gIMHc8vr_T66y_0QA1rCquQ?a=V2Vidmlldw

SQLI  : 1
SAFE  : 0
TOTAL : 1

I would like to understand why this string is causing an XSS match.

libinjection_xss() returns an int to indicate evidence of XSS (1) or absence (0). If the parser's state machine wound up in a bad state (e.g. string cursor position greater than string length), libinjection would abort the process it was in.

This change creates an enum return type for libinjection_xss() and downstream state functions that indicates XSS True, False or Error. The Error return code indicates the parser state machine got into a bad state. The library will no longer abort on error.

@client9 Hey Nick!

Can we add a some documentation so the community knows there is a new fork (from https://github.com/client9/libinjection/issues/150#issuecomment-668179739)?

Also archiving this repo might make sense, so people won't create new issues.

[-:error] ModSecurity: Warning. detected SQLi using libinjection with fingerprint 'f(n)' [file "/../.. /coreruleset-3.4-dev/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf"] [line "65"] [id "942100"] [msg "SQL Injection Attack Detected via libinjection"] [data "Matched Data: f(n) found within ARGS:q: cos(accckt)"] [severity "CRITICAL"] [ver "OWASP_CRS/3.3.0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-sqli"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/152/248/66"] [tag "PCI/6.5.2"] [hostname **************]

Your Environment CRS version (v3.2.0): Paranoia level setting: ModSecurity version (v2.9.3): Web Server and version (httpd2.4.41): Operating System and version: RHEL 7.9 Confirmation [ ] I have removed any personal data (email addresses, IP addresses, passwords, domain names) from any logs posted.

Hi Guys,

I am getting this false positive when I click a particular tab in my website. Could you please help me that this rule can be removed or we have any other fix?

https://github.com/coreruleset/coreruleset/issues/2076

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)

This can be a defeat.

I've tested with 3.9.2 and 3.10.0.

Description If you use the following Json in the playload, the rule 94110 is triggered. The problem is the string "filter={AnyChar}" "query":"filter=in(labels.name,"test")"

Error message:

"message":"XSS Attack Detected via libinjection","action":"Matched","site":"Global","details":{"message":"Warning. detected XSS using libinjection. ","data":"Matched Data: XSS data found within ARGS:query: filter=in(labels.name,\x22test\x22)"

From my point of view, the rule should not be triggered by this payload

Here is the orginal issue: https://github.com/coreruleset/coreruleset/issues/2041#issuecomment-804098811