Wie sicher ist PHP?

Computer: Software & Programmierung PHP
#1

Hey,

wie sicher ist PHP? Also ist es einfach, es zu „hacken“, also eigenen Code einzufügen?

Gruß,
Lars

#2

Hey,

wie sicher ist PHP?

Hängt ganz stark von der Anwendung ab die man benutzt.

#3

Moien

wie sicher ist PHP?

Ziemlich sicher.

Also ist es einfach, es zu „hacken“, also eigenen Code einzufügen?

Das geht sehr einfach wenn der Programmierer nicht aufgepast hat. Aber das hat nix mit php zu tun, das ist ein Fehler der Programmierer.

cu

#4

Hi Lars,

wie sicher ist PHP? Also ist es einfach, es zu „hacken“, also
eigenen Code einzufügen?

Bei von Newbies geschriebenen Programmen: meist sehr einfach. Wenn Profis am Werk waren: nahezu unmöglich - an sich ist PHP sicher, die Fehler machen nur die, die es programmieren und/oder konfigurieren.

Ich empfehle zur Lektüre ISBN: 9783898644501 Buch anschauen - ich hab das Buch, und da steht gut beschrieben drin, welche Fehler man beim Entwickeln von PHP-Programmen nicht machen darf.

Ciao
Rudy

#5

Hi Lars!

Jede Programmiersprache ist nur so gut wie derjenige, der sie benutzt.
Oder um es mit den Worten von Forrest Gump zu sagen:
Dumm ist der der dummes tut :wink:

Sieh dir nur einmal Produkte von Microsoft an, dann weisst du wie sicher eine Programmiersprache sein kann :wink:

Viele Grüße
André

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

#6

Jede Programmiersprache ist nur so gut wie derjenige, der sie
benutzt.

man sollte aber dazu sagen, dass es sprachen gibt, die einen
vor sachen beschützen, z.b. hat perl taint-checking. wenn man
das aktiviert hat, muss man argumente, die vom benutzer
kommen (also vom browser z.b.), erstmal explizit checken und „untainten“.
PHP hat das nun mal nicht.

des weiteren hat perl z.b. eine standard-datenbank-schnittstelle mit DBI,
die auch bindvars bietet und das ganze sehr einfach macht. in PHP
ist es etwas komplizierter, wenn ich mich richtig erinnere.

wenn das mehr erfahrene php-programmierer erkennen und auch zugeben
würden, könnte man auch newbies beibringen, dass sie zumindest aufpassen
müssen. leider wird das gern geleugnet, und das macht es nicht besser.

1 Like
#7

Hallo,

wie sicher ist PHP? Also ist es einfach, es zu „hacken“, also
eigenen Code einzufügen?

Man muss da immer zwischen der Sprache und dem Interpreter unterscheiden.

Wenn man im CVE mal nach Lücken im Interpreter sucht, findet man schon einiges ( , PHP wählen).
Auch der Umgang mit Sicherheitslücken ist nicht optimal, so hat z.B. vor kurzem ein Entwickler seine Position aufgegeben und zwar aus Protest gegen die Vernachlässigung von Sicherheitsbedenken. Von anderen Scriptsprachen, die häufig für Webprogrammierung eingesetzt werden (python, perl, ruby) ist mir nichts derartiges bekannt.

Was die Sprache angeht kenne ich mich ehrlich gesagt nicht so wahnsinnig gut aus, aber die Dokumentation ermutigt z.B. nicht gerade, bei Datenbankabfragen Platzhalter zu benutzen, wie das bei Perls DBI der Fall ist.

Grüße,
Moritz

#8

Oh Mann, echt, wie wahr…

Manchmal bekomm’ ich das Gefühl, PHP ist eine Sprache von Amateuren für Amateure… Also, nix gegen PHP, ist auch die Sprache, mit der ich hauptsächlich arbeite. PHP ist halt für kleine Unternehmen und kleine bis mittlere Websites immer noch der Standard. Aber ich will wirklich nicht auf PHP schimpfen. Die meisten publik gewordenen Sicherheitsprobleme sind immer noch SQL-Injections, die durch sauberes escapen der Benutzereingaben zu vermeiden gewesen wären, also eigentlich Programmierfehler.

Aber ich hege doch die Hoffnung, daß der momentane Python-Hype zu mehr Bewußtsein darüber führt, daß es noch andere Scriptsprachen außer PHP gibt…

Ähh - schon wieder offtopic, also zurück zum Thema: ich denke, wenn man sauber arbeitet, ist PHP sicher genug. Nur sollte man vielleicht kein Online-Banking mit PHP umsetzen…

Viele Grüße,

Juan

#9

Aber ich will wirklich nicht auf PHP schimpfen.
Die meisten publik gewordenen Sicherheitsprobleme sind immer
noch SQL-Injections, die durch sauberes escapen der
Benutzereingaben zu vermeiden gewesen wären, also eigentlich
Programmierfehler.

der punkt ist aber doch: würde PHP ein so einfaches interface wie
z.b. perl DBI mit bindvars bieten, könnte man einige dieser Fehler vermeiden.
in diesem fall muss man sich nämlich nicht selbst um das escapen kümmern.

#10

Hallo,

Die meisten publik gewordenen Sicherheitsprobleme sind immer
noch SQL-Injections, die durch sauberes escapen der
Benutzereingaben zu vermeiden gewesen wären, also eigentlich
Programmierfehler.

Obwohl das natürlich Programmierfehler sind, ist sauberes escapen nicht die Lösung - Bind parameter sind es.
Beim escapen kann immer was schiefgeben, bei Bind Parameters werden die Variablen direkt zur Datenbankengine weitergegeben - es findet nie ein Fehleranfälliges escaping statt.

Ein Beispiel in Perl:

my $dbh = DBI-\>connect(...);
my $statement = $dbh-\>prepare("SELECT name FROM users WHERE id = ?");

# Die von außen kommenden Daten werden \_nie\_ in einen
# String interpoliert:
$statement-\>execute($cgi-\>param('user\_id'));

Unter der Haube macht der DBI-Treiber eine Stored Procedure, was auch noch ein Performancegewinn ist, wenn man die selbe Query mit verschiedenen Paramtern mehrfach verwendet.

Ich weiß, dass es in PHP entsprechende Bibliotheken gibt, aber anscheinend ist den meisten Programmierern nicht mal bekannt, dass so etwas erstrebenswert ist und existiert.

Grüße,
Moritz

1 Like
#11

Ach ja… *seufz*

Ihr habt natürlich Recht :smile: Und es steht noch mehr auf der Liste, allen voran das mangelhafte Error-Handling oder die fehlenden Test-Möglichkeiten (ich war sehr begeistert, daß Python sowohl ein sehr gutes Error-Handling als auch Unit- und Doc-Tests bietet). Zwar gibt es auch dafür Bibliotheken von Dritt-Anbietern, aber das kann ja nicht die Lösung sein…

Mindestens genauso schlimm finde ich allerdings, wie PHP häufig geschrieben wird: der Code von so bekannten Produkten wie WordPress oder MediaWiki ist, gelinde gesagt, eine Katastrophe. DB-, View- und Controller-Funktionalität werden wild in Methoden gemixt, lokale Variablen tauchen auf, von denen niemand weiß, wo sie initiiert wurden oder welchen Scope sie haben, und, und, und… Aber das beste: in einer einzelnen Datei tummeln sich zwei Dutzend Processing Instructions. Mein absoluter Favorit:

while ($a == $b)
{
?\>
  • …

}

Das meinte ich mit „von Amateuren für Amateure“…

Naja, aber eigentlich wollte ich ja gar nicht rumschimpfen…

Viele Grüße,

Juan

#12

Hallo,

Obwohl das natürlich Programmierfehler sind, ist sauberes
escapen nicht die Lösung - Bind parameter sind es.
Beim escapen kann immer was schiefgeben, bei Bind Parameters
werden die Variablen direkt zur Datenbankengine weitergegeben

  • es findet nie ein Fehleranfälliges escaping statt.

kannst du das Prinzip von „Bind parameter“ mal genauer erläutern?
momentan sieht das für mich so aus als ob die Anfrage direkt an die Datenbank durchgereicht wird. Was für mich im gegenschluß ja bedeutet das für SQL Injektions Haus und Hof geöffnet sind.

Ich weiß, dass es in PHP entsprechende Bibliotheken gibt, aber
anscheinend ist den meisten Programmierern nicht mal bekannt,
dass so etwas erstrebenswert ist und existiert.

Bekannt schon, nur bis jetzt keinen größeren Sinn drin gesehen.
Bin aber lernfähig :wink:

Gruß
Phillip

#13

Hallo,

Obwohl das natürlich Programmierfehler sind, ist sauberes
escapen nicht die Lösung - Bind parameter sind es.
Beim escapen kann immer was schiefgeben, bei Bind Parameters
werden die Variablen direkt zur Datenbankengine weitergegeben

  • es findet nie ein Fehleranfälliges escaping statt.

