[Owasp-modsecurity-core-rule-set] Paranoia Mode: Controversial candidate 950120 / 931130 (Possible RFI)

[Christian Folini]

Hello,

Walter has added substantial feedback on the list of possible paranoia
mode candidates. I think 8 candidates are controversial (out of about 45
candidates).

I'd like to discuss them here one by one.

Controversial Paranoia Mode Candidate 950120 (2.2.X) / 931130 (3.0.0rc1)
msg: Possible Remote File Inclusion (RFI) Attack: Off-Domain Reference/Link

Rule in 2.2.9:
SecRule ARGS "^(?:ht|f)tps?://(.*)$" \
"chain,phase:2,rev:'3',ver:'OWASP_CRS/2.2.9',maturity:'9',accuracy:'9',t:none,capture,ctl:auditLogParts=+E,block,msg:'Possible Remote File Inclusion (RFI) Attack: Off-Domain Reference/Link',logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',id:'950120',severity:'2',tag:'OWASP_CRS/WEB_ATTACK/RFI'"
SecRule TX:1 "!@beginsWith %{request_headers.host}" "setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-OWASP_CRS/WEB_ATTACK/RFI-%{matched_var_name}=%{tx.1}"

Rule in 3.0.0rc1:
SecRule ARGS "^(?:ht|f)tps?://(.*)$" \
"chain,\
phase:request,\
rev:'3',\
ver:'OWASP_CRS/3.0.0',\
maturity:'9',\
accuracy:'9',\
t:none,\
capture,\
ctl:auditLogParts=+E,\
block,\
msg:'Possible Remote File Inclusion (RFI) Attack: Off-Domain Reference/Link',\
logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',\
id:'931130',\
severity:'CRITICAL',\
tag:'application-multi',\
tag:'language-multi',\
tag:'platform-multi',\
tag:'attack-remote file inclusion',\
tag:'OWASP_CRS/WEB_ATTACK/RFI'"
SecRule TX:1 "!@beginsWith %{request_headers.host}" \
"setvar:'tx.msg=%{rule.msg}',\
setvar:tx.rfi_score=+%{tx.critical_anomaly_score},\
setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},\
setvar:tx.%{rule.id}-OWASP_CRS/WEB_ATTACK/RFI-%{matched_var_name}=%{tx.1}"

Rule in 2.2.9:
SecRule ARGS "^(?:ht|f)tps?://(.*)$" \
"chain,phase:2,rev:'3',ver:'OWASP_CRS/2.2.9',maturity:'9',accuracy:'9',t:none,capture,ctl:auditLogParts=+E,block,msg:'Possible Remote File Inclusion (RFI) Attack: Off-Domain Reference/Link',logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',id:'950120',severity:'2',tag:'OWASP_CRS/WEB_ATTACK/RFI'"
SecRule TX:1 "!@beginsWith %{request_headers.host}" "setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-OWASP_CRS/WEB_ATTACK/RFI-%{matched_var_name}=%{tx.1}"


In my blogpost at
https://www.netnea.com/cms/2016/01/17/most-frequent-false-positives-triggered-by-owasp-modsecurity-core-rules-2-2-x/
I identified the said rule as one with very few false positives. Walter however brought it up as a rule with many false positives.

A wider perspective is thus needed.

Does anybody has anything to add?

Best,

Christian


--
mailto:***@netnea.com
http://www.christian-folini.ch
twitter: @ChrFolini

[Walter Hop]

Hi Christian,

Thanks, that’s a nice torrent of mail you sent there! :) I’ll have time to look at the rules next weekend, although maybe I’ll sneak in a few replies before that.

Before making a good judgement call on SQLi and XSS related rules, I still need to know a bit more about libinjection.

We should recommend moving a rule into paranoia if its cost is too high relative to its benefit.
But, for SQLi and XSS rules, this depends on libinjection, which I haven’t really exercised yet.

If libinjection in itself already has a high sensitivity, the benefits of the regexp based rules will become lower. After all, an attack will then likely already be flagged without those rules. In that case, we could move rules from normal to paranoid mode, or dismiss currently removed rules, much more easily.

I don’t quite have a good feel about this factor yet, so I really want to launch some tests against it, but it will probably be Saturday before I have the time to do that.

Cheers!
WH

--
Walter Hop | PGP key: https://lifeforms.nl/pgp

[Christian Folini]

Hello Walter,

On Tue, Feb 02, 2016 at 02:02:13PM +0100, Walter Hop wrote:
> Thanks, that’s a nice torrent of mail you sent there! :) I’ll have time to look at the rules next weekend, although maybe I’ll sneak in a few replies before that.

Cool.

> Before making a good judgement call on SQLi and XSS related rules, I still need to know a bit more about libinjection.
>
> We should recommend moving a rule into paranoia if its cost is too high relative to its benefit.
> But, for SQLi and XSS rules, this depends on libinjection, which I haven’t really exercised yet.

Libinjection has been around for a few years. I always considered it
underdocumented and too much of a one man show. After my rant in
https://www.netnea.com/cms/2015/12/20/modsec-crs-2-2-x-vs-3-0-0-dev/
I got in touch with the developer Nick Galbreath who admitted many
shortcomings and promised to clean up his project. In fact we are seeing
more activity with libinjection on github now
https://github.com/client9/libinjection/pulse/monthly
But it's still an almost exclusive and I am convinced nobody outside
Nick did a through code review. Meanwhile Chaim told me, libinjection is
included in other WAF products as well and I agree it is a great
piece of code. It's just that I feel uneasy with the state of the
project and the linking of it into my parameter parser aimed to
stop evil attackers (trying to exploit libinjection).

With that being said, the blogpost above showed me, that libinjection
is able to detect a great many sqli and xss attacks. But it is far
from complete. (See blogpost for numbers) So I think it is _one_ rule
in a set of rules aimed to stop sqli and xss. Diversity is key.

Also: A realworld sqlinjection typically triggers a variety of
anti-sqli rules. With _only_ libinject it would be a single critical
alert.

