PHP - GET variable

[lonskiswerk]

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:

$_GET['test'] = mysql_real_escape_string($_GET['test'])

stellt das in irgendeiner weise ein sicherheitsrisiko dar, wenn man nach dieser zeile mit $_GET['test'] weiterarbeitet?

[mkinzler]

Warum manipulierst du den Originalparameter?

[lonskiswerk]

Gegenfrage: Wie sollte ich extra eine neue Variable nehmen?

ich weiß schon, dass man es eigentlich nicht macht, aber es spricht doch im sinne der sicherheit nichts dagegen, oder?

[himitsu]

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.

[lonskiswerk]

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.

[DonManfred]

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.

[Matze]

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. Hier findest du ein paar Beispiele.

@Markus: Es kann sinnvoll sein, die Originalparameter zu verändern. Beispielsweise nutze ich das hier generell:

Code:

// 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);

Grüße, Matze

[alcaeus]

Zitat von Matze:

Code:

// 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);

Du weisst dass du unter PHP5 mit $_GET, $_POST usw. Vorlieb nehmen musst und die Variablen nur bei gesetztem Ini-Flag noch gefuellt werden?

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:

$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();

Hier ein Beispiel, das auf Doctrine basiert:

Code:

public function getEmploymentHistory()
{
   return Doctrine::getTable('EmployeesEmploymentVersion')->createQuery()->
      where('id = ?', $this->id)->
      orderBy('start_date DESC')->
      execute();
}

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.

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:

$countryLanguage = new CountryLanguage();
$countryLanguage->code = 'DEU';
$countryLanguage->language = 'Bavarian';
$countryLanguage->official = 'F';
$countryLanguage->percent = 11.2;
$countryLanguage->save();

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

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:

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 }

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.
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