reflect the discussion with kik

docs/unsure-where-to-put/threat_analysis_star_activity.md

@@ -1,5 +1,7 @@
 # Threat analysis for the federated star activity
 
+See also [1] for getting an idea about the analysis.
+
 ## Technical Background
 ### Control Flow
 
@@ -71,7 +73,7 @@ flowchart TD
 
 1. **Script Kiddies**: Boored teens, willing to do some illigal without deep knowlege of tech details but broad knowlege across internet discussions. Able to do some bash / python scripting.
 2. **Experienced Hacker**: Hacker with deep knowlege.
-3. **OpenSource Promoter**: 
+3. **OpenSource Promoter**: Developers motivated to increase (or decrease) star count for some dedicated projects.
 
 ### Threat
 
@@ -80,14 +82,16 @@ flowchart TD
 3. OpenSource Promoter sends Star Activities having not authorized Person Actors. The Actors listed as stargazer migth get angry about this, we loose reputation.
 4. Experienced Hacker records activities sent and replays some of them. Without order of activities (i.e. timestamp) we can not decide wether we should execute the activity again. If the replayed activities are Unstar Activity we might loose stars.
 5. Experienced Hacker records activities sends a massive amount of activities which leads to new user creation & storage. Our instance might get off service.
+6. Experienced Hacker may craft their malicious server to keep connections open. Then they send you a Star activity with the actor URL pointing to that malicious server, and your background job keeps waiting for data. Then they send more such requests, until you exhaust your limit of file descriptors openable for your system and cause a DoS (by causing cascading failures all over the system, given file descriptors are used for about everything, from files, to sockets, to pipes). See also [Slowloris@wikipedia][2].
 
 ### Mitigations
+
 1. Validate object uri in order to send only requests to well defined endpoints.
 2. giteas global SQL injection protection. TODO: verify if there is one.
 3. We accept only signed Activities
 4. We accept only activities having an timestamp & remember the last executed activity timestamp.
-5. ...
-
+5. We introduce (or have) rate limiting per IP.
+6. We ensure, that outgoing HTTP requests have a reasonable timeout (if you didn't get that 500b JSON response after 10 seconds, you probably won't get it).
 
 ### DREAD-Score
 
@@ -104,6 +108,13 @@ Bewertet wird mit Schulnoten von 1 - 6
 * Affected Users – wenn eine Bedrohung ausgenutzt werden würde, wieviel Prozent der Benutzer wären betroffen?
 * Discoverability – Wie einfach lässt sich ein Angriff entdecken? Muss der Angreifer Strafverfolgung erwarten? 6 ist sehr schwer zu entdecken / ist gar nicht illegal
 
+## Contributors
+
+In adition to direct commiter our special thanks goes to the experts joining our discussions:
+
+* [kik](https://codeberg.org/oelmekki)
+
 ## Reference
 
-* https://geballte-sicherheit.de/threat-modelling-bedrohungsanalyse-7-teil-einstufung-von-bedrohungen-ranking-of-threats/
+* [1]: https://geballte-sicherheit.de/threat-modelling-bedrohungsanalyse-7-teil-einstufung-von-bedrohungen-ranking-of-threats/
+* [2]: https://en.wikipedia.org/wiki/Slowloris_(computer_security)