1. Webanwendungen
Heutzutage ist ein Alltag ohne Web kaum noch vorstellbar. Besonders im Consumer-Bereich hat sich das Web als unverzichtbares Medium etabliert. Aber auch Geschäftsprozesse sowie der Austausch zwischen Bürger und Behörde lagert sich zunehmend in das Internet aus. Angefangen bei der Suche nach Informationen, sozialer Vernetzung, über das Lesen/Senden von E-Mails bis hin zum Online-Shopping, Internet-Banking oder Auktionen – all diese Anwendungszwecke gelten als selbstverständlich und werden im Hintergrund durch Webanwendungen realisiert.
Aufgrund ihrer globalen Erreichbarkeit ziehen Webanwendungen nicht nur interessierte Anwender an, sondern sind gleichzeitig ein begehrtes Angriffsziel. Zweckendfremdete Webanwendungen werden für Spam, Phishing und sonstige Zwecke missbraucht. Daneben stehen Kreditkartennummern und Kundendaten ganz oben auf dem Wunschzettel der Angreifer. Etablierte Sicherheitsmaßnamen wie Firewalls bieten dagegen kaum Schutz.
In der Artikelserie „Sicherheit von Webanwendungen“ möchte ich auf Folgendes eingehen:
- Warum Webanwendungen ein Risiko darstellen.
- Auf welchen Ebenen eine Webanwendung verwundbar ist.
- Welche Informationen möchten Angreifer ausspähen.
- Welche typischen Angriffsszenarien auf Webanwendungen existieren.
- Maßnahmen und Tools zur Erhöhung der Sicherheit vorstellen.
- Risiko Webanwendung – Sicherheit von Webanwendungen Teil1
- Klassifizierungsmodell – Sicherheit von Webanwendungen Teil2
- Angriffstechniken – Sicherheit von Webanwendungen Teil3
- Penetrationstest – Sicherheit von Webanwendungen Teil4
2. Risiko Webanwendung
Noch vor Jahren waren schlecht konfigurierte Firewalls und Fehler in den Systemen für eine Großzahl von Einbrüchen in Firmennetzwerke verantwortlich. Heute bilden Webanwendungen das Haupteinfallstor für Angreifer. Angetrieben von der Idee Geschäftsprozesse zu vereinfachen, zu beschleunigen und damit letztendlich die Produktivität zu erhöhen, unterschätzen Unternehmen das Risiko von Webanwendungen. Im Vordergrund stehen Wettbewerbsvorteile, Kosteneinsparungen und die Eröffnung neuer Geschäftsfelder. All diese Vorteile möchte man sich zu Nutzen machen ohne die damit verbundenen Risiken genauer zu analysieren.
2.1 Warum ein Risiko?
Oftmals sind Webanwendungen individuell entwickelt und nicht annähernd auf Fehler getestet wie es bei Standardsoftware der Fall ist. Im Normfalfall besitzen sie eine direkte Verbindung zum internen Datenbankserver, also auf jene sensible Daten die noch vor Jahren wie Fort Knox geschützt wurden. In der Annahme Firewalls würden den erforderlichen Schutz bieten werden Webanwendungen ohne zusätzliche Absicherung in die Prozesskette eines Unternehmens integriert.
Laut den Angaben des Data Breach Investigation Report 2012 von Verizon Business gingen im Jahr 2011 54% aller Hackereinbrüche in größeren Unternehmen auf Schwachstellen in Webanwendungen zurück. Web-/Anwendungsserver und Datenbankserver sind dabei die am stärksten kompromittierten Ziele. Rund 82% – 98% aller entwendeten Datensätze sind auf diese Angriffskategorie zurückzuführen.
Hilf mit die Spendenziele zu erreichen!
Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.
Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.
2.2 Die Ursachen
Für die Benutzung müssen Webanwendungen notwendigerweise im Internet sichtbar sein und meist auch rund um die Uhr. Das macht sie attraktiv – gerade für Angreifer. Diese verschaffen sich mit teils simplen Mitteln Zugang zu den Systemen und den dahinterliegenden Unternehmensdaten. Hauptursache sind Programmierfehler bzw. das fehlende Bewusstsein für eine sichere Anwendungsentwicklung. Und Webanwendungen bieten aufgrund ihrer Komplexität eine Vielzahl von Möglichkeiten für Programmierfehler. In erster Linie muss die Webanwendung den unbemerkten Abfluss von sensiblen Daten verhindern.
Weitere Ursachen sind neben den Programmierfehlern die fehlende Sensibilität für weitere Schutzmaßnahmen. Dazu gehören beispielsweise die SSL-verschlüsselte Kommunikation, insbesondere bei der Authentifizierung, als auch die Absicherung der Komponenten wie Webserver und Datenbankserver. Eine zusätzliche Sicherungslinie kann durch Web Application Firewalls (WAFs) errichtet werden.
3. Open Web Application Security Project (OWASP)
Die OWASP ist eine offene Community die sich zum Ziel gesetzt hat, die Sicherheit von Anwendungen und Diensten im Internet zu verbessern. Bekannt geworden durch die Top-10 Liste der größten Risiken für Webanwendungen. Für 2013 hat die OWASP ihre Liste aktualisiert. Ein beispielhafte Erklärung von diesen Angriffsszenarien wird Bestandteil der Artikelserie sein:
- A1 Injection
- A2 Broken Authentication and Session Management (2010 A3)
- A3 Cross-Site Scripting (XSS) (2010 A2)
- A4 Insecure Direct Object References
- A5 Security Misconfiguration (2010 A6)
- A6 Sensitive Data Exposure (merged from former A7 Insecure Cryptographic Storage and former A9 Insufficient Transport Layer Protection)
- A7 Missing Function Level Access Control (renamed/broadened from former A8 Failure to Restrict URL Access)
- A8 Cross-Site Request Forgery (CSRF) (2010 A5)
- A9 Using Known Vulnerable Components (new but was part of former A6 – Security Misconfiguration)
- A10 Unvalidated Redirects and Forwards
Des Weiteren bietet die OWASP Guidlines und Informationen für die sichere Entwicklung von Webanwendungen. Dazu gehört beispielsweise die Enterprise Security API – eine offene Bibliothek, die es Programmieren erleichtern soll sichere Anwendungen zu entwickeln. Ergänzt durch zahlreiche Konferenzen erhöht die OWASP die Notwendigkeit für Secure Coding Guidlines und schärft die Sensibilität bei den Entwicklern.
4. Maßnahmen – Kurz angerissen
Durch entsprechende Maßnahmen kann die Sicherheit von Webanwendungen erhöht werden. Im weiteren Verlauf der Artikelserie werde ich darauf detailliert eingehen und Möglichkeiten vorstellen, wie dies in der Praxis umgesetzt werden kann. Mein Fokus liegt dabei nicht auf der Beschreibung von sicheren Programmiermethoden oder Guidlines – dazu bietet die OWASP bereits genügend Informationen. Im Mittelpunkt stehen folgende Maßnahmen:
- Web Application Firewalls
- Penetrationstests mit diversen Tools
- Tipps zur Absicherung von Systemen
5. Fazit
Webanwendungen sind ein begehrtes Ziel für Cyberangriffe. Sie sind nahezu ständig erreichbar und bieten interessante Möglichkeiten für Angreifer. Und durch die zunehmende Verbreitung mobiler Endgeräte (Smartphones, Tablets) wird die Verbreitung und Relevanz von Webanwendungen weiterhin zunehmen.
Grundlegend sollte die Sicherheit von Anwendungen ein Bestandteil der Softwarequalität sein. Unternehmen die Webanwendungen entwickeln sollten dies bei der Konzeption beachten und dies insbesondere auch in der Budgetplanung berücksichtigen. Awarness-Workshops können IT-Verantwortliche / das Management für das Risiko von Webanwendungen sensibilisieren. Die OWASP bietet dazu weitreichende Informationen an.
Hauptsächlich wird die Sicherheit von Webanwendungen durch die Programmierung bestimmt. In der Artikelserie werde ich weitere Maßnahmen vorstellen, welche die Sicherheit nachträglich erhöhen und zum Schutz beitragen können. Der kommende Beitrag wird sich mit einem Modell beschäftigen, welches die Verwundbarkeiten von Webanwendungen in Ebenen klassifiziert. Weiterhin werde ich aufzeigen, welche Ziele für Angreifer besonders interessant sind und welche Absichten sie verfolgen.
Bildquellen:
pianoBrad: „Bee“, https://openclipart.org/detail/63127/bee
Verizon: „Hacking vectors“, https://www.wired.com/images_blogs/threatlevel/2012/03/Verizon-Data-Breach-Report-2012.pdf
OWASP: „Logo“, https://www.owasp.org/index.php/Main_Page
Hans: „Wire“, https://pixabay.com/en/barbed-wire-fence-barbed-wire-fence-6904/
Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:
Abschließender Hinweis
Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.