[Themen-Talk] (Web-)Sicherheit und technische Aspekte von Loseseiten

Drakor

Well-known member
ID: 360281
L
31 Juli 2009
174
22
Hey Leute,

vermutlich erinnert sich keiner mehr an mich, aber vor ein paar Jahren war ich in der Klammunity relativ aktiv und hatte dann ne lange Pause.

Schon damals habe ich gerne an Loseseiten rumgebastelt, rumgeproggt, Sicherheitslücken gefunden, mit anderen Proggern zusammengearbeitet und versucht überwiegend ein netter Geselle zu sein. Wenn ich nun wieder auf Loseseiten herumklicke und einfach mal vergleiche, so stelle ich folgendes fest:
Es hat sich nix geändert. Die meisten Loseseiten sind immernoch verbuggt und man findet Sicherheitslücken am laufenden Band. Auch was die Qualität des Quellcodes angeht hat sich wenig getan.

Daher würde ich gerne mit euch einmal über die technischen Aspekte von Loseseiten diskutieren:

# Was empfindet ihr so als derzeitigen Stand der Technik ?

# Regt ihr euch über Sicherheitslücken auf, oder lassen die euch kalt ?

# Gibt es Leute, die aktiv nach Sicherheitslücken suchen und diese offenlegen oder darüber evtl. bloggen ?

# Was wünschen sich die Progger für die Zukunft ?

# Vor allem, interessiert es überhaupt den Webbie hinter der Loseseite, wie es technisch um seine Seite steht ?

# Wie steht es mit den Leuten, die Slots bauen ?

# Wertet ihr das Verhalten eures Slots statistisch aus ?

# Auf welche Feinheiten achtet ihr ?

# Liegt euch etwas an einem gut funktionierenden Slot ?

Alles Ansätze und Fragen, zu denen ich gespannt auf eure Meinungen bin und mich freuen würde, wenn es hierzu etwas Diskussion und noch viele weitere Anregungen gibt.

Gruß
Drakor

Ich hoffe, ich hab die Sektion mit den Fragen nicht zu sehr in die Länge gezogen :D
 
Zuletzt bearbeitet:
# Was empfindet ihr so als derzeitigen Stand der Technik ?
Der derzeitige Stand? Aktuell ist der technische Stand meiner Ansicht nach so: Bleib auf einem Punkt stehen und drehe dich die ganze Zeit im Kreise.

# Regt ihr euch über Sicherheitslücken auf, oder lassen die euch kalt ?
Kalt lässt mich sowas nicht, denn beim ausnutzen einer Sicherheitslücke geht es nicht nur um den Schaden auf dem der Admin sitzen bleibt (meiner Meinung nach bei fahrlässigen Fehlern sind diese es selber Schuld) - sondern der Nutzer der dieser Seite und dem Admin vertraute um den sein Guthaben geht es...

# Gibt es Leute, die aktiv nach Sicherheitslücken suchen und diese offenlegen oder darüber evtl. bloggen ?
Es gibt Leute die danach suchen, aber eher damit man die Lücken ausnutzen kann. Ob es jetzt spezielle Blogs dazu gibt das weiß ich nicht. Aber werfe mal einen Blick in diesem Thema hier im Forum rein, so ein Blog wäre brauchbar! -> https://www.klamm.de/forum/f74/suche-leute-die-auch-durch-r******r-geschaedigt-wurden-durch-hacking-und-losediebstahl-384180.html
 
# Was empfindet ihr so als derzeitigen Stand der Technik ?

Geht gerade noch so aber an vielen Stellen einfach veraltet. PHP 5 Versionen vor allem von den Loginscripten Fehlen.

# Regt ihr euch über Sicherheitslücken auf, oder lassen die euch kalt ?
Nein, Das eine Sicherheitlücke auftreten kann passiert selbst den besten. Deswegen rege ich mich darüber nicht auf.
Was mich aber aufregt ist, das einfach zu viele Leute unterwegs sind die behaupten Profi zu sein, es bei weitem aber nicht sind und Sicherheitslücken die man sehr detailliert meldet ( <script type="text/javascript">alert("XSS")</script> landet ungefiltert in der Datenbank beim Nicknamen (optimal zum Verbreiten von Viren, etc.), addslashes ohne zusätzliches mysql_real_escape_string verwendet da Addslashes selber ne Lücke hat, etc.) nicht geschlossen werden. Sowas regt mich auf. Kein Wunder das Angreifer sich auf die Loseseiten einschießen.....

# Gibt es Leute, die aktiv nach Sicherheitslücken suchen und diese offenlegen oder darüber evtl. bloggen ?
Einen Blog gab es dazu mal, der wurde laufend verklagt so wie nahezu alle Deutschen Blogs die Sicherheitslücken im Detail offen gelegt haben. Bei einigen Programmen exisiteren die Lücken die in diesen Blogs standen immer noch. Dabei wär eine zusammen Arbeit mit den Blog Betreibern wohl weit Sinnvoller aber dagegen Klagen ist wohl einfacher als das Beheben der Lücken.....

