Beim Stöbern nach Sicherheitslücken auf Seiten vom Bund bzw. Bundesbehörden bin ich – natürlich – fündig geworden, aber das wäre noch keinen Eintrag hier wert. Es gibt da aber eine Datenbank mit etwas eigenwilligen “Features”… ;O)

Bei der Datenbankabfrage werden die Eingaben aus dem Suchformular vom verarbeitenden Script nicht gefiltert, was zu einer XSS-Lücke führt, kennt man, nichts neues. Dies wäre eine reflektive XSS-Lücke, bei der alles was über das Formular gesendet wird, wieder ungefiltert im Browser erscheint – “wäre”?! Jupp, wäre! :O)

Es gibt im Formular einen Button zum löschen der eingegebenen Suchkriterien, was mich schon etwas stutzig machte, d.h. die Formulareingaben werden zwischengespeichert und zwar am Server. Die Jungs meinen sehr schlau zu sein, indem sie einen Cookie setzen, um damit die Suchanfrage nur für die jeweilige Sitzung in dem einen Browser verfügbar zu machen. Die Session-ID wird per URL übertragen, wenn Cookies im Browser deaktiviert sind, kennt man diese URL, so kann diese auch bei aktivierten Cookies benutzt werden.

Ich stelle also eine Suchanfrage, inkl. etwas HTML-, CSS- oder JavaScript-Code, der ungefiltert wieder ausgegeben wird. In der Adresszeile des Browsers findet sich auch die Session-ID, aber nicht der Schadcode aus dem Formularfeld, was die URL vollkommen unverdächtig macht. Diese URL kann man nun auch in einem anderen Browser aufrufen und dabei wird dann auch der zusätzliche Code ausgeführt.

Aus der scheinbar reflektiven XSS-Lücke wird, durch die fehlerhafte Verwaltung der Session-ID eine persistente, also beständige Lücke. Die Session-ID verliert erst nach mehreren Stunden ihre Gültigkeit.