O.Source 9: 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 Web-Anwendung MUSS Maßnahmen vorsehen, die verhindern, dass Funktionalitäten, die nicht in der Entwicklungshoheit des Herstellers liegen, in die Web-Anwendung eingeschleust und zur Ausführung gebracht werden. | Die Web-Anwendung MUSS Maßnahmen vorsehen, die verhindern, dass Funktionalitäten, die nicht in der Entwicklungshoheit des Herstellers liegen, in die Web-Anwendung eingeschleust und zur Ausführung gebracht werden. | ||
]] | |||
== Kurzfassung == | == Kurzfassung == | ||
[[Kurzfassung:: | |||
Vorbeugende Maßnahmen zum Schutz von Funktionalitäten außerhalb der eigenen Entwicklungshoheit. | Vorbeugende Maßnahmen zum Schutz von Funktionalitäten außerhalb der eigenen Entwicklungshoheit. | ||
]] | |||
== 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 stellt durch Quelltextanalyse und praktische Tests sicher, dass die Web-Anwendung dem Stand der Technik entsprechende Maßnahmen ergreift, um ein ausführen von injizierten Funktionalitäten zu verhindern. Beispielsweise kann die Web-Anwendung als Gegenmaßnahme gegen Cross-Site-Request-Forgery (CSRF) Angriffe einen SessionCode (auch Synchronizer Token Pattern (STP) oder CSRF-Token) in jede URL als weiteren zufälligen (d.h. nicht erratbaren) Parameter in einem HiddenField einfügen. Auf Basis des SessionCodes kann das Hintergrundsystem die Gültigkeit der Anfrage zusätzlich prüfen. | Der Evaluator stellt durch Quelltextanalyse und praktische Tests sicher, dass die Web-Anwendung dem Stand der Technik entsprechende Maßnahmen ergreift, um ein ausführen von injizierten Funktionalitäten zu verhindern. Beispielsweise kann die Web-Anwendung als Gegenmaßnahme gegen Cross-Site-Request-Forgery (CSRF) Angriffe einen SessionCode (auch Synchronizer Token Pattern (STP) oder CSRF-Token) in jede URL als weiteren zufälligen (d.h. nicht erratbaren) Parameter in einem HiddenField einfügen. Auf Basis des SessionCodes kann das Hintergrundsystem die Gültigkeit der Anfrage zusätzlich prüfen. | ||
]] | |||
== Lösungsansätze == | == Lösungsansätze == | ||
| Zeile 27: | Zeile 30: | ||
== Ressourcen und Einzelnachweise == | == Ressourcen und Einzelnachweise == | ||
[[Category:EXAMINE]] | [[Category:EXAMINE]] | ||
[[Category: Source]] | [[Category: Source]] | ||
Aktuelle Version vom 26. Juli 2024, 18:01 Uhr
Beschreibung
Die Web-Anwendung MUSS Maßnahmen vorsehen, die verhindern, dass Funktionalitäten, die nicht in der Entwicklungshoheit des Herstellers liegen, in die Web-Anwendung eingeschleust und zur Ausführung gebracht werden.
Kurzfassung
Vorbeugende Maßnahmen zum Schutz von Funktionalitäten außerhalb der eigenen Entwicklungshoheit.
Testcharakteristik
Prüftiefe
| Bezeichnung | Mindestanforderungen an die Prüfung |
|---|---|
| EXAMINE | Der Evaluator untersucht (englisch „examine“, analog zu Begriffsverwendung in der Common Criteria Evaluation Methodology) die betreffende Testcharakteristik. Der Evaluator MUSS in seiner Prüfung über die Mindestanforderungen für „CHECK“ hinausgehen: In der Regel wird dies durch umfassende Quelltextanalyse der relevanten Implementierungsanteile und Penetrationstests geschehen. Die Unterstützung durch den Hersteller kann genutzt werden. „EXAMINE“ erfordert in jedem Fall eine eigenständige Beurteilung durch den Evaluator. |
Ergänzende Informationen für Evaluatoren
Der Evaluator stellt durch Quelltextanalyse und praktische Tests sicher, dass die Web-Anwendung dem Stand der Technik entsprechende Maßnahmen ergreift, um ein ausführen von injizierten Funktionalitäten zu verhindern. Beispielsweise kann die Web-Anwendung als Gegenmaßnahme gegen Cross-Site-Request-Forgery (CSRF) Angriffe einen SessionCode (auch Synchronizer Token Pattern (STP) oder CSRF-Token) in jede URL als weiteren zufälligen (d.h. nicht erratbaren) Parameter in einem HiddenField einfügen. Auf Basis des SessionCodes kann das Hintergrundsystem die Gültigkeit der Anfrage zusätzlich prüfen.