Bedrohungsanalysen

Unabhängig davon, ob Ihre Applikation Single Sign-On Systeme, Webservices Lösungen, unterschiedliche Daten- oder Dokumentenformate (JSON, XML, PDF, ODF, OOXML), ein Information Rights Management oder kryptographischen Verfahren einsetzt, die Aspekte der Sicherheit müssen gründlich geplant werden.

Unsere individuellen Bedrohungsanalysen unterstützen Sie dabei Ihre Applikation von Grund auf sicher zu gestalten und einen sicheren Betrieb zu gewährleisten. Eine Bedrohungsanalyse deckt dabei drei wichtige Schritte bei der Planung einer sicheren Applikation ab:

Optimaler Schutz dank fundierter Expertise
Profitieren Sie von der langjährigen Erfahrung des Expertenteams von Hackmanit und vermeiden Sie nachträgliche zeit- und kostenintensive Anpassungen Ihrer Applikation. Eine Bedrohungsanalyse hilft Ihnen die Sicherheit Ihrer Applikation von vornherein optimal zu gestalten.

Die Wahl der passenden Sicherheits-Technologie ist häufig nicht trivial. Standards werden kontinuierlich weiterentwickelt und Technologien stetig erweitert, so dass es schwer fällt den Überblick der zur Verfügung stehenden Möglichkeiten zu behalten. Die Auswahl der passenden Technologie hängt zudem stark von individuellen Faktoren, wie etwa Ihrem Szenario und Ihren gewünschten Sicherheitsanforderungen, ab.

Eine Bedrohungsanalyse bietet Ihnen die Möglichkeit Ihr Szenario von den Experten von Hackmanit untersuchen zu lassen. Bedrohungen werden hierbei erkannt bevor sie entstehen und Ihnen wird erspart sich zeitaufwendig in verschiedene Technologien einzuarbeiten, bevor Sie sicher sind, welche Technologie für Ihr Szenario die richtige Wahl ist. Der große Nutzen einer Bedrohungsanalyse lässt sich anhand der folgenden Fallbeispiele erläutern.

• Fallbeispiel: Schutz gegen Cross-Site Scripting (XSS)

  

  Wenn Sie sich mit der Sicherheit Ihrer Web-Applikation beschäftigen und die Benutzer optimal vor Angriffen schützen möchten, gibt es zahlreiche Angriffsklassen, die Sie berücksichtigen müssen: Angefangen von Clickjacking und UI-Redressing, über SQL Injection und Cross-Site Request Forgery (CSRF), bis hin zu Cross-Site-Scripting (XSS). Um diese komplexen Angriffsklassen schon bei der Planung und Implementierung zu adressieren, ist es notwendig die Feinheiten jeder Angriffsklasse und passende Gegenmaßnahmen zu kennen. Zudem müssen aktuelle Entwicklungen, wie neu entdeckte Angriffsklassen oder -vektoren und verändertes Verhalten von Web-Browsern, berücksichtigt werden.

  Ein konkretes Beispiel für den nicht trivialen Einsatz von Gegenmaßnahmen ist der X-XSS-Protection HTTP-Header. Dieser galt in der Vergangenheit als eine sinnvolle Maßnahme zur Erhöhung des Schutzes gegen XSS. Im Internet finden sich viele Empfehlungen diesen Header mit dem Wert 1; mode=block auszuliefern. Dieser Wert aktiviert den XSS Filter im Internet Explorer und in Google Chrome und sorgt dafür, dass bei einem erkannten Angriff die Darstellung des gesamten Dokuments verhindert wird. Beispielsweise findet sich diese Empfehlung in dem bekannten HTTP-Header Scanner Mozilla Observatory (Stand: Oktober 2020).

  In Anbetracht der neuen Angriffsklasse “XS-Leaks” ist dieser Wert für den X-XSS-Protection Header jedoch nicht mehr empfehlenswert. Mittels eines XS-Leak-Angriffs können bspw. andere Schutzmechanismen, wie CSRF-Tokens, umgangen werden. Aufgrund dieser Gefahr haben Browserhersteller wie Google den XSS Filter entfernt. Für andere Browser (insbesondere ältere Browser, wie der Internet Explorer) gilt aufgrund der neuen Erkenntnisse: Um im Regelfall den optimalen Schutz zu erhalten, sollte der HTTP-Header X-XSS-Protection auf den Wert 0 gesetzt werden.

  Im Rahmen einer Bedrohungsanalyse können wir Ihnen diese und weitere Gegenmaßnahmen für eine Vielzahl von Angriffsklassen empfehlen - spezifisch für Ihre Applikation angepasst. Unsere Erfahrung hilft Ihnen mögliche Schwachstellen vor der Implementierung zu erkennen und zu vermeiden, ohne, dass Sie sich im Detail in jede Angriffsklasse selbst einarbeiten müssen. Dies erspart Ihnen den Aufwand von Zeit und Kosten ohne dabei Kompromisse bei der Sicherheit Ihrer Applikation und Ihrer Benutzer eingehen zu müssen.

