Back
12.09.2024
#Javascript
#HTML Entities
#Web Development

XSS

⚡ New findings in (XSS) Cross Site Scripting



Disclaimer: Wer seine Web-Apps mit den verbreiteten und etablierten Tool-chains entwickelt, ist meistens auf der sicheren Seite. Die Entwickler sind vom Fach und wissen, was sie tun, und wenn sie nicht wissen, was sie tun, wissen sie zumindest mehr über XSS-Angriffe als der durchschnittliche User.

XSS-Angriffe machen seit einer sehr langen Zeit die Runde - die Konsequenz davon ist, dass das Playbook mittlerweile feststeht. Wir wissen, warum XSS gefährlich sein kann und wie man sich vor XSS schützt.

Allerdings entsteht zwischen dem Aufkommen von Web-Application-Firewalls und dem AI-Hype ein neues Problem: Viele Entwickler von Web-Firewalls springen auf den Hypetrain und versuchen, Machine Learning in ihre Produkte zu integrieren. Teilweise funktioniert der neue Ansatz, doch stabil ist er noch nicht.

Somdev Sangwan hat eine Anleitung darüber geschrieben, wie sich Machine-Learning-basierte Firewalls umgehen lassen. Er beschreibt auch eine Angriffsmethode, bei der XSS-Payloads in Strings untergebracht werden, die von Regex-patterns nicht erkannt werden. Auf jeden Fall lesenswert.

Dies sind die Namen von Web-Firewall Entwicklern, die Machine Learning einsetzen:

OWASP hat eine Checkliste für XSS-Verteidigung online gestellt. Den Webdev-Leuten dort draußen sei zu empfehlen, vor dem Deployment einen Blick auf darauf zu werfen.

Hier die meiner Meinung nach wichtigsten Punkte:

  1. Verwende einen isomorphic-DOMPurify

  2. Verwende Entity Encoding:
    • “&” -> “&amp”;
    • ”<” -> “&lt”;
    • ”>” -> “&gt”;
    • ”” “ -> “&quot”;
    • ”’ “ -> “&#x27”;
    • Mehr Informationen über Entity Encoding hier
  3. Setze Variablen in Anführungszeichen, so wie hier:
     <div attr="$varUnsafe">
     <div attr="*x" onblur="alert(1)*"> <!-- Example Attack -->
    
  4. Vermeide dynamisches CSS:

     <style> selector { property : $varUnsafe; } </style>
     <style> selector { property : $varUnsafe; } </style>
     <span style="property : $varUnsafe">Oh no</span>
    

Alle weiteren Punkte der Checkliste im Artikel oben.


Katz und Maus

Kompetente Hacker wissen, dass kompetente Admins an Report-Endpoints denken und enstprechende Mechanismen in ihre CSPs (Content Security Policies) implementieren. Semi-kompetente Hacker wissen das auch, aber nicht, was das für sie bedeutet. Viele Angreifer lassen beim Verschicken von Sonden den User-Agent leer:

curl -H "User-Agent:" <URL> # Conceals webbrowser operating System

… und wähnen sich im Glauben an todsichere Obskurität. Doch in den Access-Logs der Server steht nun ein großes Nichts, was den Verdacht schöpft, dass hier jemand entweder etwas zu verbergen hat, kein Spoofing beherscht, oder beides. Eine gut gemachte Sonde sieht aus wie ein ganz normaler curl; gefährlich, ohne gefährlich auszusehen.

Trotzdem kann auch eine halbwegs-kompetent gemachte Sonde die Reponse-Headers einer Request holen und einen Blick in die CSPs werfen (Sofern der Admin seine CSPs nicht versteckt hat).

Sollte der Hacker lesenden Zugriff auf die CSPs haben, kann er sich ein Bild davon machen, wie weit er sein XSS-Game treiben kann. Ist der Admin ein Schelm, kann er Fake-CSPs in den head seines HTMLs unterbringen und somit die Illusion erzeugen, ein Honeypot zu sein, ohne es in Wahrheit zu sein.