kann mir jemand sagen wie man am besten injection Verhindern kann wäre sehr nett
injection Hilfe
08/05/2015 22:11
brongseherr21#1
08/05/2015 22:49
xKeRnx#2
Hier mal eine einfache Methode, gibt zwar noch andere aber diese hier ist sehr einfach.
PHP Code:
// --> Injectbar <--
$GET = $_GET['Username'];
$Post = $_POST['Username'];
PHP Code:
// --> NICHT Injectbar <--
$GET = Escape($_GET['Username']);
$Post = Escape($_POST['Username']);
public function Escape( $str )
{
$str = str_replace( "'", "''", $str );
return trim( $str );
}
08/06/2015 03:06
BennySama#3
Wenn du ausnahmslos jedes Sonderzeichen im Usernamen entfernen möchtest:
Da ich injectionmäßig noch nicht probiert habe, wie es beim Passwort aussieht, da ich das mit einer Variable bereits verschlüssle, bevor es als String in die Datenbank kommt, würde ich beim Passwort auch KeRns Variante nehmen, um zumindest die Anführungszeichen weg zu haben :D
PHP Code:
<?php
$username = preg_replace('/[^a-z\d_äöüß ]/si' , '' , $_GET['username'];
?>
08/06/2015 05:16
D0n!#4
Wenn überhaupt, dann benutze von vorneherein preg_match() und gebe dem Client
dann Auskunft darüber ob seine gewählten Benutzerdaten den Zeichenregeln entsprechen,
wenn nicht dann script abbrechen.
Die ganze replace geschichte ist sehr schwammig und sollte man wohl eher für Output benutzen
um gewisse Zeichen umzuwandeln.
Ausserdem solltest du von vorneherein dich mit Prepared Statements beschäftigen,
denn diese sind grundlegend injectionsicher, egal welcher input vom User kommt.
Dabei muss dann allerdings auf den Output geachtet werden, willst du also später eine
Ausgabe der mit prepared statements hinterlegten Datensätze machen welche unter Umständen auch
HTML oder jeglichen anderen Code enthalten können, achte darauf das dieser "Output" dann dementsprechend
behandelt (bzw nicht behandelt) wird.
Gemeint ist damit, wenn du prepared statements benutzt, kann der Client theorethisch jeglichen kram
als Benutzernamen wählen (soweit nicht vorher behandelt) und dieser würde so wie er es eingegeben
hat als Datensatz in die DB eingetragen jedoch besteht keine möglichkeit die eigentliche Abfrage zu manipulieren
da diese bereits schon vorgefertigt im SQL Server auf die Benutzerwerte wartet.
Würde er nun z.B. als Benutzername <font color="red">HalloIchBins</font> benutzen, und du hättest Später
eine Seite auf der du den Benutzernamen z.B. per echo $username; ausgibst, dann würde auf dieser Seite
in Rot "HalloIchBins" stehen, das gleiche gilt für die weiterverarbeitung in weiteren scripten, auch dort würde exact
das benutzt, was in der DB hinterlegt wird und nutzt du dann an irgendeiner Stelle keine prepared statements mehr
ist die injection vorprogrammiert von daher ist dort sorgfalt angebracht.
Am besten du setzt dich mal 2 Stunden intensiv an die Suchmaschine und informierst dich näher über
die möglichkeiten von Prepared Statements, suchst dir Beispiele raus und wendest diese direkt an.
Replace funktionen sind jedenfalls zumindest für Registrierungseiten oder Loginformulare pfusch und sollten dort
nur bedingte Anwendung finden.
Eine weitere Alternative wären da noch Stored Procedures,
auch diese sollten grundsätzlich injectionsicher sein.
dann Auskunft darüber ob seine gewählten Benutzerdaten den Zeichenregeln entsprechen,
wenn nicht dann script abbrechen.
Die ganze replace geschichte ist sehr schwammig und sollte man wohl eher für Output benutzen
um gewisse Zeichen umzuwandeln.
Ausserdem solltest du von vorneherein dich mit Prepared Statements beschäftigen,
denn diese sind grundlegend injectionsicher, egal welcher input vom User kommt.
Dabei muss dann allerdings auf den Output geachtet werden, willst du also später eine
Ausgabe der mit prepared statements hinterlegten Datensätze machen welche unter Umständen auch
HTML oder jeglichen anderen Code enthalten können, achte darauf das dieser "Output" dann dementsprechend
behandelt (bzw nicht behandelt) wird.
Gemeint ist damit, wenn du prepared statements benutzt, kann der Client theorethisch jeglichen kram
als Benutzernamen wählen (soweit nicht vorher behandelt) und dieser würde so wie er es eingegeben
hat als Datensatz in die DB eingetragen jedoch besteht keine möglichkeit die eigentliche Abfrage zu manipulieren
da diese bereits schon vorgefertigt im SQL Server auf die Benutzerwerte wartet.
Würde er nun z.B. als Benutzername <font color="red">HalloIchBins</font> benutzen, und du hättest Später
eine Seite auf der du den Benutzernamen z.B. per echo $username; ausgibst, dann würde auf dieser Seite
in Rot "HalloIchBins" stehen, das gleiche gilt für die weiterverarbeitung in weiteren scripten, auch dort würde exact
das benutzt, was in der DB hinterlegt wird und nutzt du dann an irgendeiner Stelle keine prepared statements mehr
ist die injection vorprogrammiert von daher ist dort sorgfalt angebracht.
Am besten du setzt dich mal 2 Stunden intensiv an die Suchmaschine und informierst dich näher über
die möglichkeiten von Prepared Statements, suchst dir Beispiele raus und wendest diese direkt an.
Replace funktionen sind jedenfalls zumindest für Registrierungseiten oder Loginformulare pfusch und sollten dort
nur bedingte Anwendung finden.
Eine weitere Alternative wären da noch Stored Procedures,
auch diese sollten grundsätzlich injectionsicher sein.
08/10/2015 13:18
brongseherr21#5
danke für die hilfe ich hab mir jetzt schon so viel angeschaut wie man so ein angrif macht ich kapir es immer noch nicht wie man das bei mir gemacht hatt wenn mir jemand mal ein beispil schreiben kann wie man so ein fiesta charackter admin rechte geben kann kann ich das vieleicht besser verstehen und es so besser verhindern
08/10/2015 13:21
хαrvα#6
Eventuell über die Homepage bzw den Homepage Login?Quote:
danke für die hilfe ich hab mir jetzt schon so viel angeschaut wie man so ein angrif macht ich kapir es immer noch nicht wie man das bei mir gemacht hatt wenn mir jemand mal ein beispil schreiben kann wie man so ein fiesta charackter admin rechte geben kann kann ich das vieleicht besser verstehen und es so besser verhindern
Password Change?
08/11/2015 15:48
Knartz#7
Lies Dir nochmal genau durch, was D0n! geschrieben hat.Quote:
Die Frage danach, wie es funktioniert und gleich ein Beispiel verlangen ist schon etwas auffällig. Du willst es doch eigentlich verhindern und nicht selbst machen!!!
Mfg Knartz
08/12/2015 10:15
xFavouR#8
Bei so gut wie jedem Server geht es noch durch den RestServer/LoginServer, kann ja mal aufzählen wo es geht: Falou, Infinity, Lumia, Fatality, Cyphex, Horizon, Core, Crown, Crusader, Penta, Eternity, Pintos, Chrisma, KernQuote:
08/12/2015 10:46
Galton~#9
Crusader ist nichtmal nen Fiesta server aber gut :DDD
08/12/2015 11:37
xFavouR#10
Hab irgendein Crusader dreck auf dem PC, kann nur aufzählen was im Launcher usw steht. xDQuote:
[Only registered and activated users can see links. Click Here To Register...]
08/12/2015 20:26
Knartz#11
Das Bild sagt gar nichts! Ordner kann jeder ... umbenennen!Quote:
[Only registered and activated users can see links. Click Here To Register...]
Mfg Knartz
08/12/2015 20:44
xFavouR#12
Willst du von einem Müllserver jetzt einen Launcher-Screen, ein IG Screen, alle Seiten + DB Screen, damit du glaubst, das es diesen gibt?Quote:
Mfg Knartz
08/12/2015 21:16
Knartz#13
Nein, mach Dir keine Mühe. ^^Quote:
Lieber hätte ich gerne von Dir einen Injection-Beweis, wenn Du schon solche Behauptungen aufstellst.
Mfg Knartz
08/13/2015 01:00
xFavouR#14
Habe es Kobalt/Mischief schon bewiesen, warum dann noch einen, der nichtmal BEWEISEN KONNTE, dass man buggen kann? :^)Quote:
Lieber hätte ich gerne von Dir einen Injection-Beweis, wenn Du schon solche Behauptungen aufstellst.
Mfg Knartz
08/13/2015 09:18
D0n!#15
Beim releasten Restserver würde ich mal durchaus "Ja" sagen, wenn jemand fragen würde obs geht.
Allein durch die übergabe des Tokens müsste die injection schon möglich sein, denn mit:
wird weder nen prepared statement gestartet, noch werden stored procedures genutzt und das token
landet ungefiltert beim sqlserver.
Zwar werden vorher schon per .Replace() bestimmte zeichen ersetzt, aber nicht alle
die für ne erfolgreiche injection nötig sind.
Was den Loginserver angeht, kein plan, source liegt ja nicht offen und nachschauen kein bock
aber ist durchaus möglich das auch dort irgendwo "ungesicherte" querys stattfinden.
Aber wen wunderts noch.... :D
Allein durch die übergabe des Tokens müsste die injection schon möglich sein, denn mit:
Code:
cmdDoLogin.CommandText = "SELECT nEMID, dDate FROM " + Program.Settings["DatabaseManager.DataSource.TokenTable"] + " WHERE sToken = @token order by dDate asc;";
landet ungefiltert beim sqlserver.
Zwar werden vorher schon per .Replace() bestimmte zeichen ersetzt, aber nicht alle
die für ne erfolgreiche injection nötig sind.
Was den Loginserver angeht, kein plan, source liegt ja nicht offen und nachschauen kein bock
aber ist durchaus möglich das auch dort irgendwo "ungesicherte" querys stattfinden.
Aber wen wunderts noch.... :D