Mal wieder ein CMS inkl. XSS und SQL-Injection gefunden. Ich war auch wieder so frech und habe dem Entwickler dazu einen Hinweis gemailt. ;O)

1te Antwort:

danke für den Hinweis. Die SQl Lücke hatte ich schon in den Downloadversionen längst gefixt, aber auf der Seite noch nicht upgedatet.

Das XSS Problem beruht darauf dass hier nur auf Skript Elemente gecheckt wurde, nicht auf die restlichen HTML Tags. Das habe ich erweitert.

Interessant an der SQL-Injection ist: Alle von mir untersuchten WebSites (ca. 60) die ich nach kurzer Suche gefunden habe, nutzen noch die Versionen inkl. der SQL-Lücke. Da er das SQL-Problem wohl erst kürzlich gefixt hat, ist die neue Version noch nicht im Einsatz. Und – ich lach mich wieder schlapp – die Passworte der Admins und User werden ungesalzen in der Datenbank als MD5-Hash gespeichert. Zum Glück gibt es angeblich nur ca. 1000 Installationen von dem CMS und da niemand einfache Passworte vergibt, ist die SQL-Injection kein echtes Problem. ;O)

Mit “Skript Elemente” meinte er JavaScript, denn jeglicher HTML- und CSS-Code wird nach der Injektion ausgeführt.

Bisher hatte er nur diese Form ausgefiltert:
<script src=http://hacker.tld/xss.js></script>
Im war nicht bewusst das auch dieses funktioniert ohne schließendem TAG:
<script src=http://hacker.tld/xss.js />

Dann habe ich ihm noch einmal ein weiteres Beispiel geschickt, da er meinte die XSS-Lücke bereinigt zu haben (Bei solcher Rückmeldung fühle ich mich herausfordert, das Gegenteil zu beweisen. <g>), mit dem Hinweis, dass doch bitte alle Daten die gesendet wurden zu filtern sind.

2te Antwort:

natürlich checken wir alle eingehenden Variablen auf diese Elemente, die durchlaufen eine Reihe von Filtern mit regulären Ausdrücken.

Aber offensichtlich sind die Filter nicht gut genug.

Ich werde mir das einmal prinzipiell anschauen um eine bessere Lösung einbauen zu können.

Er hat eine Blacklist, nach der er die bösen-TAGs aussortiert. Falsch! Falsch! Falsch!

Abhängig davon welche Daten vom User übertragen werden sollen, wird erstmal alles ausgefiltert, was kein alphanumerisches Zeichen ist – fertig. Nur in sehr seltenen Sonderfällen sind Sonderzeichen in einem Formular oder einer Suchfunktion überhaupt erforderlich.


Warum machen sich die Entwickler so unnötige Arbeit und zerbrechen sich den Kopf darüber welcher TAG böse ist und welcher nicht?

Wenn man hiermit filtert:
$ausgabe = preg_replace('/[^a-zA-Z0-9 äöüÄÖÜß]/', '', $eingabe);

darf im Formular natürlich nicht dies stehen:
<input type="text" name="eingabe" value="<?=$eingabe?>" />

Aber das sollte klar sein – so hoffe ich doch. ;O)


Es wird wahrscheinlich so manche WebSite gehackt werden, bevor ein Update eingespielt wird, weil die Betreiber einfach nicht wissen dass das verwendete CMS Sicherheitslücken hat. Auf der Seite des Entwicklers gibt es leider keine Hinweise zu den Lücken. Man kann aber einen Newsletter abonnieren…
Warning: Smarty error: unable to read resource: "/www/htdocs/blabla/newsletter.html" in /www/htdocs/blabla/smarty/Smarty.class.php on line 0815
Mal schauen ob ich da nun einen Newsletter bekomme, so wirklich vertrauenserweckend sieht das aber auch nicht aus. ;O)

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.