![]() |
PHP - GET variable
hi,
ich habe mal eine frage: Was sagt ihr zu dieser zeile am anfang eines skriptes, um im skript weiterhin mit $_GET['test'] arbeiten zu können
Code:
stellt das in irgendeiner weise ein sicherheitsrisiko dar, wenn man nach dieser zeile mit $_GET['test'] weiterarbeitet?
$_GET['test'] = mysql_real_escape_string($_GET['test'])
|
Re: PHP - GET variable
Warum manipulierst du den Originalparameter?
|
Re: PHP - GET variable
Gegenfrage: Wie sollte ich extra eine neue Variable nehmen? :-D
ich weiß schon, dass man es eigentlich nicht macht, aber es spricht doch im sinne der sicherheit nichts dagegen, oder? |
Re: PHP - GET variable
wieso nicht?
So hat man zumindestens keine doppelten Daten im Speicher. Und dieses ist wohl genauso sicher, als wenn du den Test in einer anderen Variable speichern würdest. |
Re: PHP - GET variable
Danke.
Ich habe das bis jetzt immer so gemacht. Ich wollte nur wissen, ob ich nicht nochmal alles ändern muss wegen der Sicherheit. Aber so wie es aussieht, werde ich es erst bei zukünftigen Seiten ändern. |
Re: PHP - GET variable
Man kann sich so aber nie wirklich sicher sein, ob man nun die Daten wie von PHP geliefert oder die selber behandelten Werte gerade vor der Nase hat.
Ich halte das für ein Potentielle Risiko. Was, wenn Du mal tief in deinen Scripts mal einen direktaufruf machst und, aus welchem Grund auch immer, deine "Behandlungsroutine" wurde nicht durchlaufen...??? Du benutzt fleissig die _GET-Werte ohne sicher zu sein, das sie nochnicht gecheckt wurden. In einem eigenen Array aufgenommen bei der behandlung macht es für Dich sicherer. Nehmen wir an, Du nennst dein Array $getwerte dann kannst Du im weiteren Verlauf sicher sein, das $getwerte ein "behandeltes" Array von Werten ist, die Du problemlos im Querys oder so verwenden kannst. Bei _GET hast du diese Sicherheit nicht. |
Re: PHP - GET variable
Ich würde es zwar auch nicht machen, aber es sollte keine Probleme verursachen.
Allerdings wäre es sinnvoll, bei SQL-Abfragen mit den sog. "prepared statements" zu arbeiten. Da erstellst du die Abfrage mit Platzhaltern und übergibst Typ der Parameter und die Parameter dann an diese maske. Den Rest erledigt PHP für dich. Ich habe mich da nun auch eingearbeitet und da muss man sich ums Escapen nicht mehr kümmern. ;) ![]() @Markus: Es kann sinnvoll sein, die Originalparameter zu verändern. Beispielsweise nutze ich das hier generell:
Code:
Grüße, Matze
// unset deprecated globals
unset($HTTP_GET_VARS, $HTTP_POST_VARS, $HTTP_COOKIE_VARS, $HTTP_SERVER_VARS, $HTTP_POST_FILES, $HTTP_ENV_VARS, $HTTP_SESSION_VARS); |
Re: PHP - GET variable
Zitat:
Ich kann den Prepared-Statement-Vorschlag nur empfehlen, aber noch mehr empfehle ich aber nen Blick ueber den Tellerrand (naja, teilweise). Hier mal ein Beispiel mit Prepared Statements von php.net kopiert:
Code:
Hier ein Beispiel, das auf
$stmt = $mysqli->prepare("INSERT INTO CountryLanguage VALUES (?, ?, ?, ?)");
$stmt->bind_param('sssd', $code, $language, $official, $percent); $code = 'DEU'; $language = 'Bavarian'; $official = "F"; $percent = 11.2; /* execute prepared statement */ $stmt->execute(); ![]()
Code:
Hier wird ohne grossen Aufwand ein Select-Query zusammengestellt. Im Unterschied zum obigen Code ist es mir als Entwickler hier auch vollkommen egal, was fuer ne Datenbank dahinterliegt. Das koennte mySQL sein, aber auch Oracle, MSSQL, ein ODBC-Treiber, usw.
public function getEmploymentHistory()
{ return Doctrine::getTable('EmployeesEmploymentVersion')->createQuery()-> where('id = ?', $this->id)-> orderBy('start_date DESC')-> execute(); } Und um weiter zu gehn, das obige Beispiel von php.net fuegt ein Objekt ein. Insofern ist das Doctrine-Beispiel vielleicht nicht so gut gewaehlt. Deshalb nochmal das Erstellen von Objekten in Doctrine:
Code:
Du sparst dir also viel Handarbeit mit nem ORM wie Doctrine oder Propel, da du nichtmal mehr die Queries selbst ausfuehren musst. Du kannst zwar noch selbst SQL schreiben, aber die oben notierte DQL-Syntax (Doctrine Query Language) ist so intuitiv und angenehm, dass du es nicht mehr willst ;)
$countryLanguage = new CountryLanguage();
$countryLanguage->code = 'DEU'; $countryLanguage->language = 'Bavarian'; $countryLanguage->official = 'F'; $countryLanguage->percent = 11.2; $countryLanguage->save(); Ausserdem hat ein ORM immer Ahnung von den verwendeten Datentypen. Es wird also dafuer sorgen, dass du nen Boolean ins Objekt reinstopfst und ihn wieder rauskriegst, egal was die Datenbank dahinter davon haelt. Foreign Relations sind auch kein Problem - die sind (lazy-loaded natuerlich) im Objekt verfuegbar. Oh, referentielle Integritaet? Klar - ich zeig nochmal ganz kurz wie man ne Datenbanktabelle mit YAML fuer Doctrine definiert:
Code:
Hier definiere ich eine Mitarbeitertabelle. Der actAs-Block sagt Doctrine, dass es bestimmte Verhaltensmuster anwenden soll. TimeStampable sorgt dafuer, dass meine Datensaetze bei jedem Update einen aktuellen Zeitstempel kriegen, damit ich weiss wann der zuletzt bearbeitet wurde.
EmployeesEmployee:
actAs: TimeStampable: ~ Sluggable: name: employee_slug unique: true canUpdate: true fields: [nickname] columns: lastname: { type: string(255), notnull: true } firstname: { type: string(255), notnull: true } nickname: { type: string(255), notnull: true, unique: true } birthday: { type: date, notnull: true } Sluggable erstellt nen Unique-Identifier, der SEO-technisch besser ist als ne ID. In diesem Fall wird der nickname als zusaetzlicher Identifier verwendet, so dass man einfach sprechende URLs bauen kann. Ich empfehl euch echt nen Blick auf Doctrine, das kann einiges an Arbeit abnehmen. Im naechsten Teil gibts dann den Hinweis, warum es Sinn macht, nicht nur ein ORM sondern ein Framework zu verwenden ;) Greetz alcaeus |
Alle Zeitangaben in WEZ +1. Es ist jetzt 10:45 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz