Improper use of regex inside MRF Simple #235
Labels
No labels
approved, awaiting change
bug
configuration
documentation
duplicate
enhancement
extremely low priority
feature request
Fix it yourself
help wanted
invalid
mastodon_api
needs docs
needs tests
not a bug
planned
pleroma_api
privacy
question
static_fe
triage
wontfix
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: AkkomaGang/akkoma#235
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The function at https://akkoma.dev/AkkomaGang/akkoma/src/branch/develop/lib/pleroma/web/activity_pub/mrf.ex#L153 tries to compile a user provided domain glob into a regex. This leads to a few bugs:
The
.
character in domains is interpreted as a wildcard character. This leads to blocking ofis.rab.dev
resulting iniscrab.dev
being blocked. A more extreme example of this would be an attacker buying a domain such assoc.al
oronl.ne
and creating instances on subdomains, leading to admins blocking the entire social/online tlds or not being able to block the malicious instances.Workaround in case this is an issue for you: It's possible to escape the dot char using backslashes.
An admin can unintentionally break akkoma by inserting a domain that can't be interpreted as a regex(eg. a+b.com, ex[ample].com, *badword*). This doesn't cause any error inside adminfe, and instead causes akkoma to throw an error whenever it executes the MRF, breaking inbound and outbound federation.
for the second point, we'd need to have a list of disallowed characters, but the only source i can find on that is RFC 1034, which predates Punycode.or wait actually nvm this is a regex error not a domain errorgoing to solve two birds with one stone here
the only real use for regex here is to match subdomains
i'm going to group this with #228 and automatically match subdomains, thus eliminating the need for regex here