php-resource



Zurück   PHP-Scripte PHP-Tutorials PHP-Jobs und vieles mehr > Entwicklung > PHP Developer Forum
 

Login

 
eingeloggt bleiben
star Jetzt registrieren   star Passwort vergessen
 

 

 


PHP Developer Forum Hier habt ihr die Möglichkeit, eure Skriptprobleme mit anderen Anwendern zu diskutieren. Seid so fair und beantwortet auch Fragen von anderen Anwendern. Dieses Forum ist sowohl für ANFÄNGER als auch für PHP-Profis! Fragen zu Laravel, YII oder anderen PHP-Frameworks.

Antwort
 
LinkBack Themen-Optionen Thema bewerten
  #1 (permalink)  
Alt 06-06-2009, 18:08
INC.
 Registrierter Benutzer
Links : Onlinestatus : INC. ist offline
Registriert seit: Nov 2005
Beiträge: 106
INC. ist zur Zeit noch ein unbeschriebenes Blatt
Standard mysqli vs. PDO, Bugs, Sicherheit

Hallo Community

Ich will mich nun mal wieder PHP (5.2.6) widmen, komme sonst aber aus der ASP.NET Ecke. Aufgrund dessen möchte ich möglichst alles objekt-orientiert umsetzen, einfach der Gewohnheit wegen. Ich habe mich schon etwas eingelesen in die PHP-OOP und vermisse vieles, aber das wird schon.

Nun stellt sich mit die Frage, ob ich zu mysqli oder doch lieber zu PHP Data Objects greifen soll. Da die beiden Erweiterungen ja schon objekt-mäßig aufgebaut sind und beide prepared statements unterstützen, hab ich mir die mal kurz angesehen. Eigentlich gefällt mir PDO besser, mehr oo-like und ein paar coole Features (Daten aus der DB direkt in ein Zielobjekt stecken etc.), allerdings habe ich in einem englischen Forum folgendes gefunden:

Zitat:
Here's something else to keep in mind: For now (PHP 5.2) the PDO library is buggy. It's full of strange bugs. For example: before storing a PDOStatement in a variable, the variable should be unset() to avoid a ton of bugs. Most of these have been fixed in PHP 5.3 and they will be released in early 2009 in PHP 5.3 which will probably have many other bugs. You should focus on using PDO for PHP 6.1 if you want a stable release and using PDO for PHP 5.3 if you want to help the community.
Das bringt mich von meinem Favoriten PDO dann doch wieder etwas ab. Ich bin froh, wenn ich von mir selbst produzierte Bugs finde und ausmerzen kann, da brauch ich nicht noch ne weitere Fehlerquelle. Da ich auch längerfristig bei MySQL bleibe, bringt mir die Abstraktheit von PDO auch nicht viel.
Aber es macht nunmal den moderneren und umfangreicheren Eindruck und hat echt nette Möglichkeiten.

Was würdet ihr wählen?

Und mal abgesehen von meiner Situation, was ist sonst so zu sagen zum Thema "mysqli vs. PDO"?

---

Als letztes hab ich noch eine Frage zum Thema Sicherheit: ganz egal ob ich nun mysqlis oder PDOs prepared statements verwende, auf was muss noch achten, bevor eine Usereingabe in die DB geschickt wird?

Vor Injections dürfte ich nun geschützt sein, soll trotzdem noch eine manuelle Überprüfung stattfinden? Falls ja, wie? Denn mysql_real_escape_string funktioniert ja logischerweise nicht, zumindest nicht bei PDO.

htmlspecialchars und htmlenities gibts noch, reicht ersteres? Ich denke, vor allem JavaScript in der DB sollte vermieden werden, HTML bei Usereingaben lieber auch.

Sonst noch was zu beachten?


Danke, Gruß
Mit Zitat antworten
  #2 (permalink)  
Alt 06-06-2009, 18:31
PHP-Desaster
 PHP Expert
Links : Onlinestatus : PHP-Desaster ist offline
Registriert seit: Mar 2006
Beiträge: 3.105
PHP-Desaster befindet sich auf einem aufstrebenden Ast
Standard

Ich nutze in meinen Projekten PDO und mir ist ehrlich gesagt nur ein Bug mit einer zu alten Mysql-Clientversion bekannt, welcher bei mehreren aktiven Select-Statements auftritt. Darum würde ich einfach mal behaupten das du mit sauberer Programmierung irgendeinen unset-vor-Benutzung-Bug nicht bemerken wirst. Allerdings programmiere ich ausdrücklich Datenbankunabhängig, weswegen mysqli direkt ausscheidet.

Zu deiner Contentbereinigung. Injections sind mit PDO nicht mehr so möglich, wenn du mit den bind*-Methoden arbeitest. Wie du JavaScript oder komplett HTML aus Inhalten entfernst hat aber erstmal nichts mit der Datenbank zu tun. Für einfachste Bereinigungen reicht zum Beispiel strip_tags. htmlspecialchars genügt, wird aber erst vor der Contentausgabe auf die Daten angewandt. In der Datenbank müssen die Rohdaten liegen bleiben!
Mit Zitat antworten
  #3 (permalink)  
Alt 06-06-2009, 19:44
INC.
 Registrierter Benutzer
Links : Onlinestatus : INC. ist offline
Registriert seit: Nov 2005
Beiträge: 106
INC. ist zur Zeit noch ein unbeschriebenes Blatt
Standard

Okay, danke mal soweit. Dann hoffe ich, dass mich die Käfer in Ruhe lassen und setze auf PDO.

Aber nochmal zur Contentbereinigung und der Reihenfolge, da hab ich echt die Übersicht verloren:

Also die manuelle Überprüfung auf SQL-Sachen fällt komplett weg, soweit, so gut.

Fehlen noch Javascript und eventuell HTML (wobei letzteres ja eher harmlos sein sollte, oder?)

Stellt sich die Frage, ob strip_tags, htmlspecialchars oder htmlenities am sinnvollsten dafür ist. strip_tags löscht ja wirklich, während die anderen beiden nur ersetzen. Nennt sich ein User bei der Anmeldung also

<script type="text/javascript">alert("XSS");</script>

so würde er mit strip_tags "alert("XSS");" heißen und bei enities seinen ganzen Namen behalten dürfen, allerdings entsprechend maskiert? Das ist dann wohl Geschmackssache denk ich mal...

Worin liegt eigentlich der Grund, die Rohdaten unbehandelt in die DB zu schreiben und erst bei der Ausgabe zu maskieren?
Mit Zitat antworten
  #4 (permalink)  
Alt 07-06-2009, 12:10
Benutzerbild von onemorenerd onemorenerd
  Moderator
Links : Onlinestatus : onemorenerd ist offline
Registriert seit: Mar 2005
Ort: Berlin
Beiträge: 9.471
onemorenerd wird schon bald berühmt werdenonemorenerd wird schon bald berühmt werden
Standard

Man maskiert immer anders, abhängig davon was man wie ausgeben will.
Mit Zitat antworten
  #5 (permalink)  
Alt 07-06-2009, 13:02
combie
 PHP Expert
Links : Onlinestatus : combie ist offline
Registriert seit: May 2006
Beiträge: 3.296
combie wird schon bald berühmt werden
Standard

Ich habe ab und an auch mit anderen DBMS zu tun, also nicht nur mit MySQL. PDO kann sie alle. Aber es abstrahiert mir nicht weit genug. Prepared Statements werden emuliert, wenn es das DBMS von Hause nicht kann. Aber bei LIMIT klemmts dann schon.
Also nutze ich Doctrine. Und von heftigen Problemen habe ich weder gehört, noch sie selber spüren müssen.
__________________
Wir werden alle sterben
Mit Zitat antworten
  #6 (permalink)  
Alt 07-06-2009, 21:47
Benutzerbild von fireweasel fireweasel
 Registrierter Benutzer
Links : Onlinestatus : fireweasel ist offline
Registriert seit: Sep 2008
Ort: At home
Beiträge: 851
fireweasel wird schon bald berühmt werdenfireweasel wird schon bald berühmt werden
fireweasel eine Nachricht über AIM schicken fireweasel eine Nachricht über Yahoo! schicken
Standard

Zitat:
Zitat von INC. Beitrag anzeigen
Okay, danke mal soweit. Dann hoffe ich, dass mich die Käfer in Ruhe lassen und setze auf PDO.

Fehlen noch Javascript und eventuell HTML (wobei letzteres ja eher harmlos sein sollte, oder?)
Nein, ist es nicht. Fehlerhaftes HTML ist ja gerade der Einfallspunkt für Javascript-Code-Injections. Und es gibt, dank des unermesslichen Einfallsreichtums der Browser-Hersteller und auch der Entwickler des MSIE, eine Unzahl von Möglichkeiten, irgendwo in HTML und auch CSS Befehle zum Ausführen von Scripts einzuschmuggeln.
Zitat:
Stellt sich die Frage, ob strip_tags, htmlspecialchars oder htmlenities am sinnvollsten dafür ist.
Ganz einfach: Nimm htmlspecialchars($raw, ENT_QUOTES) mit sonst keiner weiteren Option. Bspq. den UTF-8-Mode einzustellen, verdoppelt nur die Laufzeit, ändert aber ansonsten nichts.

Die anderen Funktionen sind für die Tonne.

Übrigens sollte htmlspecialchars() auch bei den Daten angewendet werden, die in Attribut-Werte eingetragen werden, wie beispielsweise bei Links das href-Attribut.

Zitat:
Nennt sich ein User bei der Anmeldung also

<script type="text/javascript">alert("XSS");</script>

so würde er mit strip_tags "alert("XSS");" heißen und bei enities seinen ganzen Namen behalten dürfen, allerdings entsprechend maskiert? Das ist dann wohl Geschmackssache denk ich mal...
Bei Nutzung von htmlspecialchars() würde er diesen Namen behalten dürfen. Und das ist nicht Geschmackssache, sondern Erhaltung der eingegebenen Daten, statt Verstümmelung (wie bspw. mit strip_tags()). Wenn ich in irgendein Webformular was eingebe, dann erwarte ich, dass das verarbeitende Script das so speichert und nichts davon kaputtmacht, nur weil der Programmierer zu dusselig war und seine Grundlagen nicht kapiert hat.

Zitat:
Worin liegt eigentlich der Grund, die Rohdaten unbehandelt in die DB zu schreiben und erst bei der Ausgabe zu maskieren?
Weil sie so in Originalform erhalten bleiben und die Datenbank eben nicht für HTML-JavaScript-Code-Injections anfällig ist.

Für Datenbanken reicht die passende Escaping-Funktion.

http://xkcd.com/327/

Geändert von fireweasel (07-06-2009 um 23:37 Uhr)
Mit Zitat antworten
Antwort

Lesezeichen


Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)
 

Ähnliche Themen
Thema Autor Forum Antworten Letzter Beitrag
Kleine und mittlere Änderungen in communityscript und Behebung von kleineren Bugs. Ravenor Jobgesuche 0 21-05-2007 00:19
[s] Hilfe beim finden von Bugs DeeAge BRAINSTORMING PHP/SQL/HTML/JS/CSS 10 25-02-2007 10:34
Der Link der Stunde: bugs.php.net miximaxi IT-Security 1 03-04-2006 21:59
Bugs in MySQL finden und iPod nano gewinnen Hopka News / Kostenloses 2 07-03-2006 23:53
[Coder gesucht] 2 Bugs im Browsergame Apropo Projekthilfe 1 05-06-2005 18:50

Themen-Optionen
Thema bewerten
Thema bewerten:

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are an


PHP News

ebiz-trader 7.5.0 mit PHP7 Unterstützung veröffentlicht
ebiz-trader 7.5.0 mit PHP7 Unterstützung veröffentlichtDie bekannte Marktplatzsoftware ebiz-trader ist in der Version 7.5.0 veröffentlicht worden.

28.05.2018 | Berni

Wissensbestand in Unternehmen
Wissensbestand in UnternehmenLebenslanges Lernen und Weiterbilden sichert Wissensbestand in Unternehmen

25.05.2018 | Berni


 

Aktuelle PHP Scripte

PHP Server Monitor

PHP Server Monitor ist ein Skript, das prüft, ob Ihre Websites und Server betriebsbereit sind.

11.09.2018 Berni | Kategorie: PHP/ Security
PHP WEB STATISTIK ansehen PHP WEB STATISTIK

Die PHP Web Statistik bietet Ihnen ein einfach zu konfigurierendes Script zur Aufzeichnung und grafischen und textuellen Auswertung der Besuchern Ihrer Webseite. Folgende zeitlichen Module sind verfügbar: Jahr, Monat, Tag, Wochentag, Stunde Folgende son

28.08.2018 phpwebstat | Kategorie: PHP/ Counter
Affilinator - Affilinet XML Produktlisten Skript

Die Affilinator Affilinet XML Edition ist ein vollautomatisches Skript zum einlesen und darstellen der Affili.net (Partnerprogramm Netzwerk) Produktlisten und Produktdaten. Im Grunde gibt der Webmaster seine Affilinet PartnerID ein und hat dann unmittelb

27.08.2018 freefrank@ | Kategorie: PHP/ Partnerprogramme
 Alle PHP Scripte anzeigen

Alle Zeitangaben in WEZ +2. Es ist jetzt 15:34 Uhr.