Sicherheitsnachweis für WebOffice |
  
|
Sicherheitsnachweis für WebOffice |
|
In den letzten Jahren wurde WebOffice 10.8 SP2 bei einer Vielzahl von Kunden durch externe, unabhängige Sicherheitsfirmen sehr umfänglichen Penetrationstests und Sicherheitstests unterzogen.
Wenn bei diesen Penetrationstests ein Sicherheitsrisiko entdeckt wurde, wurde von Seite VertiGIS immer mit höchster Priorität reagiert und zeitnah entsprechende Optimierungen vorgenommen.
Die 10 kritischsten Sicherheitsrisiken für Webanwendungen ("OWASP Top 10") und wie WebOffice 10.8 SP2 als Webanwendung dagegen geschützt ist, soll in diesem Kapitel aufgelistet werden.
Ein Angreifer kann Eingabedaten so manipulieren, dass er nicht vorgesehene Kommandos ausführen oder unautorisiert auf Daten zugreifen kann.
Maßnahmen:
SQL Injection wird in WebOffice 10.8 SP2 umfänglich verhindert, da die Eingabefeld-Validatoren SQL Syntax erkennen und eine weitere Verarbeitung verhindern, falls eine solche erkannt wird.
Ein Angreifer kann die Identität anderer Benutzer vorübergehend oder dauerhaft annehmen.
Maßnahmen:
Session Hijacking Attacken werden in WebOffice durch ein robustes und vielfach getestetes Session Management verhindert. Es werden so wenig Session Information wie möglich an den Referrer bekanntgegeben.
Vertrauliche Daten können kompromittiert werden, wenn sie nicht durch Maßnahmen, wie Verschlüsselung gespeicherter Daten und verschlüsselte Datenübertragung, zusätzlich geschützt werden.
Maßnahmen:
TLS Verbindungen sind in WebOffice standardmäßig im Einsatz und werden durch die Verwendung von Protokollen wie SAML auch forciert; die WebOffice Administration bietet ein einfache und effizient Möglichkeit zum Hinzufügen und Verwalten von Zertifikaten im Runtime Truststore der Webanwendung.
Veraltete oder schlecht konfigurierte XML Prozessoren berücksichtigen Referenzen auf externe Entitäten innerhalb von XML-Dokumenten.
Maßnahmen:
Eingaben, die das parsen von referenzierten XML Dokumenten zur Folge haben, welche aus nicht vertrauenswürdigen Quellen stammen, wie etwa das Hinzufügen von externen WMS Diensten, gehen mit einer XXE Protection einher. Dafür werden die Zugriffe auf nicht vertrauenswürdige externe DTDs, ENTITIES, und STYLESHEET Referenzen innerhalb eines Dokuments verhindert. Mithilfe einer Whitelist von vertrauenswürdigen Referenzen, welche der Administrator festlegen kann, kann die Gefahr einer XXE Attacke somit minimiert werden.
Zugriffsrechte für authentifizierte Nutzer nicht korrekt um- bzw. durchgesetzt.
Maßnahmen:
Durch die Verwendung von Standard Protokollen für die Authentifizierung und Autorisierung von Benutzern (z.B. SAML), sowie der Verwendung einer gut getesteten Benutzerverwaltung in WebOffice in Kombination mit ESRI Identitäten, kann von einer zuverlässigen Zugriffskontrolle ausgegangen werden. Einträge in die Benutzerdatenbank können nur von dafür autorisierten Administratoren durchgeführt werden.
Fehlkonfigurationen von Sicherheitseinstellungen sind das am häufigsten auftretende Problem. Ursachen sind unsichere Standardkonfigurationen, unvollständige oder ad-hoc durchgeführte Konfigurationen. Betriebssysteme, Frameworks, Bibliotheken und Anwendungen müssen sicher konfiguriert werden und zeitnah Patches und Updates erhalten.
Maßnahmen:
Kunden wird bei jedem WebOffice Deployment empfohlen die aktuellste JDK mit Sicherheitspatches, bzw. Sicherheitspatches von weiteren Software Drittanbietern, zu installieren. Standard Sicherheitseinstellungen von Komponenten werden in der Regel nicht geändert. Notwendige Änderungen werden immer von qualifiziertem Personal der jeweiligen Fachabteilungen durchgeführt.
XSS erlaubt es einem Angreifer, Scriptcode im Browser eines Opfers auszuführen und so Benutzersitzungen zu übernehmen, Seiteninhalte verändert anzuzeigen oder den Benutzer auf bösartige Seiten umzuleiten.
Maßnahmen:
XSS Erkennung für Client Widgets wurde umfänglich implementiert; am Server werden noch zusätzlich für eingehende Request mit Hilfe der OWASP Bibliothek (com.googlecode.owasp-java-html-sanitizer) XSS Attacken verhindert.
Unsichere, weil unzureichend geprüfte Deserialisierungen können zu Remote-Code-ExecutionSchwachstellen führen.
Maßnahmen:
Für die Deserialisierung von Objekten/Daten welche über externe Anwendungsschnittstellen in die Anwendung gelangen, werden Standard Softwarekompenenten verwendet (z.B. GSON, JAX-WS-API, etc.); Die deklarierten Felder, welche mit einem deserialisiertem Wert befüllt werden können, werden inhaltlich überprüft soweit dies möglich ist.
Applikationen und APIs, die Komponenten mit bekannten Schwachstellen einsetzen, können Schutzmaßnahmen unterlaufen und so Angriffe mit schwerwiegenden Auswirkungen verursachen.
Maßnahmen:
Client Bibliotheken werden mit ESRI Release Zyklen regelmäßig aktualisiert: ESRI Script API, DOJO, jQuery, etc.
Server Bibliotheken könnten mit Hilfe des MAVEN Build Frameworks ohne viel Aufwand auf dem neuesten Stand gehalten werden. Dies wird von Entwicklern auch regelmäßig durchgeführt.
Kunden wird bei jedem WebOffice Deployment empfohlen die aktuellste JDK mit Sicherheitspatches, bzw. Sicherheitspatches von weiteren Software Drittanbietern, zu installieren.
Viele Studien zeigen, dass die Zeit bis zur Aufdeckung eines Angriffs bei ca. 200 Tagen liegt sowie typischerweise durch Dritte entdeckt wird und nicht durch interne Überwachungs- und Kontrollmaßnahmen.
Maßnahmen:
Logging ist derzeit in vielen Kategorien mit unterschiedlichen Log Levels möglich. Es kann während der Laufzeit von WebOffice Administrator nach belieben konfiguriert werden.
MDC and NDC Logging wird verwendet; Logausgaben sind strukturiert and haben teilweise Report Character; eingehende als auch ausgehende Kommunikation mit dem Webserver wird ungefiltert geloggt; etc.