> If libinjection in itself already has a high sensitivity, the benefits of the regexp based rules will become lower. After all, an attack will then likely already be flagged without those rules. In that case, we could move rules from normal to paranoid mode, or dismiss currently removed rules, much more easily.

I see your point. I think that would work in strict blocking mode.
In anomaly scoring mode, it would only work with a anomaly scoring
limit of 5 or lower. Otherwise, sqlinjections would simply trigger
libinjection, but fly under the radar of the final blocking rule.

Thanks for your input and food for thought. Interesting.

Ahoj,

Christian


--
People demand freedom of speech as a compensation for the freedom
of thought which they seldom use.
-- Soren Kierkegaard

[Walter Hop]

> On 04 Feb 2016, at 10:08, Christian Folini <***@netnea.com> wrote:
>
> With that being said, the blogpost above showed me, that libinjection
> is able to detect a great many sqli and xss attacks. But it is far
> from complete. (See blogpost for numbers) So I think it is _one_ rule
> in a set of rules aimed to stop sqli and xss. Diversity is key.
>
> Also: A realworld sqlinjection typically triggers a variety of
> anti-sqli rules. With _only_ libinject it would be a single critical
> alert.


I’ve done a little testdrive with the CRS v3.0.0-rc1 rules today and the coverage of libinjection for MySQL is pretty complete actually!

When scanning a little vulnerable test app with the dev version of sqlmap in two configurations: (1) --random-agent and (2) --random-agent --dbms=mysql, the complete CRS v3.0.0-rc1 detected all attempts with mostly high anomaly scores.

Then I disabled all CRSv3’s SQLi and XSS rules, except libinjection's @detectSQLi rule. Similarly, almost all attempts were detected just by libinjection alone! Out of 380 malicious requests, only the following examples were let through by libinjection:

select * from foo where id=1,."'.""',)
select * from foo where id=1'wqffhb<'">wweNuE
select * from foo where id=1) WAITFOR DELAY '0:0:5' AND (9227=9227
select * from foo where id=1 WAITFOR DELAY '0:0:5'
select * from foo where id=1') WAITFOR DELAY '0:0:5' AND ('UUAn'='UUAn
select * from foo where id=1' WAITFOR DELAY '0:0:5' AND 'AzTu'='AzTu
select * from foo where id=1%' WAITFOR DELAY '0:0:5' AND '%'='

(WAITFOR DELAY is Microsoft SQL dialect, usable for blind injection. I’ll try this again with a newer libinjection, and if necessary report it upstream.)

Resuming, libinjection’s sensitivity in detecting SQLi is already very impressive! So if we ever should find a large false positive rate in an SQLi rule in the future, we don’t need to be too sentimental about that single rule, as the addition of libinjection in CRS v3 ensures that SQLi should start with a nice anomaly score already.

However, I agree with you completely that it’s preferable to leave in any useful regexp based rules that we have. I was just curious about libinjection since it was an unknown factor to me.

I’ll comment on the individual rules later!

--
Walter Hop | PGP key: https://lifeforms.nl/pgp

[Chaim Sanders]

This is very helpful, recently I've come to share in some views of the community that libinjection isn't the most well supported/reviewed of all the projects on github. Fortunately compared to many other projects it is quite small from a codebase perspective and as a result the attack surface isn't outrageous, and reviewing it is reasonable. That being said we NEED to continue to including other rules that suppliment libinjection in case of a bypass, which is what we do in v3.0.0-rc1 :)

From: <owasp-modsecurity-core-rule-set-***@lists.owasp.org<mailto:owasp-modsecurity-core-rule-set-***@lists.owasp.org>> on behalf of Walter Hop <***@spam.lifeforms.nl<mailto:***@spam.lifeforms.nl>>
Date: Saturday, February 6, 2016 at 10:23 AM
To: "owasp-modsecurity-core-rule-***@lists.owasp.org<mailto:owasp-modsecurity-core-rule-***@lists.owasp.org>" <owasp-modsecurity-core-rule-***@lists.owasp.org<mailto:owasp-modsecurity-core-rule-***@lists.owasp.org>>
Subject: Re: [Owasp-modsecurity-core-rule-set] Paranoia Mode: Controversial candidate 950120 / 931130 (Possible RFI)

On 04 Feb 2016, at 10:08, Christian Folini <***@netnea.com<mailto:***@netnea.com>> wrote:

With that being said, the blogpost above showed me, that libinjection
is able to detect a great many sqli and xss attacks. But it is far
from complete. (See blogpost for numbers) So I think it is _one_ rule
in a set of rules aimed to stop sqli and xss. Diversity is key.

Also: A realworld sqlinjection typically triggers a variety of
anti-sqli rules. With _only_ libinject it would be a single critical
alert.

I've done a little testdrive with the CRS v3.0.0-rc1 rules today and the coverage of libinjection for MySQL is pretty complete actually!

When scanning a little vulnerable test app with the dev version of sqlmap in two configurations: (1) --random-agent and (2) --random-agent --dbms=mysql, the complete CRS v3.0.0-rc1 detected all attempts with mostly high anomaly scores.

Then I disabled all CRSv3's SQLi and XSS rules, except libinjection's @detectSQLi rule. Similarly, almost all attempts were detected just by libinjection alone! Out of 380 malicious requests, only the following examples were let through by libinjection:

select * from foo where id=1,."'.""',)
select * from foo where id=1'wqffhb<'">wweNuE
select * from foo where id=1) WAITFOR DELAY '0:0:5' AND (9227=9227
select * from foo where id=1 WAITFOR DELAY '0:0:5'
select * from foo where id=1') WAITFOR DELAY '0:0:5' AND ('UUAn'='UUAn
select * from foo where id=1' WAITFOR DELAY '0:0:5' AND 'AzTu'='AzTu
select * from foo where id=1%' WAITFOR DELAY '0:0:5' AND '%'='

(WAITFOR DELAY is Microsoft SQL dialect, usable for blind injection. I'll try this again with a newer libinjection, and if necessary report it upstream.)

Resuming, libinjection's sensitivity in detecting SQLi is already very impressive! So if we ever should find a large false positive rate in an SQLi rule in the future, we don't need to be too sentimental about that single rule, as the addition of libinjection in CRS v3 ensures that SQLi should start with a nice anomaly score already.

However, I agree with you completely that it's preferable to leave in any useful regexp based rules that we have. I was just curious about libinjection since it was an unknown factor to me.

I'll comment on the individual rules later!

--
Walter Hop | PGP key: https://lifeforms.nl/pgp<http://scanmail.trustwave.com/?c=4062&d=1ZW21qA6mVzaHrUP30VymOueR3E0w4jjrmj3ltOfGA&s=5&u=https%3a%2f%2flifeforms%2enl%2fpgp>


________________________________

This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.

[Christian Folini]

Good evening,

On Sat, Feb 06, 2016 at 03:53:06PM +0000, Chaim Sanders wrote:
> This is very helpful, recently I've come to share in some views of the community that libinjection isn't the most well supported/reviewed of all the projects on github. Fortunately compared to many other projects it is quite small from a codebase perspective and as a result the attack surface isn't outrageous, and reviewing it is reasonable. That being said we NEED to continue to including other rules that suppliment libinjection in case of a bypass, which is what we do in v3.0.0-rc1 :)

Chaim, I remember you stating, that you guys might be able to
help the libinjection project with a code review. Is this
still an option? I think it would be very helpful and fix a
sore spot.

The fact that the codebase is of a reasonable size give me
hope.

Ahoj,

Christian


--
Seek simplicity, and distrust it.
-- Alfred North Whitehead

[Chaim Sanders]

Yes, we could probably end up doing a review, I¹m sure they wouldn¹t mind
:).

On 2/7/16, 2:05 PM, "Christian Folini" <***@netnea.com> wrote:

>Good evening,
>
>On Sat, Feb 06, 2016 at 03:53:06PM +0000, Chaim Sanders wrote:
>> This is very helpful, recently I've come to share in some views of the
>>community that libinjection isn't the most well supported/reviewed of
>>all the projects on github. Fortunately compared to many other projects
>>it is quite small from a codebase perspective and as a result the attack
>>surface isn't outrageous, and reviewing it is reasonable. That being
>>said we NEED to continue to including other rules that suppliment
>>libinjection in case of a bypass, which is what we do in v3.0.0-rc1 :)
>
>Chaim, I remember you stating, that you guys might be able to
>help the libinjection project with a code review. Is this
>still an option? I think it would be very helpful and fix a
>sore spot.
>
>The fact that the codebase is of a reasonable size give me
>hope.
>
>Ahoj,
>
>Christian
>
>
>--
>Seek simplicity, and distrust it.
>-- Alfred North Whitehead


