Die 10 wichtigsten Application-Security-Abkürzungen

Spickzettel

Die 10 wichtigsten Abkürzungen im Bereich Anwendungssicherheit erklärt

1. SAST – Static Application Security Testing (statische Anwendungssicherheitstests)

2. DAST – Dynamic Application Security Testing (dynamische Anwendungssicherheitstests)

3. SCA – Software Composition Analysis (Analyse der Softwarezusammensetzung)

4. OWASP – Open Web Application Security Project

5. XSS – Cross-Site Scripting

6. CSRF – Cross-Site Request Forgery

7. RASP – Runtime Application Self-Protection

8. DoS – Denial of Service

9. CSP – Content Security Policy

10. SSRF – Server Side Request Forgery

Stellen Sie sich folgende Situation vor: Sie sind Entwickler und nehmen an einer Besprechung teil, in der ein Security-Experte die Ergebnisse eines kürzlich durchgeführten Penetrationstests oder einer statischen Analyse des von Ihnen geschriebenen Codes bespricht.

Während des Gesprächs verwendet die Person verschiedene Abkürzungen aus dem Bereich Anwendungssicherheit und setzt einfach voraus, dass Sie deren Bedeutung kennen. Tatsächlich sind Ihnen diese Begriffe aber nicht vertraut. Kommt Ihnen das bekannt vor? Leider ist das in vielen DevSecOps-Organisationen keine Seltenheit. Auch wir bei Snyk sind mit unserer jüngsten Ankündigung der SAST-Funktionen von Snyk in diese Falle getappt. In den sozialen Medien erhielten wir viele Rückmeldungen von Menschen, die nicht wussten, was SAST bedeutet. Deshalb dachten wir, es wäre sinnvoll, einen Spickzettel mit den zehn gängigsten Security-Abkürzungen zusammenzustellen. Und keine Sorge: SAST ist auch dabei. Lesen Sie weiter, um mehr zu erfahren.

1. SAST – Static Application Security Testing

Static Application Security Testing (statische Anwendungssicherheitstests), 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 mithilfe automatisierter Tools umgesetzt, 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 erkennen. Die Analyse findet üblicherweise während der Programmierphase oder dann statt, wenn der Code in eine Testumgebung überführt wird.

Ein wichtiger Vorteil von SAST ist, dass Schwachstellen früh im Entwicklungsprozess erkannt werden können. Außerdem lassen sich verborgene Schwachstellen aufdecken, die bei einer reinen Betrachtung der Anwendungsfunktionen möglicherweise unentdeckt bleiben. Automatisierte SAST-Tools können große Mengen an Code sehr schnell analysieren. Dadurch können sie jedoch auch zahlreiche Ergebnisse liefern, die oft falsch positive Befunde oder Schwachstellen enthalten, die im Kontext der Anwendung tatsächlich kein Risiko darstellen. Bei manchen Tools kann es viel Zeit kosten, sie entsprechend anzupassen und diese Probleme zu beseitigen. Dennoch sind solche 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 laufenden Dienstes auf Sicherheitslücken. DAST soll die Arten von Angriffen nachahmen, die ein Angreifer über die Benutzer- oder Anwendungsschnittstelle gegen die Anwendung ausführen könnte. Dieser Ansatz kann komplexe Schwachstellen aufdecken, die sich aus bestimmten Funktionen der Anwendung ergeben 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 – oft als Payloads bezeichnet – reagiert. Von Eingabefeldern bis hin zu HTTP-Headern wird alles daraufhin untersucht, ob geeignete Maßnahmen zur Datenverarbeitung und Sicherheitsvorkehrungen umgesetzt wurden, um Angreifer daran zu hindern, die Anwendung oder den Dienst zu manipulieren.

Für DAST können automatisierte, halbautomatisierte und manuelle Tools eingesetzt werden. Vollautomatisierte DAST-Tools können in der Regel die verschiedenen Seiten einer Anwendung erfassen und sie mithilfe unterschiedlicher Payload-Varianten auf eine Vielzahl potenzieller Sicherheitslücken testen. Häufig können diese Tools auch Webdienste und Microservices prüfen. Andere DAST-Tools sind stärker spezialisiert und analysieren eine oder einige wenige bestimmte Arten von Schwachstellen gründlicher. DAST wird üblicherweise in späten Testphasen durchgeführt, kurz bevor eine Anwendung oder ein Dienst in einer Produktionsumgebung bereitgestellt wird.

In unserem Artikel SAST vs. DAST erfahren Sie mehr über die Unterschiede zwischen SAST und DAST.

3. SCA – Software Composition Analysis

Software Composition Analysis, kurz SCA, bezeichnet die Analyse einer Anwendung, um darin enthaltene Softwarekomponenten von Drittanbietern oder aus Open-Source-Projekten zu identifizieren. In der Regel umfasst SCA die Analyse dieser externen Abhängigkeiten auf bekannte Sicherheitslücken und mögliche Lizenzprobleme. Automatisierte SCA-Tools wie Snyk Open Source können normalerweise den gesamten Abhängigkeitsbaum erfassen. Sie untersuchen nicht nur die im Quellcode der Anwendung enthaltenen Komponenten, sondern auch deren Abhängigkeiten und so weiter.

Software Composition Analysis kann in jeder Phase der Delivery-Pipeline durchgeführt werden. Empfehlenswert ist jedoch eine frühzeitige Analyse, 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 während der Anwendungsentwicklung durch Komponenten von Drittanbietern entstehen, sondern auch sicherzustellen, dass die Organisation bei neu entdeckten Schwachstellen in Drittanbieter- oder Open-Source-Software schnell beurteilen kann, ob sie betroffen ist, und Gegenmaßnahmen planen kann.

Erfahren Sie mehr über SAST vs. SCA und wie Sie damit sichere Software veröffentlichen können.

4. OWASP – Open Web Application Security Project

Das Open Web Application Security Project, kurz OWASP, ist eine gemeinnützige Organisation, die sich auf die Sicherheit von Software konzentriert. OWASP ist für zahlreiche von der Community getragene Projekte bekannt, die Wissen und Orientierungshilfen für die Entwicklung sicherer Software bieten. OWASP bringt eine große Community von Freiwilligen zusammen, die diese Projekte und Schulungsmaterialien zum Nutzen der gesamten Security- und Softwareentwicklungsgemeinschaft vorschlagen, entwickeln und betreuen.

Eines der bekanntesten Projekte ist die OWASP Top 10, eine regelmäßig anhand von Beiträgen aus der Community aktualisierte Liste der zehn häufigsten Arten von Webanwendungsschwachstellen. 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 bildet zwar nicht alle möglichen Schwachstellenarten vollständig ab, ist aber ein guter Ausgangspunkt.

OWASP veranstaltet außerdem weltweit verschiedene Security-Konferenzen und verfügt über regionale Gruppen, die sich regelmäßig treffen, um Ideen auszutauschen, an Projekten zu arbeiten und Wissen zu vermitteln. Einzelne Projekte veranstalten gelegentlich auch Gipfeltreffen, bei denen Fachleute und Projektmitglieder zusammenkommen, um Aspekte der Projekte zu besprechen und weiterzuentwickeln.

5. XSS – Cross-Site Scripting

Cross-Site Scripting, kurz XSS, ist eine häufig in Webanwendungen auftretende Sicherheitslücke. XSS steht seit der ersten Veröffentlichung im Jahr 2003 auf der OWASP Top 10. Bei XSS kann ein Angreifer schädlichen Skriptcode – meist JavaScript – im Browser einer oder mehrerer Personen ausführen. Mithilfe dieser Angriffsmethode lassen sich sensible Informationen wie Sitzungsdaten oder personenbezogene Daten sammeln.

Üblicherweise werden drei Arten von XSS unterschieden:

• Reflektiert: Der Angreifer veranlasst die Person, eine Anfrage mit der Angriffspayload an die Anwendung zu senden. Die Anwendung gibt diese in der Antwort zurück, sodass sie im Browser ausgeführt wird.

• Gespeichert: Der Angreifer sendet die Angriffspayload an die Anwendung. Sie wird dort in einem Wert gespeichert, der anderen Personen als Teil dynamisch erzeugter Seiten zurückgegeben wird. Dadurch wird das Skript in deren Browsern ausgeführt.

• DOM-basiert: Der Angreifer sendet der Person das schädliche Skript – meist über einen bösartigen Link. Es wird direkt im DOM der Seite ausgeführt, ohne die Anwendung zu durchlaufen.

Auf unserer XSS-Seite auf Snyk Learn erfahren Sie mehr über XSS und wie Sie sich davor schützen können.

6. CSRF – Cross-Site Request Forgery

Cross-Site Request Forgery, kurz CSRF, ist eine weitere häufige Angriffsform auf Webanwendungen. Bei einem CSRF-Angriff nutzt der Angreifer eine bereits authentifizierte Sitzung zwischen dem Browser der betroffenen Person und der Anwendung aus. So kann er Funktionen der Anwendung über Anfragen ausführen, die in eine von ihm kontrollierte bösartige Website eingebettet sind. CSRF wird manchmal auch als „Session Riding“ bezeichnet; manche sprechen es „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 beispielsweise eine Anfrage einer Online-Banking-Anwendung abfangen, mit der eine Überweisung ausgeführt wird. Anschließend erstellt er eine bösartige Website und bindet dieselbe Anfrage in einem IFRAME ein. Wer die Website besucht, sendet dann dieselbe Anfrage an die Banking-Anwendung. Wenn die Besucherin oder der Besucher dort eine aktive Sitzung hat – etwa in einem anderen Browser-Tab –, wird 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, um potenzielle Bankkunden und damit wahrscheinliche Nutzer der Banking-Anwendung zum Besuch der bösartigen Website zu bewegen.

Weitere Informationen zu Cross-Site Request Forgery und Schutzmaßnahmen finden Sie auf unserer CSRF-Seite auf Snyk Learn.

7. RASP – Runtime Application Self-Protection

Runtime Application Self-Protection, kurz RASP, ist eine in eine Anwendung integrierte Abwehrtechnik, mit der die Anwendung Angriffe erkennen und sofort darauf reagieren kann. RASP wird meist mithilfe von Tools von Drittanbietern umgesetzt. RASP-Tools werden in der Regel in die Anwendung eingebettet und ü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 verwendet werden, die wie ein Filter vor der Anwendung agieren und Anfragen sowie das Anwendungsverhalten überprüfen. Der wichtigste Vorteil von RASP: Selbst wenn eine Anwendung Schwachstellen aufweist, kann ein Angreifer sie nicht erfolgreich ausnutzen – oder zumindest lässt sich das Ausmaß des Angriffs deutlich begrenzen.

8. DoS – Denial of Service

Denial of Service, kurz DoS, bezeichnet eine Angriffsmethode, bei der 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. Auch die Netzwerkinfrastruktur, über die die Anwendung erreichbar ist, kann angegriffen werden. DoS-Angriffe sind möglich, wenn ein Angreifer eine Schwachstelle im Code, in der Systemsoftware oder in der Netzwerkinfrastruktur einer Anwendung ausnutzen kann, um sie für andere unzugänglich zu machen. Es gibt viele Möglichkeiten, einen DoS-Angriff durchzuführen. Zwei bestimmte Arten werden besonders häufig besprochen:

• DDoS: Bei einem Distributed Denial of Service nutzt der Angreifer eine große Anzahl von Systemen – üblicherweise Teil eines Botnetzes –, um ein Ziel mit Datenverkehr zu überlasten und dadurch nicht mehr verfügbar zu machen.

• REDoS: Regular Expression Denial of Service ist eine spezifische Schwachstelle, die häufig in serverseitigen JavaScript-Anwendungen auftritt. Ein Angreifer kann damit die RegEx-Engine dazu bringen, große Mengen an Ressourcen zu verbrauchen, sodass die Anwendung nicht mehr reagiert.

9. CSP – Content Security Policy

Die 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 nach dem Erreichen des Browsers tatsächlich ausgeführt werden.

Weitere Ressourcen und Informationen zur 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 Zugriff auf nicht autorisierte Daten oder Funktionen erhalten.

Weitere Informationen zu SSRF finden Sie in diesem Leitfaden von OWASP.

Zusammenfassung

Wie in jeder Branche gibt es auch in der Sicherheitsbranche viele technische Fachbegriffe, die der Einfachheit halber oft zu Akronymen verkürzt werden. Das kann für Personen außerhalb des Sicherheitsbereichs verwirrend sein. Für Entwickler kann es ein wichtiger Schritt zu einer besseren Zusammenarbeit in der DevSecOps-Delivery-Pipeline sein, die Begriffe ihrer Sicherheitspartner zu verstehen.