Commit graph

91 commits

Author SHA1 Message Date
ad7dcf38a8 Add HTTP backoff cache to respect 429s 2024-04-26 19:00:35 +01:00
2fc25980d1 fix pattern matching in fetch errors 2024-04-13 23:55:26 +01:00
33fb74043d Bring our adjustments into line with atom-failure 2024-04-13 22:56:04 +01:00
c0532bcae0 Handle 401s as I have observed it in the wild 2024-04-12 20:33:11 +01:00
ff515c05c3 Prevent requeuing Remote Fetcher jobs that exceed thread depth 2024-04-12 20:32:31 +01:00
7e5004b3e2 Leverage existing atoms as return errors for the object fetcher 2024-04-12 20:32:13 +01:00
53a9413b95 Formatting 2024-04-12 20:31:40 +01:00
3c54f407c5 Conslidate log messages for object fetcher failures and leverage Logger.metadata 2024-04-12 20:30:38 +01:00
825ae46bfa Set Logger level to error 2024-04-12 20:29:33 +01:00
30d63aaa6e Revert "Mark instances as unreachable when returning a 403 from an object fetch"
This reverts commit d472bafec19cee269e7c943bafae7c805785acd7.
2024-04-12 20:28:56 +01:00
4ff22a409a Consolidate the HTTP status code checking into the private get_object/1 2024-04-12 20:28:16 +01:00
4c29366fe5 Mark instances as unreachable when returning a 403 from an object fetch
This is a definite sign the instance is blocked and they are enforcing authorized_fetch
2024-04-12 20:27:33 +01:00
ac4cc619ea Fix Transmogrifier tests
These tests relied on the removed Fetcher.fetch_object_from_id!/2 function injecting the error tuple into a log message with the exact words "Object containment failed."

We will keep this behavior by generating a similar log message, but perhaps this should do a better job of matching on the error tuple returned by Transmogrifier.handle_incoming/1
2024-04-12 20:26:56 +01:00
c241b5b09f Remove Fetcher.fetch_object_from_id!/2
It was only being called once and can be replaced with a case statement.
2024-04-12 20:26:28 +01:00
fae0a14ee8 Use standard-compliant Accept header when fetching
Spec says clients MUST use this header and servers MUST respond to it,
while servers merely SHOULD respond to the one we used before.
https://www.w3.org/TR/activitypub/#retrieving-objects

The old value is kept as a fallback since at least two years ago
not every implementation correctly dealt with the spec-compliant
variant, see: https://github.com/owncast/owncast/issues/1827

Fixes: AkkomaGang/akkoma#730
2024-04-12 00:22:37 +02:00
61ec592d66 Drop obsolete pixelfed workaround
This pixelfed issue was fixed in 2022-12 in
https://github.com/pixelfed/pixelfed/pull/3932

Co-authored-by: FloatingGhost <hannah@coffee-and-dreams.uk>
2024-03-26 15:11:06 -01:00
8684964c5d Only allow exact id matches
This protects us from falling for obvious spoofs as from the current
upload exploit (unfortunately we can’t reasonably do anything about
spoofs with exact matches as was possible via emoji and proxy).

Such objects being invalid is supported by the spec, sepcifically
sections 3.1 and 3.2: https://www.w3.org/TR/activitypub/#obj-id

Anonymous objects are not relevant here (they can only exists within
parent objects iiuc) and neither is client-to-server or transient objects
(as those cannot be fetched in the first place).
This leaves us with the requirement for `id` to (a) exist and
(b) be a publicly dereferencable URI from the originating server.
This alone does not yet demand strict equivalence, but the spec then
further explains objects ought to be fetchable _via their ID_.
Meaning an object not retrievable via its ID, is invalid.

This reading is supported by the fact, e.g. GoToSocial (recently) and
Mastodon (for 6+ years) do already implement such strict ID checks,
additionally proving this doesn’t cause federation issues in practice.

However, apart from canonical IDs there can also be additional display
URLs. *omas first redirect those to their canonical location, but *keys
and Mastodon directly serve the AP representation without redirects.

Mastodon and GTS deal with this in two different ways,
but both constitute an effective countermeasure:
 - Mastodon:
   Unless it already is a known AP id, two fetches occur.
   The first fetch just reads the `id` property and then refetches from
   the id. The last fetch requires the returned id to exactly match the
   URL the content was fetched from. (This can be optimised by skipping
   the second fetch if it already matches)
   05eda8d193/app/helpers/jsonld_helper.rb (L168)
   63f0979799

 - GTS:
   Only does a single fetch and then checks if _either_ the id
   _or_ url property (which can be an object) match the original fetch
   URL. This relies on implementations always including their display URL
   as "url" if differing from the id. For actors this is true for all
   investigated implementations, for posts only Mastodon includes an
   "url", but it is also the only one with a differing display URL.
   2bafd7daf5 (diff-943bbb02c8ac74ac5dc5d20807e561dcdfaebdc3b62b10730f643a20ac23c24fR222)