# Was wünschen sich die Progger für die Zukunft ?
Ich weiß nicht wie das bei anderen aus sieht aber ich würde mir wünschen das so einige "Progger" mal auf den Boden der Tatsachen kommen und gemachte Aussagen zu Sicherheitslücken auch mal Ordentlich Prüfen und auch wenn man selber nicht in der Lage ist diese auszunutzen, sich mal überlegt ob es Theoretisch geht und die dann trotzdem schließt. Ich kann auch nicht jede Lücke ausnutzen, versuche aber soweit machbar wenn mir was gemeldet wird das zumindest Logisch nach zu vollziehen und entsprechend zu schließen.
Auch das in Punkto Sicherheit mal über den Tellerrand geschaut wird, es gibt schließlich mehr als nur SQL_Injections ...

# Vor allem, interessiert es überhaupt den Webbie hinter der Loseseite, wie es technisch um seine Seite steht ?

Teilweise, da gibts 2 Lager. Die einen wollen nur installieren und läuft.
Die anderen versuchen zumindest sich darum zu kümmern. Das ist ziemlich unterschiedlich.

Ist ähnlich bei den Entwicklern der Login Systeme. Bei dem einen meldet sich ein Cracker im Forum dazu und findet das Script gut. Sowas sollte man als Warnung betrachten. Ich hab mit nem OpenScource web application security scanner mal ganz kurz über 60 Lücken finden können und dam Entwickler geschrieben wie er das selber testen kann (URL zum Programm inkl. Beispiele, etc.) und wurd ignoriert.
In einem anderen Fall wurd das Script für 3 Tage Offline genommen, danach kam ne Version wo der Scanner nichts mehr lieferte.
Im Prinzip das selbe, der eine Interessiert sich dafür und kümmert sich, der andere steckt einfach den Kopf in den Sand und hofft das nichts schief geht ......
 
marcaust schrieb:
Auch das in Punkto Sicherheit mal über den Tellerrand geschaut wird, es gibt schließlich mehr als nur SQL_Injections ...

Das ist ein ganz exzellenter Punkt und da muss ich auch sagen, dass (vermutlich) Herr Lüttig als er das FWX geschrieben hat, an den entscheidenden Stellen da die richtigen Ideen hatte.
Denn während im FWX z.b. bei der Loseüberweisung an andere Benutzer eine tan in das Formular eingebettet wird, ist dies im VMS im Allgemeinen auf keiner Seite der Fall. Das ist natürlich ein gefundenes Fressen für Leute, die CSRF benutzen.
Man bedenke was passiert wenn ich nun eine Seite mit einem Autoformular das mir Lose überweist in einem Lose-Werbenetzwerk bewerbe und Klicker mit eingeschaltetem Javascript draufklicken (da gibts noch genug von). Ich wette mit euch, wenn ich da jetzt eine solche Kampagne starten würde, hätte ich mit Sicherheit heute Abend 10 Mrd Lose mehr aufm Konto.
Außerdem betrifft sowas nun ja nicht ausschließlich Loseüberweisungen, sondern ausnahmslos alle Aktionen, die im VMS/FWX getätigt werden können und die nicht mit einer tan geschützt sind. (z.b. Slot spielen, Adminforceaktionen, Gutscheine erstellen, usw.).

Also, wie du komplett richtig gesagt hast, gibt es noch dutzende weitere Möglichkeiten außer XSS/SQLi Loseseiten zu unerwünschten Aktionen zu bringen. Wäre ich Loseseitenbetreiber würde ich mich gerade auch vor denen gruseln, denn bei vielen ist es im Nachhinein nicht immer nachvollziehbar, was genau passiert ist.

Gruß
Drakor
 
[...] addslashes ohne zusätzliches mysql_real_escape_string verwendet [...]
*brrr*. Da direkt davor die Frage zum aktuellen Stand der Technik war: PDO Prepared Statements und die Ausgabe konsequent durch htmlentities()/htmlspecialchars() schicken bzw. im Idealfall durch ein Templatesystem, welches XSS-Prevention per Design vorsieht (ein Beispiel wäre Twig) und man hat schonmal die beiden grossen Felder SQL-Injection und XSS komplett abgedeckt.
 
Wäre ich Loseseitenbetreiber würde ich mich gerade auch vor denen gruseln, denn bei vielen ist es im Nachhinein nicht immer nachvollziehbar, was genau passiert ist.

Hierbei kann z.Bsp.: ein im Hintergrund laufendes https://www.phpids.org zumindest Teilweise Abhilfe schaffen da damit Angriffe eben Protokoliert werden können. Ich hab damit schon so einige gefunden, auch Angriffe in Hexdezimaler Schreibweise, etc.

So ein Tan System (Page Token denke ich mal meinst du) ist keine schlechte Idee. Nur ist mir gerade bei den Slots derzeit keine Lösung dazu eingefallen wie man das umsetzen könnte. Das Token müste ja beim Klick auf Play wieder übermittelt werden..
 
marcaust schrieb:
Das Token müste ja beim Klick auf Play wieder übermittelt werden..

So ungefähr, wobei ich sagen muss, dass ich die Gefahr nicht unbedingt bei den Slots für am Größten empfinde,
denn ein Angreifer kann sich daran nur schwierig bereichern. Eher sehe ich die Gefahr bei externen Addons, die sonst was für Features haben, die missbraucht werden können.

Für Gegenmaßnahmen:
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet

EDIT:
*brrr*. Da direkt davor die Frage zum aktuellen Stand der Technik war: PDO Prepared Statements

Die Losewelt ist derzeit (leider) Lichtjahre von PDO oder mysqli entfernt.


Gruß
Drakor