O.Source 2

Aus d.hack
Version vom 26. Juli 2024, 17:58 Uhr von D.hack (Diskussion | Beiträge)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)

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.

Lösungsansätze

Weblinks

Ressourcen und Einzelnachweise