spartantri · spartantri · Jul 25, 2018 · Oct 5, 2017 · Oct 5, 2017 · Oct 9, 2017
diff --git a/.gitignore b/.gitignore
@@ -1,7 +1,11 @@
-crs-setup.conf
 *.swp
 *.swo
 
+# User configuration
+crs-setup.conf
+rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
+rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf
+
 # The MaxMind GeoIP database can be downloaded or upgraded by running:
 # util/upgrade.py geoip
 util/geo-location/GeoIP.dat
@@ -12,4 +16,4 @@ util/geo-location/GeoIP.dat
 # Byte-compiled / optimized / DLL files
 __pycache__/
 *.py[cod]
-*$py.class
+*$py.class
diff --git a/.travis.yml b/.travis.yml
@@ -1,12 +1,31 @@
+sudo: required
+services:
+- docker
 language: python
 python:
-  - "2.7"
-install: "pip install -r ./util/integration/requirements.txt"
+  - 2.7
+before_install:
+  - docker build --build-arg REPO=$TRAVIS_PULL_REQUEST_SLUG --build-arg COMMIT=$TRAVIS_PULL_REQUEST_SHA -t modsecurity-crs ./util/
+  - docker run -ti -e PARANOIA=5 -d --rm -p 80:80 -v /var/log/apache2:/var/log/apache2/ modsecurity-crs
+install: 
+  - pip install -r ./util/integration/requirements.txt
+  - pip install -r ./util/regression-tests/requirements.txt
 script:
-    - py.test -vs ./util/integration/format_tests.py
+  - docker ps | grep -q modsecurity-crs || exit 1
+  - py.test -vs ./util/integration/format_tests.py
+  - py.test -vs util/regression-tests/CRS_Tests.py --rule=util/regression-tests/tests/test.yaml
+  - py.test -vs util/regression-tests/CRS_Tests.py --ruledir=util/regression-tests/tests/REQUEST-911-METHOD-ENFORCEMENT
+  - py.test -vs util/regression-tests/CRS_Tests.py --ruledir=util/regression-tests/tests/REQUEST-913-SCANNER-DETECTION
+  - py.test -vs util/regression-tests/CRS_Tests.py --ruledir=util/regression-tests/tests/REQUEST-921-PROTOCOL-ATTACK
+  - py.test -vs util/regression-tests/CRS_Tests.py --ruledir=util/regression-tests/tests/REQUEST-930-APPLICATION-ATTACK-LFI
+  - py.test -vs util/regression-tests/CRS_Tests.py --ruledir=util/regression-tests/tests/REQUEST-941-APPLICATION-ATTACK-XSS
+  - py.test -vs util/regression-tests/CRS_Tests.py --ruledir=util/regression-tests/tests/REQUEST-942-APPLICATION-ATTACK-SQLI
+  - py.test -vs util/regression-tests/CRS_Tests.py --ruledir=util/regression-tests/tests/REQUEST-943-APPLICATION-ATTACK-SESSION-FIXATION
 # safelist
 branches:
   only:
   - v3.0/dev
   - v3.0/master
   - v3.1/dev
+notifications:
+  irc: "chat.freenode.net#modsecurity"
diff --git a/CHANGES b/CHANGES
@@ -5,7 +5,9 @@
   or the CRS mailinglist at
 * https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
 