________________________________

This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.

[Christian Folini]

On Sun, Feb 07, 2016 at 07:07:49PM +0000, Chaim Sanders wrote:
> Yes, we could probably end up doing a review, I¹m sure they wouldn¹t mind
> :).

That would be really cool.

Christian

>
> On 2/7/16, 2:05 PM, "Christian Folini" <***@netnea.com> wrote:
>
> >Good evening,
> >
> >On Sat, Feb 06, 2016 at 03:53:06PM +0000, Chaim Sanders wrote:
> >> This is very helpful, recently I've come to share in some views of the
> >>community that libinjection isn't the most well supported/reviewed of
> >>all the projects on github. Fortunately compared to many other projects
> >>it is quite small from a codebase perspective and as a result the attack
> >>surface isn't outrageous, and reviewing it is reasonable. That being
> >>said we NEED to continue to including other rules that suppliment
> >>libinjection in case of a bypass, which is what we do in v3.0.0-rc1 :)
> >
> >Chaim, I remember you stating, that you guys might be able to
> >help the libinjection project with a code review. Is this
> >still an option? I think it would be very helpful and fix a
> >sore spot.
> >
> >The fact that the codebase is of a reasonable size give me
> >hope.
> >
> >Ahoj,
> >
> >Christian
> >
> >
> >--
> >Seek simplicity, and distrust it.
> >-- Alfred North Whitehead
>
>
> ________________________________
>
> This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.
> _______________________________________________
> Owasp-modsecurity-core-rule-set mailing list
> Owasp-modsecurity-core-rule-***@lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set

--
mailto:***@netnea.com
http://www.christian-folini.ch
twitter: @ChrFolini

[Walter Hop]

> Controversial Paranoia Mode Candidate 950120 (2.2.X) / 931130 (3.0.0rc1)
> msg: Possible Remote File Inclusion (RFI) Attack: Off-Domain Reference/Link
>
> [
]
>
> In my blogpost at
> https://www.netnea.com/cms/2016/01/17/most-frequent-false-positives-triggered-by-owasp-modsecurity-core-rules-2-2-x/
> I identified the said rule as one with very few false positives. Walter however brought it up as a rule with many false positives.
>
> A wider perspective is thus needed.
>
> Does anybody has anything to add?

To talk about my opinion of with this rule a bit, it’s super easy to trigger it.
Just any text input for a URL will do.
For example: http://example/?url=https://yahoo.com/

That is super common and bound to give various false positives on registration forms, contact forms, blog comment forms, etcetera. Firing on any plain URL submitted in a form? That’s a prime example of being paranoid :)

Whether the rule annoys a user depends on the blocking score I guess. I personally block on first sight and think everybody should. As you guys said, with SQLi and XSS you usually get high scores, but with this type of vulnerability you just get one shot.

What could improve false positives?
- I have multiple whitelistings for this rule on ARGS:url. If I was non-paranoid, I would assume that IF a web application accepts a parameter called “url”, it’s pretty likely that this was intended to be a URL field and not an avenue for RFI. So ARGS:url could be excluded in normal mode.
- From a quick log grep, people absolutely LOVE to do LFI and RFI on parameters like ARGS:page and ARGS:id. Maybe others have more suggestions.

