Der Hinweis, den dennisdra dort teilte, offenbart tatsächlich eine XSS-Lücke. Das bedeutet im Klartext: Man kann einer Variablen einen beliebigen Wert geben, der dann im HTML ohne Filterung exakt wie die Eingabe ausgegeben wird. Das bedeutet, dass man beispielsweise <script>-Tags dort einbinden kann.
Auch der Lösungsansatz ist vollkommen richtig. htmlentities()
(ich hätte eher htmlspecialchars() benutzt) maskiert sämtliche HTML-Tags in einer Nutzereingabe, sodass - wenn die Eingabe des Nutzers auf der Seite geechot wird - der Wert nicht mehr vom Browser als HTML interpretiert wird.
__________________
Theoretisches Beispiel: Aus <script> wird unter Zuhilfenahme einer der entsprechenden Maskierungsfunktionen im Quelltext <script>. Das ist kein gültiges HTML-Tag, somit behandelt der Browser ebendieses auch als bloßen Text und gibt dann <script> aus.
Praktisches Beispiel: Man nehme eine beliebige Surako-Website, öffne dort das Ranking und wähle irgendeinen Job in der Dropdownbox aus und lasse sich ebendiesen anzeigen. Sofort bekommt man in der Browser-URL angezeigt:
ranking.php?job=6, im Quelltext steht:
PHP Code:
...
<option value="6">Knight</option>
...
Wenn man nun ein ganz einfaches Javascript in die $_GET['job']-Variable einspielt
(etwa so: ranking.php?job="><SCRIPT>alert('XSS')</SCRIPT>), dann ist ohne htmlentities() / htmlspecialchars() Quelltext so aufgebaut:
PHP Code:
...
<option value=""><SCRIPT>alert('XSS')</SCRIPT>">Knight</option>
...
Das <option>-Tag geschlossen und schon hat man damit seine XSS-Lücke. Das gilt nicht nur für $_GETs, sondern auch für $_POSTs, $_COOKIES und sonstige Variablen, die ein Nutzer mit irgendwelchen Werten belegen kann und die dann an irgendeiner Stelle auf der Website wieder ausgegeben werden. Deswegen: Nutzereingaben müssen immer über PHP gefiltert werden. Inwiefern man nun Derartiges ausnutzen kann, weiß ich nicht. Dafür fehlt mir die kriminelle Energie, da solltest du dich lieber an eine gewisse Person hier im Forum wenden.
