kleines offtopic
kurzer hinweiss an Kallisti
$_SERVER['HTTP_USER_AGENT'] wird nicht von magic quotes behandelt und kann somit nicht escapte zeichen enthalten
Split: magic_quotes in $_SERVER-Vars
gepostet vor 18 Jahre, 5 Monate von HSINC
gepostet vor 18 Jahre, 5 Monate von Kallisti
Whopsala, danke dir.
gepostet vor 18 Jahre, 5 Monate von BLUESCREEN
Original von HSINC
$_SERVER['HTTP_USER_AGENT'] wird nicht von magic quotes behandelt und kann somit nicht escapte zeichen enthalten
Ich habe das eben getestet und es wird durch magic_quotes_gpc behandelt, obwohl "gpc" nur für "GET/POST/COOKIE" steht.
gepostet vor 18 Jahre, 5 Monate von Kampfhoernchen
Ich logge zu jeder Session:
- Username, Startzeit, IP, User-Agent
Und zu jedem Seitenaufruf (pro User einstellbar):
- URL + Post-daten
- Zugehörige Session
- Zeitpunkt des klicks
- Username, Startzeit, IP, User-Agent
Und zu jedem Seitenaufruf (pro User einstellbar):
- URL + Post-daten
- Zugehörige Session
- Zeitpunkt des klicks
gepostet vor 18 Jahre, 5 Monate von HSINC
Original von BLUESCREEN
Original von HSINC
$_SERVER['HTTP_USER_AGENT'] wird nicht von magic quotes behandelt und kann somit nicht escapte zeichen enthalten
Ich habe das eben getestet und es wird durch magic_quotes_gpc behandelt, obwohl "gpc" nur für "GET/POST/COOKIE" steht.
mhh bei meinen tests wird nix escaped. ' werden 1:1 übernommen. liegt vielleicht an der php version
gepostet vor 18 Jahre, 5 Monate von woodworker
anmerkung: magic quotes sind das schlimmste was php jemals passiert ist
wer das benutzt sollten die finger abgehackt bekommen und in php6 gibts das nicht mehr genausowenig wie den safemode und register globals
wer das benutzt sollten die finger abgehackt bekommen und in php6 gibts das nicht mehr genausowenig wie den safemode und register globals
gepostet vor 18 Jahre, 5 Monate von knalli
Original von woodworker
anmerkung: magic quotes sind das schlimmste was php jemals passiert ist
wer das benutzt sollten die finger abgehackt bekommen und in php6 gibts das nicht mehr genausowenig wie den safemode und register globals
letzteres ist doch seit 4 schon verwunschen gewesen.. nun ja, per default erst in 5
Was ist an MQ schlecht? Das man faul wird? Das Argument könnte ich nämlich verstehen, man muss schon wissen, was man tut.
gepostet vor 18 Jahre, 5 Monate von woodworker
nein wenn du magicquotes an hast und selber nochmal escapst kann es dazu kommen das das escapen wieder aufgehoben wird
also musst du immer prüfen ob mq an ist oder nicht und richtig drauf reagieren
PS: per defualt war reg globals schon ab 4.3 in der ini aus aber ab 6 ist es halt komplett aus dem source raus und es wird ein fehler geworfen wenn es doch in der ini steht
also musst du immer prüfen ob mq an ist oder nicht und richtig drauf reagieren
PS: per defualt war reg globals schon ab 4.3 in der ini aus aber ab 6 ist es halt komplett aus dem source raus und es wird ein fehler geworfen wenn es doch in der ini steht
gepostet vor 18 Jahre, 5 Monate von Mudder
So da aus dem kleinen Offtopic wiedermal eine Threadfremde Diskussion geworden ist gabs nun ein kleinen Themensplit..
gepostet vor 18 Jahre, 5 Monate von knalli
Original von woodworker
nein wenn du magicquotes an hast und selber nochmal escapst kann es dazu kommen das das escapen wieder aufgehoben wird
also musst du immer prüfen ob mq an ist oder nicht und richtig drauf reagieren
Das ist klar.. das ist übel. Wie gesagt, wenn man etwas nutzt, muss man wissen, was man tut. Also spricht deiner Meinung eigentlich nichts dagegen.. nur Code bzw Coder, die nicht wissen, was wann zu tun ist?
gepostet vor 18 Jahre, 5 Monate von woodworker
um vorwärtskompatibel zu bleiben kein MQ nutzen
gepostet vor 18 Jahre, 5 Monate von knalli
Original von woodworker
um vorwärtskompatibel zu bleiben kein MQ nutzen
Okay, in bezug zu 6 ja
gepostet vor 18 Jahre, 5 Monate von HSINC
dann wage ich mich mal ans orakeln und sag mal ein chaos vorraus wenn es in php6 keine MQ gibt. weil dann auf einen schlag ne menge scripte nicht mehr sicher sind. und das glaube ich nicht das das die php entwickler wollen.
sollte es dann nicht einfach nur doppelt gequotet sein ? also aus \' -> \\\' werden ? ist zwar nicht schoen, aber ich sehe das momentan nicht als sicherheitsrisiko.
btw ich find MQ eine ziemlich gute sache, macht das leben bzw proggen ungemein leichter.
nein wenn du magicquotes an hast und selber nochmal escapst kann es dazu kommen das das escapen wieder aufgehoben wird
sollte es dann nicht einfach nur doppelt gequotet sein ? also aus \' -> \\\' werden ? ist zwar nicht schoen, aber ich sehe das momentan nicht als sicherheitsrisiko.
btw ich find MQ eine ziemlich gute sache, macht das leben bzw proggen ungemein leichter.
gepostet vor 18 Jahre, 5 Monate von Sarge
vergessts wieder kleiner denk fehler
gepostet vor 18 Jahre, 5 Monate von BLUESCREEN
Original von HSINC
mhh bei meinen tests wird nix escaped. ' werden 1:1 übernommen. liegt vielleicht an der php version
Mit welcher Version hast du das denn getestet?
Ich habe inzwischen zwei Versionen getestet:
PHP 4.4.2 (aktuelle PHP4-Version)
PHP 4.3.10-16 (Debian stable)
Und bei beiden wurde $_SERVER['HTTP_USER_AGENT'] durch magic_quotes_gpc escaped.
gepostet vor 18 Jahre, 5 Monate von exception
Ich finde es gut, dass magic_quotes entfernt wird. Meiner Meinung nach waren magic quotes einfach der falsche Ansatz um Injection zu verhindern:
Eine Webapplikation läuft ja oft so ab, dass:
1. Daten aus verschiedenen Quellen eingelesen werden
2. verarbeitet werden
3. Für Datenbankzugriffe genutzt werden
magic_quotes versucht bei 1. die Eingaben zu escapen. Das Problem ist aber, dass die Eingabedaten aus ganz verschiedenen Datenquellen kommen können ($_GET, $_POST, $_SERVER aber halt auch Sachen wie Datenbanken, Dateien, Webservices, ...). Um sicher gegen Injection zu sein, müsste man nun alle Datenquellen absichern. Außerdem müsste man darauf achten, dass bei der Verarbeitung der Daten keine ungültigen Zeichen hinzugefügt werden.
In der Praxis würde dies sehr viel Sorgfalt erfordern und kann leicht zu Fehlern führen.
VOn daher halte ich es für einfacher und sicherer, dass bei Datenbankzugriffen die Parameter escaped werden, um Injektion zu vermeiden.
Eine Webapplikation läuft ja oft so ab, dass:
1. Daten aus verschiedenen Quellen eingelesen werden
2. verarbeitet werden
3. Für Datenbankzugriffe genutzt werden
magic_quotes versucht bei 1. die Eingaben zu escapen. Das Problem ist aber, dass die Eingabedaten aus ganz verschiedenen Datenquellen kommen können ($_GET, $_POST, $_SERVER aber halt auch Sachen wie Datenbanken, Dateien, Webservices, ...). Um sicher gegen Injection zu sein, müsste man nun alle Datenquellen absichern. Außerdem müsste man darauf achten, dass bei der Verarbeitung der Daten keine ungültigen Zeichen hinzugefügt werden.
In der Praxis würde dies sehr viel Sorgfalt erfordern und kann leicht zu Fehlern führen.
VOn daher halte ich es für einfacher und sicherer, dass bei Datenbankzugriffen die Parameter escaped werden, um Injektion zu vermeiden.
gepostet vor 18 Jahre, 5 Monate von The-Winner
Ich halte auch nicht viel davon die Eingaben zu escapen. Ich finde dass man die Daten erst escapen sollte wenn man das query erstellt.
Mittlerweile macht das meine Queryfunktion automatisch:
z.B. query("select * from users where nick='%s'",$_GET['nick'])
Dabei escaped query alle Parameter bis auf den ersten mit mysql_escape und ruft anschließen sprintf mit den escapten parametern auf und führt das so entstandene query aus. Für integer Werte verwendet anstelle von %s %d.
Das ist imo eine angenehme uns sichere Methode.
Außerdem kann man so auch noch einfach einbauen, dass wenn das query am lokalen Rechner ausgeführt wird, das fertige query+die Fehlermeldung ausgegeben wird. Und falls trotz allem auf dem server einmal ein sql-Fehler auftritt kann man das gleich loggen, sodass eigentlich kein user unbemerkt sql-injection ausführen kann(Auf Anhieb ein Fehlerloses query mit sql-injection halte ich für extrem unwahrscheinlich).
Mittlerweile macht das meine Queryfunktion automatisch:
z.B. query("select * from users where nick='%s'",$_GET['nick'])
Dabei escaped query alle Parameter bis auf den ersten mit mysql_escape und ruft anschließen sprintf mit den escapten parametern auf und führt das so entstandene query aus. Für integer Werte verwendet anstelle von %s %d.
Das ist imo eine angenehme uns sichere Methode.
Außerdem kann man so auch noch einfach einbauen, dass wenn das query am lokalen Rechner ausgeführt wird, das fertige query+die Fehlermeldung ausgegeben wird. Und falls trotz allem auf dem server einmal ein sql-Fehler auftritt kann man das gleich loggen, sodass eigentlich kein user unbemerkt sql-injection ausführen kann(Auf Anhieb ein Fehlerloses query mit sql-injection halte ich für extrem unwahrscheinlich).
gepostet vor 18 Jahre, 5 Monate von woodworker
jo das ist eine gute lösung so habe ich das auch früher in nutzung gehabt
aber siet dem umstieg auf PDO brauch ich garnicht mehr escapen da ich nur prepared statements nutze udn da ja queryprototyp und daten einzeln geschickt werden
aber siet dem umstieg auf PDO brauch ich garnicht mehr escapen da ich nur prepared statements nutze udn da ja queryprototyp und daten einzeln geschickt werden