O.Source 2: Unterschied zwischen den Versionen
D.hack (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
D.hack (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
||
Zeile 1: | Zeile 1: | ||
== Beschreibung == | == Beschreibung == | ||
[[Beschreibung:: | |||
Die Anwendung MUSS eingehende und ausgehende Daten maskieren beziehungsweise von potenziell schadhaften Zeichen bereinigen oder deren Verarbeitung ablehnen. | Die Anwendung MUSS eingehende und ausgehende Daten maskieren beziehungsweise von potenziell schadhaften Zeichen bereinigen oder deren Verarbeitung ablehnen. | ||
]] | |||
== Kurzfassung == | == Kurzfassung == | ||
[[Kurzfassung:: | |||
Nutzung einer Escape-Syntax bei strukturierten Daten. | Nutzung einer Escape-Syntax bei strukturierten Daten. | ||
]] | |||
== Testcharakteristik == | == Testcharakteristik == | ||
==== Prüftiefe ==== | ==== Prüftiefe ==== | ||
Zeile 20: | Zeile 21: | ||
<br /> | <br /> | ||
==== Ergänzende Informationen für Evaluatoren ==== | ==== Ergänzende Informationen für Evaluatoren ==== | ||
[[Anmerkungen:: | |||
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 == | ||
Zeile 27: | Zeile 30: | ||
== Ressourcen und Einzelnachweise == | == Ressourcen und Einzelnachweise == | ||
[[Category:CHECK]] | [[Category:CHECK]] | ||
[[Category: Source]] | [[Category: Source]] |
Aktuelle Version vom 26. Juli 2024, 17:58 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.
Testcharakteristik
Prüftiefe
Bezeichnung | Mindestanforderungen an die Prüfung |
---|---|
CHECK | Der Evaluator validiert (englisch „check“, analog zu Begriffsverwendung in der Common Criteria Evaluation Methodology) die vom Hersteller beschriebene Maßnahme im Hinblick auf ihre Wirksamkeit und räumt bestehende Zweifel (Plausibilitätsprüfung) aus, ob der Prüfaspekt und die damit verbundene Sicherheitsproblematik umfassend durch die beschriebenen Maßnahmen adressiert wird. Hierbei MUSS der Evaluator den aktuellen Stand der Technik für die jeweilige Plattform mitberücksichtigen. Die Validierung KANN weitergehende Schritte, wie z.B. eine Quelltextanalyse, umfassen, falls der Evaluator diese für eine umfassende Einschätzung benötigt. |
Ergänzende Informationen für Evaluatoren
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.