Albeit Mastodon’s refetch offers higher compatibility with theoretical
implmentations using either multiple different display URL or not
denoting any of them as "url" at all, for now we chose to adopt a
GTS-like refetch-free approach to avoid additional implementation
concerns wrt to whether redirects should be allowed when fetching a
canonical AP id and potential for accidentally loosening some checks
(e.g. cross-domain refetches) for one of the fetches.
This may be reconsidered in the future.
2024-03-25 14:05:05 -01:00
9061d148be Ensure object id doesn’t change on refetch 2024-03-25 14:05:05 -01:00
3e134b07fa fetcher: return final URL after redirects from get_object
Since we reject cross-domain redirects, this doesn’t yet
make a difference, but it’s requried for stricter checking
subsequent commits will introduce.

To make sure (and in case we ever decide to reallow
cross-domain redirects) also use the final location
for containment and reachability checks.
2024-03-25 14:05:05 -01:00
59a142e0b0 Never fetch resource from ourselves
If it’s not already in the database,
it must be counterfeit (or just not exists at all)

Changed test URLs were only ever used from "local: false" users anyway.
2024-03-25 14:05:05 -01:00
fee57eb376 Move actor check into fetch_and_contain_remote_object_from_id
This brings it in line with its name and closes an,
in practice harmless, verification hole.

This was/is the only user of contain_origin making it
safe to change the behaviour on actor-less objects.

Until now refetched objects did not ensure the new actor matches the
domain of the object. We refetch polls occasionally to retrieve
up-to-date vote counts. A malicious AP server could have switched out
the poll after initial posting with a completely different post
attribute to an actor from another server.
While we indeed fell for this spoof before the commit,
it fortunately seems to have had no ill effect in practice,
since the asociated Create activity is not changed. When exposing the
actor via our REST API, we read this info from the activity not the
object.

This at first thought still keeps one avenue for exploit open though:
the updated actor can be from our own domain and a third server be
instructed to fetch the object from us. However this is foiled by an
id mismatch. By necessity of being fetchable and our longstanding
same-domain check, the id must still be from the attacker’s server.
Even the most barebone authenticity check is able to sus this out.
2024-03-25 14:05:05 -01:00
c4cf4d7f0b Reject cross-domain redirects when fetching AP objects
Such redirects on AP queries seem most likely to be a spoofing attempt.
If the object is legit, the id should match the final domain anyway and
users can directly use the canonical URL.

The lack of such a check (and use of the initially queried domain’s
authority instead of the final domain) was enabling the current exploit
to even affect instances which already migrated away from a same-domain
upload/proxy setup in the past, but retained a redirect to not break old
attachments.

(In theory this redirect could, with some effort, have been limited to
 only old files, but common guides employed a catch-all redirect, which
 allows even future uploads to be reachable via an initial query to the
 main domain)

