Spickzettel: Die 10 wichtigsten Abkürzungen der Anwendungssicherheit
1. Dezember 2020
0 Min. LesezeitStellen Sie sich folgende Situation vor: Sie sind als Entwickler in einem Meeting, in dem ein Security-Experte die Ergebnisse eines kürzlich durchgeführten Penetrationstests oder einer statischen Codeanalyse bespricht.
Im Laufe des Gesprächs verwendet die Person verschiedene Abkürzungen und setzt voraus, dass Sie deren Bedeutung kennen. Tatsächlich sind Ihnen diese Begriffe jedoch nicht vertraut. Kommt Ihnen das bekannt vor? Leider kommt das in vielen DevSecOps-Organisationen häufig vor. Auch wir bei Snyk sind in diese Falle getappt: Bei unserer kürzlich erfolgten Ankündigung der SAST-Funktionen von Snyk erhielten wir in den sozialen Medien viel Feedback von Menschen, die nicht wussten, was SAST bedeutet. Deshalb dachten wir, ein Spickzettel mit den 10 wichtigsten Abkürzungen im Bereich Sicherheit wäre eine gute Idee. Und keine Sorge: SAST ist auch dabei. Lesen Sie weiter, um mehr zu erfahren.
DAST – Dynamic Application Security Testing
SCA – Software Composition Analysis
OWASP – Open Web Application Security Project
XSS – Cross-Site Scripting
CSRF – Cross-Site Request Forgery
RASP – Runtime Application Self-Protection
DoS – Denial of Service
CSP – Content Security Policy
SSRF – Server Side Request Forgery
1. SAST – Static Application Security Testing
Static Application Security Testing, kurz SAST, bezeichnet die Analyse des Quellcodes einer Anwendung, eines Dienstes, eines Microservices usw., um potenzielle Sicherheitslücken zu erkennen, die durch unsichere Programmierpraktiken entstehen. SAST wird meist mit automatisierten Tools durchgeführt, die den Quellcode nach Programmiermustern, unsicheren Funktionen oder unsicheren Objekten durchsuchen, die zu Sicherheitslücken führen könnten. SAST dient vor allem dazu, Schwachstellen in neu entwickeltem Code zu finden. Die Analyse erfolgt üblicherweise während der Programmierphase oder dann, wenn Code in eine Testumgebung überführt wird.
Ein wesentlicher Vorteil von SAST ist, dass Sicherheitslücken früh im Entwicklungsprozess erkannt werden können. Außerdem lassen sich verborgene Schwachstellen finden, die allein durch die Betrachtung der Anwendungsfunktionen unentdeckt bleiben könnten. Automatisierte SAST-Tools können große Mengen an Code sehr schnell analysieren. Dadurch erzeugen sie jedoch auch viele Ergebnisse, die oft Fehlalarme oder Schwachstellen enthalten, die im Kontext der Anwendung gar kein echtes Risiko darstellen. Bei manchen Tools kann es viel Zeit kosten, sie so einzustellen, dass solche Probleme ausgeschlossen werden. Dennoch sind diese Tools für Ihre Sicherheitslage unverzichtbar.
2. DAST – Dynamic Application Security Testing
Dynamic Application Security Testing, kurz DAST, bezeichnet die Analyse einer laufenden Anwendung oder eines Dienstes auf Sicherheitslücken. DAST soll Angriffe nachahmen, die ein böswilliger Nutzer über die Benutzer- oder Anwendungsschnittstelle ausführen könnte. Der Vorteil dieses Ansatzes besteht darin, dass sich komplexe Schwachstellen erkennen lassen, die durch bestimmte Funktionen der Anwendung entstehen und bei einer reinen Quellcodeanalyse möglicherweise übersehen werden.
Bei DAST wird die Schnittstelle auf verschiedene Anzeichen für Schwachstellen untersucht. Dazu wird geprüft, wie die Anwendung auf unterschiedliche Anfragen und Eingaben (häufig als Payloads bezeichnet) reagiert. Von Eingabefeldern für Nutzer bis hin zu HTTP-Headern wird alles daraufhin untersucht, ob eine angemessene Datenverarbeitung und geeignete Sicherheitsmaßnahmen implementiert wurden, um zu verhindern, dass Angreifer die Anwendung oder den Dienst manipulieren.
Für DAST können automatisierte, teilautomatisierte und manuelle Tools eingesetzt werden. Vollautomatisierte DAST-Tools können üblicherweise die verschiedenen Seiten einer Anwendung erfassen und mit unterschiedlichen Payload-Varianten auf zahlreiche potenzielle Sicherheitslücken testen. Oft können diese Tools auch Webdienste und Microservices testen. Andere DAST-Tools sind stärker spezialisiert und analysieren eine oder wenige bestimmte Arten von Schwachstellen besonders gründlich. DAST wird üblicherweise in späten Testphasen durchgeführt, kurz bevor eine Anwendung oder ein Dienst in einer Produktionsumgebung bereitgestellt wird.
Weitere Informationen zu den Unterschieden zwischen SAST und DAST finden Sie auf unserer Snyk-Learn-Seite SAST vs. DAST.
3. SCA – Software Composition Analysis
Software Composition Anlaysis, kurz SCA, bezeichnet die Analyse einer Anwendung, um darin enthaltene Softwarekomponenten von Drittanbietern oder aus Open-Source-Projekten zu ermitteln. In der Regel umfasst SCA auch die Analyse dieser externen Abhängigkeiten auf bekannte Sicherheitslücken und mögliche Lizenzprobleme. Automatisierte SCA-Tools wie Snyk OpenSource können üblicherweise den gesamten Abhängigkeitsbaum abbilden. Dabei untersuchen sie nicht nur die Einbindungen im Quellcode der Anwendung, sondern auch die Abhängigkeiten jeder einzelnen Abhängigkeit und so weiter.
Software Composition Analysis kann in jeder Phase der Bereitstellungspipeline durchgeführt werden. In der Regel empfiehlt es sich jedoch, möglichst früh damit zu beginnen, häufig bereits während der Programmierphase, damit auftretende Probleme schnell behoben werden können. Ein wichtiger Grund für SCA ist nicht nur, potenzielle Sicherheitslücken zu erkennen, die durch Drittanbieterkomponenten während der Anwendungsentwicklung entstehen. Unternehmen können damit auch schnell feststellen, ob sie von neu bekannt gegebenen Sicherheitslücken in Drittanbieter- oder Open-Source-Software betroffen sind, und zeitnah Maßnahmen zur Behebung planen.
4. OWASP – Open Web Application Security Project
Das Open Web Application Security Project, kurz OWASP, ist eine gemeinnützige Organisation, die sich mit der Sicherheit von Software befasst. OWASP ist für zahlreiche von der Community getragene Projekte bekannt, die Wissen und Orientierungshilfe dazu bieten, wie sich sicherere Software entwickeln lässt. OWASP bringt eine große Community aus Freiwilligen zusammen, die diese Projekte und Lernmaterialien zum Nutzen der gesamten Security- und Softwareentwicklungs-Community vorschlagen, entwickeln und betreuen.
Zu den bekanntesten Projekten gehört die OWASP Top 10, eine regelmäßig anhand von Beiträgen aus der Community aktualisierte Liste der zehn häufigsten Arten von Sicherheitslücken in Webanwendungen. Bei SAST- oder DAST-Analysen hören Sie möglicherweise, dass die OWASP Top 10 als Orientierung für die Arten von Schwachstellen dienen, nach denen Tester suchen. Die Liste deckt zwar nicht alle möglichen Arten von Schwachstellen ab, bietet aber einen guten Ausgangspunkt.
OWASP veranstaltet außerdem weltweit verschiedene Sicherheitskonferenzen und unterhält regionale Chapters, die sich regelmäßig treffen, um Ideen auszutauschen, an Projekten zu arbeiten und Wissen weiterzugeben. Einzelne Projekte veranstalten gelegentlich auch eigene Gipfeltreffen, bei denen Fachleute und Projektmitglieder zusammenkommen, um Aspekte der Projekte zu diskutieren und weiterzuentwickeln.
5. XSS – Cross-Site Scripting
Cross-Site Scripting, kurz XSS, ist eine häufig in Webanwendungen auftretende Art von Sicherheitslücke. XSS steht bereits seit der ersten Veröffentlichung im Jahr 2003 auf der OWASP Top 10. Bei dieser Art von Anwendungsangriff kann ein Angreifer bösartigen Skriptcode (meist JavaScript) im Browser eines oder mehrerer Nutzer ausführen. Dadurch können vertrauliche Informationen wie Sitzungsdaten oder personenbezogene Daten abgegriffen werden.
Üblicherweise werden drei Arten von XSS unterschieden:
Reflected: Der Angreifer veranlasst einen Nutzer, eine Anfrage mit der Angriffspayload an die Anwendung zu senden. Die Anwendung fügt diese in die Antwort ein, wodurch sie im Browser ausgeführt wird.
Stored: Der Angreifer sendet die Angriffspayload an die Anwendung. Dort wird sie in einem Wert gespeichert, der anderen Nutzern als Teil dynamisch erstellter Seiten zurückgegeben wird. Dadurch wird das Skript in deren Browsern ausgeführt.
DOM-based: Der Angreifer sendet dem Nutzer das bösartige Skript (meist in einem schädlichen Link). Es wird direkt im DOM der Seite ausgeführt, ohne die Anwendung überhaupt zu durchlaufen.
Weitere Informationen zu XSS und dazu, wie Sie sich davor schützen können, finden Sie auf unserer XSS-Seite bei Snyk Learn.
6. CSRF – Cross-Site Request Forgery
Cross-Site Request Forgery, kurz CSRF, ist eine weitere häufige Form von Webanwendungsangriffen. Bei einem CSRF-Angriff nutzt der Angreifer eine bereits authentifizierte Sitzung zwischen dem Browser des Nutzers und der Anwendung aus. So kann er Funktionen der Anwendung über Anfragen ausführen, die in einer vom Angreifer kontrollierten, schädlichen Website eingebettet sind. CSRF wird manchmal auch als Session Riding bezeichnet; manche sprechen es als „C-Surf“ aus.
Bei Cross-Site Request Forgery wird häufig eine gültige Anfrage an die Zielanwendung abgefangen und im Browser des Opfers erneut ausgelöst, während dort eine aktive authentifizierte Sitzung mit der Zielanwendung besteht. Ein Angreifer könnte zum Beispiel eine Anfrage aus einer Online-Banking-Anwendung abfangen, mit der eine Überweisung ausgeführt wird. Anschließend erstellt er eine schädliche Website und bindet dieselbe Anfrage in einen IFRAME ein. Jeder, der die Website besucht, würde dadurch dieselbe Anfrage an die Banking-Anwendung senden. Hat der Besucher dort eine aktive Sitzung – möglicherweise in einem anderen Browser-Tab –, würde die Anfrage im Rahmen dieser Sitzung ausgeführt. Um Besucher auf die Website zu locken, würde der Angreifer wahrscheinlich eine gezielte Phishing-Kampagne einsetzen, die Kunden der Bank und damit potenzielle Nutzer der Banking-Anwendung anspricht.
Weitere Informationen zu Cross-Site Request Forgery und dazu, wie Sie sich davor schützen können, finden Sie auf unserer CSRF-Seite bei Snyk Learn.
7. RASP – Runtime Application Self-Protection
Runtime Application Self-Protection, kurz RASP, bezeichnet eine in eine Anwendung integrierte Schutztechnik, mit der die Anwendung Angriffe erkennen und sofort darauf reagieren kann. RASP wird meist mithilfe von Tools von Drittanbietern implementiert. RASP-Tools werden in der Regel in die Anwendung integriert. Sie überwachen nicht nur eingehende Anfragen, sondern auch das Verhalten der Anwendung, um Angriffe zu erkennen und zu verhindern. Dafür können Pakete, Bibliotheken oder Plug-ins eingesetzt werden, die wie ein Filter vor der Anwendung Anfragen und das Anwendungsverhalten untersuchen. Der wichtigste Vorteil von RASP: Selbst wenn die Anwendung Sicherheitslücken enthält, kann ein Angreifer diese nicht erfolgreich ausnutzen – oder die Auswirkungen eines Angriffs lassen sich zumindest erheblich begrenzen.
8. DoS – Denial of Service
Denial of Service, kurz DoS, ist eine Art von Angriff, bei dem ein Angreifer die Verfügbarkeit einer Anwendung oder eines Dienstes einschränken oder verhindern will. Häufig wird dafür gesorgt, dass die Anwendung, der Dienst oder das System nicht mehr oder nur noch extrem langsam reagiert. Alternativ kann die Netzwerkinfrastruktur angegriffen werden, über die die Anwendung kommuniziert. DoS-Angriffe sind möglich, wenn ein Angreifer eine Schwachstelle im Code, in der Systemsoftware oder in der Netzwerkinfrastruktur einer Anwendung ausnutzt, um sie für andere unzugänglich zu machen. Es gibt viele Möglichkeiten, einen DoS-Angriff durchzuführen. Zwei bestimmte Arten werden jedoch besonders häufig besprochen:
DDoS: Bei einem Distributed Denial of Service setzt ein Angreifer eine große Anzahl von Systemen ein (meist Teil eines Botnets), um ein Ziel mit Datenverkehr zu überlasten und dadurch unerreichbar zu machen.
REDoS: Regular Expression Denial of Service ist eine bestimmte Schwachstelle, die häufig in serverseitigen JavaScript-Anwendungen vorkommt. Ein Angreifer kann damit die Engine für reguläre Ausdrücke dazu bringen, große Mengen an Ressourcen zu verbrauchen, sodass die Anwendung nicht mehr reagiert.
9. CSP – Content Security Policy
Content Security Policy (CSP) ist eine Gegenmaßnahme für Webanwendungen, die XSS-Angriffe verhindern soll. Sie ermöglicht es Anwendungsentwicklern, den Browser mithilfe eines HTTP-Headers anzuweisen, Skripte nur aus bestimmten Quellen zu laden und auszuführen. Indem verhindert wird, dass Skripte aus nicht vorgesehenen Quellen geladen werden, können Anwendungsentwickler verhindern, dass über einen XSS-Angriff eingeschleuste Skripte ausgeführt werden, sobald sie den Browser erreichen.
Weitere Ressourcen und Informationen zu CSP finden Sie in unserem Blog.
10. SSRF – Server-Side-Request-Forgery
Server-Side-Request-Forgery (SSRF) ist eine Form des Anwendungsangriffs, bei der ein Angreifer die Frontend-Anwendung dazu bringen kann, Anfragen an beliebige Ziele zu senden – etwa an andere interne oder externe Server oder sogar an sich selbst. Dadurch kann der Angreifer auf nicht autorisierte Daten oder Funktionen zugreifen.
Weitere Informationen zu SSRF finden Sie in diesem Leitfaden von OWASP.
Zusammenfassung
Wie in jeder Branche gibt es auch in der IT-Sicherheit viele Fachbegriffe, die zur Vereinfachung der Kommunikation häufig zu Abkürzungen werden. Das kann für Personen außerhalb des Security-Bereichs verwirrend sein. Für Entwickler kann es ein wichtiger Schritt hin zu einer besseren Zusammenarbeit in der DevSecOps-Delivery-Pipeline sein, die Begriffe zu verstehen, die ihre Security-Partner verwenden.
Laden Sie jetzt den Spickzettel mit den 10 wichtigsten Abkürzungen in der Anwendungssicherheit herunter!
