From 9274c0adafab376db17d456b0ec184d44565d27b Mon Sep 17 00:00:00 2001 From: duffyduck Date: Thu, 18 Jun 2026 18:54:24 +0200 Subject: [PATCH] Doku: URL-encoded Route-Params als by-design dokumentiert (R85-INFO) --- docs/SECURITY-HARDENING.md | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/docs/SECURITY-HARDENING.md b/docs/SECURITY-HARDENING.md index dbc8e7de..4d10b56a 100644 --- a/docs/SECURITY-HARDENING.md +++ b/docs/SECURITY-HARDENING.md @@ -473,6 +473,37 @@ Vor jedem Launch mit echten Tokens probieren. --- +## 📝 Bewusste Akzeptanz – URL-encoded Route-Parameter + +**Finding aus Pentest-Runde 85 (INFO, kein Security-Impact):** + +`/api/stressfrei-emails/%31/...` (URL-encoded `1`) liefert dieselbe +Antwort wie `/api/stressfrei-emails/1/...` – die `requireIdParam`- +Validierung mit `/^\d+$/` sieht die schon dekodierte Form, weil +Express URL-Parameter **vor** dem Routing dekodiert. + +**Wir akzeptieren das als by-design:** + +1. RFC 3986 fordert genau dieses Verhalten: prozentual-codierte und + roh-Form derselben Zeichen müssen semantisch identisch behandelt + werden. `/1` und `/%31` ist HTTP-konform äquivalent. +2. Ein nachträglicher Strict-Check auf `req.url` (roh) würde + legitime Clients brechen – Browser-Bookmarks mit URL-Encoding, + curl-Calls mit `--data-urlencode`, Proxy-Tools die URL-encoden, + Mobile-Clients mit kanonischer URL-Normalisierung. +3. Der Pentester selbst bestätigt: **kein Security-Impact** – die ID + landet nach Dekodierung als gültige Zahl bei der gleichen + Auth-/IDOR-Logik, die auch für die rohe Form greift. Insbesondere + `canAccessStressfreiEmail` läuft identisch. +4. Validierungs- und Access-Control-Kette ist nach der Dekodierung + identisch dicht – Auth, Ownership, Rate-Limit, alles greift gleich. + +**Code-Notiz:** kein Patch nötig. Diese Markdown-Sektion ist die +einzige Dokumentation, damit das in zukünftigen Pentest-Runden nicht +erneut als „offenes Finding" auftaucht. + +--- + ## 🧭 Wann ist „dicht" dicht? 100 % gibt es nicht. Erreicht ist: