PHP [MYSQL] SQL injection möglich?

[Timmey92]

Hab hier mal einen code ausschnitt aus einem account registrierungs script.

if(count($_POST) > 0) {
		$values = $_POST;
	} elseif(count($_GET) > 0) {
		$values = $_GET;
	} else {
		$values = array();
	} 
	if(count($values) == 0) {
		echo "No data submitted!";
	} else {

//werte stammen ursprünglich aus texteingabefeldern
$login = $values['login'];
$password = $values['password'];
$password2 = $values['password2'];
$email = $values['email'];
$flag = $values['flag'];	
			$create_q = "
				INSERT INTO $logindb.`account` (
										`id` ,
										`username` ,
										`sha_pass_hash` ,
										`last_ip` ,
										`email` ,
										`expansion`
							)VALUES(
										NULL ,
										'$login',
										SHA1(CONCAT(UPPER('$login'),':',UPPER('$password'))),
										'$ip',
										'$email',
										'$flag');";
// for encrypted password:  			SHA1(CONCAT(UPPER('$login'),':',UPPER('$password'))),

			$create_query = mysql_query($create_q, $dbconn)or die(mysql_error());

Meine frage: ist es so, wie ich es geschrieben habe möglich sql injection zu betreiben?

 

[Digital_D99]

ja! du solltest die hochkomma (') abfangen

 

[Fleshgrinder]

Nicht nur Hochkommas, hier wird gar nichts überprüft. Dieses Statement kann auf viele verschiedene Arten missbraucht werden.

 

[Timmey92]

ok danke, wie mache ich das bzw. wie meint ihr das "überprüfen"?
wie kann es denn noch missbraucht werden? :S

 

[Ungolianth]

Dafür gibt es die Funktion mysql_real_escape_string()

 

[badday]

Nur mal so Interessehalber: Gibt es da nicht fertige Filer für sowas?

 

[TheChamäleon]

Pass auf, füge folgendes in deinen Code mal ein:

- Checke deine Textfelder mit If-Abfragen ...
- Wenn Magic_quotes_GPC() "on" ist, schütze deinen Variablen mit der stripslash-Funktion
- Deine variablen mit htmlentities($variable, ENT_QUOTES, "UTF-8") ausstatten...
- trimme mit der Funktion "trim" alle deine Variablen!!!

mysql_real_escape_string brauchst du dann nichtmehr ...

 

[Timmey92]

Nur mal so Interessehalber: Gibt es da nicht fertige Filer für sowas?

bitte was?^^

 

[badday]

Filer = Filter; spezielle Funktionen, sowas wie TheChemäleon mit Magic_quotes_GPC() meint

Sry, das t wollte nicht

 

[ice-breaker]

- Checke deine Textfelder mit If-Abfragen

was er sagen möchte: Wenn etwas eine eMail-Adresse sein soll, dann prüf auch, ob das wirklich eine eMail-Adresse ist. Und das musst du mit allen Daten machen, die vom Client kommen, den der schickt dir potentiell immer böse Daten.

- Wenn Magic_quotes_GPC() "on" ist, schütze deinen Variablen mit der stripslash-Funktion

ein Schutz ist das aber nicht, da wird höchstens ein nicht funktionierender Schutz entfernt.

- Deine variablen mit htmlentities($variable, ENT_QUOTES, "UTF-8") ausstatten...

theoretisch richtig, praktisch hat der Threadhersteller keine Ahnung wo er es tun soll und warum.
Die Antwort: Bei der Ausgabe an den Browser, der zugehörige Angriff nennt sich XSS (ist gefährlicher als SQL-Injections, da viel leichter zu finden)

- trimme mit der Funktion "trim" alle deine Variablen!!!

sinnloser Ratschlag, das hat nichts mit Sicherheit oder ähnlichem zu tun. Es wird nur sinnloser Inhalt in Userdaten entfernt, sollte man zwar auch machen, hat aber null mit Sicherheit zu tun.

mysql_real_escape_string brauchst du dann nichtmehr ...

natürlich braucht er das weiterhin, es gibt auch immernoch Angriffe, die durch solche Prüfungen durchschlüpfen.

Wenn Daten an ein Subsystem übergeben werden (Datenbank, Ausgabe usw.) müssen die Daten immer gesichert werden.
Verfolgt diesen Leitsatz konsequent!


Als Einstieg kann ich dir noch den PHP Security Guide ans Herz legen.

 

[-=Renegade=-]

Die Antwort: Bei der Ausgabe an den Browser, der zugehörige Angriff nennt sich XSS (ist gefährlicher als SQL-Injections, da viel leichter zu finden)

Seit wann ist eine Sicherheitslücker gefährlicher, nur weil sie leichter zu finden ist? Auch wenn man mit einer Stored XSS mehr machen kann als nur Session Hijacking (Keylogger, DoS, ...) so kommt es doch idR nicht annähernd an das potential einer vergleichbaren SQL Injection Lücke.

@TE: Ich würde mich auch mal mit der Thematik von Prepared Statements auseinandersetzen, mysql_real_escape_string ist zwar nett und praktisch, aber wenn du mal auf eine andere Sprache oder ein anderes System (zB Oracle) umsteigst, stehst du sehr schnell an.



so long

 

[TheChamäleon]

Hallo,

@ice-breaker:
Danke das du meine Ratschläge kommentiert hast! :-)

Sicherlich ist es allerdings sehr schwierig zu entscheiden, vorallem bei einem Userregistrationsscript, ob man "mysql_real_escape_string" benötigt oder nicht ... Lasse mal ein User nennt sich "MO$her''"cker" ....

Würde die Funktion mit "mysql_real_escape_string" das nicht in der Datenbank ändern???

Schwer zu entscheiden??

Natürlich könnte man da gewissen Richtlinien bei der Registration einhalten aber damit gibt man dem User weniger Freiheit ....

Was würdest du tun??

 

[-=Renegade=-]

mysql_real_escape_string würde das nicht in der Datenbank ändern. Es würde lediglich verhindern, dass durch die Quotes von "MO$her''"cker" der Parameter beendet wird mit dem SQL Statement fortgefahren wird. Man kann sich trotzdem mit demselben Nickname anmelden.

Die Funktion escaped lediglich durch voran stellen eines Backslashes \ Metacharaktere in SQL Statements, so dass sie nicht als Metazeichen fungieren, sondern als normales Zeichen behandelt werden.

Siehe dazu auch die Referenz Was man natürlich nicht machen darf ist ein komplettes zusammengesetztes SQL Statement escapen, das würde den Programmfluss beeinträchtigen. Lediglich der User Input in den Parametern muss validiert werden.

Sicherheit ist ein sehr komplexes und wichtiges Thema, bitte daher auch nur Ratschläge geben, wenn man sich sehr sicher was man sagt (natürlich kann jeder Mensch irren, aber nicht schon an der Basis )

so long

 

[ice-breaker]

Seit wann ist eine Sicherheitslücker gefährlicher, nur weil sie leichter zu finden ist? Auch wenn man mit einer Stored XSS mehr machen kann als nur Session Hijacking (Keylogger, DoS, ...) so kommt es doch idR nicht annähernd an das potential einer vergleichbaren SQL Injection Lücke.

natürlich hat eine SQL-Injection mehr potential, wenn ich aber in einer Webanwendung als normaler Nutzer XSS-Lücken ca 100 mal so schnell finden kann, wie SQL-Injections und diese auch besser ausnutzen kann (Blind-SQL-Injections sind eine Wissenschaft für sich) dann rechne ich XSS-Lücken ein höheres Gefahrenpotential zu.

 

[-=Renegade=-]

Naja, trotzdem muss man immer in einem gewissen Zusammenhang sehen, was man mit einer Sicherheitslücke machen kann und in welche Richtung sie abzielt. Eine XSS Lücke zielt halt idR auf einen Anwender (clientseitig) ab, während eine SQL Injection das komplette System serverseitig angreifen kann. Natürlich darf man XSS nicht unterschätzen oder als geringfügig abwerten, aber für mich macht das dann doch einen signifikanten Unterschied im Gefahrenpotential.

Außerdem vergleichst du mMn Äpfel mit Birnen wenn du eine einfach zu findende XSS Lücke mit einer Blind SQL Injection vergleichst, es gibt genauso schwierig auszunützende XSS Lücken, bei denen man mehrere Filtersysteme durchbricht, wie es SQL Injection Lücken gibt, die man durch einfache Eingabe in ein Textfeld ausnützen kann.

Zudem sind XSS Lücken auch sehr abhängig von der Struktur des Codes, nicht immer wird es möglich sein, einen Keylogger genau auf der Loginmaske positionieren zu können, noch dazu sind sehr viele XSS Lücken reflected, denen ich ein noch geringeres Gefahrenpotential als Stored XSS Lücken zurechne, da sie eine erweiterte Interaktion mit dem User erfordert.

Zudem bleibt die Frage, was ich als "normaler" Nutzer mit einer XSS Lücke will


so long
Renegade

 

[Fleshgrinder]

Nur mal so Interessehalber: Gibt es da nicht fertige Filer für sowas?

Die gibt es, das Ganze nennt sich „Prepared Statements“ [1], das Ganze könnte dann noch durch „Gespeicherte Prozeduren“ [2] erweitert werden.

In PHP gibt es dafür übrigens speziell das PHP Data Object (PDO) [3]. Joomla! und Drupal 7 setzen dies auch ein um das Backend effektiv zu schützen. Mit etwas Können lässt sich so eine extrem sichere und unglaublich performante Applikation programmieren.