Das Auslösen eines 404-Fehlers für jede ungültige Anfrage könnte fragwürdig sein, ein Angreifer kann dieses Verhalten vermuten, insbesondere wenn er den Dienst kennt, auf den er abzielt.
Hilft dies beim Schutz Ihres Dienstes? das hängt wirklich von der Ausdauer des Angreifers ab.
Bearbeiten :
Der Angreifer kann den Unterschied erkennen, wenn Sie den 404-Antwort-Header nicht so erstellen, wie es der Server tun würde
Hier ist ein PoC für Java-Server-Fall (Tomcat8):
Dies ist ein „wahrer“ 404-Status, der vom Server selbst für jede nicht gefundene Ressource zurückgegeben wird:
Content-Language:en
Content-Length:1026
Content-Type:text/html;charset=utf-8
Date:Tue, 31 Jan 2017 09:15:54 GMT
Server:Apache-Coyote/1.1
Dieser wird vom Servlet zurückgegeben :
Content-Language:en
Content-Length:992
Content-Type:text/html;charset=utf-8
Date:Tue, 31 Jan 2017 09:18:04 GMT
Server:Apache-Coyote/1.1
Sie sehen den Wert des Parameters "Content-length" in beiden Fällen könnte dieser die Aufmerksamkeit des Angreifers erregen.
Achtung, das Ausblenden des tatsächlichen Fehlercodes riecht ein wenig nach Verschleierung. Aus sicherheitstechnischer Sicht gibt es nichts wirklich Schlechtes, aber es fügt wenig Sicherheit hinzu, wenn überhaupt. Glauben Sie wirklich, dass Angreifer Fehlercodes blind akzeptieren? Sie wissen, dass sie nach Belieben geändert werden können, und das tun sie auch. Ok, es kann gegen Skript-Kiddies nützlich sein, aber Sie stehen nicht vor einem ernsthaften Angriff, also sollten Sie wirklich über Ihr Bedrohungsmodell nachdenken, bevor Sie diesen Weg gehen.
Und hier könnte es einen Nachteil geben. Wenn Sie kein spezielles Protokollsystem aufbauen, das den internen Fehler protokolliert, werden Sie in Protokollen enden, die nur 404-Fehler enthalten. Das bedeutet, dass Sie jede Möglichkeit der Protokollanalyse verloren haben, um zu versuchen, Angriffe auf Ihre Website und mögliche Sicherheitslücken zu entdecken. IMHO sind Fehlercodes für den Betreuer einer Anwendung nützlicher als für einen Angreifer ...