O.Source 2: Unterschied zwischen den Versionen
(Die Seite wurde neu angelegt: „== Beschreibung == Die Anwendung MUSS eingehende und ausgehende Daten maskieren beziehungsweise von potenziell schadhaften Zeichen bereinigen oder deren Verarbeitung ablehnen. == Kurzfassung == Nutzung einer Escape-Syntax bei strukturierten Daten. == Anmerkungen == ==== Prüftiefe ==== <br /> :: ''' CHECK ''' <br /> Der Evaluator prüft, ob eine Escape-Syntax von strukturierten Daten für alle Eingaben vorhanden ist. Schadhafte Zeichen sind kontextabh…“) |
Keine Bearbeitungszusammenfassung |
||
| Zeile 8: | Zeile 8: | ||
==== Prüftiefe ==== | ==== Prüftiefe ==== | ||
<br /> | <br /> | ||
:: ''' | :: '''CHECK''' | ||
CHECK | |||
''' | |||
<br /> | <br /> | ||
Der Evaluator prüft, ob eine Escape-Syntax von strukturierten Daten für alle Eingaben vorhanden ist. Schadhafte Zeichen sind kontextabhängig zu betrachten. Im Datenbank-Kontext sind beispielsweise Hochkommata oder Prozentzeichen gegebenenfalls schadhaft, während im Web/HTML Kontext eher Tag-Klammern (<) schadhaft sind. Grundsätzlich muss die Input-Validierung daher kontextbezogen stattfinden. Wird eine potenziell schädliche Eingabe erkannt, muss sie entweder bereinigt/maskiert oder abgelehnt/verworfen werden. Das Verwerfen sollte dem Bereinigen vorgezogen werden. Sofern vorher maskierte oder bereinigte Eingaben weitergegeben werden, müssen diese so maskiert oder enkodiert werden, dass sie im Kontext der Weitergabe keine schädlichen Effekte haben. | Der Evaluator prüft, ob eine Escape-Syntax von strukturierten Daten für alle Eingaben vorhanden ist. Schadhafte Zeichen sind kontextabhängig zu betrachten. Im Datenbank-Kontext sind beispielsweise Hochkommata oder Prozentzeichen gegebenenfalls schadhaft, während im Web/HTML Kontext eher Tag-Klammern (<) schadhaft sind. Grundsätzlich muss die Input-Validierung daher kontextbezogen stattfinden. Wird eine potenziell schädliche Eingabe erkannt, muss sie entweder bereinigt/maskiert oder abgelehnt/verworfen werden. Das Verwerfen sollte dem Bereinigen vorgezogen werden. Sofern vorher maskierte oder bereinigte Eingaben weitergegeben werden, müssen diese so maskiert oder enkodiert werden, dass sie im Kontext der Weitergabe keine schädlichen Effekte haben. | ||
== Lösungsansätze == | == Lösungsansätze == | ||
Version vom 23. April 2024, 16:41 Uhr
Beschreibung
Die Anwendung MUSS eingehende und ausgehende Daten maskieren beziehungsweise von potenziell schadhaften Zeichen bereinigen oder deren Verarbeitung ablehnen.
Kurzfassung
Nutzung einer Escape-Syntax bei strukturierten Daten.
Anmerkungen
Prüftiefe
- CHECK
Der Evaluator prüft, ob eine Escape-Syntax von strukturierten Daten für alle Eingaben vorhanden ist. Schadhafte Zeichen sind kontextabhängig zu betrachten. Im Datenbank-Kontext sind beispielsweise Hochkommata oder Prozentzeichen gegebenenfalls schadhaft, während im Web/HTML Kontext eher Tag-Klammern (<) schadhaft sind. Grundsätzlich muss die Input-Validierung daher kontextbezogen stattfinden. Wird eine potenziell schädliche Eingabe erkannt, muss sie entweder bereinigt/maskiert oder abgelehnt/verworfen werden. Das Verwerfen sollte dem Bereinigen vorgezogen werden. Sofern vorher maskierte oder bereinigte Eingaben weitergegeben werden, müssen diese so maskiert oder enkodiert werden, dass sie im Kontext der Weitergabe keine schädlichen Effekte haben.