Core Rule Set: random passwords pass on the remaining password fields (closes #288)

Each app's sign-in, sign-up, password change and reset fields that had no
exclusion now skip the 35 rules random passwords set off, on that app's
paths and only when the query has no field of that name. Added gitea,
Vaultwarden's admin token, WordPress pass1/pass2/post_password and its REST
password, Drupal's forms and JSON, MediaWiki retype and password on the
pages that take them, Mastodon's challenge, and Nextcloud's confirm, reset,
change, share, LDAP renewal, encryption and OCS fields. Vaultwarden's
clients send a hash, which needs no exclusion.

Model: opus-5-5

SPEC.md

@@ -858,6 +858,27 @@ The changes hold in front of every app, and no setting undoes them:
         - to list a directory's last commits.
     - The `Content-Range` header of an artifact upload from
       `actions/upload-artifact@v3` (920450).
+    - The passwords in a body, for each rule that random passwords set off. The
+      numbers are in `internal/coreruleset/gitea.conf`.
+        - `password` on these paths:
+            - `/user/login`, `/user/sign_up`, `/user/activate`;
+            - `/user/link_account_signin` and `/user/link_account_signup`;
+            - `/user/recover_account`, which resets a password;
+            - `/user/settings/change_password` and `/user/settings/account`;
+            - `/user/settings/account/delete`;
+            - `/-/admin/users/new` and `/-/admin/users/<id>/edit`, and the same
+              paths under `/admin/`.
+        - `retype` on `/user/sign_up`, `/user/link_account_signup`,
+          `/user/settings/change_password` and `/user/settings/account`.
+        - `old_password` on `/user/settings/account`.
+        - `password` in the JSON body of `/api/v1/admin/users` and each user
+          under it.
+
+        Each field listed skips these rules on every path listed, not only on
+        the paths given for it. None applies when the query has a parameter of
+        the same name. `' OR '1'='1`, `../../etc/passwd`, `; cat /etc/passwd`
+        and `<img src=x onerror=x()>` sent as the password reach gitea;
+        `<script>alert(1)</script>` and `javascript:alert(1)` are still refused.
 
     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
@@ -933,6 +954,20 @@ The changes hold in front of every app, and no setting undoes them:
             `<script>alert(1)</script>` and `javascript:alert(1)` are still
             refused.
 
+        - `pass1`, `pass2` and `post_password` on `/wp-login.php`, which reset a
+          password and sign in to a protected post, for the same rules.
+        - `pass1` and `pass2` on these pages, for the same rules:
+            - `/wp-admin/profile.php`;
+            - `/wp-admin/user-edit.php`;
+            - `/wp-admin/user-new.php`;
+            - `/wp-admin/network/user-edit.php` and
+              `/wp-admin/user/profile.php`, on a multisite install.
+
+            Each of `pass1`, `pass2` and `post_password` skips these rules on
+            all of these pages and on `/wp-login.php`.
+
+        - `password` in form data or JSON on the REST API's `/wp/v2/users` and
+          the user under it, for the same rules.
         - `title`, `excerpt` and `name` in a JSON body sent to any REST API
           route under `/wp/v2/`, for the rules on system files and commands
           (930120, 932120, 932250, 932260).
@@ -1012,6 +1047,17 @@ The changes hold in front of every app, and no setting undoes them:
         `<img src=x onerror=x()>` sent as the password reach Drupal;
         `<script>alert(1)</script>` and `javascript:alert(1)` are still refused.
 
+    - The other passwords, for the same rules:
+        - `pass[pass1]`, `pass[pass2]` and `current_pass` on `/user/register`,
+          `/user/<id>/edit` and `/admin/people/create`;
+        - `pass.value`, `pass.0.value` and `pass.0.existing` in the JSON body of
+          `/user/register` and `/user/<id>`;
+        - `data.attributes.pass.value` and `data.attributes.pass.existing` in
+          the JSON:API body of `/jsonapi/user/user` and each user under it.
+
+        Each field listed skips these rules on every path listed, not only on
+        the paths given for it.
+
     - `name` when resetting a password through Drupal's JSON format on
       `/user/password`, for the same four rules.
     - `mail` in that same reset, for 932120 and 932260 only.
@@ -1091,9 +1137,13 @@ The changes hold in front of every app, and no setting undoes them:
         - `wpTextbox1` on MediaWiki's pages;
         - `text`, `appendtext` and `prependtext` on `/api.php`;
         - `source` in the JSON body of `/rest.php/`.
-    - The passwords when signing in:
+    - The passwords when signing in, signing up and changing a password:
         - `wpPassword` on MediaWiki's pages;
-        - `lgpassword` and `password` on `/api.php`.
+        - `password` and `retype` on `Special:ChangeCredentials`;
+        - `retype` on `Special:CreateAccount`;
+        - `retype` on `Special:UserLogin`, where a password reset sets the new
+          password;
+        - `lgpassword`, `password` and `retype` on `/api.php`.
 
         They skip each rule that random passwords set off:
 
@@ -1106,6 +1156,10 @@ The changes hold in front of every app, and no setting undoes them:
         `<img src=x onerror=x()>` sent as a password reach MediaWiki;
         `<script>alert(1)</script>` and `javascript:alert(1)` are still refused.
 
+        The path must name the special page, or be `/index.php` with a `title`
+        that names it. Other apps use `password` and `retype` too, so on any
+        other page those two fields keep every rule.
+
     These body exclusions matter only while `SWW_WAF_BODY_LIMIT` is set. None
     applies when the query has a parameter of the same name.
 
@@ -1239,6 +1293,9 @@ The changes hold in front of every app, and no setting undoes them:
         - `account_migration[current_password]` and
           `form_redirect[current_password]`;
         - `form_delete_confirmation[password]`;
+    - `form_challenge[current_password]`, which asks for the password again, on
+      `/auth/challenge`, `/settings/two_factor_authentication` and
+      `/settings/two_factor_authentication_methods`, and the paths under them;
     - `password` on `/api/v1/accounts`, in form data or JSON.
 
     They skip each rule that random passwords set off:
@@ -1248,6 +1305,9 @@ The changes hold in front of every app, and no setting undoes them:
     933100, 933135, 933180, 933210, 941100, 941120, 941160, 941180, 942100,
     942151, 942190, 942230, 942290, 942320, 942540, 942550, 944150.
 
+    Each field in the first two items skips these rules on every path in those
+    items.
+
     `' OR '1'='1`, `../../etc/passwd`, `; cat /etc/passwd` and
     `<img src=x onerror=x()>` sent as a password reach Mastodon;
     `<script>alert(1)</script>` and `javascript:alert(1)` are still refused.
@@ -1322,6 +1382,17 @@ The changes hold in front of every app, and no setting undoes them:
     `username` in the query of `/api/hibp/breach`, the data breach report, skips
     930120, 932120 and 932260 too.
 
+    `token` in the body of `/admin`, the admin token typed on the admin page,
+    skips each rule that random passwords set off. The numbers are in
+    `internal/coreruleset/vaultwarden.conf`. It applies only when the query has
+    no `token` parameter. `' OR '1'='1`, `../../etc/passwd`, `; cat /etc/passwd`
+    and `<img src=x onerror=x()>` sent as the token reach Vaultwarden;
+    `<script>alert(1)</script>` and `javascript:alert(1)` are still refused.
+
+    The apps hash the master password before sending it. So `password` on
+    `/identity/connect/token`, `masterPasswordHash` and `newMasterPasswordHash`
+    hold only base64 and need no exclusion.
+
     The names of uploaded files skip 920120 on the paths that take attachments
     and file sends:
     - `/api/ciphers/<id>/attachment` and the paths under it;
@@ -1397,6 +1468,35 @@ The changes hold in front of every app, and no setting undoes them:
     as the password reach Nextcloud; `<script>alert(1)</script>` and
     `javascript:alert(1)` are still refused.
 
+    The other passwords skip the same rules, in form data or JSON. None applies
+    when the query has a parameter of the same name.
+    - `password` on `/login/confirm`, `/lostpassword/set/<token>/<user>`,
+      `/settings/users/changepassword` and a public share's
+      `/s/<token>/authenticate/<page>`.
+    - `oldpassword` and `newpassword` on `/settings/personal/changepassword`.
+    - `recoveryPassword` on `/settings/users/changepassword`.
+    - `oldPassword` and `newPassword` on `/apps/user_ldap/renewpassword`, which
+      changes an expired password, and on
+      `/apps/encryption/ajax/updatePrivateKeyPassword`.
+    - `oldPassword`, `newPassword` and `confirmPassword` on
+      `/apps/encryption/ajax/changeRecoveryPassword`.
+    - `recoveryPassword` and `confirmPassword` on
+      `/apps/encryption/ajax/adminRecovery`.
+    - `password` on the OCS API's `person/check`, which checks a sign-in, and
+      `core/apppassword/confirm`, which confirms the password.
+    - `password` on the OCS API's `cloud/users` and the share API's
+      `apps/files_sharing/api/v1/shares`, each user or share under them, and a
+      share's `send-email`.
+    - `value` on the OCS API's `cloud/users/<id>` when the body's `key` is
+      `password`. A body with more than one `key`, or a `key` or `value` in the
+      query, gets none of this.
+
+    Each field listed but `value` skips these rules on every path listed, not
+    only on the paths given for it.
+
+    `password` on `/login/flow/apptoken` and `/login/v2/apptoken` holds a
+    generated app token, so it needs no exclusion.
+
     Some fields hold sentences a person writes:
     - `note`, a share's note, on `apps/files_sharing/api/v1/shares` of the OCS
       API and on each share under it;