• Fallbeispiel: Erweiterung Ihrer Applikation durch Single Sign-On

  

  Die Benutzung Ihrer Applikation erfordert es, dass sich Benutzer anmelden. Um die Hürde für neue Benutzer zu verringern und Benutzern ein weiteres Paar von Zugangsdaten zu ersparen, planen Sie Ihre Applikation um die Unterstützung für Single Sign-On zu erweitern. Dies bietet sich auch an, wenn Sie mehrere Applikationen betreiben, die von derselben Benutzergruppe verwendet werden und durch einen einzelnen Account verknüpft werden sollen.

  Da die Anmeldung ein sicherheitskritische Vorgang ist, stehen Sie nun vor der Herausforderung sich mit verschiedenen Single Sign-On Lösungen und deren Sicherheit auseinanderzusetzen und zu entscheiden, welches Verfahren das richtige für Ihre Applikation ist.

  Die Standards SAML, OAuth und OpenID Connect sind alle weit verbreitet und kommen in vielen Applikationen zum Einsatz. Jeder der Standards bietet unterschiedliche Protokollvarianten und -erweiterungen für spezielle Szenarien. Daher ergeben sich nach der grundsätzlichen Entscheidung für einen der Standards weitere Fragen, u. a.:

  • Welche Protokollvariante kann ich in meinem Szenario einsetzen?
  • Wie kann ich die Sicherheit der Technologie optimal für meinen Einsatzzweck gestalten?
  • Sind erweiterte Sicherheitsmechanismen, wie PKCE oder Proof-of-Possession Tokens, für mich relevant? Was muss ich beim Einsatz beachten?

  Um Ihnen die Entscheidung für den richtigen Standard zu ermöglichen und spezifische Fragen zu Ihrem Szenario zu beantworten, fertigt Hackmanit eine ausführliche Bedrohungsanalyse für Sie an. Im Rahmen der Analyse betrachtet Hackmanit Ihre Applikation, das individuelle Szenario in der die Applikation zum Einsatz kommt, sowie die von Ihnen definierten Sicherheitsanforderungen im Detail. Die Analyse erspart Ihnen die langwierige Einarbeitung in mehrere Single Sign-On Standards. Zusätzlich hilft eine Bedrohungsanalyse Fallstricke bei der Konzipierung Ihrer Applikation zu vermeiden. So können nachträgliche Anpassungen aufgrund von Sicherheitslücken, die häufig kosten- und zeitintensiv sind, vermieden werden.

• Fallbeispiel: Ablösung des OAuth Implicit Grants

  

  Bei Ihrer Applikation handelt es sich um eine Javascript-basierte Web Applikation - eine sogenannte Single Page Application (SPA). Ihre SPA verwendet OAuth um über APIs auf Daten ihrer Benutzer zuzugreifen. Das hierfür benötigte OAuth Access Token erhält Ihre SPA mittels des OAuth Implicit Grants, bei dem das Access Token in der URL übertragen wird.

  Der Implicit Grant war von Beginn an nur als “Workaround” für SPAs gedacht, da die Same-Origin-Policy (SOP) einen Einsatz des OAuth Authorization Code Grants verhindert hat. Mittels Cross-Origin Resource Sharing (CORS) ist es heute möglich Ausnahmen für die SOP zu definieren, sodass Ihre SPAs nun auf den sicheren Authorization Code Grant zurückgreifen kann. Aufgrund der zahlreichen Nachteile im Bezug auf die Sicherheit, sollte der OAuth Implicit Grant heutzutage grundsätzlich nicht mehr verwendet werden.

  Sie überlegen daher Ihre Applikation zu aktualisieren und den OAuth Implicit Grant durch den OAuth Authorization Code Grant abzulösen. Hierbei stellen sich Ihnen einige Fragen, die durch eine Bedrohungsanalyse beantwortet werden können, u. a.:

  • Warum sollte der OAuth Implicit Grant nicht verwendet werden?
  • Welche Vorteile bringt der Einsatz des Authorization Code Grants?
  • Welche Angriffe werden durch den Wechsel des Grants verhindert?
  • Gibt es sicherheitsrelevante Aspekte, die bei dem Wechsel beachtet werden müssen?

  Durch einen Wechsel auf den Authorization Code Grant werden zahlreiche Angriffe verhindert; bspw. ist die Gefahr, dass das Access Token von einem Angreifer gestohlen wird deutlich geringer, da das Token nicht mehr in der URL übertragen wird. Detaillierte Informationen zu den Angriffen auf den OAuth Implicit Grant finden sich hier.

  Eine Bedrohungsanalyse untersucht welche theoretischen Angriffe in Ihrem Szenario relevant sind und durch den Wechsel des Grants verhindert werden können. Des Weiteren behandelt die Bedrohungsanalyse, was Sie beim Einsatz des Authorization Code Grants beachten müssen und wie Sie Ihre Applikation optimal gegen Angriffe absichern.