My recommendation would be:
1) Put the full rule in paranoid set
2) In the basic set, clone this rule, but ensure it doesn’t work on ARGS:url
3) In the basic set, possibly consider raising the anomaly score if it’s sent as ARGS:id, ARGS:page

--
Walter Hop | PGP key: https://lifeforms.nl/pgp

[Christian Folini]

Walter,

On Sat, Feb 06, 2016 at 08:42:26PM +0100, Walter Hop wrote:
> To talk about my opinion of with this rule a bit, it’s super easy to trigger it.
> Just any text input for a URL will do.
> For example: http://example/?url=https://yahoo.com/

Just to make sure we are on the same boat: This
rule triggers on any argument containing a URI
which does not start with a FQDN identical with the
host-header of the request. Am I right?

> That is super common and bound to give various false positives on registration forms, contact forms, blog comment forms, etcetera. Firing on any plain URL submitted in a form? That’s a prime example of being paranoid :)

I can not really tell, why I hardly see any FP with this. But ok. I agree with
you, this is paranoid.

> My recommendation would be:
> 1) Put the full rule in paranoid set

Agree with that.

> 2) In the basic set, clone this rule, but ensure it doesn’t work on ARGS:url

I understand your reasoning. But is not that too much fiddling?
Or is ARGS:url that common? I have the same functionality on
ARGS:target
ARGS:remote
ARGS:back
...

Can't we leave that sort of tuning to the sysadmins?
Why don't we simply move the rule from standard to paranoia mode
as it has too many false positives.


> 3) In the basic set, possibly consider raising the anomaly score if it’s sent as ARGS:id, ARGS:page

It is already critical.

Cheers,

Christian


--
The need for mystery is greater than the need for an answer.
--- Ken Kesey

[Walter Hop]

> Just to make sure we are on the same boat: This
> rule triggers on any argument containing a URI
> which does not start with a FQDN identical with the
> host-header of the request. Am I right?

Yes :)

> 2) In the basic set, clone this rule, but ensure it doesn’t work on ARGS:url
> I understand your reasoning. But is not that too much fiddling?
> Or is ARGS:url that common? I have the same functionality on
> ARGS:target
> ARGS:remote
> ARGS:back
> ...
>
> Can't we leave that sort of tuning to the sysadmins? Why don't we simply move the rule from standard to paranoia mode as it has too many false positives.

Well, such a tuning was just one proposal to reduce FP for non-paranoid users so it might tip the balance in favor of keeping the rule in base. (Moving it to paranoid is just one possible way to change the FP / protection balance)

I’m not 100% sure we should go very far with whitelistings in the default set. But there is some precedent (excluding Google Analytics cookies, formerly also Piwik I think). The CRS does carve little holes sometimes in order to deal with reality of the current web and still be strict on the rest (while commercial WAFs are necessarily much less strict on this, since it causes them too many support calls).

I would hate to see the rule totally disappear from base just on my one FP note though. Maybe more people can check their audit logs for the rule since it’s in CRSv2 too. It does rule out a lot of exploits on legacy / in house PHP apps and attackers try it daily. So it’s a hard call...

--
Walter Hop | PGP key: https://lifeforms.nl/pgp

[Christian Folini]

Hello again,

On Tue, Feb 09, 2016 at 10:29:54PM +0100, Walter Hop wrote:
> Well, such a tuning was just one proposal to reduce FP for non-paranoid users so it might tip the balance in favor of keeping the rule in base. (Moving it to paranoid is just one possible way to change the FP / protection balance)

That makes a lot of sense. I was not aware of this reasoning behind your
previous message. Thanks for making this clear.

> I’m not 100% sure we should go very far with whitelistings in the default set. But there is some precedent (excluding Google Analytics cookies, formerly also Piwik I think). The CRS does carve little holes sometimes in order to deal with reality of the current web and still be strict on the rest (while commercial WAFs are necessarily much less strict on this, since it causes them too many support calls).

Exactly.

> I would hate to see the rule totally disappear from base just on my one FP note though. Maybe more people can check their audit logs for the rule since it’s in CRSv2 too. It does rule out a lot of exploits on legacy / in house PHP apps and attackers try it daily. So it’s a hard call...

Let's keep it in the base / on the default paranoia level then. Adding the whitelisting you
proposed does little harm and is in line with the UUID whitelisting Noël has developed
for 981173 (lately moved to
https://www.owasp.org/index.php/OWASP_ModSec_CRS_Paranoia_Mode_Sibling_981173)

Cheers,

Christian

--
mailto:***@netnea.com
http://www.christian-folini.ch
twitter: @ChrFolini

[Noël Zindel]

Hey there,

> On 10 Feb 2016, at 07:36, Christian Folini <***@netnea.com> wrote:
>
> Let's keep it in the base / on the default paranoia level then. Adding the whitelisting you
> proposed does little harm and is in line with the UUID whitelisting Noël has developed
> for 981173 (lately moved to
> https://www.owasp.org/index.php/OWASP_ModSec_CRS_Paranoia_Mode_Sibling_981173)

I was not following up on this branch of the conversation. But let me look into this to see if i can write out a whitelisting proposal.

Regards,
Noël

[Christian Folini]

Cool. Thanks, Noël!

Christian

On Wed, Feb 10, 2016 at 08:36:51AM +0100, Noël Zindel wrote:
> Hey there,
>
> > On 10 Feb 2016, at 07:36, Christian Folini <***@netnea.com> wrote:
> >
> > Let's keep it in the base / on the default paranoia level then. Adding the whitelisting you
> > proposed does little harm and is in line with the UUID whitelisting Noël has developed
> > for 981173 (lately moved to
> > https://www.owasp.org/index.php/OWASP_ModSec_CRS_Paranoia_Mode_Sibling_981173)
>
> I was not following up on this branch of the conversation. But let me look into this to see if i can write out a whitelisting proposal.
>
> Regards,
> Noël
>



> _______________________________________________
> Owasp-modsecurity-core-rule-set mailing list
> Owasp-modsecurity-core-rule-***@lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set

[Richard Lin]

Hi folks, I just joined the lists one day ago. And would like to seek the opinions of dealing with a SQLI pattern verdict-ed differently between regex rules and libinjection.
http://test.com?id=select a from table b.
I did not make SQLI "select a from table b" as URL encoded for easier discussion here.
Basically, libinjection does not consider this string as SQLI although its SQLI pattern is so obvious. Libinjection considers the SQL injections are typically in the context of
select * from table where id =%input with or without injection%

From libinjection point of view, the input of "select a from table b" is unable to join the above statement with correct SQL syntax. But if we just use regex rules, this input is so easy to marked as SQLI. I would like to seek the opinion in this group. Do you think the request as "http://test.com?id=select a from table b." would cause really SQL injection successful in SQL syntax in any site?
ThanksRichard

[Chaim Sanders]

Hey Richard,
I've seen things CLOSE to this in production. Sites where they've attempted to use prepared statements to secure a location where the variable injected in a table name. Of course prepared statements are designed for this environment and will fail miserably. But this accounts for a situation where all of the following except the word select is true. Granted it's unusual.

From: <owasp-modsecurity-core-rule-set-***@lists.owasp.org<mailto:owasp-modsecurity-core-rule-set-***@lists.owasp.org>> on behalf of Richard Lin <***@hotmail.com<mailto:***@hotmail.com>>
Date: Wednesday, February 10, 2016 at 7:31 PM
To: "owasp-modsecurity-core-rule-***@lists.owasp.org<mailto:owasp-modsecurity-core-rule-***@lists.owasp.org>" <owasp-modsecurity-core-rule-***@lists.owasp.org<mailto:owasp-modsecurity-core-rule-***@lists.owasp.org>>
Subject: [Owasp-modsecurity-core-rule-set] Need suggestion for a SQLI pattern

Hi folks, I just joined the lists one day ago. And would like to seek the opinions of dealing with a SQLI pattern verdict-ed differently between regex rules and libinjection.

http://test.com?id=select<http://scanmail.trustwave.com/?c=4062&d=pNy71nQ6my89hadbculWPuIrswrAlseaEkF1b2C_pA&s=5&u=http%3a%2f%2ftest%2ecom%3fid%3dselect> a from table b.

I did not make SQLI "select a from table b" as URL encoded for easier discussion here.

Basically, libinjection does not consider this string as SQLI although its SQLI pattern is so obvious. Libinjection considers the SQL injections are typically in the context of


select * from table where id =%input with or without injection%


From libinjection point of view, the input of "select a from table b" is unable to join the above statement with correct SQL syntax. But if we just use regex rules, this input is so easy to marked as SQLI. I would like to seek the opinion in this group. Do you think the request as "http://test.com?id=select a from table b.<http://scanmail.trustwave.com/?c=4062&d=pNy71nQ6my89hadbculWPuIrswrAlseaEhJ6aGfioQ&s=5&u=http%3a%2f%2ftest%2ecom%3fid%3dselect%20a%20from%20table%20b>" would cause really SQL injection successful in SQL syntax in any site?

Thanks
Richard

________________________________

This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.

[Richard Lin]

Thanks. Could you explain in more detail?
My understanding for SQL injection case is that careless web developers take the web request parameters and add them to their "where clause".
So if the input is '1 union select a from uid2" that would cause successful injection because the careless developer's SQL was modified from
select * from User where id = [ input] to select * from User where id = 1 union select a from uid2
In above case, the SQL statement was successfully modified with correct syntax. Thus I can accept this is a successful injection.
But if the input is "select a from uid2", then careless developers SQL is as:
select * from User where id = select a from uid2
The above SQL statement is not correct in syntax. So this injection will not be successful. Maybe due to this consideration, the libinjection does not consider input of "select a from uid2" is a SQL injection although its SQL pattern is so obvious.
Richard

From: ***@trustwave.com
To: ***@hotmail.com; owasp-modsecurity-core-rule-***@lists.owasp.org
Subject: Re: [Owasp-modsecurity-core-rule-set] Need suggestion for a SQLI pattern
Date: Thu, 11 Feb 2016 02:51:44 +0000






Hey Richard,
I’ve seen things CLOSE to this in production. Sites where they’ve attempted to use prepared statements to secure a location where the variable injected in a table name. Of course prepared statements are designed for this environment and will fail miserably.
But this accounts for a situation where all of the following except the word select is true. Granted it’s unusual.





From: <owasp-modsecurity-core-rule-set-***@lists.owasp.org> on behalf of Richard Lin <***@hotmail.com>

Date: Wednesday, February 10, 2016 at 7:31 PM

To: "owasp-modsecurity-core-rule-***@lists.owasp.org" <owasp-modsecurity-core-rule-***@lists.owasp.org>

Subject: [Owasp-modsecurity-core-rule-set] Need suggestion for a SQLI pattern








Hi folks, I just joined the lists one day ago. And would like to seek the opinions of dealing with a SQLI pattern verdict-ed differently between regex rules and libinjection.



http://test.com?id=select a from table b.



I did not make SQLI "select a from table b" as URL encoded for easier discussion here.



Basically, libinjection does not consider this string as SQLI although its SQLI pattern is so obvious. Libinjection considers the SQL injections are typically in the context of




select * from table where id =%input with or without injection%






From libinjection point of view, the input of "select a from table b" is unable to join the above statement with correct SQL syntax. But if we just use regex rules, this input is so easy to marked as SQLI. I would
like to seek the opinion in this group. Do you think the request as "http://test.com?id=select
a from table b." would cause really SQL injection successful in SQL syntax in any site?



Thanks
Richard








This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information
contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.

[Christian Folini]

Richard,

You are on good tracks with your reasoning.

What LibInjection is doing is feeding your input string into an
sql parser and check if it results in a possible injection.

Obviously, your input string _is_ sql, which gives reason to
believe that libinjection is combining your string with
predefined strings first. Much like you do in your message.

The problem is, that libinjection is underdocumented from a
technical viewpoint so all I am writing here is based on
fairly highlevel presentations.

The takeaway for me is that not even libinjection is a silver
bullet. It catches a lot, but there are dark areas where
it has to be combined with regexes in a diverse approach.

Ahoj,

Christian







On Thu, Feb 11, 2016 at 06:06:35AM +0000, Richard Lin wrote:
> Thanks. Could you explain in more detail?
> My understanding for SQL injection case is that careless web developers take the web request parameters and add them to their "where clause".
> So if the input is '1 union select a from uid2" that would cause successful injection because the careless developer's SQL was modified from
> select * from User where id = [ input] to select * from User where id = 1 union select a from uid2
> In above case, the SQL statement was successfully modified with correct syntax. Thus I can accept this is a successful injection.
> But if the input is "select a from uid2", then careless developers SQL is as:
> select * from User where id = select a from uid2
> The above SQL statement is not correct in syntax. So this injection will not be successful. Maybe due to this consideration, the libinjection does not consider input of "select a from uid2" is a SQL injection although its SQL pattern is so obvious.
> Richard
>
> From: ***@trustwave.com
> To: ***@hotmail.com; owasp-modsecurity-core-rule-***@lists.owasp.org
> Subject: Re: [Owasp-modsecurity-core-rule-set] Need suggestion for a SQLI pattern
> Date: Thu, 11 Feb 2016 02:51:44 +0000
>
>
>
>
>
>
> Hey Richard,
> I’ve seen things CLOSE to this in production. Sites where they’ve attempted to use prepared statements to secure a location where the variable injected in a table name. Of course prepared statements are designed for this environment and will fail miserably.
> But this accounts for a situation where all of the following except the word select is true. Granted it’s unusual.
>
>
>
>
>
> From: <owasp-modsecurity-core-rule-set-***@lists.owasp.org> on behalf of Richard Lin <***@hotmail.com>
>
> Date: Wednesday, February 10, 2016 at 7:31 PM
>
> To: "owasp-modsecurity-core-rule-***@lists.owasp.org" <owasp-modsecurity-core-rule-***@lists.owasp.org>
>
> Subject: [Owasp-modsecurity-core-rule-set] Need suggestion for a SQLI pattern
>
>
>
>
>
>
>
>
> Hi folks, I just joined the lists one day ago. And would like to seek the opinions of dealing with a SQLI pattern verdict-ed differently between regex rules and libinjection.
>
>
>
> http://test.com?id=select a from table b.
>
>
>
> I did not make SQLI "select a from table b" as URL encoded for easier discussion here.
>
>
>
> Basically, libinjection does not consider this string as SQLI although its SQLI pattern is so obvious. Libinjection considers the SQL injections are typically in the context of
>
>
>
>
> select * from table where id =%input with or without injection%
>
>
>
>
>
>
> >From libinjection point of view, the input of "select a from table b" is unable to join the above statement with correct SQL syntax. But if we just use regex rules, this input is so easy to marked as SQLI. I would
> like to seek the opinion in this group. Do you think the request as "http://test.com?id=select
> a from table b." would cause really SQL injection successful in SQL syntax in any site?
>
>
>
> Thanks
> Richard
>
>
>
>
>
>
>
>
> This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information
> contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.
>
>

> _______________________________________________
> Owasp-modsecurity-core-rule-set mailing list
> Owasp-modsecurity-core-rule-***@lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set


--
mailto:***@netnea.com
http://www.christian-folini.ch
twitter: @ChrFolini

[Chaim Sanders]

This post might be inappropriate. Click to display it.

[Richard Lin]

Thanks Chaim and Christian and I agree that it is bad that a user controls a SQL statement. I think libinjection covered 'Where' and 'Like' clause as you mentioned.
I am trying to judge if libinjection missed a category of attacking model in which the user's input is an independent SQLs which can be invoked by themselves (i.e, without prefix of "1 UNION", '1 or", "1 and", etc) If that is the case, I would consider to propose a patch. But I am not sure how careless developers can directly take the input as SQL itself. That sounds too naive to be believed :)

From: ***@trustwave.com
To: ***@hotmail.com; owasp-modsecurity-core-rule-***@lists.owasp.org
Subject: Re: [Owasp-modsecurity-core-rule-set] Need suggestion for a SQLI pattern
Date: Thu, 11 Feb 2016 13:28:40 +0000






Hey Richard, first I’ll echo what Christian said, but also what you have described is just a LIMITED case of SQL injection. SQL Injection can really deal with any area in which SQL may be introduced by an attacker and it will
then be executed later. There is no need to limit this to a where clause. For instance it could be in a like clause, it could be the clause itself, it could be the statement (select for instance) etc. The underlying idea is that anywhere a user can control
a SQL statement would be bad. In fairness to libinjection it isn’t factoring in all these situations it is designed with parameters in mind and SQL injections more a kin to the type you are describing. This is why we leave in complex regex patterns as well
that can detect SQL patterns like the one you have described.
Another situation where it would be valuable to detect such statements would be in the case of stacked sql queries. Although not all engines support it, in some you may so things like:



select * from User where id = [ input] to select * from User where id = 1; select a
from uid2




These are good questions and from these often we’ll discover other facets of the problem or solutions we never thought of so please feel free to keep asking if you have any ideas or questions, or are unclear on something :)









From: Richard Lin <***@hotmail.com>

Date: Thursday, February 11, 2016 at 1:06 AM

To: Chaim Sanders <***@trustwave.com>, "owasp-modsecurity-core-rule-***@lists.owasp.org" <owasp-modsecurity-core-rule-***@lists.owasp.org>

Subject: RE: [Owasp-modsecurity-core-rule-set] Need suggestion for a SQLI pattern







Thanks. Could you explain in more detail?



My understanding for SQL injection case is that careless web developers take the web request parameters and add them to their "where clause".



So if the input is '1 union select a from uid2" that would cause successful injection because the careless developer's SQL was modified from



select * from User where id = [ input] to select * from User where id = 1 union select a from
uid2



In above case, the SQL statement was successfully modified with correct syntax. Thus I can accept this is a successful injection.



But if the input is "select a from uid2", then careless developers
SQL is as:




select * from User where id = select a from uid2




The above SQL statement is not correct in syntax. So this injection will not be successful. Maybe due to this consideration, the libinjection does not consider input of "select a
from uid2" is a SQL injection although its SQL pattern is so obvious.



Richard









From: ***@trustwave.com

To: ***@hotmail.com;
owasp-modsecurity-core-rule-***@lists.owasp.org

Subject: Re: [Owasp-modsecurity-core-rule-set] Need suggestion for a SQLI pattern

Date: Thu, 11 Feb 2016 02:51:44 +0000



Hey Richard,
I’ve seen things CLOSE to this in production. Sites where they’ve attempted to use prepared statements to secure a location where the variable injected in a table name. Of course prepared statements are designed for this environment and will fail miserably.
But this accounts for a situation where all of the following except the word select is true. Granted it’s unusual.





From: <owasp-modsecurity-core-rule-set-***@lists.owasp.org> on behalf of Richard Lin <***@hotmail.com>

Date: Wednesday, February 10, 2016 at 7:31 PM

To: "owasp-modsecurity-core-rule-***@lists.owasp.org" <owasp-modsecurity-core-rule-***@lists.owasp.org>

Subject: [Owasp-modsecurity-core-rule-set] Need suggestion for a SQLI pattern








Hi folks, I just joined the lists one day ago. And would like to seek the opinions of dealing with a SQLI pattern verdict-ed differently between regex rules and libinjection.



http://test.com?id=select a from table b.



I did not make SQLI "select a from table b" as URL encoded for easier discussion here.



Basically, libinjection does not consider this string as SQLI although its SQLI pattern is so obvious. Libinjection considers the SQL injections are typically in the context of




select * from table where id =%input with or without injection%






From libinjection point of view, the input of "select a from table b" is unable to join the above statement with correct SQL syntax. But if we just use regex rules, this input is so easy to marked as SQLI. I would
like to seek the opinion in this group. Do you think the request as "http://test.com?id=select
a from table b." would cause really SQL injection successful in SQL syntax in any site?



Thanks
Richard








This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information
contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.











This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information
contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.

[Chaim Sanders]

This post might be inappropriate. Click to display it.

[Walter Hop]

Hi Richard and others,

Actually your original query (passing “select A from B”) might even be successful in some cases. For instance, in MySQL, you can have a subquery. However it must appear in parentheses.

For instance this is a valid query:
select * from user where id=(select id from user where admin=1)

So if an application developer does the following, your statement might get executed:
select * from user where id=(injected_parameter)

Now, the libinjection in ModSec 2.9 still tries to do something. It doesn’t think this is SQLi:
"select id from user” (your example)
“delete from foo"

But it does think the following strings are SQLi:
"(select id from user)”
"select id from user where admin=1”
"select id from user where password is null”

It’s still bit of a black box, but I’m collecting many samples and I plan to report any possible coverage test caseas upstream. I think your example is an interesting one that may not cause too many vulnerabilities, but an application that accepts full queries is still very hazardous so in my opinion ideally libinjection should trigger on it.

Cheers!
WH

> On 11 Feb 2016, at 18:50, Richard Lin <***@hotmail.com> wrote:
>
> Thanks Chaim and Christian and I agree that it is bad that a user controls a SQL statement. I think libinjection covered 'Where' and 'Like' clause as you mentioned.
>
> I am trying to judge if libinjection missed a category of attacking model in which the user's input is an independent SQLs which can be invoked by themselves (i.e, without prefix of "1 UNION", '1 or", "1 and", etc) If that is the case, I would consider to propose a patch. But I am not sure how careless developers can directly take the input as SQL itself. That sounds too naive to be believed :)
>

--
Walter Hop | PGP key: https://lifeforms.nl/pgp

[Christian Folini]

Hi there,

This is just to let you know that I think we settled this discussion
with the resolution to keep it in the set of base rules / on the
default paranoia level.

Walter suggested a set of whitelistings for the rule to avoid
false positives. These should be added, but this will be outside
of the paranoia mode pull request.

Cheers,

Christian



On Wed, Feb 10, 2016 at 07:36:10AM +0100, Christian Folini wrote:
> Hello again,
>
> On Tue, Feb 09, 2016 at 10:29:54PM +0100, Walter Hop wrote:
> > Well, such a tuning was just one proposal to reduce FP for non-paranoid users so it might tip the balance in favor of keeping the rule in base. (Moving it to paranoid is just one possible way to change the FP / protection balance)
>
> That makes a lot of sense. I was not aware of this reasoning behind your
> previous message. Thanks for making this clear.
>
> > I’m not 100% sure we should go very far with whitelistings in the default set. But there is some precedent (excluding Google Analytics cookies, formerly also Piwik I think). The CRS does carve little holes sometimes in order to deal with reality of the current web and still be strict on the rest (while commercial WAFs are necessarily much less strict on this, since it causes them too many support calls).
>
> Exactly.
>
> > I would hate to see the rule totally disappear from base just on my one FP note though. Maybe more people can check their audit logs for the rule since it’s in CRSv2 too. It does rule out a lot of exploits on legacy / in house PHP apps and attackers try it daily. So it’s a hard call...
>
> Let's keep it in the base / on the default paranoia level then. Adding the whitelisting you
> proposed does little harm and is in line with the UUID whitelisting Noël has developed
> for 981173 (lately moved to
> https://www.owasp.org/index.php/OWASP_ModSec_CRS_Paranoia_Mode_Sibling_981173)
>
> Cheers,
>
> Christian
>
> --
> mailto:***@netnea.com
> http://www.christian-folini.ch
> twitter: @ChrFolini
> _______________________________________________
> Owasp-modsecurity-core-rule-set mailing list
> Owasp-modsecurity-core-rule-***@lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set

[Walter Hop]

I want to give a FINAL reply about the RFI rule and then I’ll move on to other rules, honestly!
Also for Noel who emailed me about data for this rule.

>> I would hate to see the rule totally disappear from base just on my one FP note though. Maybe more people can check their audit logs for the rule since it’s in CRSv2 too. It does rule out a lot of exploits on legacy / in house PHP apps and attackers try it daily. So it’s a hard call...
>
> Let's keep it in the base / on the default paranoia level then. Adding the whitelisting you
> proposed does little harm and is in line with the UUID whitelisting Noël has developed
> for 981173 (lately moved to
> https://www.owasp.org/index.php/OWASP_ModSec_CRS_Paranoia_Mode_Sibling_981173 <https://www.owasp.org/index.php/OWASP_ModSec_CRS_Paranoia_Mode_Sibling_981173>)


I said I had mostly only whitelisted ARGS:url for this rule. But I lied! After Noel emailed me, I checked logs and I noticed that I had adjusted the rule in my fork of the CRS git repo so it had a lower (non critical) score. So my experience was not the norm.

To try to get some test data, I enabled the rule again on some staging & internal sites to make it critical again. The experience was pretty horrible. There was a lot of breakage, colleagues complaining that I am wasting their time with 403 errors, and now I remember why I had edited this rule... :) As I could have expected, apps that broke were basically anything where a URL is passed.

Some examples:
- Wordpress admin pages, with unpredictable names (e.g. id’s in args name)
- Wordpress multisite (ARGS:option[ping_sites])
- Symfony user profile (ARGS:fos_user_profile_form[website], ARGS:fos_user_registration_form[website])
- vBulletin user profile (ARGS:homepage)
- billing system (ARGS:return/ARGS:cancel/ARGS:notify)

This is just from a few days of people getting 403s. So after this experiment, I’m tending towards saying, this is the type of rule that makes the CRS scary to use, even if the rule is effective against RFI.

Of course if the default paranoia level is nonzero and it stays at that level, we have sorta CRSv2 parity and still a good way to get out of these FP.

--
Walter Hop | PGP key: https://lifeforms.nl/pgp

[Christian Folini]

Walter,

Thanks for the further testing.

On Sat, Feb 13, 2016 at 08:54:23PM +0100, Walter Hop wrote:
> To try to get some test data, I enabled the rule again on some staging & internal sites to make it critical again. The experience was pretty horrible. There was a lot of breakage, colleagues complaining that I am wasting their time with 403 errors, and now I remember why I had edited this rule... :) As I could have expected, apps that broke were basically anything where a URL is passed.

Really interesting. Our environments are so different. I really
see very few FPs here. But it's not the same type of software
running on the servers.

> This is just from a few days of people getting 403s. So after this experiment, I’m tending towards saying, this is the type of rule that makes the CRS scary to use, even if the rule is effective against RFI.
>
> Of course if the default paranoia level is nonzero and it stays at that level, we have sorta CRSv2 parity and still a good way to get out of these FP.

I am not sure I understand your last sentence correctly.

If we have most rules at paranoia level 1 and default is
paranoia level 1. Should this rule be a 1 with additional
whitelisting of FPs, or should we assign it a paranoia
level of 2?

I'm OK with both options.

Ahoj,

Christian



--
The reasonable man adapts himself to the world; the unreasonable man
persists in trying to adapt the world to himself. Therefore, all
progress depends on the unreasonable man.
-- George Bernard Shaw

[Walter Hop]

On 14 Feb 2016, at 13:42, Christian Folini <***@netnea.com> wrote:
>
> If we have most rules at paranoia level 1 and default is
> paranoia level 1. Should this rule be a 1 with additional
> whitelisting of FPs, or should we assign it a paranoia
> level of 2?
>
> I'm OK with both options.

OK. Still a hard call but if we set default paranoia level at 1 (sounds good to me) I would say this rule should start at a level of 2.

I was thinking out loud about the principle of CRSv2 users since they might expect this rule to stay. But we should document clearly somewhere what the benefits and drawbacks of the levels are. (Maybe it’s time to start a CHANGES document in the source tree?)

--
Walter Hop | PGP key: https://lifeforms.nl/pgp

[Christian Folini]

Walter,

On Sun, Feb 14, 2016 at 05:38:54PM +0100, Walter Hop wrote:
> > If we have most rules at paranoia level 1 and default is
> > paranoia level 1. Should this rule be a 1 with additional
> > whitelisting of FPs, or should we assign it a paranoia
> > level of 2?
> >
> > I'm OK with both options.
>
> OK. Still a hard call but if we set default paranoia level at 1 (sounds good to me) I would say this rule should start at a level of 2.

Thank you. I just moved the rule back from "dropped" to "confirmed" in
the wiki.

I am glad you confirmed the default level setting. My first pull request
is mostly done and I just moved the anomaly score evaluation and
correlation to level 0 while the other rules are running in level 1.
That works nicely.

> I was thinking out loud about the principle of CRSv2 users since they might expect this rule to stay. But we should document clearly somewhere what the benefits and drawbacks of the levels are. (Maybe it’s time to start a CHANGES document in the source tree?)

Absolutely.

You came up with a proposal. It was too narrow for me. My
proposal in the mechanics blogpost was probably to broad.
Right now, the definition of the paranoia stuff in
modsecurity_crs_10_setup.conf.example reads:

...
# The possible paranoia levels are 0,1,2,3 and 4.
#
# FIXME
# Level 0: ...
# Level 1: ...
# Level 2: ...
# Level 3: ...
# Level 4: ...
...

:-)

(btw. here is the git link:
https://github.com/dune73/owasp-modsecurity-crs/tree/paranoia-mode)


Cheers,

Christian


--
If liberty means anything at all, it means the right to tell people
what they do not want to hear.
-- George Orwell

[Christian Folini]

Richard,

On Thu, Feb 11, 2016 at 05:50:02PM +0000, Richard Lin wrote:
> But I am not sure how careless developers
> can directly take the input as SQL itself. That sounds too naive to be believed :)

A few months ago, I saw an application with a complete sql query in a
cookie named "searchform". Little bobby tables would have been
impressed.

Ahoj,

Christian

--
mailto:***@netnea.com
http://www.christian-folini.ch
twitter: @ChrFolini