Angepinnt Sicherheit

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Sicherheit

      So, da wir ( Vio RL ) einige Probleme mit der Sicherheit haben,
      liste ich hier einige Probleme auf, die es so gibt - jeweils mit Beispiel
      und einer Möglichkeit, soetwas zu verhindern.

      Dieses Tutorial ist NICHT für Anfänger geeignet,
      ihr solltet über grundliegende Kentnisse im Scripting verfügen,
      insbesondere bei der Arbeit mit Tables und im Berreich des Event-Systems.
      Ausserdem betrifft Punkt 4. nur die nutzer von MySQL!

      Folgendes wird Thematisiert:
      1. Manipulierte Clientfiles
      2. ElementData-Missbrauch
      3. Gefakte Events
      4. MySQL-Injection
      5. MD5
      6. Compiler
      7. Allgemeines

      -- Wird bei Gelegenheit noch ergänzt!!! ---

      1. Manipulierte Clientfiles
      Da MTA Open Source ist, lässt sich dem entsprechend auch eine eigene
      Client-Version kompilen, mit der sich dann eigene, manipulierte (Client)Files
      laden lassen.
      So kann man z.b. die ElementData manipulieren, oder serverseitige Events triggern -
      worauf ich in Punkt 2 bzw. 3 genauer eingehen werde.

      Allgemein lässt sich sagen:
      Vertraut keinem Client.
      Überprüft alles noch einmal Serverseitig.

      2. ElementData
      Generell wird es empfohlen, keine ElementData zu verwenden,
      da diese auch Clientseitig manipuliert werden kann.
      Z.b. könnte man die ElementData "money" clientseitig verändern
      und dementsprechend sich Geld cheaten - sofern ihr money mit dem Geld des
      Spielers belegt.
      Um dies zu verhindern, gibt es 3 Möglichkeiten:

      1. Keine ElementData verwenden, sondern ein eigenes System -
      ggf. über Serverseitige Tables.
      Der Nachteil, dass sich die Daten dann Clientseitig nicht auslesen lassen,
      lässt sich leicht kompensieren: Verwendet bei jedem Befehl, bei dem ihr
      die Werte des Spielers ändert, auch die ElementData, jedoch lest nur die Werte
      aus euren Tables aus. So sind die Daten synchron, jedoch würde ein Modifizieren der
      ElementData dem "Hacker" keinen Vorteil bringen, da lediglich seine Werte Clientseitig falsch wären.

      Hier mein Beispiel:

      Quellcode

      1. elementData = {}
      2. function saveSetElementData ( element, dataString, value )
      3. if not elementData[element] then
      4. elementData[element] = {}
      5. end
      6. elementData[element][dataString] = value
      7. setElementData ( element, dataString, value )
      8. end
      9. function saveGetElementData ( element, dataString )
      10. if elementData[element][dataString] then
      11. return elementData[element][dataString]
      12. else
      13. return nil
      14. end
      15. end
      Alles anzeigen


      2. Möglichkeit:
      Keine ElementData verwenden und alle Variabeln immer dem Client übergeben - nicht empfehlenswert, aber sicher

      3. Möglichkeit:
      OnElementDataChange verwenden und ggf. ungewollte Werte einfach zurücksetzen,
      falls die Data von einem Client geändert wurde - Beispiel:

      Quellcode

      1. badData = { ["adminlvl"]=true, ["money"]=true }
      2. function dataChange ( data, value )
      3. if client then
      4. if badData[data] then
      5. setElementData ( source, data, value )
      6. end
      7. end
      8. end
      9. addEventHandler ( "onElementDataChange", getRootElement(), dataChange )


      3. Event-Faking:
      Es ist möglich, serverseitige Events mit modifizierten Files zu rufen,
      und so z.b. einen anderen Spieler durch ein clientseitige Anticheat zu "verpetzen".

      Deshalb:
      Übergebt NIE den Spieler, der ein Event auslöst, als source oder Variabel weiter,
      oder überprüft zumindest, ob die Variabel, in der der Spieler abgelegt wird,
      auch wirklich dem jenigen entspricht, der das Event ausgelöst hat.
      Dazu könnt ihr einfach die vorgegebene Variabel "client" verwenden - z.b. so:

      Quellcode

      1. function event_func ( player )
      2. if player == client then
      3. -- Hier den Code rein
      4. end
      5. end
      6. addEvent ( "event", true )
      7. addEventHandler ( "event", getRootElement(), event_func )


      Übrigens:
      Wird ein Event nicht von einem Client ausgelöst, ist "client" = nil

      4. MySQL-Injection (Nur für Nutzer des MySQL-Moduls):
      Das Prinzip von MySQL-Injection lässt sich leicht an einem Beispiel erklären:
      Ich schreibe an Ryker ein PM, die in dei Datenbank eingetragen wird:

      Quellcode

      1. sender = "Zipper"
      2. empaenger = "Ryker"
      3. msg = "Hallo"
      4. datum = "11.11.2011"
      5. mysql_query(handler, "INSERT INTO pm (Sender, Empfaenger, Text, Datum) VALUES ('"..sender.."','"..empfaenger.."','"..msg.."','"..datum.."')")


      Würde man jetzt z.b. statt einem Text eine Eigene MySQL-Anweisung eingeben, würde der Server diese dann ausführen.
      Also könnte man bei der folgenden Eingabe die Datenbank modifizieren, so dass die Spalte "Benzin" in der Tabelle "Vehicles" alle Einträge auf 0 gesetzt werden:

      Quellcode

      1. sender = "Zipper"
      2. empaenger = "Ryker"
      3. msg = " 'UPDATE vehicles SET Benzin = 0 ' "
      4. datum = "11.11.2011"
      5. mysql_query(handler, "INSERT INTO pm (Sender, Empfaenger, Text, Datum) VALUES ('"..sender.."','"..empfaenger.."','"..msg.."','"..datum.."')")

      Dies lässt sich durch folgende Funktion verhindern:
      mysql_escape_string ( handler, string )

      Die Funktion verhindert, dass bestimmte Sondernzeichen in eime String vorkommen - z.b.
      macht sie aus ' folgendes: \'
      Dadurch wird die MySQL-Anweisung zu einem ganz normalen Text,
      also aus " 'UPDATE vehicles SET Benzin = 0 ' " -> " \'UPDATE vehicles SET Benzin = 0 \' " -
      MySQL würde es dann nicht als Anweisung verstehen.

      Damit das etwas praktischer wird, könnt ihr euch eine Funktion nach folgendem Schema erstellen:

      Quellcode

      1. function MySQL_Save ( string )
      2. return mysql_escape_string ( handler, string )
      3. end

      Verwenden könnt ihr es dann z.b. so:

      Quellcode

      1. mysql_query(handler, "INSERT INTO pm (Sender, Empfaenger, Text, Datum) VALUES ('"..MySQL_Save(sender).."','"..MySQL_Save(empfaenger).."','"..MySQL_Save(msg).."','"..MySQL_Save(datum).."')")


      5. MD5
      Dieser Part ist nur für all jene interessant, die zum Passwortschutz MD5 verwenden.
      Prinzipiell ist MD5 relativ sicher, jedoch lassen sich mittlerweile viele Hashes per Google
      bzw. per Rainbow-Table herausfinden.
      Deshalb solltet ihr nur "salted" Hashes verwenden,
      d.h. jedes Passwort noch mit einem individuellen "Salt" versehen -
      einer Zufallskombination aus X-Zeichen ( Bei Vio sinds z.b. 7 Zeichen ).
      Diese wird dann einfach angehängt:
      md5 ( passwort + salt )

      Bsp.:

      Quellcode

      1. local passwort = "Aligator3"
      2. local salt = "fDt6z67"
      3. local newPasswort = md5 ( passwort..salt )


      Diesen Algorythmus könnt ihr zum erstellen von Salts benutzen:

      Quellcode

      1. function generateNewSalt ()
      2. salt = ""
      3. for i = 1, 7 do
      4. salt = salt .. string.char ( math.random(1,128) )
      5. end
      6. return salt
      7. end


      Wichtig:
      Natürlich muss das "salted" Password in der Datenbank eingetragen sein,
      bei jedem login muss dann also das ungehashte Passwort mit dem Salt verknüpft
      und anschließend gehasht werden.
      Ausserdem müsst ihr logischerweise für jedes Passwort nur einmal einen Salt generieren
      und diesen dann anschließend immer weiter verwenden ( nur für dieses Passwort ).

      6. Compiler
      Man hat mit MTA die Möglichkeit, die eigenen (Clientseitigen) Scripts mit dem standart Luac-Compiler
      zu compilen, d.h. in Code umzuwandeln, den der Server dann direkt verarbeitet.
      Das ganze erschwert den Leuten, eure Scripts zu klauen bzw. zu verändern - es ist jedoch
      keine zu 100% sichere Methode, also vertraut nicht nur darauf, dass eure compilten Scripts
      nicht doch modifiziert oder geklaut werden können.

      Wichtig: Solltet ihr einen externen Downloadserver verwenden, achtet unbedingt darauf,
      dass die Files auf dem Downloadserver und auf dem Rootserver die selben sind -
      ansonsten kann es zu einem CRC-Missmatch führen ( d.h. entweder auf beiden Server
      compilierte Clientscripts oder nur uncompilierte Clientscripts verwenden ).

      Mehr dazu findet ihr hier:
      de.wikipedia.org/wiki/Compiler
      und hier:
      lua.org/manual/4.0/luac.html


      7. Allgemeines
      Wie schon oben bereits gesagt, solltet ihr NIEMALS einem Client vollständig vertrauen -
      sei es bei eingaben von Daten, dem Triggern von Events oder dem verwalten von Variabeln -
      überprüft immer alles Serverseitig!
      Nehmt z.b. bei Geld-Anweisung immer die absoluten werte, damit man z.b. niemandem
      negative Geldwerte überweisen kann.

      Dieses Tutorial wird noch erweitert und verbessert, bin da selber noch nicht so lange hinter - falls jemand etwas zu ergänzen hat,
      bitte hier posten.

      Dieser Beitrag wurde bereits 7 mal editiert, zuletzt von Zipper ()

    • Vielen Dank,
      einiges wuste ich selber noch nicht...

      Mir war garnicht bewusst, dass man z.B. ElementDatas modifizieren kann, denn als ich hier vor nem Monat gefragt habe, ob das ginge, sagte man mir glaub ich dass es nicht möglich sei...
      Das Positive, was es bei dieser Art von Hacks wenigstens gibt, ist dass man für jeden Server einen anderen "Hack" programmieren müsste, da nicht jeder Server im selben ElementData sein Geld speichert...
      Ich denke mal man macht es den Hacker auch mit einer anständigen Lua Verschlüsslung schwer...

      €: Was ich nicht verstehe ist der 1. Punkt, wie man setElementData hacks unterbinden kann...

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Tockra ()

    • btw ich war mal auf einem serv keine ahnung wie dias angestellt haben aber die haben ihr client scripts compiled so das die für einen selber sei es jetzt ich oder zipper oder xyz nicht lesbar waren also man konnte sie öffnen etc und auch an sich anschauen aber was da drinn stand war einfach wie wenn man versucht ein amx script einfach zu editen was die da gemacht habe würde mich sehr interessieren

      back to topic
      Nett das du das anderen Servern zur verfügung stellst gutest Tut und auf jeden fall für viele sehr hilfreich.

      LG
      [Blockierte Grafik: http://i86.servimg.com/u/f86/13/06/48/88/2143710.png]

      Realrum Reloaded would come in a new an great shine :>
    • Vip wirst du, indem du dem Forum z.B. durch eine Domainweiterleitung hilfst oder dem Forum auf einer anderen Weise beim Aufbau hilfst.
      Finde Zipper auch Sympatisch, aber ich denke nicht, dass man Vip Rechte bekommt, wenn man Tutorials schreibt, denn sonst würde jeder der gute Tutorials schreibt Anspruch auf Vip "Rechte" erheben...
      Ist meine Meinung ^^
    • Das mit dem Vip fänd ich eine nette Geste,
      aber das ist nicht meine Entscheidung und ich hab
      das Tut auch nur deshalb geschrieben, um die anderen
      zu unterstüzten und somit MTA im allgemeinen zu fördern.

      Zum Thema compilen:
      Es hilft nur bedingt, z.b. kann man sich immer noch dumps ziehen
      und so z.b. die einzelnen ElementDatas oder Events usw. auslesen,
      zudem werden ja nur die Lua-Funktionen und z.b. keine Variabeln kompiliert.
      Ausserdem schwirrt irgendwo ein Decompiler rum...

      EDIT:
      Hab mal was zum compilen von Scripts geaddet

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Zipper ()