• Fallbeispiel: Unterstützung eines zweiten Identity Providers bzw. eines weiteren Social Logins

  

  Sie betreiben erfolgreich eine Applikation, die es den Benutzern erlaubt sich mittels Single Sign-On einzuloggen. Ihre Applikation ist gut abgesichert und ihre Sicherheit wird regelmäßig durch Penetrationstests verifiziert. Zur Zeit unterstützt Ihre Applikation nur einen einzelnen Identity Provider für Single Sign-On - z. B. das Social Login “Google Sign-In”.

  Sie stehen vor der Entscheidung Ihre Applikation um einen weiteren Identity Provider zu erweitern. Dies kann der Fall sein, wenn Sie eine neue Gruppe potentieller Benutzer erschließen möchten oder aufgrund administrativer Vorschriften dazu gezwungen werden einen bestimmten Identity Provider zu unterstützen. Eine Veröffentlichung in Apples App Store erfordert bspw. die Unterstützung von “Sign in with Apple”, sofern Ihre App ein Login mittels Single Sign-On anbietet.

  Bei der Erweiterung um einen zusätzlichen Identity Provider müssen die Auswirkungen auf die Sicherheit betrachtet werden. In einer Bedrohungsanalyse wird die Erweiterung untersucht, um sicherzustellen, dass Ihre Applikation danach weiterhin bestens geschützt ist.

  Durch die parallele Unterstützung mehrerer Identity Provider ergibt sich ein neues Szenario für Ihre Applikation. Die Erweiterung Ihrer Applikation bringt auch eine vergrößerte Angriffsfläche mit sich, da nun weitere Angriffe auf Ihre Applikation anwendbar sind. Ihre Applikation kann verwundbar für spezielle Angriffe sein, die sich den Einsatz mehrerer Identity Provider zunutze machen. Diese Angriffe zielen z. B. darauf ab, dass Protokollvarianten mit unterschiedlichen Identity Providern vermischt werden und ermöglichen einem Angreifer dadurch Zugriff auf fremde Benutzerkonten und -daten. Zusätzlich zu diesen speziellen Angriffen muss nun für jeden einzelnen Identity Provider überprüft werden, welche Protokollvarianten und Sicherheitsmechanismen der Provider unterstützt und wie Ihre Applikation den Provider optimal einbinden kann.

  Eine Bedrohungsanalyse untersucht welche Fallstricke Sie bei der Erweiterung Ihrer Applikation beachten müssen und vermeidet, dass neue Schwachstellen entstehen. Sie erspart Ihnen die mühselige Einarbeitung in komplexe Angriffe und Gegenmaßnahmen und hilft ein “böses Erwachen” bei dem nächsten Penetrationstest zu verhindern.

• Fallbeispiel: Sicherer Einsatz von TLS
  

  

  Transport Layer Security (TLS) ist zu einem sinnvollen Schutz für beinahe jede (Web-)Applikation geworden. Immer wenn Ihre Applikation, beispielsweise eine Webseite, über https besucht wird, kommt im Hintergrund das TLS-Protokoll zum Einsatz. In aktuellen Browsern ist das Protokoll sogar zur Pflicht geworden; Webseiten ohne TLS-Unterstützung werden automatisch als unsicher markiert. Daher möchten Sie bei Ihrer neuen Applikation nicht auf TLS verzichten.

  Die große Bedeutung und der vielfältige Einsatz des TLS-Protokolls hat dazu geführt, dass es stetig um neue Erweiterungen und kryptographische Mechanismen ergänzt wird. Es ist schwierig den Überblick zu behalten und mögliche Fallstricke bei der TLS-Konfiguration zu vermeiden. Bei der Entwicklung Ihrer Applikation stellen sich Ihnen daher viele Fragen bezüglich des korrekten Einsatzes von TLS, u. a.:

  • Welche TLS-Versionen sind sicher? Welche Cipher Suites soll meine Applikation unterstützen?
  • Durch welche Maßnahmen kann ich die Performance von TLS-Verbindungen erhöhen?
  • Wie kann ich bekannte Angriffe auf TLS, wie DROWN, ROBOT oder BREACH, verhindern?
  • Gibt es Bibliotheken oder Frameworks, die ich für meinen spezifischen Anwendungsfall berücksichtigen soll?

  Gängige Tools können die TLS-Konfigurationen Ihrer fertigen Applikation automatisch überprüfen. Diese automatische Analyse bietet Ihnen nicht dieselben Erkenntnisse, wie eine manuelle Bedrohungsanalyse, die vor oder während der Entwicklung durchgeführt wird. Die Ergebnisse der automatischen Tools sind häufig nicht verständlich und beinhalten Meldungen zu Sicherheitslücken, die nicht immer auf Ihre getestete Applikation anwendbar sind. So wird häufig der BREACH-Angriff als Gefahr eingestuft, obwohl dieser in vielen Szenarien nicht relevant ist.

  In unserer manuellen Bedrohungsanalyse hingegen untersuchen wir individuell welche Angriffe und mögliche Schwachstellen auf Ihre Applikation anwendbar sind und wie diese optimal adressiert werden können. Sie profitieren von unserer Erfahrung als Autoren von zahlreichen Angriffen auf TLS (darunter DROWN, ROBOT und Raccoon) und erhalten Antworten auf Ihre spezifischen Fragen zu Ihren Szenarien. Wir helfen Ihnen die kryptographischen Algorithmen und Sicherheitsmechanismen auszuwählen, die Ihre Applikation bestmöglich schützen und performanter machen. Beispielsweise können Mechanismen wie Session Tickets oder die neueste Protokollversion TLS 1.3 eingesetzt werden. Dies verwendet weniger “Round-Trips” und erlaubt es performante kryptographische Verfahren einzusetzen.

Das Expertenteam von Hackmanit verfügt mit seinem Forschungshintergrund über State of the Art Wissen in verschiedenen Themen der IT-Sicherheit. Hackmanit bietet Ihnen die Möglichkeit Sie durch eine Bedrohungsanalyse bei der Planung und dem Einsatz Ihrer Applikation zu unterstützen. In vergangenen Projekten konnte Hackmanit seine Erfahrung und Expertise für verschiedene Unternehmen unter Beweis stellen.

Aus Gründen der Vertraulichkeit können wir Ihnen lediglich eine kleine Auswahl unserer Referenzen zur Verfügung stellen. Überzeugen Sie sich selbst anhand der öffentlichen Analysen, die in Zusammenarbeit mit Rhode und Schwarz Cybersecurity (ehemals Sirrix AG) und dem Bundesamt für Sicherheit in der Informationstechnik (BSI) durchgeführt wurden.

• Interoperability between Messaging Services: Secure Implementation of Encryption, Bundesnetzagentur (Link, PDF)
• Sichere Implementierung einer allgemeinen Kryptobibliothek, Bundesamtes für Sicherheit in der Informationstechnik (PDF)
• Quellcode-basierte Untersuchung von kryptographisch relevanten Aspekten der OpenSSL-Bibliothek, Bundesamtes für Sicherheit in der Informationstechnik (Link)

Sie sind unsicher, ob eine Bedrohungsanalyse die richtige Maßnahme für Sie ist? Gerne erörtern wir Ihnen in einem unverbindlichen Beratungsgespräch individuelle Optionen, wie Sie Ihre Applikation sicher gestalten können.

Ihr Ansprechpartner für Bedrohungsanalysen

Prof. Dr. Juraj Somorovsky
juraj.somorovsky@hackmanit.de