New post: Can we have a more “social” media?
-
@silverpill @liaizon not dunking on your work ofc, but I think the “best practices” around writing standards are just not very good unfortunately
@silverpill @liaizon Like, even just using urlparse() from different languages exposes us to implementation difference issues, so a simple split("#")[0] equality is *way* better than urlparse & field comparison for security reasons.
which means lowercasing is a bad-bad!
-
@silverpill @liaizon Like, even just using urlparse() from different languages exposes us to implementation difference issues, so a simple split("#")[0] equality is *way* better than urlparse & field comparison for security reasons.
which means lowercasing is a bad-bad!
-
@Profpatsch @silverpill I like this presentation
-
2. Activity-Level Origin Checks
Same-origin is checked rather than exact equality so that servers with multiple actors can sign on behalf of any of their actors — a common legitimate pattern.For incoming activities, consider checking exact equality. See FEP-fe34, section "Signatures":
In order to minimize damage in the event of a key compromise or insufficient validation, consumers MUST verify that the signing key has the same owner as the signed object. Consumers MUST also confirm the ownership of the key by verifying a reciprocal claim.
This is not strictly necessary, but would help if the origin server does poor job at validating user input.
3. Embedded Object Origin Checks
Owner origin: the object's owner (actor for Activity subtypes, attributedTo for Notes/Objects) must be same-origin as the signing actor. Anonymous objects (no owner field) are accepted.In this case I also recommend checking owner ID equality, as a rule of thumb. Because origin servers implementing C2S API may fail to validate all embedded objects (which can be deeply nested).
Response body size limits
You may also need to limit the number of redirects and set a timeout. Some HTTP libraries have bad defaults.
By the way, I collect such recommendations in this guide: https://codeberg.org/ap-next/ap-next/src/branch/main/guide.md#network. Contributions are welcome!
@silverpill @liaizon What does this mean? “Follow redirects, but set a limit. Request must be re-signed after every redirect.”
do you mean I have to check the new http signature on every 30x response? I don’t believe that can work??
-
2. Activity-Level Origin Checks
Same-origin is checked rather than exact equality so that servers with multiple actors can sign on behalf of any of their actors — a common legitimate pattern.For incoming activities, consider checking exact equality. See FEP-fe34, section "Signatures":
In order to minimize damage in the event of a key compromise or insufficient validation, consumers MUST verify that the signing key has the same owner as the signed object. Consumers MUST also confirm the ownership of the key by verifying a reciprocal claim.
This is not strictly necessary, but would help if the origin server does poor job at validating user input.
3. Embedded Object Origin Checks
Owner origin: the object's owner (actor for Activity subtypes, attributedTo for Notes/Objects) must be same-origin as the signing actor. Anonymous objects (no owner field) are accepted.In this case I also recommend checking owner ID equality, as a rule of thumb. Because origin servers implementing C2S API may fail to validate all embedded objects (which can be deeply nested).
Response body size limits
You may also need to limit the number of redirects and set a timeout. Some HTTP libraries have bad defaults.
By the way, I collect such recommendations in this guide: https://codeberg.org/ap-next/ap-next/src/branch/main/guide.md#network. Contributions are welcome!
@silverpill @liaizon Another issue I noticed: “set a max request/response size” means that we are essentially forced to implement paging of outboxes both on client and server
-
@silverpill @liaizon Another issue I noticed: “set a max request/response size” means that we are essentially forced to implement paging of outboxes both on client and server
@silverpill @liaizon we should also definitely provide some actual values here, otherwise it’s pretty useless tbh …
-
@silverpill @liaizon What does this mean? “Follow redirects, but set a limit. Request must be re-signed after every redirect.”
do you mean I have to check the new http signature on every 30x response? I don’t believe that can work??
@Profpatsch You need to create a new signature because the request target is changing. It is a part of a signature base, so the initial signature becomes invalid when the client follows a redirect.
-
@silverpill @liaizon Another issue I noticed: “set a max request/response size” means that we are essentially forced to implement paging of outboxes both on client and server
@Profpatsch @liaizon The guide recommends limiting the response size, to prevent DoS.
I also found this in your
SECURITY.md: -
@Profpatsch @liaizon The guide recommends limiting the response size, to prevent DoS.
I also found this in your
SECURITY.md:@silverpill @liaizon yeah, but in essence anything that produces or consumes an outbox needs to implement paging because of that.
-
@silverpill @liaizon yeah, but in essence anything that produces or consumes an outbox needs to implement paging because of that.
@silverpill @liaizon Which, fine, all resources from other places need to be restricted to prevent DoS attacks anyway.
Ciao! Sembra che tu sia interessato a questa conversazione, ma non hai ancora un account.
Stanco di dover scorrere gli stessi post a ogni visita? Quando registri un account, tornerai sempre esattamente dove eri rimasto e potrai scegliere di essere avvisato delle nuove risposte (tramite email o notifica push). Potrai anche salvare segnalibri e votare i post per mostrare il tuo apprezzamento agli altri membri della comunità.
Con il tuo contributo, questo post potrebbe essere ancora migliore 💗
Registrati Accedi