kannst du das Prinzip von „Bind parameter“ mal genauer
erläutern?
momentan sieht das für mich so aus als ob die Anfrage direkt
an die Datenbank durchgereicht wird. Was für mich im
gegenschluß ja bedeutet das für SQL Injektions Haus und Hof
geöffnet sind.

Das wird es gerade nicht, weil die Datenbank gesagt bekommt, dass die Variablen Daten sind, und kein Programm.

Also mal langsam (in Perl-Syntax erklärt, weil ich keine Ahnung habe, wie man das in PHP macht).

  1. Du rufst prepare auf:

    my $query = $dbh->prepare(‚SELECT foo, bar FROM baz
    WHERE qox = ? AND blubb = ?‘);

Damit erzeugt der DB-Treiber eine Stored procedure, die zwei Argumente erwartet.

Wenn man die Query ausfürhrt,

$query-\>execute($a, $b);

kopiert die Perl-Seite des DB-Treibers die Werte von $a und $b an bestimmte Stellen im Speicher, auf die die DB-Engine zugreifen kann.
Diese liest die Werte aus dem Speicher und führt die Stored Procedure aus. Dabei werden $a und $b niemals als SQL-String behandelt, sondern immer als Daten. D.h. das funktionert mit beliebigen Werten, sie werden niemals escaped.

Ich weiß, dass es in PHP entsprechende Bibliotheken gibt, aber
anscheinend ist den meisten Programmierern nicht mal bekannt,
dass so etwas erstrebenswert ist und existiert.

Bekannt schon, nur bis jetzt keinen größeren Sinn drin
gesehen.
Bin aber lernfähig :wink:

Das wünsche ich mir von mehr PHP-Programmieren…

Grüße,
Moritz

1 Like
#14

Hallo Moritz,

was raucht ihr denn da gerade :wink:

Obwohl das natürlich Programmierfehler sind, ist sauberes
escapen nicht die Lösung - Bind parameter sind es.
Beim escapen kann immer was schiefgeben, bei Bind Parameters
werden die Variablen direkt zur Datenbankengine weitergegeben

  • es findet nie ein Fehleranfälliges escaping statt.

Falsch, das ist *nicht* der Punkt von „Bind Parameters“.
Die trennung von (SQL-Befehl und SQL-Dateninhalt bei der
Eingabe ist es.)

Ein Beispiel in Perl:

my $dbh = DBI->connect(…);
my $statement = $dbh->prepare(„SELECT name FROM users WHERE
id = ?“);

Die von außen kommenden Daten werden _nie_ in einen

String interpoliert:

$statement->execute($cgi->param(‚user_id‘));

Doch, das werden sie, wenn der darunterliegende DBD
keine nativen Placeholder unterstützt, dann werden
die Parameter in DBI gequotet und aufgehoben bis
zum nächsten execute.

Unterstützt der DBD aber Placeholder (MySQL u.a.),
werden die Strings an den DBD durchgereicht,
der dann den Placeholder-Mechanismus der Engine
nutzt (http://dev.mysql.com/tech-resources/articles/4.1/pre…).

Unter der Haube macht der DBI-Treiber eine Stored Procedure,
was auch noch ein Performancegewinn ist, wenn man die selbe
Query mit verschiedenen Paramtern mehrfach verwendet.

LOL, wo hast Du denn das gelesen?

Ich weiß, dass es in PHP entsprechende Bibliotheken gibt, aber
anscheinend ist den meisten Programmierern nicht mal bekannt,
dass so etwas erstrebenswert ist und existiert.

Was Du meinst ist vielleich PEAR:smiley:B, dort gibt es Funktionen,
die den Quelltext nahezu exakt so aussehen lassen würden wie
in Deinem perl-Beispiel ().<?php $db =& DB::connect($dsn, $options);
$sth = $db->prepare(‚SELECT name FROM users WHERE id = ?‘);
$res =& $db->execute($sth, $_GET[‚user_id‘]);
…
?> :smile:

Grüße

CMБ

#15

Diese liest die Werte aus dem Speicher und führt die Stored
Procedure aus. Dabei werden $a und $b niemals als
SQL-String behandelt, sondern immer als Daten. D.h. das
funktionert mit beliebigen Werten, sie werden niemals escaped.

das heißt im gegenzug wenn ich in php so arbeite

<?PHP if($a) { $where .= 'AND `a` = $a '; }
if($b) { $where .= 'AND `b` = $b '; } if($c) { $where .= 'AND `c` = $c '; } $db-\>query("SELECT \* FROM `test` WHERE `d` = 'a'$where"); ?\> dann müsste ich in perl daraus 9 unterschiedliche querys machen? weil ich kann dann ja in dem query unterschiedliche where argumente einbauen. oder habe ich was falsch verstanden? Gruß Phillip
#16

Hallo,

Diese liest die Werte aus dem Speicher und führt die Stored
Procedure aus. Dabei werden $a und $b niemals als
SQL-String behandelt, sondern immer als Daten. D.h. das
funktionert mit beliebigen Werten, sie werden niemals escaped.

das heißt im gegenzug wenn ich in php so arbeite

<?PHP :if($a) { $where .= 'AND `a` = $a '; }
if($b) { $where .= 'AND `b` = $b '; } if($c) { $where .= 'AND `c` = $c '; } $db-\>query("SELECT \* FROM `test` WHERE `d` = 'a'$where"); ?\> dann müsste ich in perl daraus 9 unterschiedliche querys machen?

Nein, du kannst die Query (inklusive Platzhalter) ja auch dynamisch bauen:

my @params;
if ($a) { $where .= 'AND `a` = ? '; push @params, $a };
if ($b) { $where .= 'AND `b` = ? '; push @params, $b };
if ($c) { $where .= 'AND `c` = ? '; push @params, $c };

my $query = $dbh-\>prepare("SELECT \* FROM `test` $where");
$query-\>execute(@params);

Grüße,
Moritz

1 Like
#17

Hallo,

Obwohl das natürlich Programmierfehler sind, ist sauberes
escapen nicht die Lösung - Bind parameter sind es.
Beim escapen kann immer was schiefgeben, bei Bind Parameters
werden die Variablen direkt zur Datenbankengine weitergegeben

  • es findet nie ein Fehleranfälliges escaping statt.

Falsch, das ist *nicht* der Punkt von „Bind Parameters“.
Die trennung von (SQL-Befehl und SQL-Dateninhalt bei der
Eingabe ist es.)

Beides ist relevant, im Kontext der Frage nach der Sicherheit ist die Tatsache, ob ein String escaped wird, auch relevant.

Ein Beispiel in Perl:

my $dbh = DBI->connect(…);
my $statement = $dbh->prepare(„SELECT name FROM users WHERE
id = ?“);

Die von außen kommenden Daten werden _nie_ in einen

String interpoliert:

$statement->execute($cgi->param(‚user_id‘));

Doch, das werden sie, wenn der darunterliegende DBD
keine nativen Placeholder unterstützt, dann werden
die Parameter in DBI gequotet und aufgehoben bis
zum nächsten execute.

Das stimmt, nicht jeder DBD unterstützt native Placeholder. Aber die mit halbwegs „vernünftigem“ Datenbank-Backend (wie postgresql, mysql 5, oracle) unterstützen es.

Unterstützt der DBD aber Placeholder (MySQL u.a.),
werden die Strings an den DBD durchgereicht,
der dann den Placeholder-Mechanismus der Engine
nutzt
(http://dev.mysql.com/tech-resources/articles/4.1/pre…).

Unter der Haube macht der DBI-Treiber eine Stored Procedure,
was auch noch ein Performancegewinn ist, wenn man die selbe
Query mit verschiedenen Paramtern mehrfach verwendet.

LOL, wo hast Du denn das gelesen?

Gute Frage, weiss ich nicht mehr genau.
Aber ein einfacher Benchmark zeigt das. Der Unterschied ist nicht groß (bei mir: 4% für eine einfache Query), aber Fakt bleibt, dass bei einem prepare() die query nur ein mal geparst werden muss, beim weiteren execute() nicht mehr.

Ich weiß, dass es in PHP entsprechende Bibliotheken gibt, aber
anscheinend ist den meisten Programmierern nicht mal bekannt,
dass so etwas erstrebenswert ist und existiert.

Was Du meinst ist vielleich PEAR:smiley:B, dort gibt es Funktionen,
die den Quelltext nahezu exakt so aussehen lassen würden wie
in Deinem perl-Beispiel ().<?php : $db =& DB::connect($dsn, $options);
$sth = $db->prepare(‚SELECT name FROM users WHERE id =
?‘);
$res =& $db->execute($sth, $_GET[‚user_id‘]);
…
?> :smile:

Richtig.

Grüße,
Moritz