PHP 7 erschienen!

[Ap0ll0XT]

Seit gestern ist die neue Version der beliebten Web-Skriptsprache PHP draußen. Die Version 7 bietet allerhand Neuerungen sowie das entfernen vieler alter Features.

Das ist neu:
Konstanten mit Ausdruck anstatt Funktionsaufruf deklarieren

const TEST = 1;
const HALLO = 1 + TEST;

echo Str(HALLO); // Gibt "2" aus

Vorher

Define("TEST", 1);
Define("HALLO",1+TEST);

echo Str(HALLO); // Gibt "2" aus

Variable Parameteranzahl bei Funktionen ohne func_get_args()

function test(...$params)

Parameter werden in das Array "$params"geschrieben.

Neuer Potenz-Operator

$test = 2 ** 3;

echo Str($test); // ergibt "8"

use function und use constants für Namespaces

namespace Name\Space {
    const FOO = 42;
    function f() { echo __FUNCTION__."\n"; }
}

namespace {
    use const Name\Space\FOO;
    use function Name\Space\f;

    echo FOO."\n";
    f();
}

Ebenfalls dazu sind strikte Datentypen und weitere Operatoren. Alle Änderungen: PHP: PHP 7 ChangeLog

 

[Zeiss]

Manche Änderungen sind einfach nur

 

[Ap0ll0XT]

Manche Änderungen sind einfach nur

Anstatt immer nur das negative Fallobst aus dem riesen Salat zu picken versuch auch mal, die Rosinen zu erwischen. Da sind so einige gute Änderungen bei.

 

[lowskill]

Bevor ich mir Rosinen aus dem Kompost picken muss, wähle ich lieber gleich eine andere Sprache.

 

[xActionx]

These Top 10 Programming Languages Have Most Vulnerable Apps on the Internet - The Hacker News

PHP ist und bleibt ein Scherbenhaufen...

 

[RicoBrassers]

These Top 10 Programming Languages Have Most Vulnerable Apps on the Internet - The Hacker News

PHP ist und bleibt ein Scherbenhaufen...

Liegt aber eher daran, dass die Programmierer der Apps einfach die Lücken nicht geschlossen haben.
Den Großteil aller SQL-Injections kann man in PHP schon mit einem einfachen

$db = new mysqli(...);

$db->real_escape_string($string)

lösen. Wer daran nicht denkt, einfach, weil ihm solche Lücken unbekannt sind (z.B. weil der Programmierer damit noch nie konfrontiert wurde), ist selber Schuld. Das hat dann nichts mit der Sprache PHP an sich zu tun.

Ich finde es schön, dass endlich wieder eine neue PHP-Version draußen ist. Auch wenn ich mittlerweile hauptsächlich mit NodeJS arbeite - "altbackene" Foren- und CM-Systeme laufen immer noch in PHP und "vergleichbare" (und kostenlose/günstige) Alternativen, gerade für einfache Webhosting-Angebote ohne SSH-Zugang, gibt es derzeit einfach fast gar nicht.

PHP7 gibt einen ordentlichen Performance-Boost, der auch mal dringend nötig war.

 

[MaxRink]

Trotzdem performt HHVM in vielen Fällen besser

 

[RicoBrassers]

Trotzdem performt HHVM in vielen Fällen besser

Meist geben sich HHVM und PHP7 nicht viel, im Vergleich zu PHP5. Ich würde mal behaupten, HHVM und PHP7 arbeiten im Schnitt gleich schnell. Mal gewint HHVM, mal PHP7.

 

[MaxRink]

Es glt immernoch, dass PHP mehr CPU und HHVM mehr RAM benötigt. Und mehr RAM ziehe ich persönlich vor

 

[RicoBrassers]

Es glt immernoch, dass PHP mehr CPU und HHVM mehr RAM benötigt. Und mehr RAM ziehe ich persönlich vor

Kann sein, kann auch sein, dass mit PHP7 die "Lücke" weiter geschlossen wird/wurde. Ich denke mal, dass man noch etwas abwarten muss, um richtige Schlüsse ziehen zu können.
Eventuell kommt in den nächsten paar Tagen auch noch ein HotFix, wodurch weniger CPU-Last erzeugt wird, wer weiß

Jedenfalls wurde mit PHP7 einiges verbessert, es ist eigtl. nicht geändert worden, was man wirklich als Negativ-Aspekt bewerten könnte.

Edit: Für PHP7 spricht natürlich noch, dass der Großteil der PHP5-Anwendungen ohne Update von der Performance profitiert (keine Ahnung, wie das bei HHVM ist, habe damit noch nie gearbeitet. )

 

[Laudian]

Liegt aber eher daran, dass die Programmierer der Apps einfach die Lücken nicht geschlossen haben.
Den Großteil aller SQL-Injections kann man in PHP schon mit einem einfachen

$db = new mysqli(...);

$db->real_escape_string($string)

lösen.

Jetzt ist die Frage: Wieso ist das nicht längst Standardverhalten in neuen Versionen der Sprache ?

In PHP ist einfach so unendlich viel Ballast enthalten um die Abwärtskompatibilität zu gewährleisten... Nach So vielen Jahren muss man da halt einfach mal drauf pfeifen und die Leute zu ihrem Glück zwingen.

 

[RicoBrassers]

Jetzt ist die Frage: Wieso ist das nicht längst Standardverhalten in neuen Versionen der Sprache ?

In PHP ist einfach so unendlich viel Ballast enthalten um die Abwärtskompatibilität zu gewährleisten... Nach So vielen Jahren muss man da halt einfach mal drauf pfeifen und die Leute zu ihrem Glück zwingen.

Ganz einfach - weil man manchmal eben SQLi "erzwingen" möchte - warum auch immer. Ich finde aber, dass das so am Besten ist.
1.: Die Entwickler müssen/sollten sich mit SQLi auseinandersetzen und verstehen, was dahinter steckt.
2.: Man hat genug Freiheiten, falls man es absichtlich nicht haben möchte (z.B. Demonstrationszwecke? Keine Ahnung )

Edit: Mit PHP7 fliegt ja schon etwas Ballast raus. z.B. MySQL-Unterstützung. Stattdessen muss man halt MySQLi (oder andere Datenbank) benutzen.

 

[Laudian]

Ganz einfach - weil man manchmal eben SQLi "erzwingen" möchte - warum auch immer.

Ja, aber dann soll doch bitteschön die sichere Variante Standard sein und nicht andersrum...

1.: Die Entwickler müssen/sollten sich mit SQLi auseinandersetzen und verstehen, was dahinter steckt.

Wenn wir uns mit allem auseinandersetzen wollen, können wir auch gleich wieder in Assembler schreiben.
Eine High-Level Programmiersprache soll dem Programmierer die Arbeit erleichtern, nicht neue Probleme schaffen...

Aber freut mich zu hören, dass das alte MySQL Modul endlich rausgeflogen ist anstatt das man weiterhin 2 Module parallel in der Standardbibliothek anbietet, von denen eines nicht benutzt werden sollte...

 

[Zeiss]

Anstatt immer nur das negative Fallobst aus dem riesen Salat zu picken versuch auch mal, die Rosinen zu erwischen. Da sind so einige gute Änderungen bei.

Bevor ich mir Rosinen aus dem Kompost picken muss, wähle ich lieber gleich eine andere Sprache.

Da hast Du es @Ap0ll0XT. PHP ist und bleibt einfach nur eine Bastelkiste, nicht mehr und nicht weniger.

Wenn wir uns mit allem auseinandersetzen wollen, können wir auch gleich wieder in Assembler schreiben.

Das hätte einen sehr großen Vorteil: PERFORMANCE und man weiß ganz genau, was man da treibt.

Eine High-Level Programmiersprache soll dem Programmierer die Arbeit erleichtern, nicht neue Probleme schaffen...

Und genau das tut sie leider nicht all zu oft. In der HighSprache ist es einfach eine Anwendung kurz mal "zusammen zu rotzen", aber sobald es an die Optimierungen geht, steht man allein im Wald. Dann gibt es 1000 Frameworks, für alles mögliche, die setzt man sehr gern ein und schleppt mit der Zeit einen riesigen Ballast mit sich rum. Auch hier, viel Erfolg beim Ausmisten und optimieren.

Aber freut mich zu hören, dass das alte MySQL Modul endlich rausgeflogen ist anstatt das man weiterhin 2 Module parallel in der Standardbibliothek anbietet, von denen eines nicht benutzt werden sollte...

Ich weiß nicht, warum es ein Nachteil sein soll, dass man eine "depricated" Schnittstelle im Code drin hat.

 

[Laudian]

Der Nachteil ist, dass viele Leute diese Schnittstelle benutzt haben, weil sie in der Standardbibliothek vorhanden ist.
Meinetwegen kann man sie ja drinne lassen, aber zumindest sollte es bei der Ausführung zu einem Fehler kommen, wenn nicht in irgendeiner Config Datei ein Wert auf "Ja, ich möchte dass meine Datenbank für Injections anfällig ist" gesetzt ist.

Eine bekannte Sicherheitslücke der Abwärtskompatibilität wegen nicht aus dem Code zu entfernen ist einfach gemeingefährlich. Man sieht ja, wie viele Seiten nach wie vor für SQL-Injections anfällig sind. Das wären wahrscheinlich um einiges weniger, wenn man die MySQL-Bibliothek durch die MySQLi-Bibliothek ersetzt hätte anstatt sie parallel anzubieten.

 

[TessaKavanagh]

es sind ja nicht zwei Module von denen man eins nicht betreiben sollte in PHP 5.6 es sind drei Module bitte PDO nicht übersehen, m.E. die beste Schnittstelle zu Datenbanken für PHP. Für SQL sollte man doch eh soweit möglich nur prepared Statements verwenden, was die Sicherheit bedeutend erhöht. Das Problem ist nicht PHP an sich sondern die 2,5Mio dermaßen veralteten Tutorials im Internet die nicht mehr aktualisiert werden und Codebeispiele enthalten.

 

[RicoBrassers]

Ich vermute mal, dass das Ganze im Bezug auf SQLi nicht unbedingt der Fehler von PHP ist, sondern eher von (My)SQL. Immerhin führt der Datenbankenserver die Anfrage aus und müsste/sollte diese vorher Filtern. Dann wären alle SQLi-Lücken in allen Programmiersprachen gefixt.

@TessaKavanagh Ganz ehrlich - ich habe noch nie verstanden, wie Prepared Statements helfen sollen, die Sicherheit zu verbessern. Ich glaube, dafür bin ich schlicht zu dämlich

 

[Laudian]

Soweit ich das verstanden habe, werden bei prepared Statements Anweisung und Parameter getrennt voneinander übergeben und dadurch sichergestellt, dass eine Anweisung nicht als Parameter "injected" wird.

 

[bingo88]

Soweit ich das verstanden habe, werden bei prepared Statements Anweisung und Parameter getrennt voneinander übergeben und dadurch sichergestellt, dass eine Anweisung nicht als Parameter "injected" wird.

Im Prinzip läuft das so ab. Das Kommando wird vorkompiliert, enthält aber Platzhalter für die Paramterwerte. Die werden dann einfach eingefügt und können am (vorkompilierten) Code nichts mehr ändern. Man bekommt so nicht nur einen automatischen SQL Injection Schutz, sondern bei Mehrfachverwendung der Query ist das sogar effizienter, da nur noch die Parameterwerte getauscht werden müssen.

 

[Zeiss]

Eine bekannte Sicherheitslücke der Abwärtskompatibilität wegen nicht aus dem Code zu entfernen ist einfach gemeingefährlich. Man sieht ja, wie viele Seiten nach wie vor für SQL-Injections anfällig sind. Das wären wahrscheinlich um einiges weniger, wenn man die MySQL-Bibliothek durch die MySQLi-Bibliothek ersetzt hätte anstatt sie parallel anzubieten.

Das ist die Frage, wie entwickle ich. Gerade im DB-Umfeld sollte man anders denken, gerade wegen den SQL-Injections. Man kann auch mit der MySQL-Lib sauber und sicher entwickeln, man muss nur eben einpaar Sachen mehr beachten, wie zum Beispiel kein SQL-Code (also Statements) ausführen, sondern über PreparedStatement gehen und dann die Bind-Variablen einsetzen und Feuer. Wer es anders macht, hat was nicht verstanden.

@TessaKavanagh Ganz ehrlich - ich habe noch nie verstanden, wie Prepared Statements helfen sollen, die Sicherheit zu verbessern. Ich glaube, dafür bin ich schlicht zu dämlich

Es ist eigentlich ganz einfach. Du hast ein Stement wie zum Beispiel (das ist jetzt Java, aber Prinzip ist derselbe):

sqlString = "select * from kunde where id = ?";

Das Dng "preparierst" Du, der Statement wird kompiliert. Das ? ist dabei der Platzhalter, wo der Wert eingesetzt wird. Im nächsten Schritt setzt Du den Wert ein:

PreparedStatement prepStat = conn.prepareStement (sqlString);
prepStat.setInt (1, 17);

Dabei sagst Du welcher Wert an welche Stelle im SQL eingesetzt wird, hier wird eine 17 an die Stelle 1 (gibt ja nur die) eingesetzt.

Danach

ResultSet rs = prepStatement.executeQuery();

Und Dein Resultset landet in rs, fertig.

PreparedStatement hat mehrere Vorteile, zum einen Sicherheit, zum Anderen ist es für die DB auch einfacher (das Statement an sich ist derselbe, nur die Bind-Variablen ändern sich) und zum Dritten kann man sie batchen.