New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bypass SQL Injection Rules #comment symbol with logical operator should be blocked #797

Closed
umarfarook882 opened this Issue Jun 6, 2017 · 4 comments

Comments

Projects
None yet
4 participants
@umarfarook882
Copy link
Contributor

umarfarook882 commented Jun 6, 2017

sorry i just confused with both OWASP CRS and Comodo WAF rules. i think i made a mistake.. i just checked again OWASP CRS 3 with these payloads. libinjection detect these below payloads. so no way to bypass sql injection rules.

' /*!or*/1=1#
' /*!order*/ By 1#
' || 1=1#
' && 1=1#
' /*!||*/ 1=1#
' /*!&&*/ 1=1#

In case, if any application which support base 64 encoding as a input for some purpose

Example: http://www.attacker.com?id=MTIz

id is the point of entry for attacker to try all injection attack.

Check the demo Video

So OWASP CRS 3 cannot able to detect base64 encoded sql injection payload unless user customize the rules to prevent these attack. so we need to make it better for user to prevent these attacks.

We already discuss these problem and solution for the issue Base 64 Encoding Payloads

so we can implement it as a optional rule in OWASP CRS 3.

@csanders-git

This comment has been minimized.

Copy link
Collaborator

csanders-git commented Jun 9, 2017

these are very similar to #782 perhaps we should combine ticket.. love the /*! SQL specific comment, that was in some of the research we just posted as well. I think we might be able to just look for that sequence as i don't think it'd offer high FPs thoughts?

@dune73

This comment has been minimized.

Copy link
Collaborator

dune73 commented Jun 10, 2017

I am a bit overwhelmed with the different sqli evasion tickets now. However, I get the feeling this one is distinct from #782. And we need to think about attaching new detection mechanism to existing rules (vs. creating new rules).

Specific to this one: At what PL is this an evasion? (could check myself, but I am hungry now. :)

@lifeforms

This comment has been minimized.

Copy link
Collaborator

lifeforms commented Aug 6, 2017

In ModSecurity 2.9.2, these payloads all produce alerts in PL1 thanks to libinjection. So I think we are good to go, and we can close this issue! Thanks for checking. :)

num test sco actual-rules                 expected-rules         payload
--- ---- --- ---------------------------- ---------------------- -----------------------------
1   ok   5   942100                       942100                 ' /*!or*/1=1#
2   ok   5   942100                       942100                 ' /*!order*/ By 1#
3   ok   10  942100                       942100                 ' || 1=1#
4   ok   10  942100                       942100                 ' && 1=1#
5   ok   5   942100                       942100                 ' /*!||*/ 1=1#
6   ok   5   942100                       942100                 ' /*!&&*/ 1=1#

Number of entries: 6
Score distribution:
    5 ++++ 4
   10 ++ 2
Rule distribution:
  6x942100 
Tests:
    6 success

@lifeforms lifeforms closed this Aug 6, 2017

@umarfarook882

This comment has been minimized.

Copy link
Contributor

umarfarook882 commented Aug 7, 2017

@lifeforms Thanks :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment