mySQL problem...

Re(11): mySQL problem...

googleDork — Wed, 02 May 2007 07:46:45 GMT

Da muß ich mal Antimonia zitieren:

Zahlst einen Liter

Re(10): mySQL problem...

West — Wed, 02 May 2007 07:22:14 GMT

So anhand Deines (richtigen) Einwurfs hab ich jetzt das auch umgestellt..

- Login/PWD wird nur bei einmaligem Registrieren/Login übertragen
- GUID wird generiert und als Cookie abgelegt, mit 30Tagen - Timeout
- Beim einloggen wird die GUID abgefragt und mit einer Tabelle wo GUID/UserID zusammengeführt wird verglichen

... sollte jetzt schwerer zu übertricksen sein..

Re(7): mySQL problem...

Dr. Watson — Sun, 29 Apr 2007 22:06:33 GMT

Strings die in der DB landen sollen, müssen per pg_escape_string (PostgreSQL) oder mysql_real_escape_string (MySQL) escaped werden.

Absolut jede Eingabe die vom Benutzer kommt muss genauestens Validiert werden, es darf kein buchstabe in ein Query gelangen, in dem ein Integer benötigt wird.

Nochmal, die Magic Quotes sind für sowas keine Saubere Lösung, weil sie nur ein paar Zeichen escapen, aber das ist keine Schutzmaßnahme.

Dessen sind sich auch die PHP Entwickler selbst bewusst, darum werden die MagicQuotes genau so wie der Safe Mode (der eben so wenig bringt) in der kommenden Version (6) hinausfliegen.

Links:
http://www.php.net/~derick/meeting-notes.html#magic-quotes

[edit]
Das folgende Buch nimmt sich komplett der Problematik PHP + Security an, hab ich gelesen, ist zu empfehlen.
http://www.oreilly.com/catalog/phpsec/

Re(7): mySQL problem...

Dr. Watson — Sun, 29 Apr 2007 22:06:33 GMT

Re(6): mySQL problem...

MG — Sun, 29 Apr 2007 21:21:29 GMT

Sorry, dass ich nochmal lästig bin. Ist reines Eigeninteresse. Habe einige Scripte laufen. Bin aber zugegebenermaßen nur Dilettant.

MagicQuotes können deaktiviert werden, alleine darin liegt schon die größte Gefahr.
Weiters werden nur die GPC Variablen escaped, nicht aber Strings, die
anderweitig in den Code gelangen, sei es durch Schnittstellen, Verwendung
eines Wertes, der aus der DB kommt, oder sonst was.

Dachte, dafür gibts : magic_quotes_runtime = On
Zumindest behauptet meine php.ini das.

Davon abgesehen braucht es nicht zwingend single Quotes, um eine SQL Injection zu erreichen.

Das macht mich jetzt aber unruhig. Biiiite Links.
Danke.

Re(5): mySQL problem...

Dr. Watson — Sun, 29 Apr 2007 21:03:56 GMT

Links findest über Google genug.

MagicQuotes können deaktiviert werden, alleine darin liegt schon die größte Gefahr.
Weiters werden nur die GPC Variablen escaped, nicht aber Strings, die anderweitig in den Code gelangen, sei es durch Schnittstellen, Verwendung eines Wertes, der aus der DB kommt, oder sonst was.

Davon abgesehen braucht es nicht zwingend single Quotes, um eine SQL Injection zu erreichen.

Im Endeffekt sind die MagicQuotes nur ein Versuch, die Sicherheit zu erhöhen, weil die meisten Anfänger (und oft auch möchtegern Fortgeschrittene) überhaupt keine Ahnung haben, was sie da tun.

PHP hat in der Vergangenheit genug Imageschäden davon getragen, weil die Leute durch die vermeintliche Einfachheit solche Schrott-Skripte (z.b. wie das vom Thread-Ersteller, das im E_ALL Modus nur Notices ausspucken würde) produzieren.

Re(4): mySQL problem...

MG — Sun, 29 Apr 2007 20:57:38 GMT

Hm. Links bitte. Ich lese eigentlich immer und überall genau das Gegenteil.

Re(3): mySQL problem...

Dr. Watson — Sun, 29 Apr 2007 20:33:45 GMT

Magic Quotes sind keine Schutzmaßnahme gegen SQL Injections, die Gründe dafür kannst du auf einer Vielzahl von Seiten nachlesen.

Re(2): mySQL problem...

MG — Sun, 29 Apr 2007 20:24:23 GMT

ad a)
Du musst sämtliche Eingaben des Benutzers escapen - ansonsten reicht schon ein
"asd') OR 1=1" als Passwort, und schon ist dein Benutzer als admin eingeloggt,
wenn er den Usernamen eines Admins errät.

Wenn magic quotes On ist?

Re(11): mySQL problem...

googleDork — Sun, 29 Apr 2007 15:17:38 GMT

Da bin ich eh voll bei Dir...
Genau drum schrieb ich ja in dem Thread, daß man ein Secret mit Ablaufdatum bei der Anmeldung generieren soll..

West schlug aber vor, immer das encryptete Paßwort zu versenden - und das ist ein Fehler. Denn wenn der Server immer das verschlüsselte PW erwartet, übernimmt das encryptete PW die Rolle des PWs selbst...

Deine Lösung gefällt mir da weit besser - wäre ja auch meine .
Nur die client_ip einzubinden halte ich für nicht super. Denn die kann sich ja - beispielsweise via tor - bei jedem neuen GET ändern. UID verknüpft mit den aktuellen millisekunden des Datums halte ich für ausreichend unvorhersagbar - wäre ein gutes Secret in meinen Augen... Gerne die MD5 drüber.

Re(10): mySQL problem...

japh — Sun, 29 Apr 2007 11:46:28 GMT

wenn deine sessions expiren, dann kannst du mit der md5 (o.ae.) schon "nur" mehr die session hjacken, und nicht mehr den account uebernehmen - angriffe muessen also zumindest innerhalb des session timeout passieren.

wenn du die md5 z.b. aus uid + client_ip + login_timestamp generierst und das beim pruefen des cookies beruecksichtigst - (session table enthaelt client ip und timestamp vom login => select uid, ip, login_timestamp from sessions where md5=md5_cookie and timstamp > NOW() - interval '1 hour' => md5_cookie == md5(uid + client_ip + login_timestamp) ? accept : reject) geht's schon nur mehr vom selben gateway aus.

Re(9): mySQL problem...

googleDork — Thu, 26 Apr 2007 19:19:04 GMT

Ob du das PWD plain oder Encrypted schickst (oder als MD5, ...) ist völlig wurscht...
das war ja auch der Fehler in MS-CHAPv1... Denn wenn Eve das Encryted-Password mitsnifft, kann sie es genauso verwenden als ob es das echte wäre

Re(8): mySQL problem...

West — Thu, 26 Apr 2007 19:17:42 GMT

Du mußt ja des Pwd ned plain schicken, er schickts ja nur 1x bei seiner registrierung, bzw. beim ersten login, danach setzt encrypted cookie und gut ists.

Re(7): mySQL problem...

googleDork — Thu, 26 Apr 2007 19:15:54 GMT

Überprüfung der Cookies "username", "passwort" und vergleich mit der Datenbank.

vs.

Ich würd niemals ein Cookie setzen mit plain Pass

Ich kenn mich nimma aus!!!

Re(6): mySQL problem...

[mC]Kasun — Thu, 26 Apr 2007 19:08:30 GMT

is eigentlich nur eine kleine gilden hp...naja ob de jetzt noch immer so klein is, glaub ich nicht ^^

Re(6): mySQL problem...

West — Thu, 26 Apr 2007 14:25:01 GMT

Liege ich da falsch ???

Nah liegst überhaupt ned, der Aufruf wird bereits mit gesetzten Cookies getan. Die Cookies werden von PHP in einem Array sortiert.

Aber man hat natürlich selbst dfür zu sorgen welcher Inhalt in den Cookies steht. Ich würd niemals ein Cookie setzen mit plain Pass - außer zum Testen mal.

Aber ich hab des eh immer anders, da ich ja ablehne Webdesigner zu spielen arbeite ich mit Smarty und da hab ich nur eine Klasse mal die die POSTS/GETS abfängt...

public function __construct ()
{
$this->m_oConfig = new config();
$this->m_oActions = new actions();
$this->loadEnv();

}

private function workEnv()
{
}

private function loadEnv()
{
$this->m_oActions->set ($_GET, "g");
$this->m_oActions->set ($_POST, "p");
}

Hat für mich den Vorteil das ich das in meiner actionklasse das systematisch nach meinen Vorgaben ordnen kann..

public function get ($what)
{
// Gets the posted/getted/userset Values from array in order.
$result = "";
if (array_key_exists ($what, $g_actions))
$result = $this->g_actions[$what];
if (array_key_exists ($what, $p_actions))
$result = $this->g_actions[$what];
if (array_key_exists($what, $u_actions))
$result = $this->u_actions[$what];

if (strlen($result) == 0)
return FALSE;
else
return $result;
}

Somit hast schöne Collectorenklassen die man natürlich weiter wieder serialisieren kann oder ähnliches anhand der Userdaten.. ist aber..muß ich zugeben Recycle Code der schon seit php5 Release ned angegriffen wurde

Re(5): mySQL problem...

googleDork — Thu, 26 Apr 2007 14:13:35 GMT

Dann schickst du selbständig immer(!) Klartext-Username- und Password-Cookies
an den Server ???

nö.. Wieso ?

Mal ein großes "ICH GLAUBE" um alles:

Angenommen, du rufst seite xxx.porn.at auf, und hast als zahlender Stammkunde deine Cookies zur Identifizierung.

Dann hast ja Serverseitig dann beispielsweise eine PHP-Routine, die die Cookies weiter prüft.

Ich glaube nun, daß es eben nicht so ist, daß der Server dann dem Client einen Request schickt a la "Liefer mir dein username-Cookie für xxx.porn.at".

Ich glaube hingegen schon, daß der Client bei seinem GET-Request für xxx.porn.at gleich mal alle Cookies im Header mitschickt, die er für xxx.porn.at hat...

Liege ich da falsch ???
Der erste Ansatz würde ja massiv Latenzzeiten erhöhen - drum glaube ich an den zweiten.
Wenn aber der zweite Ansatz gilt und du Username & Password in Cookies abgelegt hast - dann würdest eben dauernd Username und Password mitschicken - daher entstand meine "Dann schickst dauernd..." - Vermutung.

Re(8): mySQL problem...

West — Thu, 26 Apr 2007 14:06:57 GMT

jo so ziemlich gleich sinnlos

Re(7): mySQL problem...

googleDork — Thu, 26 Apr 2007 14:05:15 GMT

Nachdem Du ja ausführtest, daß mein Weg sinnlos kompliziert sei... Und nachdem deiner ziemlich äquivalent ist... Ist also deiner auch sinnlos kompliziert, deiner Meinung nach ?

Re(6): mySQL problem...

googleDork — Thu, 26 Apr 2007 14:04:17 GMT

Nette Methode...

Da hatte ich bisher Glück mit Latin1-Encoding .

Abgesehen davon sind prepared-Statements oft eh sinnvoller..
Keine Gefahr, kein Neuparsen des Execution Plans - habe nur keine Ahnung, ob mysql/php das hinbekommt.

Re(6): mySQL problem...

West — Thu, 26 Apr 2007 14:00:20 GMT

Also den groben unterschied sehe ich noch nicht .

Naja mit der UUID verknüpfung..

ich auch nimmer wirklich

Re(5): mySQL problem...

googleDork — Thu, 26 Apr 2007 13:58:11 GMT

Also irgendwie machst Du nicht viel anderes als ich...

Dein Timestamp-Cookie entspricht so ziemlich meinem Secret-Cookie...
Wobei mein Secret-Cookie eben den User identifiziert.

Also den groben unterschied sehe ich noch nicht .

Re(5): mySQL problem...

japh — Thu, 26 Apr 2007 13:56:26 GMT

...und dann gibt's da noch so lustige sachen.

Re(4): mySQL problem...

West — Thu, 26 Apr 2007 13:53:36 GMT

Hmmm...

Die Cookies werden ja selbständig bei jedem GET- oder POST-Request mit an den
Server geschickt, wenn die Domäne paßt, oder ?

Jepp genau.

Dann schickst du selbständig immer(!) Klartext-Username- und Password-Cookies
an den Server ???

nö.. Wieso ?

Gibt ja die password() funktion von MySQL, und nach der erfolgreichen Authentification setzt man das cookie via: select password from user where id = $_GET["id"]; damit sendest nur uname plain, und der reicht ja ned.

Bin ja ned Geizhals *duck*

Abgesehen davon reicht es dann aus, sich selbst ein timestamp-Coolie zu
generieren und ich bin als jeder gewünschte User drin ?

Das stimmt schon, du kannst es natürlich auch noch verknüpfen mit einer UUID die Du generierst und in einer eigenen Tabelle (phpbb like) verknüpfst. Ist die UUID bereits abgelaufen in der Tabelle => reauth bzw. login.

(so schauts bei meinem jetztigen Projekt aus, weil man da easy mit einer zeitverknüpften Abfrage die letzten User in xx Minuten erruiren kann).

Re(4): mySQL problem...

West — Thu, 26 Apr 2007 13:53:36 GMT

Hmmm...

Die Cookies werden ja selbständig bei jedem GET- oder POST-Request mit an den
Server geschickt, wenn die Domäne paßt, oder ?

Jepp genau.

Dann schickst du selbständig immer(!) Klartext-Username- und Password-Cookies
an den Server ???

Abgesehen davon reicht es dann aus, sich selbst ein timestamp-Coolie zu
generieren und ich bin als jeder gewünschte User drin ?

Re(3): mySQL problem...

googleDork — Thu, 26 Apr 2007 13:50:15 GMT

Hmmm...

Die Cookies werden ja selbständig bei jedem GET- oder POST-Request mit an den Server geschickt, wenn die Domäne paßt, oder ?

Dann schickst du selbständig immer(!) Klartext-Username- und Password-Cookies an den Server ???

Abgesehen davon reicht es dann aus, sich selbst ein timestamp-Coolie zu generieren und ich bin als jeder gewünschte User drin ?

Re(2): mySQL problem...

West — Thu, 26 Apr 2007 13:45:51 GMT

Wozu so kompliziert ?

Da die Datenbank eh andauernd durch Seitengenerierung penetriert wird kann er ja ruhig das abfragen, die Abfrage kostet quasi keine Zeit, insbesondere wenn der Server lokal ist und die Verbindung über Sockets gemacht wird, nicht über TCP.

Weiters find ich die Authentificationsmethode bisserl kompliziert.

So machs ich:

keine Cookies gesetzt => Loginpage
timestamp cookie gefunden => ist es noch im Zeitrahmen => kein Login
== " == => es ist nicht im Zeitrahmen => Überprüfung der Cookies "username", "passwort" und vergleich mit der Datenbank.

Logout ? => timestamp cookie löschen und gut ists.

Re(7): mySQL problem...

error-is.org — Thu, 26 Apr 2007 13:21:37 GMT

welche funktion man in welcher situation benutzt muss jeder für sich selbst entscheiden.

ich habe mir ne eigene funktion gebastelt in der ich mitschicke wofür der inhalt bestimmt ist.

Re(6): mySQL problem...

googleDork — Thu, 26 Apr 2007 13:11:28 GMT

Also ich rate aus 2 Gründen zu addslashes:
1.) Unabhängig von der Datenbank. Kann nur ein Vorteil sein.
2.) Hier (Username-eingabe bzw. PW-Eingabe) würde ein "\n" kaum schaden.

Re: mySQL problem...

googleDork — Thu, 26 Apr 2007 13:08:29 GMT

Grober Ablauf-Vorschlag:

Du baust dir ein Include-File, das zuerst mal schaut, was im Secret-Cookie (Session) drin ist...
Wenn ein Secret-Cookie herkommt, prüfst in deiner DB, ob es ein gerade valides ist und welchem Benutzer es gehört. Dadurch hast du den Benutzer identifiziert, der sich gerade anmeldet.

Wenn kein gültiges (also evtl. auch keines) vorhanden ist, schickst ihn zur Anmeldemaske....
Nach Prüfung in der DB kann hier ein (möglichst langes, nicht sequenziell aufsteigendes) Secret-Cookie generieren, dem Client schicken und in der DB bei dem User als aktuelles hinterlegen.

In jeder Sicherheitsrelevanten PHP-Seite machst einfach ein require() auf obige Datei und fertig.

Beim Abmelden aus deiner Applikation wird einfach das Secret in der DB gelöscht.

Vorteil:
- Es werden nicht dauernd Username/PW hin-und-hergeschickt. Wenn einer ein Cookie mitsnifft, kann er es nur für die Dauer der Session mißbrauchen.
- Es ist recht einfach und performant.
- Gut gekapselt

Natürlich darfst natürlich nicht vergessen, auch die Cookie-Inhalte alle zu Escapen - schließlich kann sich jede Eve die auch laufend selbst erzeugen und so SQL-Injection probieren.
Ebenfalls mußt Du sicherstellen, daß die Cookies nicht fortlaufend sind... Wenn ich Eve spiele und ein Cookie wie secret="12345" erhalte, werde ich es sicher mal spaßhalber mit dem Cookue "12346" probieren bzw. mich selbst öfters anmelden um das Schema der Cookie-Generierung zu erraten

Re(5): mySQL problem...

error-is.org — Thu, 26 Apr 2007 12:55:24 GMT

um nur ' zu escapen hast du schon richtig genannt addslashes

mysql_escape_string "säubert" halt ein bisschen mehr (zb. für einzeilige eingabeformulare)
mysql_real_escape_string beachtet halt den zeichensatz noch.

eigentlich reicht es imho den delimiter (') zu escapen.

Re(4): mySQL problem...

[mC]Kasun — Thu, 26 Apr 2007 12:53:02 GMT

aso...eh... befindet sich in einer eigenen datei , wenn du das meinst hmm.. *kopfkratz*

Re(2): mySQL problem...

[mC]Kasun — Thu, 26 Apr 2007 12:39:56 GMT

is eh..hmm is eigentlich nur ein registrierscript, also der neue meledet sich am...nach eintrag (in die DB) kommt er auf die danke-seite, wo er gleich paar zusätzliche angaben machen kann.

zuvor war das nur so: jmd meldet sich auf der seit an,...und das wars, er musste sich dann noch mal einloggen damit er auf seine seite kommt, jetzt hab ich das bissl modifiziert, das er automatisch gleich nach erfolgenreichen anmelden auf seine persönliche seite kommt.
klappt aber nicht ganz und is auch unsicher,. ...hmm

Re(4): mySQL problem...

googleDork — Thu, 26 Apr 2007 12:26:48 GMT

Hilf mir mal:

Abgesehen davon, daß dein erster Link deprecated ist

Bei mysql_real_escape_string findet man, daß folgende Zeichen dann escaped werden:
"\x00, \n, \r, \, ', " und \x1a"

Meine Frage:
Warum reicht es nicht, einfach nur das "'" zu escapen ?
Dürfen MySQL-Strings beispielsweise kein \n enthalten ????

Re(3): mySQL problem...

error-is.org — Thu, 26 Apr 2007 12:20:10 GMT

zur ersten hilfe: http://at2.php.net/mysql_escape_string
interessant: http://www.phpinsider.com/php/code/SafeSQL/
grundsätzlich: http://www.google.com/search?q=php+sql+injection

Re(3): mySQL problem...

googleDork — Thu, 26 Apr 2007 12:19:58 GMT

Hmm...

Zu allererst würde ich dein Datenmodell kontrollieren...
Vielleicht postest mal einen Link auf dein ER-Diagramm!

Zum Escapen von Parametern könntest jedenfalls addslashes verwenden.

Re(4): mySQL problem...

[mC]Kasun — Thu, 26 Apr 2007 12:06:18 GMT

mei, lassen machen kommt ohnehin nicht in frage............ naja dann schau ich mich mal um...

Re(3): mySQL problem...

Dr. Watson — Thu, 26 Apr 2007 12:04:48 GMT

PHP ordentlich lernen und das ganze richtig machen, oder es lassen...so hart es auch klingt.

Re(3): mySQL problem...

Dr. Watson — Thu, 26 Apr 2007 12:04:48 GMT

PHP ordentlich lernen und das ganze richtig machen, oder es machen lassen...so hart es auch klingt.

Re(2): mySQL problem...

[mC]Kasun — Thu, 26 Apr 2007 11:54:47 GMT

oh kk.. hmmm

das es lückenhaft is ...weiß ich bzw mir bekannt,... der 1. script war noch unsicherer...

was muss ich tun das damit es sicherer wird, bin nur hobby progger,... kenn mich nur teilweise damit aus...

Re: mySQL problem...

Dr. Watson — Thu, 26 Apr 2007 11:49:36 GMT

Dein Code ist
a) extrem unsicher - SQL Injections sind sofort möglich, und
b) komplett unlogisch.

ad a)
Du musst sämtliche Eingaben des Benutzers escapen - ansonsten reicht schon ein "asd') OR 1=1" als Passwort, und schon ist dein Benutzer als admin eingeloggt, wenn er den Usernamen eines Admins errät.

ad b)
Du führst in einer IF Bedingung ein Query aus (INSERT INTO mitglieder), und den Rückgabewert von mysql_query, also 1, wenns erfolgreich war, gibst du innerhalb des IF Konstrukts gleich nochmal an mysql_query weiter.

Dadurch entsteht dann der Fehler, weil das Query "1" keines ist.

mySQL problem...

[mC]Kasun — Thu, 26 Apr 2007 11:41:41 GMT

Hallo, ich hab eine bitte, ich bin jetzt irgendwie blind und find den fehler nicht.

also ich bekomm diesen fehler.
Error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '1' at line 1

sonst bekam ich diesn fehler wenn ich zb ("") statt ('') o.s.ä verwendet hab....ok hier der code, es ist ein anmeldescript und gleichzeitig soll dieser script bei erfolgreichen eintrag dann automatisch verbinden. eingetragen wird. aber es ging zunächst der passwort match nicht, weitergeleitet wurde es dann aber auf die membersseite(weil die passwörter doch gleich waren), ...aber bei absichtlichen falsch eintragen kam ein error. den hab ich jetzt beseitigt ,jetzt pfunziwunzifunztatatut der passwort match , nur kommt es zu keiner weiterleitung auf die membersseite ^^ ..irgendwo is ein fux..


if ($_POST['passwort'] == $_POST['passwort2'])
{ $nname = $_POST['nname'];
      $passwort = md5($_POST['passwort']);
      $name = $_POST['name'];
	  $nachname = $_POST['nachname'];
	  $land = $_POST['land'];
	  $age = $_POST['age'];
	  $email = $_POST['email'];
	  $forumsig = $_POST['forumsig'];
	  $seit = $_POST['seit'];

include("config.php");
		$date = date("g:i, j F Y");
       if( $addplayer = mysql_query("INSERT INTO mitglieder (nname, passwort, 
                                                name, nachname, land, 
                                                age, email , forumsig, seit)". 
		"VALUES ('".$nname."',
		'".$passwort."',
		'".$name."',
		'".$nachname."',
		'".$land."','".$age."',
		'".$email."','".$forumsig."', '".$date."')"))
		
$result = mysql_query($addplayer) or die("Error: " . mysql_error());   


session_start();
$uid= $_POST['uid'];
$nname= $_POST['nname'];
$passwort= md5($_POST['passwort']);

$q="SELECT nname,passwort,uid,rechte FROM mitglieder WHERE ((nname='$nname') 
AND (passwort='$passwort')) LIMIT 1";
$result= mysql_query($q);
("Could not execute query : $q." . mysql_error());

if (!$result)
{ echo "<div align=center><b>Oops! Your login is wrong. Please click back and 
try again.</b></div>"; }
else
{
$r=mysql_fetch_array($result);
$login_username=$r['nname'];
$login_userid=$r['uid'];
$login_userright=$r['rechte'];
$_SESSION['benutzer'] = $login_username;
$_SESSION['uid'] = $login_userid;
$_SESSION['rechte'] = $login_userright;
Header("Location: http://*****************/members.php?content=danke");} 
}else{echo" Passwörter stimmen nicht überein";}

is ein bisserl lang, aber anders gehts leider nicht..tut mir leid

danke für die hilfe
mfg
mck