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

New rule 941360 to detect JSFuck and Hieroglyphy at PL1 #1261

Merged
merged 2 commits into from Jan 12, 2019

Conversation

Projects
None yet
3 participants
@dune73
Copy link
Collaborator

dune73 commented Dec 16, 2018

This includes a new rule among the XSS rules and a couple of tests to go with it.

@fgsch

This comment has been minimized.

Copy link
Collaborator

fgsch commented Jan 7, 2019

Reminder: capture might be missing.

@dune73

This comment has been minimized.

Copy link
Collaborator

dune73 commented Jan 8, 2019

You're right @fgsch. Thanks for pointing this out. I'll update the PR.

@spartantri
Copy link
Collaborator

spartantri left a comment

The space in the regex doesn't change the detection rate "@rx ![!+]\[\]"

@spartantri

This comment has been minimized.

Copy link
Collaborator

spartantri commented Jan 8, 2019

jsfuck payloads are huge and not really understandable, I'm ok to have the E part in the auditlog but I'm curious about why adding %{MATCHED_VAR}?

@dune73

This comment has been minimized.

Copy link
Collaborator

dune73 commented Jan 8, 2019

The comments carry the following remark:

ModSecurity always transforms "+" into " " with query strings and the
URLENCODE body processor
...

Did you notice that?

@spartantri
Copy link
Collaborator

spartantri left a comment

:)

@spartantri

This comment has been minimized.

Copy link
Collaborator

spartantri commented Jan 8, 2019

The comments carry the following remark:

ModSecurity always transforms "+" into " " with query strings and the
URLENCODE body processor
...

Did you notice that?

my bad sorry :) it may be interesting to have this tested in front of a WP or some other CMS that uses lots of [] on their payloads before releasing 3.2

@fgsch

This comment has been minimized.

Copy link
Collaborator

fgsch commented Jan 9, 2019

@dune73 you might want to rebase your branch using the latest commit in v3.2/dev so the tests pass.

@dune73

This comment has been minimized.

Copy link
Collaborator

dune73 commented Jan 11, 2019

@fgsch: That's what I planned to do, but did not have time earlier. Now I did and it messed it up. So I'm planning to throw this away and do a new, clean PR.

Here is what I did. What's wrong with this?

$> git checkout jsfuck-support
$> git remote add upstream git@github.com:SpiderLabs/owasp-modsecurity-crs.git
$> git rebase upstream/v3.2/dev
$> git push origin

I see the tests passing now. But anyways, I guess I should have cherrypicked the right commit.

@fgsch

This comment has been minimized.

Copy link
Collaborator

fgsch commented Jan 11, 2019

@dune73 not sure. I normally do the following (assuming origin points to this repo):

  1. git co v3.2/dev
  2. git pull origin
  3. git co jsfuck-support
  4. git rebase v3.2/dev
  5. git push -f origin

You should be able to fix this PR without closing it, for example:

  1. git branch -M jsfuck-support jsfuck-support-old
  2. git co v3.2/dev
  3. git pull
  4. git co -b jsfuck-support
  5. git cherry-pick <rev for commit in jsfuck-support-old>
  6. git push -f

@dune73 dune73 force-pushed the dune73:jsfuck-support branch from 682bc3e to e8b254e Jan 12, 2019

@dune73

This comment has been minimized.

Copy link
Collaborator

dune73 commented Jan 12, 2019

That worked nicely. Thank you @fgs.

Merging now. At last. :-)

@dune73 dune73 merged commit 709bdcd into SpiderLabs:v3.2/dev Jan 12, 2019

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment