Security: Automatisierter Web Security Check mit OWASP ZAP

Sicherheit gehört von Anfang an mitgedacht. Webanwendungen sind ein beliebtes Ziel für Angriffe und das wird sich so schnell nicht ändern. SQL-Injection, XSS, fehlerhafte Authentifizierung – die Liste ist lang. Die OWASP-Checkliste hilft, diese Risiken systematisch zu betrachten und in Reviews oder technische Dokumentation zu integrieren. Doch was ist mit der praktischen Umsetzung im Alltag?

Was ZAP für dich tun kann

OWASP ZAP ist ein freies und leistungsstarkes Tool, das Sicherheitslücken in Webanwendungen automatisiert erkennt. Es bietet verschiedene Scan-Modi, darunter den Full Scan, der deine Anwendung im Browser analysiert und dabei passive sowie aktive Tests durchführt. Passive Tests prüfen beispielsweise auf fehlende Sicherheitsheader oder unsichere Konfigurationen, während aktive Tests gezielt Schwachstellen wie SQL-Injection oder Cross-Site Scripting (XSS) simulieren.

Ein besonderes Highlight ist die Unterstützung von API-Scans. Mit einer sauber gepflegten OpenAPI- oder GraphQL-Spezifikation kannst du gezielt APIs testen und sicherstellen, dass auch diese keine Schwachstellen aufweisen. Dies ist besonders wichtig, da APIs oft sensible Daten verarbeiten und ein beliebtes Ziel für Angriffe sind. Regelmäßige Scans sind hier entscheidend, um neue Schwachstellen frühzeitig zu erkennen und Sicherheitslücken kontinuierlich zu schließen.

Authentifizierung? Kann ZAP

Ein Großteil der Sicherheitsprobleme liegt hinter der Login-Maske. ZAP unterstützt verschiedene Authentifizierungsmethoden, darunter HTML-Formulare, JSON-basierte Logins und NTLM. Wer OAuth nutzt, kann auch außerhalb von ZAP oder über ein Authentication Script den Token für einen Test-User generieren und dann als Auth Header an ZAP übergeben.

Die Konfiguration von Authentifizierungsmethoden kann herausfordernd sein, insbesondere bei komplexen OAuth-Flows. Es lohnt sich, Zeit in die Dokumentation und Tests zu investieren, um sicherzustellen, dass geschützte Bereiche deiner Anwendung zuverlässig getestet werden können. Dies ist besonders wichtig, wenn sicherheitskritische Entscheidungen in der Business-Logik getroffen werden, wie etwa bei der Verwaltung von Benutzerrechten oder Zahlungsprozessen. So stellst du sicher, dass auch sensible Funktionen ausreichend abgesichert sind und keine unbefugten Zugriffe möglich sind.

Mehr Features über den Marketplace

Der Funktionsumfang von ZAP lässt sich über Add-ons aus dem ZAP Marketplace erweitern. Diese Add-ons bieten zusätzliche Funktionen, wie etwa das Testen von WebSockets, was gerade bei modernen Frameworks wie SignalR oder ähnlichen Technologien von Bedeutung ist. Auch für spezifische Anforderungen, wie das Scannen von mobilen Anwendungen oder das Erstellen benutzerdefinierter Reports, gibt es passende Erweiterungen.

Wer tiefer in die Materie einsteigen möchte, kann sich ein maßgeschneidertes Setup zusammenstellen. So lässt sich ZAP optimal an die individuellen Anforderungen deines Projekts anpassen. Dabei ist es hilfreich, das Team entsprechend zu schulen, um die Konfiguration und Interpretation der Ergebnisse zu optimieren. Eine klare Sicherheitsstrategie und definierte Richtlinien helfen zusätzlich, die Priorisierung und Behebung von Schwachstellen effizient zu gestalten.

Regeln und Konfigurationen

OWASP ZAP bietet flexible Konfigurationsmöglichkeiten, um Scans an spezifische Anforderungen anzupassen. Scan-Regeln können aktiviert, deaktiviert oder angepasst werden, beispielsweise in einer zap-rules.conf, um bestimmte Sicherheitsprüfungen zu ignorieren, zu warnen oder als kritisch zu markieren. Bestimmte URLs oder Pfade lassen sich vom Scan ausschließen, indem entsprechende Muster definiert werden. Diese Optionen erlauben es, ZAP effizient und zielgerichtet an die Anforderungen eines Projekts anzupassen.

Welche Regeln kritisch, ignoriert oder nur als Warnung angezeigt werden sollen, hängt von den eigenen Sicherheitsanforderungen ab. Die OWASP Top 10 hilft hier, eine gute Einschätzung zu bekommen.

10010 WARN (Cookie No HttpOnly Flag)
10011 WARN (Cookie Without Secure Flag)
10012 WARN (Password Autocomplete in Browser)
10015 WARN (Incomplete or No Cache-control and Pragma HTTP Header Set)
10016 WARN (Web Browser XSS Protection Not Enabled)
10017 WARN (Cross-Domain JavaScript Source File Inclusion)
10019 WARN (Content-Type Header Missing)
10020 WARN (X-Frame-Options Header Scanner)
10021 WARN (X-Content-Type-Options Header Missing)
10023 WARN (Information Disclosure - Debug Error Messages)
10024 WARN (Information Disclosure - Sensitive Informations in URL)
10025 WARN (Information Disclosure - Sensitive Information in HTTP Referrer Header)
10026 WARN (HTTP Parameter Override)
10027 WARN (Information Disclosure - Suspicious Comments)
10032 WARN (Viewstate Scanner)
10035 WARN (Strict-Transport-Security Header Not Set)
10038 WARN (Content Security Policy CSP Header Not Set)
10040 WARN (Secure Pages Include Mixed Content)
10054 WARN (Cookie without SameSite Attribute)
10055 WARN (CSP: Wildcard Directive)
10063 WARN (Permissions Policy Header Not Set)
10096 WARN (Timestamp Disclosure - Unix)
10105 WARN (Weak Authentication Method)
10110 WARN (Dangerous JS Functions)
10202 WARN (Absence of Anti-CSRF Tokens)
2   WARN    (Private IP Disclosure)
3   WARN    (Session ID in URL Rewrite)
50001 WARN (Script Passive Scan Rules)
90001 WARN (Insecure JSF ViewState)
90003 WARN (Sub Resource Integrity Attribute Missing)
90011 WARN (Charset Mismatch)
90022 WARN (Application Error Disclosure)
90030 WARN (WSDL File Passive Scanner)
90033 WARN (Loosely Scoped Cookie)
10012    OUTOFSCOPE    https://lunaris.digital/sitemap.xml

Wichtig bei der Config: Die Spalten müssen tab-getrennt sein. Die erste Spalte ist die ID der Regel, die zweite Spalte ist der Status (IGNORE, WARN, FAIL), die dritte Spalte ist die Beschreibung der Regel. Diese Regeln sind nur Beispiele und können je nach Projekt variieren. Es ist wichtig, die Konfiguration regelmäßig zu überprüfen und anzupassen, um sicherzustellen, dass alle relevanten Sicherheitsaspekte abgedeckt sind.

Zusätzlich kannst du mit dem Parameter -p eine Progress-Datei angeben, um bekannte und bereits in Bearbeitung befindliche Probleme zu markieren. Dies hilft dabei, den Fokus auf neue oder noch ungelöste Sicherheitslücken zu legen und die Ergebnisse übersichtlicher zu gestalten.

{
  "site": "lunaris.digital",
  "issues": [
    {
      "id": "10020",
      "name": "X-Frame-Options Header Not Set",
      "state": "inprogress",
      "link": "https://www.example.com/bugtracker/issue=1235"
    }
  ]
}

ZAP trifft Azure DevOps

Du willst ZAP in deine CI/CD-Pipeline integrieren? Kein Problem. Es gibt eine Erweiterung für Azure DevOps, die jedoch leider nicht mehr aktiv gepflegt wird. Eine flexible Alternative ist das Docker-Image von OWASP ZAP. Mit diesem kannst du ZAP einfach in deine Build- und Deployment-Prozesse einbinden.

parameters:
  - name: targetUrl
    type: string
    default: 'https://lunaris.digital'

jobs:
  - job: ZAP
    pool:
      vmImage: 'ubuntu-latest'
    steps:
      - bash: |
          chmod -R 777 ./
          docker run --rm -v $(pwd):/zap/wrk/:rw -v $(Build.SourcesDirectory)/zap-rules.conf:/zap/wrk/zap-rules.conf:rw -t ghcr.io/zaproxy/zaproxy:stable zap-full-scan.py -c zap-rules.conf -t ${{ parameters.targetUrl }} -x zap-report.xml -r zap-report.html -w zap-report.md -m 1 -z "-config scanner.maxScanDurationInMins=1"
        displayName: Run ZAP full scan
        workingDirectory: $(Build.ArtifactStagingDirectory)

      - pwsh: |
          $XslPath = "$(Build.SourcesDirectory)/owasp_to_nunit.xslt"
          $XmlInputPath = "$(Build.ArtifactStagingDirectory)/zap-report.xml"
          $XmlOutputPath = "report.xml"
          $XslTransform = New-Object System.Xml.Xsl.XslCompiledTransform
          $XslTransform.Load($XslPath)
          $XslTransform.Transform($XmlInputPath, $XmlOutputPath)
        displayName: 'Convert report'
        workingDirectory: $(Build.ArtifactStagingDirectory)
        condition: always()

      - task: PublishTestResults@2
        condition: succeededOrFailed()
        displayName: 'Publish test results'
        inputs:
          testResultsFormat: 'NUnit'
          testResultsFiles: '$(Build.ArtifactStagingDirectory)/report.xml'
          testRunTitle: 'ZAP Security Tests'

Die Exit Codes des Scripts sind wie folgt definiert:

0: Success
1: At least 1 FAIL
2: At least one WARN and no FAILs
3: Any other failure

Auf diese Weise kannst du festlegen, dass die Pipeline bei Warnings nicht direkt fehlschlägt, sondern als “Partially Succeeded” markiert wird. Nur bei Regeln, die als FAIL definiert sind, wird der Pipeline-Run abgebrochen, da es sich hierbei um kritische Sicherheitsprobleme handelt.

Die Ergebnisse der Scans lassen sich per XSLT in Formate wie NUnit überführen und als Testberichte in Azure DevOps publishen und dann als Pipeline Test Results anzeigen. Ein Beispiel hierfür findest du auf GitHub vom Pen Test Guy. Damit werden Sicherheitslücken genauso sichtbar wie fehlgeschlagene Unit-Tests, was die Integration in bestehende Workflows erleichtert.

Der Full Scan in unserem Beispiel scannt die URL, die in der Pipeline übergeben wird. Die Konfiguration der Regeln erfolgt über die zap-rules.conf, die im Repository liegt. Diese Datei kannst du anpassen, um spezifische Sicherheitsprüfungen zu aktivieren oder zu deaktivieren. Der Scan kann je nach größe der Seite und der Anzahl der Regeln mehrere Minuten in Anspruch nehmen. Willst du eine Obergrenze für die Laufzeit setzen, kannst du den Parameter -m <minutes> und die Konfiguration -z "-config scanner.maxScanDurationInMins=<minutes>" verwenden. Dieser gibt die maximale Zeit in Minuten an, die der Scan laufen soll. Wenn du den Scan auf 5 Minuten begrenzen möchtest, fügst du einfach -m 5 und -z "-config scanner.maxScanDurationInMins=5" hinzu. Standardmäßig hat der Scan kein Limit und läuft bis er fertig ist.

Auch für andere Plattformen wie GitHub Actions gibt es passende Extensions. Diese ermöglichen es, ZAP-Scans direkt in den Entwicklungsprozess zu integrieren und Sicherheitsprobleme frühzeitig zu erkennen. Bei großen Anwendungen oder APIs kann ein vollständiger Scan jedoch viel Zeit in Anspruch nehmen. Plane solche Scans außerhalb der Hauptarbeitszeiten oder in dedizierten Testumgebungen, um Performance-Einbußen zu vermeiden.

Sicherheit ist Teil des Prozesses

Ein einmaliger Scan bringt wenig. Sicherheit sollte ein kontinuierlicher Prozess sein. Binde die Ergebnisse der ZAP-Scans fest in deinen Entwicklungsprozess ein. Dokumentiere gefundene Schwachstellen, priorisiere sie nach ihrer Kritikalität und bespreche sie im Code Review. Nach der Behebung hilft ein erneuter Scan, die Wirksamkeit der Maßnahmen zu überprüfen.

Idealerweise führst du die Scans in nicht-produktiven Umgebungen durch, wie etwa Staging-Systemen oder temporären Deployments für Pull Requests. So kannst du Sicherheitsprobleme frühzeitig erkennen, ohne die Stabilität der Produktionsumgebung zu gefährden. Kombiniere automatisierte Scans mit manuellen Tests, um eine umfassende Sicherheitsstrategie zu gewährleisten.

OWASP ZAP ist ein mächtiges Werkzeug, um Sicherheitslücken frühzeitig zu erkennen und zu beheben. Es ergänzt manuelle Tests sinnvoll und lässt sich flexibel in bestehende Entwicklungsprozesse integrieren. Mit der richtigen Konfiguration und regelmäßigen Scans wird Security zu einem festen Bestandteil deiner Softwareentwicklung. So schützt du nicht nur deine Anwendungen, sondern auch die Daten deiner Nutzer effektiv.

Nutzt du OWASP ZAP schon oder setzt du auf andere Tools? Schau gerne bei uns auf LinkedIn vorbei und diskutiere mit.