-== Version 3.0.2 - 5/FIXME/2017 ==
+== Version 3.1.0 - 6/5/2017 ==
+
+== Version 3.0.2 - 5/12/2017 ==
 
  * Remove debug rule that popped up in 3.0.1 (Christian Folini)
 

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -0,0 +1,151 @@
+# Contributing to the CRS
+
+We value third-party contributions. To keep things simple for you and us,
+please adhere to the following contributing guidelines.
+
+## Getting Started
+
+* You will need a [GitHub account](https://github.com/signup/free).
+* Submit a [ticket for your issue](https://github.com/SpiderLabs/owasp-modsecurity-crs/issues), assuming one does not already exist.
+  * Clearly describe the issue including steps to reproduce when it is a bug.
+  * Make sure you specify the version that you know has the issue.
+  * Bonus points for submitting a failing test along with the ticket.
+* If you don't have push access, fork the repository on GitHub.
+
+## Making Changes
+
+* Please base your changes on branch ```v3.1/dev```
+* Create a topic branch for your feature or bug fix.
+* Make commits of logical units.
+* Make sure your commits adhere to the rules guidelines below.
+* Make sure your commit messages are in the [proper format](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html): The first line of the message should have 50 characters or less, separated by a blank line from the (optional) body. The body should be wrapped at 70 characters and paragraphs separated by blank lines. Bulleted lists are also fine.
+
+## General Formatting Guidelines for rules contributions
+
+ - 4 spaces per indentation level, no tabs
+ - no trailing whitespace at EOL or trailing blank lines at EOF
+ - comments are good, especially when they clearly explain the rule
+ - try to adhere to a 80 character line length limit
+ - if it is a [chained rule](https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#chain), alignment should be like
+```
+    SecRule .. ..\
+        "...."
+        SecRule .. ..\
+            "..."
+            SecRule .. ..\
+                ".."
+```
+ - use quotes even if there is only one action, it improves readability (e.g use `"chain"`, not `chain`, or `"ctl:requestBodyAccess=Off"` instead of `ctl:requestBodyAccess=Off`)
+ - always use numbers for phases, instead of names
+ - format your `SecMarker` between double quotes, using UPPERCASE and separating words using hyphens. Examples are
+```
+    SecMarker "END-RESPONSE-959-BLOCKING-EVALUATION"
+    SecMarker "END-REQUEST-910-IP-REPUTATION"
+```
+ - the proposed order for actions is:
+```
+    id
+    phase
+    disruptive-action
+    status
+    capture
+    t:xxx
+    log
+    nolog
+    auditlog
+    noauditlog
+    msg
+    logdata
+    tag
+    sanitiseArg
+    sanitiseRequestHeader
+    sanitiseMatched
+    sanitiseMatchedBytes
+    ctl
+    setenv
+    rev
+    ver
+    severity
+    setvar
+    expirevar
+    chain
+    skip
+    skipAfter
+```
+
+## Variables naming conventions
+
+* Variable names are lowercase using chars from `[a-z0-9_]`
+* To somewhat reflect the fact that the syntax for variable usage is different when you define it (using setvar) and when you use it, we propose the following visual distinction:
+  * Lowercase letters for collection, dot as separator, variable name. E.g: `setvar:tx.foo_bar_variable`
+  * Capital letters for collection, colon as separator, variable name. E.g: `SecRule TX:foo_bar_variable`
+
+## Rules compliance with each Paranoia Level (PL)
+
+Rules in the CRS are organized in Paranoia Levels, which allows you to choose the desired level of rule checks.
+
+Please read file ```crs-setup.conf.example``` for introduction and a more detailed explanation of Paranoia Levels in the section `# -- [[ Paranoia Level Initialization ]]`.
+
+**PL0:**
+
+* Modsec installed, but almost no rules
+
+**PL1:**
+
+* Default level, keep in mind that most installations will normally use this one. 
+* If there is a complex memory consuming/evaluation rule it surely will be on upper levels, not this one
+* Normally we will use atomic checks in single rules
+* Confirmed matches only, all scores are allowed
+* No false positives / Low FP (Try to avoid adding rules with potential false positives!)
+* False negatives could happen
+
+**PL2:**
+
+* Chains usage are OK
+* Confirmed matches use score critical
+* Matches that cause false positives are limited to use score notice or warning
+* Low False positive rates
+* False negatives are not desirable
+
+**PL3:**
+
+* Chains usage with complex regex look arounds and macro expansions
+* Confirmed matches use score warning or critical
+* Matches that cause false positives are limited to use score notice
+* False positive rates increased but limited to multiple matches (not single string)
+* False negatives should be a very unlikely accident
+
+**PL4:**
+
+* Every item is inspected
+* Variable creations allowed to avoid engine limitations
+* Confirmed matches use score notice, warning or critical
+* Matches that cause false positives are limited to use score notice and warning
+* False positive rates increased (even on single string)
+* False negatives should not happen here
+* Check everything against RFC and white listed values for most popular elements
+
+
+## ID Numbering Scheme
+
+The CRS project used the numerical id rule namespace from 900,000 to 999,999 for the CRS rules as well as 9,000,000 to 9,999,999 for default CRS rule exclusion packages.
+
+Rules applying to the incoming request use the id range 900,000 to 949,999.
+Rules applying to the outgoing response use the id range 950,000 to 999,999.
+
+The rules are grouped by vulnerability class they address (SQLi, RCE, etc.) or functionality (initialization). These groups occupy blocks of thousands (e.g. SQLi: 942,000 - 942,999).
+The grouped rules are defined in files dedicated to a single group or functionality. The filename takes up the first three digits of the rule ids defined within the file (e.g. SQLi: REQUEST-942-APPLICATION-ATTACK-SQLI.conf).
+
+The individual rule files for the vulnerability classes are organized by the paranoia level of the rules. PL 1 is first, then PL 2 etc.
+
+The block from 9XX000 - 9XX099 is reserved for use by CRS helper functionality. There are no blocking or filtering rules in this block.
+
+Among the rules serving a CRS helper functionality are rules that skip rules depending on the paranoia level. These rules always use the following reserved rule ids: 9XX011-9XX018 with very few exceptions.
+
+The blocking or filter rules start with 9XX100 with a step width of 10. E.g. 9XX100, 9XX110, 9XX120 etc. The rule id does not correspond directly with the paranoia level of a rule. Given the size of a rule group and the organization by lower PL rules first, PL2 and above tend to have rule IDs with higher numbers.
+
+Within a rule file / block, there are sometimes smaller groups of rules that belong to together. They are closely linked and very often represent copies of the original rules with a stricter limit (alternatively, they can represent the same rule addressing a different target in a second rule where this was necessary). These are stricter siblings of the base rule. Stricter siblings usually share the first five digits of the rule ID and raise the rule ID by one. E.g. Base rule at 9XX160, stricter sibling at 9XX161.
+
+Stricter siblings often have a different paranoia level. This means that the base rule and the stricter sibling do not reside next to one another in the rule file. Instead they are ordered in their appropriate paranoia level and can be linked via the first digits of the rule id. It is a good practice to introduce stricter siblings together with the base rule in the comments of the base rule and to reference the base rule with the keyword stricter sibling in the comments of the stricter sibling. E.g. "... This is
+performed in two separate stricter siblings of this rule: 9XXXX1 and 9XXXX2", "This is a stricter sibling of rule 9XXXX0."
+
diff --git a/CONTRIBUTORS b/CONTRIBUTORS
diff --git a/CONTRIBUTORS.md b/CONTRIBUTORS.md
@@ -0,0 +1,48 @@
+## Project Lead:
+
+- [Chaim Sanders](https://github.com/csanders-git)
+
+## Core Developers:
+
+- [Christian Folini](https://github.com/dune73)
+- [Walter Hop](https://github.com/lifeforms)
+
+## Developers:
+
+- [Franziska Bühler](https://github.com/franbuehler)
+- [Christoph Hansen](https://github.com/emphazer)
+- [Victor Hora](https://github.com/victorhora)
+- [Federico G. Schwindt](https://github.com/fgsch)
+- [Manuel Spartan](https://github.com/spartantri)
+- [Felipe Zimmerle](https://github.com/zimmerle)
+- [Felipe Zipitría](https://github.com/fzipi)
+
+## Contributors:
+
+- [Zack Allen](https://github.com/zmallen)
+- [Ryan Barnett](https://github.com/rcbarnett)
+- [Jeremy Brown](https://github.com/jwbrown77)
+- [Jonathan Claudius](https://github.com/claudijd)
+- [Ashish Dixit](https://github.com/tundal45)
+- [FrozenSolid](https://github.com/frozenSolid)
+- [Aaron Haaf](https://github.com/Everspace)
+- [Michael Haas](https://github.com/MichaelHaas)
+- [jamuse](https://github.com/jamuse)
+- [Krzysztof Kotowicz](https://github.com/koto)
+- [Evgeny Marmalstein](https://github.com/shimshon70)
+- [Christian Mehlmauer](https://github.com/FireFart)
+- [Glyn Mooney](https://github.com/skidoosh)
+- [Robert Paprocki](https://github.com/p0pr0ck5)
+- [Christian Peron](https://github.com/csjperon)
+- [Elia Pinto](https://github.com/yersinia)
+- [Brian Rectanus](https://github.com/b1v1r)
+- Ofer Shezaf
+- Breno Silva
+- [Marc Stern](https://github.com/marcstern)
+- [Ben Williams](https://github.com/benwilliams)
+- [Greg Wroblewski](https://github.com/gwroblew)
+- [ygrek](https://github.com/ygrek)
+- [Zino](https://github.com/zinoe)
+- Josh Zlatin
+- [Zou Guangxian](https://github.com/zouguangxian)
+- [4ft35t](https://github.com/4ft35t)
diff --git a/KNOWN_BUGS b/KNOWN_BUGS
@@ -20,7 +20,8 @@ or the CRS mailinglist at
   with an error such as:
     Error parsing actions: Unknown action: \\
     Action 'configtest' failed.
-  This bug is known to plague RHEL 7 and Ubuntu 14.04 LTS users.
+  This bug is known to plague RHEL/Centos 7 below v7.4 or
+  httpd v2.4.6 release 67 and Ubuntu 14.04 LTS users.
   https://bz.apache.org/bugzilla/show_bug.cgi?id=55910
   We advise to upgrade your Apache version. If upgrading is not possible,
   we have provided a script in the util/join-multiline-rules directory

diff --git a/README.md b/README.md
@@ -1,4 +1,5 @@
-[![Join the chat at https://gitter.im/owasp-crs/Lobby](https://badges.gitter.im/Join%20Chat.svg)](https://gitter.im/owasp-crs/Lobby?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)![Travis build v3.1/dev](https://badges.herokuapp.com/travis/SpiderLabs/owasp-modsecurity-crs?branch=v3.1/dev&label=CRS%20v3.1/dev)![Travis build v3.0/dev](https://badges.herokuapp.com/travis/SpiderLabs/owasp-modsecurity-crs?branch=v3.0/dev&label=CRS%20v3.0/dev)![Travis build v3.0/master](https://badges.herokuapp.com/travis/SpiderLabs/owasp-modsecurity-crs?branch=v3.0/master&label=CRS%20v3.0/master)[![OWASP Flagship](https://img.shields.io/badge/owasp-flagship%20project-38a047.svg)](https://www.owasp.org/index.php/OWASP_Project_Inventory#tab=Flagship_Projects)
+[![Join the chat at https://gitter.im/owasp-crs/Lobby](https://badges.gitter.im/Join%20Chat.svg)](https://gitter.im/owasp-crs/Lobby?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)![Travis build v3.1/dev](https://badges.herokuapp.com/travis/SpiderLabs/owasp-modsecurity-crs?branch=v3.1/dev&label=CRS%20v3.1/dev)![Travis build v3.0/dev](https://badges.herokuapp.com/travis/SpiderLabs/owasp-modsecurity-crs?branch=v3.0/dev&label=CRS%20v3.0/dev)![Travis build v3.0/master](https://badges.herokuapp.com/travis/SpiderLabs/owasp-modsecurity-crs?branch=v3.0/master&label=CRS%20v3.0/master)
+[![OWASP Flagship](https://img.shields.io/badge/owasp-flagship%20project-38a047.svg)](https://www.owasp.org/index.php/OWASP_Project_Inventory#tab=Flagship_Projects)
 
 # OWASP ModSecurity Core Rule Set (CRS)
 
@@ -20,7 +21,7 @@ We strive to make the OWASP ModSecurity CRS accessible to a wide audience of beg
 
 ## License
 
-Copyright 2006-2018 Trustwave and contributors.
+Copyright (c) 2006-2018 Trustwave and contributors. All rights reserved.
 
 The OWASP ModSecurity Core Rule Set is distributed under Apache Software License (ASL) version 2. Please see the enclosed LICENSE file for full details.
 
diff --git a/crs-setup.conf.example b/crs-setup.conf.example
@@ -1,6 +1,6 @@
 # ------------------------------------------------------------------------
-# OWASP ModSecurity Core Rule Set ver.3.0.2
-# Copyright (c) 2006-2016 Trustwave and contributors. All rights reserved.
+# OWASP ModSecurity Core Rule Set ver.3.2.0
+# Copyright (c) 2006-2017 Trustwave and contributors. All rights reserved.
 #
 # The OWASP ModSecurity Core Rule Set is distributed under
 # Apache Software License (ASL) version 2
@@ -166,6 +166,10 @@ SecDefaultAction "phase:2,log,auditlog,pass"
 # example: [tag "paranoia-level/2"]. This allows you to deduct from the
 # audit log how the WAF behavior is affected by paranoia level.
 #
+# It is important to also look into the variable 
+# tx.enforce_bodyproc_urlencoded (Enforce Body Processor URLENCODED) 
+# defined below. Enabling it closes a possible bypass of CRS.
+#
 # Uncomment this rule to change the default:
 #
 #SecAction \
@@ -177,6 +181,30 @@ SecDefaultAction "phase:2,log,auditlog,pass"
 #   setvar:tx.paranoia_level=1"
 
 
+#
+# -- [[ Enforce Body Processor URLENCODED ]] -----------------------------------
+#
+# ModSecurity selects the body processor based on the Content-Type request
+# header. But clients are not always setting the Content-Type header for their
+# request body payloads. This will leave ModSecurity with limited vision into
+# the payload.  The variable tx.enforce_bodyproc_urlencoded lets you force the
+# URLENCODED body processor in these situations. This is off by default, as it
+# implies a change of the behaviour of ModSecurity beyond CRS (the body
+# processor applies to all rules, not only CRS) and because it may lead to
+# false positives already on paranoia level 1. However, enabling this variable
+# closes a possible bypass of CRS so it should be considered.
+#
+# Uncomment this rule to change the default:
+#
+#SecAction \
+#  "id:900010,\
+#   phase:1,\
+#   nolog,\
+#   pass,\
+#   t:none,\
+#   setvar:tx.enforce_bodyproc_urlencoded=1"
+
+
 #
 # -- [[ Anomaly Mode Severity Levels ]] ----------------------------------------
 #
@@ -288,7 +316,7 @@ SecDefaultAction "phase:2,log,auditlog,pass"
 # It is recommended if you run multiple web applications on your site to limit
 # the effects of the exclusion to only the path where the excluded webapp
 # resides using a rule similar to the following example:
-# SecRule REQUEST_URI "@beginsWith /wordpress/" setvar:crs_exclusions_wordpress=1
+# SecRule REQUEST_URI "@beginsWith /wordpress/" setvar:tx.crs_exclusions_wordpress=1
 
 #
 # Modify and uncomment this rule to select which application:
@@ -300,7 +328,10 @@ SecDefaultAction "phase:2,log,auditlog,pass"
 #  pass,\
 #  t:none,\
 #  setvar:tx.crs_exclusions_drupal=1,\
-#  setvar:tx.crs_exclusions_wordpress=1"
+#  setvar:tx.crs_exclusions_wordpress=1,\
+#  setvar:tx.crs_exclusions_nextcloud=1,\
+#  setvar:tx.crs_exclusions_dokuwik=1,\
+#  setvar:tx.crs_exclusions_cpanel=1"
 
 #
 # -- [[ HTTP Policy Settings ]] ------------------------------------------------
@@ -645,7 +676,7 @@ SecDefaultAction "phase:2,log,auditlog,pass"
 #
 # Blocking based on reputation is permanent in the CRS. Unlike other rules,
 # which look at the indvidual request, the blocking of IPs is based on
-# a persistent record in the IP collection, which remains active for a 
+# a persistent record in the IP collection, which remains active for a
 # certain amount of time.
 #
 # There are two ways an individual client can become flagged for blocking: