Sicherheit der Daten und Eingaben einer Seite?

ZodiacXP hat gesagt.:
Zu dem PreparedStatement:
Nachteile kenne ich bisher noch keine.
Zum Vergrößern anklicken....

Ein großer Nachteil ist, das man sich mit der Materie auseinander setzen muss. Das Wissen darüber ist nicht so leicht zu vermitteln, wie mysql_query/fetch_* und Konsorten. Ich habe noch die Hoffnung, das der ganze mysql_*-Kram irgendwann aus dem Standard raus fliegt und nur noch PDO drin ist.

Zum Thema Security-by-Obscurity: Es mag schön sein, zu verschleiern, das auf dem Webserver kein PHP läuft, in dem man die Header-Ausgaben entfernt. Unsinnig ist es jedoch, wenn man dann seine Dateien über index.php, foo.php, bar.php ... erreichbar macht.

Grundsätzlich bin ich ein Gegner von SbO. Stattdessen die Web-Applikation sicher machen.

Schau dir mal folgendes Konzept an:

http://framework.zend.com/docs/quickstart/create-your-project

Insbesondere der Teil, in dem die Verzeichnisstruktur erläutert wird. "public" ist dein DocumentRoot, jeder Aufruf mittels .htaccess an die index.php weitergeleitet, die widerum es an einen sog. Front-Controller weiterleitet, der die richtigen Controller kennt. In "public" findest du dann nur noch CSS und Bilder, und was sonst noch "freigegeben" sein soll.
 
Brauch ich dazu zwingend Zend NEtwork?
Oder kann ich das auch rein mit PHP realisieren?

Weil vom Prinzip hört sich das logisch an. Aber klingt halt als wenn ich es mit PHP nicht realisieren kann? Oder ist Zend PHP?

Könnte jemand nochmal drauf eingehen, ob es sicher ist eine Texteingabe / Variable auf die Zeichen { } < > zu überprüfen und zu escapen? Oder kann da trotzdem noch jemand was böswilliges eingeben, um mir zu schaden?

Wäre eine Umstellung auf Prepared Statements denn empfehlenswert für jemanden, der sich damit überhaupt nicht auskennt?

Ich will mich halt vor Veröffentlichung meines Projektes intensiv mit allen möglichen Sicherheitslücken auseinandersetzen, um die Wahrscheinlichkeit vor Angriffen so gering wie möglich zu halten.
 
Zend Framework ist natürlich in PHP geschrieben. Zend ist die Firma, die hinter PHP steht. Allerdings muss man sein Projekt schon darauf auslegen, Zend zu nutzen. Sprich man ist an gewisse Praktiken gebunden. In der Regel wird man auch keine Queries schreiben. Stattdessen arbeitet man mit einer Abstraktionsschicht weiter oben, dem sog. Modell und ein Result ist ein Objekt. Außerdem kann man Tabellen auf logische Art mit einander in Beziehung setzen und somit die Vorteile des ERM nutzen.

Du kannst ein ähnliches Verhalten durchaus auch ohne Zend Framework erreichen. ZF ist nur die Möglichkeit, seinen Code sehr sauber zu strukturieren, und bestimmte Fehler von vornherein auszuschließen. Außerdem muss man sich nicht um die Pflege der Basis-Komponenten kümmern, das wird ja von Zend getan. Man kann aber contributen, wenn man das möchte. Falls du wirklich Interesse daran hast, dann schau dir mal das Tutorial von Ralf Eggert an:

http://www.ralfeggert.de/zend-framework-tutorial/

Dort wird ein Blog mit Hilfe des ZF erstellt. Man lernt Schritt-für-Schritt das ZF kennen und nutzen. Schnell wirst du merken, wie toll es ist, wiederverwendbaren Code zu nutzen. Außerdem wirst du ein gutes Gefühl dabei haben, denn der Code wird anschließend sehr verständlich und gut wartbar sein. Allerdings solltest du vllt auch besser die aktualisierte Version des Tutorials verwenden, da es ZF > 1.0 und die neuen Features nutzt:

http://www.zf-tutorials.de/

Basis ist das Tutorial von Ralf Eggert, welcher sein Tutorial aus Zeitgründen und vermutlich auch weil er sein Buch verkaufen will ;-) nicht mehr pflegt.
 
Nur noch PDO?
Tut mir leid, aber das würde ich nicht wollen. Bei PDO finde ich zwar den Ansatz nett, aber es ist halt kein vollständige Datenbankabstraktion, sondern nur "data-access".
D. h. bei manchen Datenbanken muss man immer noch Queries umschreiben und auf datenbankspezifische Feinheiten achten.
Und da MySQLi eigentlich fast die gleichen Fähigkeiten wie PDO mit sich bringt, würde ich für MySQL immer MySQLi einsetzen bzw. für Projekte die auf mehrere Datenbanksysteme zugreifen einen vollen Abstraktionslayer.
Ob man dort nun auf das Zend Framework, eZComponents, Doctrine oder Propel setzt ist jedem selbst überlassen.

Nachtrag:

Ich empfehle hier auch noch mal das Buch von Padraic Brady:
Zend Framework: Surviving The Deep End
 
Mal ernsthaft: Wie oft kommt es vor, das man eine Webapplikation auf eine andere Datenbank umstellt? Wenn du damit öfter Erfahrung gemacht hast, hat derjenige, der die Applikation entworfen hat, Mist gebaut. Ich kann die Datenbank-Dialektik als Ausschlusskriterium für eine Datenbank-Client-API für mich nicht annehmen. Aber ich möchte auf ein anderes Faktum hinweisen: Wenn verschiedene Möglichkeiten vorhanden sind, auf die gleiche Datenbank zuzugreifen, muss man auch diese verschiedenen Möglichkeiten im Code maintainen. Das ist meiner Meinung nach vergeudete Ressource. Ich würde es begrüßen, wenn es nur einen Treiber gäbe, dem man sich aber voll widmet.

Mal von diesen ganzen Verschlimmbesserungen wie mysql_real_escape_string() und dergleichen. Versuch mal einem Anfänger klar zu machen, warum man das machen muss. Und vor allem: Es sind immer wieder die gleichen Fragen: "Ich bin gehackt worden, was kann ich tun?" oder "Wie kann ich meine Datenbank sicher machen?" Weiß-der-Geier wieviele Websites sich dem Thema widmen, Symptome der SQL-Injection zu erklären. Sicher sind PS nicht der Weisheit letzter Schluss. Aber machen sie das Leben nicht sehr viel leichter? Wenn ich daran denke, wie ich vor ein paar Jahren versuchte, mittels regex und dergleichen INSERTs und UPDATEs sicher zu bekommen....
 
MySQLi bietet auch Prepared Statements, trotzdem nutzt ein Gros der Anwender nur die neuen MySQLi Funktionen.

Warum also PDO nutzen? Du sagst doch selbst, dass es kein Argument ist, von wechselnden Datenbanksystemen auszugehen, von daher warum nicht direkt bei MySQLi bleiben?
 
Weil PDO gerade im Bereich punkten kann, was Geschwindigkeit angeht, den beide Extensions unterstützen: Prepared Statements: http://dealnews.com/developers/php-mysql.html

Es gibt noch ein paar andere Kleinigkeiten, die mit PDO einfacher zu realisieren sind, als mit MySQLi: http://jacobsantos.com/2006/general/mysqli-vs-pdo/ welches ja eigentlich ein Blog pro MySQLi ist. Jedoch ist dieser Kommentar interessant: http://jacobsantos.com/2006/general/mysqli-vs-pdo/comment-page-1/#comment-12404. Allerdings muss ich zugeben, das diese Anwendung wohl eher recht selten sein wird.

Was ich auch noch nirgends gefunden habe: Unterstützt MySQLi Exceptions? Laut einigen Posts konnte ich herauslesen, das die OOP-Schnittstelle noch unzureichend implementiert ist.

Da ich Datenbank-Layer ohnehin abstrahiert verwende, und PS die häufigste Anwendung in Bezug auf Datenbankzugriff bei mir ist, wähle ich PDO.
 
Öh, ja und ein Kommentar später steht die Lösung für das Comment ;)

Inwiefern Exceptions? Es bringt keine eigenen Exceptionsklassen mit, wie PDO, aber man kann ganz normal die Exceptions werfen und auffangen...

Und PDO punktet erst ab PHP 5.3 wieder, wenn PDO den MySQLnd anspricht ;)
Drunter läuft es noch über den alten MySQL Driver und ist somit ein wenig langsamer....

Für mich heißt es entweder einen richtigen Abstraktionslayer nutzen oder man bleibt bei spezifischen Funktionen. Und das ist für mich momentan MySQLi.
PDO kann mich in der Beziehung einfach nicht überzeugen.
 
Ich meinte eher sowas:

PHP: 
  <?php
try {
   $dbh = new PDO('mysql:host=localhost;dbname=test', $user, $pass);
   foreach ($dbh->query('SELECT * from FOO') as $row) {
      print_r($row);
   }
   $dbh = null;
} catch (PDOException $e) {
   print "Error!: " . $e->getMessage() . "<br/>";
   die();
}
?>

Sprich die Extension selbst wirft schon Exceptions.

Bei MySQLi sehe ich nur sowas:
PHP: 
  <?php
$mysqli = @new mysqli('localhost', 'fake_user', 'my_password', 'my_db');

if ($mysqli->connect_errno) {
    die('Connect Error: ' . $mysqli->connect_errno);
}
?>

Das heißt für mich, das ich die OOP letztendlich selbst implementieren muss (wenn ich OOP verwenden will [was ich tue]).

PDO nimmt sich dem objekt-orientierten Ansatz einfach besser an und integriert sich dort besser. Wenn man lieber prozedural entwickelt, bringt einem mysqli wahrscheinlich mehr. Ich bin aber von der halb-herzig implementierten OOP-Variante nicht sehr begeistert.

Ok, lassen wir es dabei: Jeder hat seine Vorlieben. Prinzipiell ist nichts gegen mehrere Verbindungsmodelle zu sagen. Außer dem Wartungsargument.
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück