IT-Security im Web

Die Top 10 Sicherheitsrisiken bei Webanwendungen

Anlässlich des Safer Internet Days am 7. Februar möchten wir uns dem Thema Security im Kontext von Webseiten und Webanwendungen ausführlicher widmen. Nicht nur als User:in muss man sich über potenzielle Gefahren im Internet bewusst sein, sondern auch bei der Planung, Umsetzung und im Betrieb von Webprojekten gibt es eine Vielzahl an Sicherheitsrisiken, die zu beachten sind. Denn nur, wenn man potenzielle Sicherheitsprobleme kennt, kann man sich dagegen absichern.

OWASP #

Sicherheit wird in der Webentwicklung glücklicherweise sehr ernst genommen. Es gibt viele Sicherheitsexpert:innen und ‑forscher:innen, die sich ausführlich mit dem Thema beschäftigen und ihre Ergebnisse der Community zur Verfügung stellen. Eine gute Quelle, um sich über sicherheitsrelevante Themen für Webanwendungen zu informieren, ist die OWASP® — Open Web Application Security Project — Foundation. Neben Informationen, News und Trainings zu sicherheitsrelevanten Themen, stellt OWASP auch die Liste der Top Ten Web Application Security Risks zur Verfügung — eine Auflistung der zehn kritischsten Sicherheitslücken in Web Applikationen. Diese Liste wollen wir hier vorstellen, um einerseits Bewusstsein darüber zu schaffen, aber auch um einen Einblick zu geben, welche Sicherheitsvorkehrungen und ‑überlegungen bei jedem unserer Projekte im Hintergrund beachtet werden.

Top Ten Security Risks #

Im Folgenden geben wir einen komprimierten Überblick und eine kurze, zusammenfassende Beschreibung der aktuellen Top Ten Sicherheitsrisiken im Web. Unser Ziel ist es primär, ein Bewusstsein für diese Risiken zu schaffen, ohne dabei zu sehr auf technische Hintergründe einzugehen. Wenn Sie die angesprochenen Themen interessieren, empfehlen wir den Links zu OWASP zu folgen, um detailliertere Informationen zu erhalten.

Hier sind sie, die 10 kritischsten Sicherheitsrisiken:

1. Broken Access Control #

Die Nummer eins der kritischtsen Sicherheitsrisiken in modernen Webprojekten beschreibt Probleme oder Lücken bei der Zugriffskontrolle. Das bedeutet, dass eine Applikation Berechtigungen nicht oder nicht ausreichend prüft. Als Beispiel für ein Broken Access Control Problem können Sie sich einen Löschen-Button vorstellen, der im Frontend für den User deaktiviert ist, jedoch serverseitig nicht geprüft wird. Wenn ein:e Benutzer:in den Button manuell aktiviert und klickt, wird die Ressource gelöscht, obwohl diese:r User:in nicht zum Löschen berechtigt gewesen wäre. Probleme bei der Zugriffskontrolle wurden auf 94 % der getesteten Web-Applikationen festgestellt und sind damit die am weitesten verbreitetste Sicherheitslücke (unter den getesteten Anwendungen).

Weiterführende Informationen zu Broken Access Control findet ihr hier.

2. Cryptographic Failures #

Das zweitkritischste Risiko umfasst die Verschlüsselung sensibler Daten. Hierunter zusammengefasst werden u.a. die fehlende oder nicht ausreichende Verschlüsselung von Daten wie zum Beispiel personenbezogener Daten lt. DSGVO, Kreditkartendaten oder Finanzdaten (sowohl während der Kommunikation als auch der Speicherung), das Verwenden veralteter oder schwacher Verschlüsselungsalgorithmen, als auch die nicht ordnungsgemäße Aufbewahrung von Sicherheitsschlüssen und ‑zertifikaten.

Weiterführende Informationen zu Cryptographic Failures findet ihr hier.

3. Injection #

Injection beschreibt grob das Einschleusen von Schadcode in eine Anwendung oder ein System. Dieser Risikotyp entsteht vor allem dann, wenn Benutzereingaben und Parameter nicht oder nicht ausreichend validiert und gefiltert werden. Bekannte Vertreter für Injection Angriffe sind sogenannte SQL Injections. Hierbei bringt ein:e Angreifer:in durch einen manipulierten Parameter eine SQL Datenbank Abfrage dazu, zusätzliche oder anderer Informationen abzufragen als gewollt.

Weiterführende Informationen zu Injection findet ihr hier.

4. Insecure Design #

Insecure Design beschreibt eine breite Kategorie an Risiken und Problemen, die in der Planung einer Applikation auftreten. Diese Kategorie beschreibt primär Risiken, die durch falsche Annahmen oder unvollständige Anforderungen entstehen. Ein Beispiel hierfür ist das Verwenden von Sicherheitsfragen und ‑antworten im Passwort-Zurücksetzen-Prozess. Die Verwendung von Fragen und Antworten ist ein Sicherheitsrisiko, auch wenn sie perfekt und fehlerfrei implementiert wird.

Weiterführende Informationen zu Insecure Design findet ihr hier.

5. Security Misconfiguration #

Security Misconfiguration ist eine weitere breite Kategorie, die viele verschiedene Probleme zusammenfasst. Generell handelt es sich hierbei um Probleme, bei denen einzelne Teile eines Systems durch falsche oder unvollständige Konfiguration angreifbar sind. Beispiele in dieser Risikokategorie sind u.A. fehlende oder falsche konfigurierte Dienste und Services, wie z.B. Cloud Services, Webserver, etc. Aktivierte bzw. installierte, jedoch nicht notwendige Services, Anwendungen oder Ports, unveränderte Standardbenutzernamen und ‑passwörter und veraltete oder nicht upgedatete Software.

Weiterführende Informationen zu Security Misconfiguration findet ihr hier.

6. Vulnerable and Outdated Components #

Verwundbare und veraltete Komponenten umfasst das Risiko, das durch externe Plugins, Pakete und Systeme entsteht, wenn diese nicht regelmäßig geprüft und zeitnah upgedatet werden. Aber auch der Prozess an sich, der sicherstellt, dass Verwundbarkeiten und Updates zeitnah erkannt und entsprechende Updates eingespielt werden, wird hier als Risikofaktor berücksichtigt.

Weiterführende Informationen zu Vulnerable and Outdated Components findet ihr hier.

7. Identification and Authentication Failures #

Dieses Risiko beschreibt die Authentifizierung eines Users bzw. einer Userin, die nicht oder nicht ausreichend geprüft bzw. gesichert ist. Auch dieser Punkt fasst eine Reihe an Problemen zusammen, die alle dazu führen, dass sich ein:e Angreifer:in unrechtmäßig als Benutzer:in ausgeben kann.

Weiterführende Informationen zu Identification and Authentication Failures.

8. Software and Data Integrity Failures #

Punkt 8 beschreibt eine Reihe an Sicherheitsproblemen, wie das Verwenden von Plugins, Libraries und Modulen aus unsicheren Quellen oder CDNs, unsichere automatisierte Pipelines oder ungesicherte Auto-Updater. Diese Probleme können es Angreifer:innen ermöglichen, falsche Pakete oder Updates bereitzustellen und damit Schadcode in die Anwendung einzuschleusen.

Weiterführende Informationen zu Software and Data Integrity Failures findet ihr hier.

9. Security Logging and Monitoring Failures #

Dieses Sicherheitsproblem beschreibt das fehlende bzw. nicht zureichende Aufzeichnen und Überwachen von Aktivitäten in der Anwendung. Genauer gesagt, die daraus bestehenden Problematik, Datenlecks und Einbrüche nicht erkennen und darauf reagieren zu können.

Weiterführende Informationen zu Security Logging and Monitoring Failures.

10. Server-Side Request Forgery (SSRF) #

Eine SSRF-Sicherheitslücke entsteht, wenn eine serverseitige Webapplikation dazu gebracht wird, Inhalte von einer, durch den Benutzer festgelegten, URL zu laden, ohne diese URL ausreichend zu prüfen. Dadurch kann es einem Angreifer bzw. einer Angreiferin zum Beispiel möglich sein, Einstellungen auszulesen oder interne Services zu erreichen, die nicht öffentlich zugänglich sein sollten.

Weiterführende Informationen zu Server-Side Request Forgery (SSRF).

IT-Security als wichtige Komponente in jedem Projekt #

Mit diesem Artikel wollten wir vor allem Awareness schaffen und potenzielle Schwachstellen in Webprojekten aufzeigen. Unser Fokus bei bitperfect liegt klar auf der Entwicklung von individuellen Web- und Softwarelösungen. IT-Security ist damit zwar nicht unser spezifisches Kerngebiet, dennoch ist es ein wesentlicher Aspekt, der in jedem unserer Projekt einfließt, um robuste Lösungen für unsere Kund:innen zu schaffen.