Core Rule Set: random passwords pass on the remaining password fields (closes #288)
check / check (push) Failing after 6m24s

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, Mastodon's
challenge, and Nextcloud's confirm, reset, change, share and OCS fields.
Vaultwarden's clients send a hash, which needs no exclusion.

Model: opus-5-5
This commit is contained in:
sneak committed 2026-11-10 15:48:18 +00:00
1 parent 3268ec95c1
commit 0aec33b017
15 files changed
+853 -141

No files matched your search

+64 -3
View File
@@ -858,6 +858,26 @@ 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 the paths
under 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 +953,13 @@ 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 `/wp-admin/profile.php`,
`/wp-admin/user-edit.php` and `/wp-admin/user-new.php`, for the same
rules.
- `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 +1039,13 @@ 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.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 the paths under 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 +1125,9 @@ 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:
- `wpPassword` on MediaWiki's pages;
- `lgpassword` and `password` on `/api.php`.
- The passwords when signing in, signing up and changing a password:
- `wpPassword`, `password` and `retype` on MediaWiki's pages;
- `lgpassword`, `password` and `retype` on `/api.php`.
They skip each rule that random passwords set off:
@@ -1239,6 +1273,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:
@@ -1322,6 +1359,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 +1445,19 @@ 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`.
- `password` on the OCS API's `cloud/users` and the share API's
`apps/files_sharing/api/v1/shares`, and each user or share under them.
- `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.
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;