Same-domain redirects are valid and also used by ourselves,
e.g. for redirecting /notice/XXX to /objects/YYY.
2024-03-25 14:05:05 -01:00
2bcf633dc2 Document Pleroma.Object.Fetcher 2024-03-25 14:05:05 -01:00
c806adbfdb Refactor Fetcher.get_object for readability
Apart from slightly different error reasons wrt content-type,
this does not change functionality in any way.
2024-03-18 22:40:43 -01:00
64e233ca20 Tag Mock-tests as "mocked" and run them seperately 2023-08-04 12:50:50 +01:00
77e9a52450 allow http AS profile in ld+json header 2022-12-12 19:06:04 +00:00
68894089e8 Do not fetch anything from blocked instances 2022-12-10 00:09:45 +00:00
f5a315f04c Add URL and code to :not_found errors
Ref #355
2022-12-09 20:13:31 +00:00
@r3g_5z@plem.sapphic.site
565ead8397 minor-changes (#313)
Only real change here is making MRF rejects log as debug instead of info (AkkomaGang/akkoma#234)

I don't know if it's the best way to do it, but it seems it's just MRF using this and almost always this is intended.

The rest are just minor docs changes and syncing the restricted nicknames stuff.

I compiled and ran my changes with Docker and they all work.

Co-authored-by: r3g_5z <june@terezi.dev>
Reviewed-on: AkkomaGang/akkoma#313
Co-authored-by: @r3g_5z@plem.sapphic.site <june@girlboss.ceo>
Co-committed-by: @r3g_5z@plem.sapphic.site <june@girlboss.ceo>
2022-11-26 19:27:58 +00:00
Haelwenn (lanodan) Monnier
3e0a5851e5 Set instance reachable on fetch 2022-11-15 17:23:47 +00:00
2641dcdd15 Post editing (#202)
Rebased from #103

Co-authored-by: Tusooa Zhu <tusooa@kazv.moe>
Co-authored-by: FloatingGhost <hannah@coffee-and-dreams.uk>
Reviewed-on: AkkomaGang/akkoma#202
2022-09-06 19:24:02 +00:00
Haelwenn (lanodan) Monnier
461123110b
Object.Fetcher: Fix getting transmogrifier reject reason 2021-04-05 19:19:12 +02:00
Haelwenn (lanodan) Monnier
96212b2e32
Fix addressing 2021-04-05 19:19:12 +02:00
Haelwenn (lanodan) Monnier
c4439c630f
Bump Copyright to 2021
grep -rl '# Copyright © .* Pleroma' * | xargs sed -i 's;Copyright © .* Pleroma .*;Copyright © 2017-2021 Pleroma Authors <https://pleroma.social/>;'
2021-01-13 07:49:50 +01:00
lain
e1e7e4d379 Object: Rework how Object.normalize works
Now it defaults to not fetching, and the option is named.
2021-01-04 13:38:31 +01:00
rinpatch
2c55f7d7cb Remove FedSockets
Current FedSocket implementation has a bunch of problems. It doesn't
have proper error handling (in case of an error the server just doesn't
respond until the connection is closed, while the client doesn't match
any error messages and just assumes there has been an error after 15s)
and the code is full of bad descisions (see: fetch registry which uses
uuids for no reason and waits for a response by recursively querying a
 ets table until the value changes, or double JSON encoding).

Sometime ago I almost completed rewriting fedsockets from scrach to
adress these issues. However, while doing so, I realized that fedsockets
 are just too overkill for what they were trying to accomplish, which is
 reduce the overhead of federation by not signing every message.
This could be done without reimplementing failure states and endpoint
 logic we already have with HTTP by, for example, using TLS cert auth,
or switching to a more performant signature algorithm. I opened
https://git.pleroma.social/pleroma/pleroma/-/issues/2262 for further
discussion on alternatives to fedsockets.

From discussions I had with other Pleroma developers it seems like they
 would approve the descision to remove them as well,
therefore I am submitting this patch.
2020-11-17 17:28:30 +03:00
rinpatch
6ca709816f Fix object spoofing vulnerability in attachments
Validate the content-type of the response when fetching an object,
according to https://www.w3.org/TR/activitypub/#x3-2-retrieving-objects.

content-type headers had to be added to many mocks in order to support
this, some of this was done with a regex. While I did go over the
resulting files to check I didn't modify anything unrelated, there is a
 possibility I missed something.

Closes pleroma#1948
2020-11-12 15:25:33 +03:00
Steven Fuchs
f2ef9735c5 Federate data through persistent websocket connections 2020-09-18 11:58:22 +00:00
Haelwenn (lanodan) Monnier
f1f44069ae
Fetcher: Correctly return MRF reject reason 2020-09-11 20:00:41 +02:00
lain
9433311923 Merge branch 'bugfix/incoming-poll-emoji' into 'develop'
Fix emoji in Question, force generated context/context_id insertion

Closes #1870

See merge request pleroma/pleroma!2915
2020-09-03 11:50:30 +00:00
Alexander Strizhakov
79f65b4374
correct pool and uniform headers format 2020-09-02 09:16:51 +03:00
Haelwenn (lanodan) Monnier
d9a21e4784
fetcher: Remove fix_object call for Question activities 2020-09-01 08:35:00 +02:00
Haelwenn (lanodan) Monnier
b1fc4fe0ca
fetcher: fallback to [] when to/cc is nil
Related: https://git.pleroma.social/pleroma/pleroma/-/issues/2063
2020-08-18 02:02:20 +02:00
Haelwenn (lanodan) Monnier
ac2598307d
Merge remote-tracking branch 'pleroma/develop' into features/poll-validation 2020-07-31 13:57:21 +02:00
Haelwenn (lanodan) Monnier
ad867ccfa1
fetcher: Reinject Question through validator 2020-07-15 11:39:55 +02:00
Haelwenn (lanodan) Monnier
6b9c4bc1f1
fetcher: more descriptive variable names 2020-07-15 11:39:55 +02:00
Haelwenn (lanodan) Monnier
ce243b107f
Use Logger.info for {:reject, reason} 2020-07-13 15:26:31 +02:00
Haelwenn (lanodan) Monnier
1566543bec
object/fetcher: Pass full Transmogrifier error 2020-06-26 20:10:47 +02:00
Alexander Strizhakov
509c81e4b1
Merge branch 'develop' into gun 2020-03-03 10:08:07 +03:00
Haelwenn (lanodan) Monnier
6da6540036
Bump copyright years of files changed after 2020-01-07
Done via the following command:
git diff fcd5dd259a --stat --name-only | xargs sed -i '/Pleroma Authors/c# Copyright © 2017-2020 Pleroma Authors <https:\/\/pleroma.social\/>'
2020-03-02 06:08:45 +01:00