SWW_APPS: an app's Core Rule Set fixes apply only to the hostnames that serve it (closes #220)

gitea's fixes (its parameters, its cookies and gitea.conf) now apply
only to a hostname SWW_APPS lists gitea for, or to every hostname while
it is unset. Each app's fixes are one .conf file, whose first rule skips
the rest unless Inspect sets tx.app_<name>, and one entry in apps.

A hostname in SWW_APPS that is not a DNS name, such as *.example.com,
stops the start. Unset, SWW_APPS is logged at start as null; set
empty, as "".

Model: opus-5-5

SPEC.md

@@ -81,8 +81,8 @@ to them.
       of bans is full.
     - `internal/rules`: reads the rule files at start and again when they
       change, and tells which rules a request matches.
-    - `internal/waf`: the Core Rule Set, with the eight changes listed under
-      "Attack detection", as Coraza directives.
+    - `internal/waf`: the Core Rule Set, with the six changes and the apps'
+      fixes listed under "Attack detection", as Coraza directives.
     - `internal/lookup`: looks clients up through GeoJS or in the lookup
       database.
     - `internal/reputation`: fetches the lists, asks the DNS blocklists and
@@ -584,7 +584,7 @@ files, the limits and the bans still apply to the client that sends it.
 - `SWW_CORE_RULE_SET_EXCLUSIONS_FILE` names a file of exclusions, written as
   Coraza directives. An exclusion switches one rule off for some fields or paths
   only, where `SWW_WAF_DISABLED_RULES` switches it off everywhere. The file
-  holds an app's own exclusions; the eighth change below holds gitea's.
+  holds an app's own exclusions; gitea's fixes below hold gitea's.
     - `discriminator` loads the file after `smallwebwaf`'s own setup rules and
       before the Core Rule Set's rules. The Core Rule Set loads its own
       `REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf` at the same point.
@@ -630,7 +630,7 @@ files, the limits and the bans still apply to the client that sends it.
     scanner from an ordinary client. In front of a code forge, registry and git
     clients get `404` and `401` by design, hundreds of times a minute.
 
-`smallwebwaf` changes the Core Rule Set 4.25.0 in eight ways, since in front of
+`smallwebwaf` changes the Core Rule Set 4.25.0 in six ways, since in front of
 gitea it would otherwise refuse ordinary requests. The changes hold in front of
 every app, and no setting undoes them:
 
@@ -649,8 +649,52 @@ every app, and no setting undoes them:
    and tea, which gitea registers for OAuth sign-in, ask to be sent back to
    `http://127.0.0.1` on the user's own machine. The server never fetches that
    address.
-4. Ten query parameters are not checked against the Core Rule Set's lists of
-   system files (930120), shell paths (932160) and command names (932260):
+4. `Referer` is not checked for a Unix command given without arguments (932340),
+   for Java starting a process (944110) or for a Java class name (944130).
+   `Referer` names the page a request comes from, on everything that page loads
+   and on every link followed from it. The Core Rule Set takes some page
+   addresses for attacks:
+    - a search for `env`;
+    - OpenJDK's `Runtime.java`, whose path holds both `runtime` and `java.`;
+    - a file named `java.lang.String.md`.
+
+    Every request from such a page would be refused. `Referer` keeps the other
+    rules, except after some gitea searches (gitea's fixes). An app that passes
+    `Referer` to a shell must check it itself.
+
+5. Responses are not inspected. A raw file from a repository, such as a shell
+   script, looks to the response rules like source code leaking from the server.
+6. The `from` parameter of a container registry's upload path,
+   `/v2/<image>/blobs/uploads/`, is not checked for command names (932260). When
+   a push reuses a layer, `from` names the image the layer comes from. An image
+   such as `owner/python3-app` would have that push refused.
+
+Each supported app also has its own fixes, which let its ordinary requests
+through. An app's fixes hold for the hostnames `SWW_APPS` lists the app for:
+
+- `SWW_APPS` holds entries separated by semicolons. Each is a hostname, a colon,
+  then one or more apps separated by commas, for example
+  `git.example.com:gitea;code.example.com:gitea`.
+- The request's `Host` is matched by exact name, without its port and without
+  regard to case. There are no wildcards.
+- A hostname not listed gets no app's fixes, so every rule checks it in full.
+  Set empty, `SWW_APPS` lists no hostname.
+- Unset, every app's fixes hold for every hostname. An app's fixes then weaken
+  the check of any other app that serves the same paths or fields.
+- Any of these mistakes stops the start:
+    - an unknown app;
+    - a hostname that is not a DNS name, such as `*.example.com`;
+    - a hostname listed twice;
+    - an app listed twice for one hostname;
+    - an entry without a colon.
+
+`gitea` is the only app supported. Each app's fixes are in one file, such as
+`internal/waf/gitea.conf`, and one entry of `apps` in `internal/waf/waf.go`.
+gitea's fixes are:
+
+1. Ten query parameters are not checked against the Core Rule Set's lists of
+   system files (930120), shell paths (932160) and command names (932260), on
+   any path:
     - `path`, `files`, `skip-to` and `sub_path`;
     - `ref`, `sha`, `branch` and `workflow`;
     - `artifactName` and `redirect_to`.
@@ -663,41 +707,18 @@ every app, and no setting undoes them:
     catch reaches the app, such as the command `|cat /etc/passwd`. Path
     traversal, SQL and script injection, and PHP, Java and Node.js code are
     still refused there. Other parameters keep all three rules, except on the
-    gitea paths the eighth change names. An app that uses one of these
-    parameters as a file on the server, or passes it to a shell, must check the
-    value itself. A rule file can refuse it instead.
+    gitea paths the third fix names.
 
-5. Two cookies are left out, and `Referer` keeps fewer rules:
-    - The Core Rule Set reads the request without the `gitea_flash` and
-      `redirect_to` cookies. gitea puts a message naming what was just done into
-      `gitea_flash`. It puts into `redirect_to` the page to return to after
-      signing in. The Core Rule Set takes file names in them, such as
-      `package.json`, for attacks. A browser sends such a cookie with every
-      request until gitea replaces it. gitea cannot replace it while those
-      requests are refused, so one refusal would keep the browser out of the
-      whole site. gitea shows the message with any script removed and returns
-      only to its own pages. Every other cookie is read in full. An app that
-      reads a cookie of either name must check it itself.
-    - `Referer` is not checked for a Unix command given without arguments
-      (932340), for Java starting a process (944110) or for a Java class name
-      (944130). `Referer` names the page a request comes from, on everything
-      that page loads and on every link followed from it. The Core Rule Set
-      takes some page addresses for attacks:
-        - a search for `env`;
-        - OpenJDK's `Runtime.java`, whose path holds both `runtime` and `java.`;
-        - a file named `java.lang.String.md`.
-
-        Every request from such a page would be refused. `Referer` keeps the
-        other rules, except after some gitea searches (the eighth change). An
-        app that passes `Referer` to a shell must check it itself.
-
-6. Responses are not inspected. A raw file from a repository, such as a shell
-   script, looks to the response rules like source code leaking from the server.
-7. The `from` parameter of a container registry's upload path,
-   `/v2/<image>/blobs/uploads/`, is not checked for command names (932260). When
-   a push reuses a layer, `from` names the image the layer comes from. An image
-   such as `owner/python3-app` would have that push refused.
-8. On gitea's paths, some fields skip the rules that refused ordinary gitea
+2. The Core Rule Set reads the request without the `gitea_flash` and
+   `redirect_to` cookies. gitea puts a message naming what was just done into
+   `gitea_flash`. It puts into `redirect_to` the page to return to after signing
+   in. The Core Rule Set takes file names in them, such as `package.json`, for
+   attacks. A browser sends such a cookie with every request until gitea
+   replaces it. gitea cannot replace it while those requests are refused, so one
+   refusal would keep the browser out of the whole site. gitea shows the message
+   with any script removed and returns only to its own pages. Every other cookie
+   is read in full.
+3. On gitea's paths, some fields skip the rules that refused ordinary gitea
    requests there. They are the fields where gitea sends a search, a file name
    or a branch name. `internal/waf/gitea.conf` lists each rule and the request
    it refused. The fields are:
@@ -715,8 +736,7 @@ every app, and no setting undoes them:
         - packages.
 
         A user's or an organisation's page is any path of one segment, so on
-        every such path, on any app, `q` skips these three rules, for example on
-        `/search`.
+        every such path `q` skips these three rules, for example on `/search`.
 
         Some of these searches also skip the rule for Java class names (944130),
         which refused `org.apache.commons.logging`.
@@ -754,11 +774,14 @@ every app, and no setting undoes them:
       `actions/upload-artifact@v3` (920450).
 
     Elsewhere these fields keep every rule. The paths are those of gitea at the
-    site root. An app other than gitea that serves one of them must check these
-    fields itself.
+    site root.
 
-The parameter and cookie names in these changes are matched without regard to
-case, as Coraza matches them.
+On a hostname that gets gitea's fixes, an app other than gitea must check these
+fields and cookies itself. Listing each hostname's own apps in `SWW_APPS` keeps
+the full check for the others.
+
+The parameter names in these changes and fixes are matched without regard to
+case, and the cookie names exactly.
 
 ### Ban lengths, response and scope