mmofacts.com

Sicherheit von Grund auf!

gepostet vor 18 Jahre, 1 Monat von TheUndeadable
Mal wieder ein paar Microsoft Links. Nahezu alle Links sind nicht auf die Windows-Programmierung bezogen:
Der Entwicklungszyklus für sichere Software:
www.microsoft.com/germany/msdn/library/security/EntwicklungszyklusFuerSichereSoftware.mspx
"Qualität und Microsoft – geht das? Angesichts der scheinbar immer noch andauernden Flut von Patches ist man geneigt, diese Frage eindeutig zu Ungunsten von Microsoft zu beantworten. [...]"
www.microsoft.com/germany/msdn/library/security/SicherheitIstRisikomanagement.mspx
Nochmalig: Erklärung von Injections (kann man nie häufig genug erwähnen)
www.microsoft.com/germany/msdn/library/security/AngriffeVerhindernMassnahmenFuerEntwickler.mspx
Für die Fans eigener Netzwerkprotokolle:
www.microsoft.com/germany/msdn/library/security/WieLassenSichNetzwerkprotokolleVonGrundAufSicherGestalten.mspx
"Fazit
Sicherheit ist kein Feature, welches einem Softwareprodukt nachträglich hinzugefügt werden kann.
"
Zitieren
gepostet vor 17 Jahre von T0bbes
So nebenbei. WebDeveloper Tool ist ein verdammt gefährliches Tool.
Jeder Betreiber/Programmierer sollte sich verpflichten seine Projekte (besonders BG's) mit diesem Tool zu überprüfen. Ich kenne viele Spiele die dies leider noch gemerkt haben, und so hintergangen werden.
Zitieren
gepostet vor 17 Jahre von Nuky
Was meinst du damit jetzt? Die Änderbarkeit von JS, Form-Daten usw.?
Zitieren
gepostet vor 17 Jahre von T0bbes
Der häufigste Fehler liegt daran, das manche BG's die Form-Daten nicht überprüfen.

Pro Stufe eine neue Einheit. Maximal Stufe 5
Ich denke es dürfte klar sein, das ich hier ein Formular habe, um irgendwas in der Werft zu bauen. Aktuelle Stufe: 1. Maximale Stufe 5.
Um nun direkt Stufe 5 zu erforschen kann man mittels des Tools die Formulardaten anzeigen lassen, und so alles ändern. Ich änder in meinem Beispiel nun folgendes:

value="5">
Pro Stufe eine neue Einheit. Maximal Stufe 5

$db->query("SELECT * FROM einht WHERE gebäude = '".$_POST['gebäude']."' AND einheit = '".$_POST['einheit']."');
function einheit_build($_POST['werft_stufe'])
//usw... überprüfung ob es die Einheiten gibt etc...
function einheit_build(&$stufe)
{
$neues_level = $stufe + 1
$db->query("UPDATE user_forschung SET forschung_einheiten = '$neues_level' ");
}
Und schon kann der User nach dieser Aktion die höchste Einheit bauen, ohne jemals Geld für die Entwicklung anderer Einheiten verschwendet zu haben.. Es gibt unendlich viele Möglichkeiten  Bei den großen Games tritt dieser Fehler zum Glück nicht auf, aber es gibt viele kleine Projekte wo solche Sachen oft nicht bedacht werden.
Ich hoffe es wird trotz des schlechten Codes deutlich 
Gruß,







Zitieren	





    
    









gepostet vor 17 Jahre von KoMtuR 







Sorry, aber solch ein Code ist doch schon selten oder nicht? Also ich kann mir kaum vorstellen, dass wirklich noch so viele "ordentliche" Spiele wirklich dem Nutzer vertrauen.
Wer so einen Aufbau in seinem BG hat, bei dem ist das WebDeveloper Tool das geringste Problem 







Zitieren	





    
    









gepostet vor 17 Jahre von T0bbes 







Das was ich im Beispiel gezeigt habe ist mittlerweile wirklich selten ja 
Aber wie gesagt, es war ein einfaches Beispiel und ich werde auch keine konkreten Beispiele zeigen. Aber es gibt einige Fehler die noch immer nicht behoben wurden, und man sich bei einigen Spielen "vorteile" "erpielen" kann 
Gruß,
T0bbes







Zitieren	





    
    









gepostet vor 17 Jahre von Macavity 







Klar halt die üblichen Verdächtigen.. einfach mal negative Werte eingeben und hoffen das man was geschenkt bekommt
was gibts denn sonst noch so?







Zitieren	





    
    









gepostet vor 17 Jahre von Drezil 







naja .. oft geht auch noch sql-injection.
nimm mal folgenden code an:

$qry = $db->query('SELECT uid FROM user WHERE name=\''.$_REQUEST['name'].'\' AND pass=\''.md5($_REQUEST['pass']).'\'');
list($uid) = $qry->fetch($db::NUM);
name ist ungefiltert drin, das pw wird aber gehasht und ist somit für eine sql-injection nicht zu gebrauchen.
Exploit: meld dich mit dem namen "admin' --" und einem pw != '' (wird oft geprüft, ob leer) an.
Qry, die ausgeführt wird: 'SELECT uid FROM user WHERE name='admin' -- AND pass='$md5-ding'
da in SQL alles nach einem "--" als kommentart gilt wird das passwort ignoriert.
Sollte die Anfrage andersrum sein, dann kann man immernoch sowas machen:
Meld dich mit namen "' OR name='admin'" an.
Qry, die ausgeführt wird: 'SELECT uid FROM user WHERE pass='$md5-ding' AND name='' OR name = 'admin'
Dazu muss man aber mindestens den spaltennamen kennen.. (wenn man nen bissl was ungültiges eingibt und der server wie in der standardeinstellung die komplette sql-query als fehler gibt, dann ist das auch kein problem).
Auch beliebt: In pns schauen, ob man irgendwie javascript einschleusen kann, um dann per ajax oder location.href seine eigene seite aufrufen und die cookies stehlen.
Dann kann man sich mit den gewonnenen Daten auch in accs einschleichen und z.b. das passwort ändern (falls man dazu nicht das alte braucht), oder die email ändern und sich ein neues pw zusenden lassen.
Ganz gefählich kann es schnell werden, wenn jemand z.b. zugriff auf die datenbank bekommt (z.b. durch ein veraltetes phpmyadmin auf dem server etc. pp.). Selbst wenn die pws gehasht sind (sha1 oder md5), dann schaut man in einer rainbow-table nach. Auch ein statischer salt oder ein einfacher dynamischer salt (z.b. mit einer anderen tabellenspalte) nützt dann nichts.
Aber gerade in dem letzten Absatz sind sehr viele Wenns.
Wenn der Admin sich an ein paar einfache Regeln hält (z.b. kein ungefiltertes $_REQUEST in einer sql-query), dann kommt man nur noch mit einigen kenntnissen weiter - falls überhaupt.







Zitieren	





    
    









gepostet vor 17 Jahre von KoMtuR 








Original von Drezil
Wenn der Admin sich an ein paar einfache Regeln hält (z.b. kein ungefiltertes $_REQUEST in einer sql-query), dann kommt man nur noch mit einigen kenntnissen weiter - falls überhaupt.

Ich versteh eh nicht, wieso SQL-Injections immernoch möglich sind, obwohl php5 schon so lange existiert. Mit prepared statements sollte dies doch alles Geschichte sein. Da ists mir in erster Linie "egal", was da nun in den übergebenen Daten stehen und ich überlasse die Prüfung der Datenbank.
Aber ich denke viele sehen einfach nur php5 als OO-Wunder und nicht als Aufwertung der Webanwendung, wenn es um Sicherheit und Performance geht. (Performance: xml-Verarbeitung in php4 und 5 mal vergleichen)







Zitieren	





    
    









gepostet vor 17 Jahre von Macavity 







SQL-Injection wurde doch oben schon mal erwähnt dachte ich. Sollte ja auch jeder wissen was es ist 






Zitieren	





    
    




    
    




    











Auf diese Diskussion antworten