diff --git a/static/images/logo.png b/assets/logo.png similarity index 100% rename from static/images/logo.png rename to assets/logo.png diff --git a/config/_default/config.toml b/config/_default/config.toml index cd7a24ea..a1db59b5 100644 --- a/config/_default/config.toml +++ b/config/_default/config.toml @@ -16,8 +16,12 @@ home = ['html', 'rss', 'print'] author.name = "CRS project" # Shows a checkmark for visited pages on the menu showVisitedLinks = true + # Logo image displayed in the sidebar + logo = { direction = 'column' } + # Text below the logo in the sidebar + linkTitle = '' # Disable search function. It will hide search bar - search.disable=false + search.disable = false # Javascript and CSS cache are automatically busted when new version of site is generated. # Set this to true to disable this behavior (some proxies don't handle well this optimization) disableAssetsBusting = false diff --git a/content/1-getting-started/1-1-crs-installation.md b/content/1-getting-started/1-1-crs-installation.md index 0193fe46..66b62e34 100644 --- a/content/1-getting-started/1-1-crs-installation.md +++ b/content/1-getting-started/1-1-crs-installation.md @@ -18,7 +18,7 @@ For *production* environments, it is recommended to use the latest release, whic ### Verifying Releases -{{% notice note %}} +{{% notice style="note" icon="key" %}} Releases are signed using the CRS project's [GPG key](https://coreruleset.org/security.asc) (fingerprint: 3600 6F0E 0BA1 6783 2158 8211 38EE ACA1 AB8A 6E72). Releases can be verified using GPG/PGP compatible tooling. To retrieve the CRS project's public key from public key servers using `gpg`, execute: `gpg --keyserver pgp.mit.edu --recv 0x38EEACA1AB8A6E72` (this ID should be equal to the last sixteen hex characters in the fingerprint). @@ -95,7 +95,7 @@ Other aspects of ModSecurity, particularly engine-specific parameters, are contr In many scenarios, the default example CRS configuration will be a good enough starting point. It is, however, a good idea to take the time to look through the example configuration file *before* deploying it to make sure it's right for a given environment. -{{% notice warning %}} +{{% notice style="warning" icon="shield-halved" %}} In particular, _Response_ rules are enabled by default. You must be aware that you may be vulnerable to RFDoS attacks, depending on the responses your application is sending back to the client. You could be vulnerable, if your responses from your application can contain user input. If an attacker can submit user input that is returned as part of a response, the attacker can craft the input in such a way that the response rules of the WAF will block responses containing that input _for all_ clients. For example, a blog post might no longer be accessible because of the contents of a comment on the post. See [this blog post](https://blog.sicuranext.com/response-filter-denial-of-service-a-new-way-to-shutdown-a-website/) about the problems you could face. There is an [experimental scanner](https://github.com/edoardottt/RFDos-Scanner) that uses [nuclei](https://github.com/projectdiscovery/nuclei?tab=readme-ov-file#install-nuclei) to find out if are affected. So if you are unsure, first test your application before enabling the response rules, or risk accidentally blocking some valid responses. diff --git a/content/1-getting-started/1-2-extended_install.md b/content/1-getting-started/1-2-extended_install.md index 4507c4f1..d025ba6d 100644 --- a/content/1-getting-started/1-2-extended_install.md +++ b/content/1-getting-started/1-2-extended_install.md @@ -39,7 +39,7 @@ ModSecurity is frequently pre-packaged and is available from several major Linux For Windows, get the latest MSI package from https://github.com/owasp-modsecurity/ModSecurity/releases. -{{% notice warning %}} +{{% notice style="warning" icon="box-open" %}} **Distributions might not update their ModSecurity releases frequently.** As a result, it is quite likely that a distribution's version of ModSecurity may be missing important features or **may even contain security vulnerabilities**. Additionally, depending on the package and package manager used, the ModSecurity configuration will be laid out slightly differently. @@ -117,7 +117,7 @@ For *production* environments, it is recommended to use the latest release, whic ### Verifying Releases -{{% notice note %}} +{{% notice style="note" icon="key" %}} Releases are signed using the CRS project's [GPG key](https://coreruleset.org/security.asc) (fingerprint: 3600 6F0E 0BA1 6783 2158 8211 38EE ACA1 AB8A 6E72). Releases can be verified using GPG/PGP compatible tooling. To retrieve the CRS project's public key from public key servers using `gpg`, execute: `gpg --keyserver pgp.mit.edu --recv 0x38EEACA1AB8A6E72` (this ID should be equal to the last sixteen hex characters in the fingerprint). @@ -233,6 +233,6 @@ Nginx will include files from the Nginx configuration directory (`/etc/nginx` or Include {{< param crs_install_dir >}}/plugins/*-after.conf ``` -{{% notice note %}} +{{% notice style="note" icon="puzzle-piece" %}} You will also need to include the plugins you want along with your CRS installation. {{% /notice %}} diff --git a/content/1-getting-started/1-4-engine_integration_options.md b/content/1-getting-started/1-4-engine_integration_options.md index 756224d8..43efd687 100644 --- a/content/1-getting-started/1-4-engine_integration_options.md +++ b/content/1-getting-started/1-4-engine_integration_options.md @@ -88,7 +88,7 @@ Most big cloud providers and CDNs provide a CRS offering. While originally these The CRS project has some insight into some of these platforms and is in touch with most of these providers. The *exact specifics* are not really known, however, but what *is* known is that almost all of these integrators compromised and provide a *subset* of CRS rules and a *subset* of features, in the interests of ease of integration and operation. -{{% notice info %}} +{{% notice style="info" icon="cloud" %}} The [CRS Status page project](https://github.com/coreruleset/coreruleset/wiki/DevRetreat21StatusPage) will be testing cloud and CDN offerings. As part of this effort, the CRS project will be documenting the results and even publishing code on how to quickly get started using CRS in CDN/cloud providers. This status page project is in development as of spring 2022. {{% /notice %}} @@ -96,7 +96,7 @@ A selection of these platforms are listed below, along with links to get more in ### AWS WAF -{{% notice note %}} +{{% notice style="note" icon="cloud" %}} AWS provides a rule set called the ["Core rule set (CRS) managed rule group"](https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-baseline.html) which "…provides protection against… commonly occurring vulnerabilities described in OWASP publications such as OWASP Top 10." The CRS project does **not** believe that the AWS WAF "core rule set" is based on or related to OWASP CRS. diff --git a/content/2-how-crs-works/2-1-anomaly_scoring/index.md b/content/2-how-crs-works/2-1-anomaly_scoring/index.md index f9978bdb..3ee0a0c9 100644 --- a/content/2-how-crs-works/2-1-anomaly_scoring/index.md +++ b/content/2-how-crs-works/2-1-anomaly_scoring/index.md @@ -89,7 +89,7 @@ Most detected inbound threats carry an anomaly score of 5 (by default), while sm Rule coverage should be taken into account when setting anomaly score thresholds. Different CRS rule categories feature different numbers of rules. SQL injection, for example, is covered by more than 50 rules. As a result, a real world SQLi attack can easily gain an anomaly score of 15, 20, or even more. On the other hand, a rare protocol attack might only be covered by a single, specific rule. If such an attack only causes the one specific rule to match then it will only gain an anomaly score of 5. If the inbound anomaly score threshold is set to anything higher than 5 then attacks like the one described will not be stopped. **As such, a CRS installation should aim for an inbound anomaly score threshold of 5.** -{{% notice warning %}} +{{% notice style="warning" %}} Increasing the anomaly score threshold above the defaults (5 for requests, 4 for responses), will allow a substantial number of attacks to bypass CRS and will impede the ability of critical rules to function correctly, such as LFI, RFI, RCE, and data-exfiltration rules. The anomaly score threshold should only ever be increased temporarily during false-positive tuning. Some WAF vendors (such as Cloudflare) set the default anomaly score well above our defaults. This is not a proper implementation of CRS, and will result in bypasses. @@ -198,7 +198,7 @@ Early blocking makes this possible by inserting **two additional rounds of block More information about processing phases can be found in the [processing phases section](https://github.com/owasp-modsecurity/ModSecurity/wiki/Reference-Manual-(v2.x)#processing-phases) of the ModSecurity Reference Manual. {{% /notice %}} -{{% notice warning %}} +{{% notice style="warning" icon="eye-slash" %}} The early blocking option has a major drawback to be aware of: **it can cause potential alerts to be hidden**. If a transaction is blocked early then its body is not inspected. For example, if a transaction is blocked early at the end of phase 1 (the request headers phase) then the body of the request is never inspected. If the early blocking option is *not* enabled, it's possible that such a transaction would proceed to cause phase 2 rules to match. Early blocking hides these potential alerts. The same applies to responses that trigger an early block: it's possible that some phase 4 rules would match if early blocking were not enabled. @@ -206,7 +206,7 @@ If a transaction is blocked early then its body is not inspected. For example, i Using the early blocking option results in having less information to work with, due to fewer rules being executed. This may mean that the full picture is not present in log files when looking back at attacks and malicious traffic. It can also be a problem when dealing with false positives: tuning away a false positive in phase 1 will allow the same request to proceed to the next phase the next time it's issued (instead of being blocked at the end of phase 1). The problem is that now, with the request making it past phase 1, more, previously "hidden" false positives may appear in phase 2. {{% /notice %}} -{{% notice warning %}} +{{% notice style="warning" icon="bolt" %}} If early blocking is not enabled, there's a chance that the web server will interfere with the handling of a request between phases 1 and 2. Take the example where the Apache web server issues a redirect to a new location. With a request that violates CRS rules in phase 1, this may mean that the request has a higher anomaly score than the defined threshold but it gets redirected away before blocking evaluation happens. {{% /notice %}} diff --git a/content/2-how-crs-works/2-2-paranoia_levels.md b/content/2-how-crs-works/2-2-paranoia_levels.md index dbf747fa..7127852a 100644 --- a/content/2-how-crs-works/2-2-paranoia_levels.md +++ b/content/2-how-crs-works/2-2-paranoia_levels.md @@ -20,7 +20,7 @@ A higher paranoia level makes it harder for an attacker to go undetected. Yet th When false positives occur they need to be tuned away. In ModSecurity parlance: rule exclusions need to be written. A rule exclusion is a rule that disables another rule, either disabled completely or disabled partially only for certain parameters or for certain URIs. This means **the rule set remains intact** yet the CRS installation is no longer affected by the false positives. -{{% notice note %}} +{{% notice style="note" icon="sliders" %}} Depending on the complexity of the service (web application) in question and on the paranoia level, the process of writing rule exclusions can be a *substantial* amount of work. This page won't explore the problem of handling false positives further: for more information on this topic, see the appropriate chapter or refer to the [tutorials at netnea.com](https://www.netnea.com/cms/apache-tutorials/). diff --git a/content/2-how-crs-works/2-3-false-positives-and-tuning.md b/content/2-how-crs-works/2-3-false-positives-and-tuning.md index c306e699..5be76dbb 100644 --- a/content/2-how-crs-works/2-3-false-positives-and-tuning.md +++ b/content/2-how-crs-works/2-3-false-positives-and-tuning.md @@ -44,7 +44,7 @@ This example log entry provides lots of information about the rule match. Some o `[data "Matched Data:

found within ARGS:wp_post:

welcome to my blog

"]` -{{% notice tip %}} +{{% notice style="tip" icon="puzzle-piece" %}} CRS ships with a prebuilt *rule exclusion package* for WordPress, as well as other popular web applications, to help prevent false positives. See the section on [rule exclusion packages]({{% ref "#rule-exclusion-packages" %}}) for details. {{% /notice %}} @@ -68,7 +68,7 @@ When working in strict blocking mode, false positives can cause legitimate user ### Directly Modifying CRS Rules -{{% notice warning %}} +{{% notice style="warning" icon="ban" %}} Making direct modifications to CRS rule files is a bad idea and is strongly discouraged. {{% /notice %}} @@ -118,11 +118,11 @@ The different rule exclusion types and methods are summarized in the table below *\*\*Can also exclude ranges of rules (not currently supported in ModSecurity v3).* -{{% notice tip %}} +{{% notice style="tip" icon="file-arrow-down" %}} This table is available as a well presented, downloadable [Rule Exclusion Cheatsheet](https://www.netnea.com/cms/rule-exclusion-cheatsheet-download) from Christian Folini. {{% /notice %}} -{{% notice note %}} +{{% notice style="note" icon="link" %}} When using `SecRuleUpdateTargetById` and `ctl:ruleRemoveTargetById` with *chained rules*, target exclusions are only applied to the first rule in the chain. You can't exclude targets from other rules in the chain, depending on how the rule is written, you may have to remove the entire rule using `SecRuleRemoveById` or `ctl:ruleRemoveById`. This is a current limitation of the SecLang configuration language. {{% /notice %}} @@ -206,7 +206,7 @@ The 'ctl' action for writing runtime rule exclusions does **not** support any us Runtime rule exclusions *modify* rules in some way. If a rule is to be modified then this should occur before the rule is executed (modifying a rule *after* it has been executed has no effect). As such, this type of rule exclusion must appear *before* the CRS and all its rules have been included. -{{% notice tip %}} +{{% notice style="tip" icon="folder-open" %}} CRS ships with the files `REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example` and `RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf.example`. After dropping the ".example" suffix, these files can be used to house "BEFORE-CRS" (i.e. runtime) and "AFTER-CRS" (i.e. configure-time) rule exclusions in their correct places relative to the CRS rules. These files also contain example rule exclusions to copy and learn from. {{% /notice %}} @@ -338,7 +338,7 @@ SecRule REQUEST_URI "@beginsWith /webapp/login.html" \ ctl:ruleRemoveTargetByTag=attack-sqli;REQUEST_COOKIES:uid" ``` -{{% notice tip %}} +{{% notice style="tip" icon="code-branch" %}} It's possible to write a conditional rule exclusion that tests something other than just the request URI. Conditions can be built which test, for example, the source IP address, HTTP request method, HTTP headers, and even the day of the week. Multiple conditions can also be chained together to create a logical AND by using ModSecurity's [chain](https://github.com/owasp-modsecurity/ModSecurity/wiki/Reference-Manual-(v2.x)#chain) action. This allows for creating powerful rule logic like "for transactions that are from source IP address 10.0.0.1 AND that are for location '/login.html', exclude the query string parameter 'user_id' from rule 920280". Extremely granular and specific rule exclusions can be written, in this way. @@ -354,7 +354,7 @@ If using a native CRS installation, rule exclusion packages can be enabled in th If running CRS where it has been integrated into a commercial product or CDN then support varies. Some vendors expose rule exclusion packages in the GUI while other vendors require custom rules to be written which set the necessary variables. Unfortunately, there are also vendors that don't allow rule exclusion packages to be used at all. -{{% notice tip %}} +{{% notice style="tip" icon="location-dot" %}} If running multiple web applications, it is highly recommended to enable a rule exclusion package only for the location where the corresponding web application resides. For example, to enable the WordPress rule exclusion package only for locations under '/wordpress', a rule like the following could be used: ```apache diff --git a/content/2-how-crs-works/2-4-sampling_mode.md b/content/2-how-crs-works/2-4-sampling_mode.md index 40906380..b04f4d25 100644 --- a/content/2-how-crs-works/2-4-sampling_mode.md +++ b/content/2-how-crs-works/2-4-sampling_mode.md @@ -49,7 +49,7 @@ In the latter case, where sampling mode is triggered and CRS is bypassed, an ale Here, CRS reports that it disabled the rule engine because the random number was above the sampling limit. The sampling percentage is set at the desired level, the rule set generates a random integer in the range 0-99 per-transaction, and if it’s *above* the sampling percentage then the WAF is disabled for the remainder of the transaction. -{{% notice warning %}} +{{% notice style="warning" icon="percent" %}} As sampling mode works by selectively disabling the ModSecurity WAF engine, if *other rule sets* are installed then they will be bypassed too. {{% /notice %}} diff --git a/content/3-about-rules/creating.md b/content/3-about-rules/creating.md index 020e3526..563749d0 100644 --- a/content/3-about-rules/creating.md +++ b/content/3-about-rules/creating.md @@ -5,7 +5,7 @@ disableToc: false chapter: false --- -{{% notice note %}} +{{% notice style="note" icon="clock-rotate-left" %}} **The content on this page may be outdated.** We are currently in the process of rewriting all of our documentation: please bear with us while we update our older content. {{% /notice %}} diff --git a/content/3-about-rules/metadata.md b/content/3-about-rules/metadata.md index 436eadf7..8affc9ed 100644 --- a/content/3-about-rules/metadata.md +++ b/content/3-about-rules/metadata.md @@ -5,7 +5,7 @@ disableToc: false chapter: false --- -{{% notice note %}} +{{% notice style="note" icon="clock-rotate-left" %}} **The content on this page may be outdated.** We are currently in the process of rewriting all of our documentation: please bear with us while we update our older content. {{% /notice %}} diff --git a/content/3-about-rules/ruleid.md b/content/3-about-rules/ruleid.md index 91b7df77..e88761ef 100644 --- a/content/3-about-rules/ruleid.md +++ b/content/3-about-rules/ruleid.md @@ -5,7 +5,7 @@ disableToc: false chapter: false --- -{{% notice note %}} +{{% notice style="note" icon="clock-rotate-left" %}} **The content on this page may be outdated.** We are currently in the process of rewriting all of our documentation: please bear with us while we update our older content. {{% /notice %}} diff --git a/content/4-about-plugins/4-1-plugins.md b/content/4-about-plugins/4-1-plugins.md index 73198f95..ab250809 100644 --- a/content/4-about-plugins/4-1-plugins.md +++ b/content/4-about-plugins/4-1-plugins.md @@ -8,7 +8,7 @@ aliases: ["../concepts/plugins"] > The CRS plugin mechanism allows the rule set to be extended in specific, experimental, or unusual ways, as this page explains. -{{% notice note %}} +{{% notice style="note" icon="puzzle-piece" %}} Plugins are not part of the CRS 3.3.x release line. They are released officially with CRS 4.0. In the meantime, plugins _can_ be used with one of the stable releases by following the instructions presented below. {{% /notice %}} @@ -73,7 +73,7 @@ crs/plugins/empty-after.conf These empty rule files ensure that the web server does not fail when `Include`-ing `*.conf` if there are no plugin files present. -{{% notice info %}} +{{% notice style="info" icon="server" %}} Apache supports the `IncludeOptional` directive, but that is not available on *all* web servers, so `Include` is used here in the interests of having consistent and simple documentation. {{% /notice %}} diff --git a/content/5-advanced-topics/5-1-self-contained-mode.md b/content/5-advanced-topics/5-1-self-contained-mode.md index 4fe1ecf9..2a0630db 100644 --- a/content/5-advanced-topics/5-1-self-contained-mode.md +++ b/content/5-advanced-topics/5-1-self-contained-mode.md @@ -18,7 +18,7 @@ crs-setup.conf file usees the pass action: SecDefaultAction "phase:2,pass,log" ``` -{{% notice warning %}} +{{% notice style="warning" icon="rotate-left" %}} From version 3.0 onwards, Anomaly Scoring is the default detection mode. Traditional detection mode is discouraged. {{% /notice %}} diff --git a/content/5-advanced-topics/5-3-kubernetes-ingress-controller.md b/content/5-advanced-topics/5-3-kubernetes-ingress-controller.md index a278c6c2..1716bb81 100644 --- a/content/5-advanced-topics/5-3-kubernetes-ingress-controller.md +++ b/content/5-advanced-topics/5-3-kubernetes-ingress-controller.md @@ -22,7 +22,7 @@ Refer to the [upstream installation guide](https://github.com/kubernetes/ingress The upstream project provides [many examples](https://github.com/kubernetes/ingress-nginx/tree/main/docs/examples) of how to configure the controller. These are a good starting point. -{{% notice info %}} +{{% notice style="info" icon="dharmachakra" %}} All of the configuration is done via the ConfigMap. All options for ModSecurity and CRS can be found in the [annotations list](https://github.com/kubernetes/ingress-nginx/blob/main/docs/user-guide/nginx-configuration/annotations.md#modsecurity). {{% /notice %}} diff --git a/content/6-development/6-2-crs-toolchain.md b/content/6-development/6-2-crs-toolchain.md index 0150f2e4..4c49a633 100644 --- a/content/6-development/6-2-crs-toolchain.md +++ b/content/6-development/6-2-crs-toolchain.md @@ -36,7 +36,7 @@ crs-toolchain-2.7.0_amd64.deb: OK ### Method 2: Install with Go -{{% notice note %}} +{{% notice style="note" icon="code" %}} This method requires Go 1.19 or higher installed on your system. {{% /notice %}} @@ -156,7 +156,7 @@ crs-toolchain --help # Show help for a specific command - Removed mage build tool dependency - Restricted evasion modifiers usage -{{% notice tip %}} +{{% notice style="tip" icon="code-branch" %}} To see the full release history and detailed changelogs, visit the [releases page](https://github.com/coreruleset/crs-toolchain/releases) on GitHub. {{% /notice %}} @@ -244,7 +244,7 @@ The output will show: Updates rule files directly with newly generated expressions. This command modifies the actual CRS rule configuration files. -{{% notice warning %}} +{{% notice style="warning" icon="file-pen" %}} This command modifies files in place. Make sure you have committed your changes or have a backup before running update commands. {{% /notice %}} @@ -418,7 +418,7 @@ crs-toolchain completion fish > ~/.config/fish/completions/crs-toolchain.fish crs-toolchain completion powershell | Out-String | Invoke-Expression ``` -{{% notice tip %}} +{{% notice style="tip" icon="terminal" %}} After installing shell completion, you may need to restart your shell or source your shell configuration file for the changes to take effect. {{% /notice %}} diff --git a/content/6-development/6-4-using-the-crs-sandbox.md b/content/6-development/6-4-using-the-crs-sandbox.md index 232d038e..2f70409a 100644 --- a/content/6-development/6-4-using-the-crs-sandbox.md +++ b/content/6-development/6-4-using-the-crs-sandbox.md @@ -6,6 +6,10 @@ chapter: false aliases: ["../development/sandbox"] --- +{{% notice style="info" icon="flask" %}} +The CRS Sandbox is a shared public resource. Please review the [CRS Sandbox Security Policy]({{% ref "6-7-crs-sandbox-security-policy.md" %}}) before use. +{{% /notice %}} + ## Introducing the CRS Sandbox We have set up a public **CRS Sandbox** which you can use to send attacks at the CRS. You can choose between various WAF engines and CRS versions. The sandbox parses audit logs and returns our detections in an easy and useful format. @@ -65,7 +69,7 @@ x-backend: apache-3.3.2 It’s useful to know that you can tweak the sandbox in various ways. If you don’t send any `X-` headers, the sandbox will use the following defaults. - The default backend is _Apache 2 with ModSecurity 2.9_. -- The default CRS version is the _latest release version_, currently 3.3.2. +- The default CRS version is the _latest release version_, currently 4.22.0. - The default Paranoia Level is 1, which is the least strict setting. - By default, the response is the full audit log from the WAF, which is verbose and includes unnecessary information, hence why `X-Format-Output: txt-matched-rules` is useful. @@ -73,7 +77,7 @@ It’s useful to know that you can tweak the sandbox in various ways. If you don Let’s say you want to try your payload on different WAF engines or CRS versions, or like the output in a different format for automated usage. You can do this by adding the following HTTP headers to your request: -- `x-crs-version`: will pick another CRS version. Available values are `3.3.2` (default), `3.2.1`, `nightly` (which has the latest changes which are not released) and `3.4.0-dev-log4j` (which contains an experimental rule against Log4j attacks). +- `x-crs-version`: will pick another CRS version. Available values are `4.22.0` (default) and `3.3.8`. - `x-crs-paranoia-level`: will run CRS in a given paranoia level. Available values are `1` (default), `2`, `3`, `4`. - `x-crs-mode`: can be changed to return the http status code from the backend WAF. Default value is blocking (`On`), and can be changed using `detection` (will set engine to `DetectionOnly`). Values are case insensitive. - `x-crs-inbound-anomaly-score-threshold`: defines the inbound anomaly score threshold. Valid values are any integer > 0, with `5` being the CRS default. ⚠️ Anything different than a positive integer will be taken as 0, so it will be ignored. This only makes sense if `blocking` mode is enabled (the default now). @@ -81,7 +85,6 @@ Let’s say you want to try your payload on different WAF engines or CRS version - `x-backend` allows you to select the specific backend web server - `apache` (default) will send the request to **Apache 2 + ModSecurity 2.9**. - `nginx` will send the request to **Nginx + ModSecurity 3**. - - `coraza-caddy` will send the request to **Caddy + Coraza WAF**. - `x-format-output` formats the response to your use-case (human or automation). Available values are: - omitted/default: the WAF’s audit log is returned unmodified as JSON - `txt-matched-rules`: human-readable list of CRS rule matches, one rule per line @@ -91,7 +94,9 @@ Let’s say you want to try your payload on different WAF engines or CRS version The header names are case-insensitive. -Tip: if you work with JSON output (either unmodified or matched rules), `jq` is a useful tool to work with the output, for example you can add `| jq .` to get a pretty-printed JSON, or use `jq` to filter and modify the output. +{{% notice style="tip" icon="terminal" %}} +If you work with JSON output (either unmodified or matched rules), `jq` is a useful tool to work with the output, for example you can add `| jq .` to get a pretty-printed JSON, or use `jq` to filter and modify the output. +{{% /notice %}} ### Advanced examples @@ -148,11 +153,15 @@ CRS therefore detects this payload starting with paranoia level 1. - Please do not send more than 10 requests per second. - We will try to scale in response to demand. +## Data and privacy + +All requests sent to the sandbox are logged and processed by the sandbox infrastructure. **Do not send real personal data, credentials, API keys, or any sensitive information** in your requests. By using the sandbox, you acknowledge that submitted request content may be retained and analyzed by the OWASP CRS Team for the purpose of improving CRS rules and sandbox infrastructure. See the [CRS Sandbox Security Policy]({{% ref "6-7-crs-sandbox-security-policy.md" %}}) for full details. + ## Architecture The sandbox consists of various parts. The frontend that receives the requests runs on Openresty. It handles the incoming request, chooses and configures the backend running CRS, proxies the request to the backend, and waits for the response. Then it parses the WAF audit log and sends the matched rules back in the format chosen by the user. -There is a backend container for every engine and version. For instance, one Apache with CRS 3.2.2, one with CRS 3.2.1, et cetera... These are normal webserver installations with a WAF and the CRS. +There is a backend container for every engine and version. For instance, one Apache with CRS 4.22.0, one with CRS 3.3.8, et cetera... These are normal webserver installations with a WAF and the CRS. The backend writes their JSON logs to a volume to be read by a collector script and sent to S3 bucket and Elasticsearch. diff --git a/content/6-development/6-7-crs-sandbox-security-policy.md b/content/6-development/6-7-crs-sandbox-security-policy.md new file mode 100644 index 00000000..90ce9fc6 --- /dev/null +++ b/content/6-development/6-7-crs-sandbox-security-policy.md @@ -0,0 +1,156 @@ +--- +author: fzipi +date: '2026-02-18T22:11:21+02:00' +title: CRS Sandbox Security Policy +url: /crs-sandbox-policy +noindex: true +--- + +**Document Version:** 1.0 +**Last Updated:** 2026-02-19 +**Maintained by:** OWASP CRS Team + +--- + +## 1. Overview + +The OWASP CRS Sandbox (`https://sandbox.coreruleset.org/`) is a public, shared testing environment that allows users to evaluate CRS detection capabilities against real payloads — without requiring a local WAF installation. Because it is publicly accessible and shared across all users, responsible usage is essential to ensure availability, integrity, and fair access for everyone. + +This policy applies to **all users** of the CRS Sandbox, including security researchers, integrators, administrators, exploit developers, and CRS rule writers. + +For usage instructions, available options, and examples, see [Using the CRS Sandbox]({{% ref "6-4-using-the-crs-sandbox.md" %}}). + +--- + +## 2. Intended Use + +The sandbox is provided for the following **legitimate purposes**: + +- Testing whether a known payload or CVE is detected by a specific CRS version or WAF engine. +- Evaluating CRS detection behavior during urgent security events (e.g., Log4Shell, Spring4Shell). +- Validating new or modified CRS rules during development and review. +- Research and publishing: generating detection evidence for vulnerability disclosures or security publications. +- Integration testing: verifying CRS behavior across different backends and CRS versions. + +--- + +## 3. Acceptable Use + +Users **may**: + +- Send HTTP requests containing attack payloads representative of real-world exploits. +- Use any HTTP method, header manipulation, or request body encoding to test detection. +- Automate testing workflows within the rate limit specified in Section 5. +- Use the `X-Unique-Id` response header to reference a specific request when reporting issues. +- Select any available backend engine and CRS version for comparative testing. +- Adjust paranoia level and anomaly score thresholds for evaluation purposes. + +--- + +## 4. Prohibited Use + +Users **must not**: + +- Use the sandbox as a **proxy or relay** to attack third-party systems. +- Attempt to **compromise the sandbox infrastructure** itself (e.g., exploiting the OpenResty frontend, backend containers, or supporting services). +- Deliberately trigger **ReDoS (Regular Expression Denial of Service)** conditions to degrade performance for other users. If a payload causes a timeout (HTTP 502), discontinue testing with that payload and report it as a potential ReDoS via a GitHub issue. +- Send **malformed HTTP requests** that are designed to exploit the frontend server rather than the WAF/CRS layer. Requests rejected by the frontend with HTTP 400 are not processed by CRS and provide no valid test results. +- Use the sandbox for **sustained load testing or stress testing** beyond the rate limits defined in Section 5. +- Attempt to **exfiltrate logs, audit data, or internal metadata** from the sandbox infrastructure. +- Use the sandbox for any activity that violates applicable **local, national, or international laws**. + +--- + +## 5. Rate Limiting + +To ensure fair access and availability for all users: + +- **Do not send more than 10 requests per second.** +- Automated scripts and pipelines must implement appropriate throttling. +- Excessive usage may result in temporary blocking of the originating IP address without prior notice. + +The OWASP CRS Team will attempt to scale capacity in response to increased demand, but cannot guarantee availability under excessive load. + +--- + +## 6. Data and Privacy + +- All requests sent to the sandbox are **logged and processed** by the sandbox infrastructure. +- Logs are written to an S3 bucket and an Elasticsearch cluster, and reviewed via Kibana by the OWASP CRS Team. +- **Do not send real personal data, credentials, API keys, or any sensitive information** in your requests. +- User-Agent strings and geolocation data are extracted from logs for operational analytics. +- By using the sandbox, you acknowledge that submitted request content may be retained and analyzed by the OWASP CRS Team for the purpose of improving CRS rules and sandbox infrastructure. + +--- + +## 7. Responsible Disclosure + +If you discover a **vulnerability in the sandbox infrastructure itself**, please do **not** attempt to exploit it and do **not** disclose it publicly. Instead, send a private email to `security@coreruleset.org` with: + +1. A clear description of the vulnerability and its potential impact. +2. Steps to reproduce, including any relevant request details. +3. The `X-Unique-Id` response header value from your request, if available. + +Please allow reasonable time for the team to assess and remediate before any public disclosure. + +The OWASP CRS Team will respond as quickly as possible. + +--- + +## 8. Known Limitations + +Users should be aware of the following sandbox behaviors to avoid misinterpreting results: + +| Issue | Cause | Symptom | +|---|---|---| +| Malformed HTTP requests not scanned by CRS | OpenResty or backend server rejects the request before CRS processes it | HTTP 400 response | +| ReDoS causing request failure | A payload triggers catastrophic backtracking in a regex | HTTP 502 after long delay | +| Default backend/version | Requests without `X-` headers use Apache 2 + ModSecurity 2.9 and the latest CRS release | Unexpected detection results when comparing engines | +| Detection-only mode | When `x-crs-mode: detection` is set, the WAF does not block; this affects score threshold behavior | No blocking even above threshold | + +--- + +## 9. Sandbox Detection Output Is Not a Vulnerability Report + +The CRS Sandbox is **intentionally designed to detect attacks and report matched rules**. Its output — including rule IDs, anomaly scores, and matched patterns — is publicly documented and expected behavior, not evidence of a vulnerability. + +We periodically receive reports claiming a vulnerability was found in the sandbox, accompanied by `txt-matched-rules` output showing that a payload was detected. To be unambiguous: **a payload being detected by the sandbox is the sandbox working correctly**. This is not a security finding. + +A valid security report for the CRS Sandbox would involve one of the following: + +- A payload that **bypasses** CRS detection when it should be caught (a false negative in a specific CRS version or engine). +- A vulnerability in the **sandbox infrastructure itself** (e.g., a flaw in the OpenResty frontend, backend containers, or supporting services). +- A **ReDoS condition** triggered by a specific payload that causes backend instability. + +Reports that consist solely of sandbox detection output, WAF audit logs, or anomaly scores generated through normal sandbox usage will be closed without further response. + +--- + +## 10. No Bug Bounty Program + +The OWASP CRS project is a volunteer-driven, open-source initiative. **We do not operate a bug bounty program and we do not offer monetary rewards** of any kind for vulnerability reports, security research, or any other contributions. + +If you submit a report and receive a thank-you from the team, please understand that this is an acknowledgment of your effort and nothing more — it does not imply eligibility for compensation. + +We are grateful for genuine contributions to CRS security, and we recognize meaningful work through community credit, changelog attribution, and public acknowledgment where appropriate. + +--- + +## 11. Questions, Feedback, and Support + +For questions, bugs, or feature suggestions related to the CRS Sandbox: + +- Open a GitHub issue: `https://github.com/coreruleset/coreruleset/issues` +- Tag the issue appropriately (e.g., `sandbox`, `bug`, `enhancement`). + +The OWASP CRS Team reviews issues regularly and will respond as resources allow. + +--- + +## 12. Policy Updates + +This policy may be updated at any time. Significant changes will be announced via the OWASP CRS GitHub repository. Continued use of the sandbox constitutes acceptance of the current policy. + +--- + +*This policy is maintained by the OWASP CRS Team. The CRS Sandbox is a community resource — please use it responsibly.* diff --git a/content/7-known-issues/_index.md b/content/7-known-issues/_index.md index 4f0167c5..4ff9aca6 100644 --- a/content/7-known-issues/_index.md +++ b/content/7-known-issues/_index.md @@ -45,16 +45,15 @@ aliases: ["../operation/known_issues"] Action 'configtest' failed.` ``` - 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. (The original bug report can be found [here](https://bz.apache.org/bugzilla/show_bug.cgi?id=55910)). - - It is advisable to upgrade an affected Apache version. If upgrading is not possible, the CRS project provides a script in the `util/join-multiline-rules` directory which converts the rules into a format that works around the bug. This script must be re-run whenever the CRS rules are modified or updated. - -- As of CRS version 3.0.1, support has been added for the `application/soap+xml` MIME type by default, as specified in RFC 3902. **OF IMPORTANCE:** application/soap+xml is indicative that XML will be provided. In accordance with this, ModSecurity's XML request body processor should also be configured to support this MIME type. Within the ModSecurity project, [commit 5e4e2af](https://github.com/owasp-modsecurity/ModSecurity/commit/5e4e2af7a6f07854fee6ed36ef4a381d4e03960e) has been merged to support this endeavor. However, if running a modified or preexisting version of the modsecurity.conf file provided by this repository, it is a good idea to upgrade rule '200000' accordingly. The rule now appears as follows: +{{% notice style="note" icon="code" %}} +application/soap+xml is indicative that XML will be provided. In accordance with this, ModSecurity's XML request body processor should also be configured to support this MIME type. Within the ModSecurity project, [commit 5e4e2af](https://github.com/owasp-modsecurity/ModSecurity/commit/5e4e2af7a6f07854fee6ed36ef4a381d4e03960e) has been merged to support this endeavor. However, if running a modified or preexisting version of the modsecurity.conf file provided by this repository, it is a good idea to upgrade rule '200000' accordingly. The rule now appears as follows: ``` SecRule REQUEST_HEADERS:Content-Type "(?:application(?:/soap\+|/)|text/)xml" \ "id:'200000',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=XML" ``` +{{% /notice %}} + - **All versions of libmodsecurity3** [do not support](https://github.com/owasp-modsecurity/ModSecurity/wiki/Reference-Manual-(v3.x)#secdisablebackendcompression) the `SecDisableBackendCompression` directive at all. If Nginx is acting as a proxy and the backend supports any type of compression, if the client sends an `Accept-Encoding: gzip,deflate,...` or `TE` header, the backend will return the response in a compressed format. Because of this, the engine cannot verify the response. As a workaround, you need to override the `Accept-Encoding` and `TE` headers in the proxy: diff --git a/content/8-additional-resources/_index.md b/content/8-additional-resources/_index.md index e894e783..5530921f 100644 --- a/content/8-additional-resources/_index.md +++ b/content/8-additional-resources/_index.md @@ -6,7 +6,7 @@ chapter: true aliases: ["resources"] --- -{{% notice note %}} +{{% notice style="note" icon="clock-rotate-left" %}} **The content on this page may be outdated.** We are currently in the process of rewriting all of our documentation: please bear with us while we update our older content. {{% /notice %}} diff --git a/content/_index.md b/content/_index.md index d46351a7..067b6f4e 100644 --- a/content/_index.md +++ b/content/_index.md @@ -5,7 +5,7 @@ description: "CRS Documentation" > OWASP CRS provides documentation for many of the aspects surrounding the project. This page provides an overview of the project and its documentation. -{{% notice info %}} +{{% notice style="info" icon="shield-halved" %}} Security issues regarding CRS can be submitted via email to security [ at ] coreruleset.org. {{% /notice %}} diff --git a/layouts/partials/custom-header.html b/layouts/partials/custom-header.html new file mode 100644 index 00000000..a381a5f6 --- /dev/null +++ b/layouts/partials/custom-header.html @@ -0,0 +1,5 @@ + diff --git a/layouts/partials/logo.html b/layouts/partials/logo.html deleted file mode 100644 index 0b36eee3..00000000 --- a/layouts/partials/logo.html +++ /dev/null @@ -1,3 +0,0 @@ - diff --git a/themes/hugo-relearn b/themes/hugo-relearn index bf3dbc83..8bb66fa6 160000 --- a/themes/hugo-relearn +++ b/themes/hugo-relearn @@ -1 +1 @@ -Subproject commit bf3dbc8308313d6dd1f7ad32ba2a7983a4e9b3e5 +Subproject commit 8bb66fa674351f3a0b0917a7552caac686eca920