Das Putzlowitsch Test- und SEO-Blog

PHP Update jetzt, bei IONOS, Strato und All-Inkl

Letze Woche war ich im Urlaub und just in dieser Zeit gab es das große PHP-Sicherheitsloch, auch als php2shell bekannt. Diese Sicherheitslücken hatten es bis in die Nachrichten der Tagesschau geschafft. Dadurch hatte ich auch davon erfahren.

Da ich beim Shared Webhosting PHP nicht selbst aktualisieren kann, muß ich mich da auf meine Webhoster verlassen.

IONOS

Info zu PHP-Schwachstellen bei IONOS

Am Donnerstag kam dann auch die beruhigende E-Mail von IONOS „PHP-Schwachstellen: Ihre Projekte sind sicher“.

… Gute Nachrichten für Sie: Ihre Projekte sind sicher und es besteht kein Handlungsbedarf – wir haben uns bereits um alles gekümmert.
Die PHP-Community hat am 21. Oktober ein offizielles Sicherheitsupdate für die betroffenen PHP-Versionen zur Verfügung gestellt. Wir haben dieses Update sofort nach Veröffentlichung auf all Ihren Web-Projekten installiert, sodass für Sie keine Gefahr bestand.
Schon vor Erscheinen dieses Updates griffen bei IONOS zusätzliche Schutzmaßnahmen wie angepasste PHP-Konfigurationen sowie Firewall-Regeln, die verdächtige Anfragen blockieren. …

Eine zweite E-Mail folgte einen Tag später:
„PHP-Schwachstellen: Dank PHP Extended Support sind Sie sicher„.

Oha, das ist nicht gut, denn der „PHP Extended Support“ kostet monatlich Geld. Je älter die Version, um so höher die Kosten. Ich war mir eigentlich sicher, alles mindestens auf PHP 8.2 umgestellt zu haben. Das hatte mir keine Ruhe gelassen und so habe ich mich dann doch noch im Urlaub im IONOS-Kundenbereich angeneldet und nachgeschaut. Die lange Liste an Domains und Subdomains zeigte in der Sortierung „Älteste PHP-Version zuerst“ die Version 8.2 als minimale Version an.

Also alles gut, die E-Mail wurde wohl an alle Kunden pauschal verschickt, egal ob sie tatsächlich im „Extended Support“ sind oder nicht.

Weil der PHP Community Support für Version 8.2 nur noch bis 12/2026 läuft, habe ich dann von zu Hause prophylaktisch alle 23 Domains und Subdomains auf PHP 8.5 umgestellt. So habe ich erstmal für drei Jahre Ruhe.

Ganz schmerzfrei hat das allerdings nicht funktioniert, die eine oder andere Änderung an meinem PHP-Code mußte ich vornehmen. So darf z.B. der erste Parameter der Funktion idn_to_utf8( domain ) nich mehr leer sein, was vor der Version 8.4 noch kein Problem war:

8.4.0: 	Now throws a ValueError if the domain parameter is empty.

Strato

Info zu PHP-Schwachstellen bei Strato

Auch von Strato kam am Donnerstag, zeitlich sogar etwas eher als von IONOS, die Entwarnungs-E-Mail „PHP-Schwachstellen: Ihre Projekte sind sicher“.

… Gute Nachrichten für Sie: Ihre Projekte sind sicher und es besteht kein Handlungsbedarf – wir haben uns bereits um alles gekümmert.
Die PHP-Community hat am 21. Oktober ein offizielles Sicherheitsupdate für die betroffenen PHP-Versionen zur Verfügung gestellt. Wir haben dieses Update sofort nach Veröffentlichung auf all Ihren Web-Projekten installiert, sodass für Sie keine Gefahr bestand.
Schon vor Erscheinen dieses Updates griffen bei STRATO zusätzliche Schutzmaßnahmen wie angepasste PHP-Konfigurationen sowie Firewall-Regeln, die verdächtige Anfragen blockieren. …

Der Text liest sich genau wie der von IONOS. Kein Wunder, gehört Strato doch seit 2017 zur „United Internet“ und hier zur IONOS-Gruppe.

Die Nachricht mit dem Extended-Support für PHP kam von Strato nicht, aber es gibt ihn dort ebenfalls.

Bei Strato kann man die PHP-Version nur global für das ganze Webhosting-Paket einstellen. Ich hatte dort 8.2 konfiguriert, bin dann aktuell auf PHP-Version „8.4 – Empfohlene Version“ gegangen. Die Umstellung auf 8.5 steht aber demnächst an.

All-Inkl

Info zu PHP-Schwachstellen bei All-Inkl

Die E-Mail „Wichtige Sicherheitsinformation zu PHP [NMM:1E2C98B]“ von All-Inkl kam am Samstag. Ich persönlich finde es gut, das All-Inkl die E-Mails als Plain-Text verschickt, auch wenn sie dadurch unauffälliger aussehen.

… Welche Maßnahmen haben wir ergriffen?
Unsere Techniker haben unmittelbar reagiert und bereits vor Veröffentlichung der Sicherheitsupdates zusätzliche Schutzmaßnahmen vorbereitet und aktiviert. Nach Veröffentlichung der Sicherheitskorrekturen haben wir mit höchster Priorität damit begonnen, die notwendigen Patches zu erstellen, zu testen und auf unseren Kundenservern zu verteilen. Dabei mussten wir zahlreiche unterschiedliche PHP-Versionen berücksichtigen. Innerhalb von etwa acht Stunden konnten wir die notwendigen Sicherheitsupdates auf unserer Hosting-Infrastruktur verteilen. Inzwischen haben wir sämtliche bei uns angebotenen PHP-Versionen gegen die beiden bekannt gewordenen Sicherheitslücken gepatcht. Dies gilt ausdrücklich auch für ältere Versionen wie PHP 5.6 und PHP 7.x. Für unsere Kunden war hierfür keine eigene Aktualisierung erforderlich. …

Auch hier wurden die älteren PHP-Versionen 5.6 und 7.x gepatcht und das ganz ohne kostenpflichtigen „Extended Support“.

Die PHP-Konfiguration erfolgt pro Domain/Subdomain bei „Domain bearbeiten“. Angeboten werden die Versionen 5.6, 7.4, 8.1, 8.2, 8.3, 8.4 und 8.5. Meine Putzlowitsch-Seite lief noch mit 7.4, das habe ich dann zeitnah auf 8.4 umgestellt. Auch hier waren einige Änderungen am selbstgeschriebenen PHP-Code notwendig, bei mir eigene WordPress-Plugins und das Theme.

Fazit

Beim Shared Webhosting muß man sich im Falle von Sicherheitslücken auf den Webhoster verlassen. Meine drei Webhoster IONOS, Strato und All-Inkl haben die jüngsten PHP-Sicherheitslücken zeitnah gefixt, teilweise auch für ältere Versionen. Es ist aber trotzdem eine gute Idee, auf halbwegs aktuell PHP-Versionen umzustellen, auch wenn das mit Anpassungsarbeiten verbunden ist. Ewig kann und sollte man programmtechnische Altlasten nicht mitschleppen.

bhb2shall

Keine Kommentare »

Contentbär SEO-Wettbewerb mit Umlautproblem

Contentbääääääär

Umlaute waren und sind immer noch ein Problem in URLs. Seit längerer Zeit funktionieren sie zumindest im Pfadteil der URL dank Unicode (UTF-8) und URL-Encoding technisch recht gut. Moderne Browser haben damit kein Problem mehr.

Auch im Domainnamen dürfen seit einiger Zeit ÄäÖöÜüß verwendet werden. Damit das funktioniert, werden sie im sogenannten Punycode kodiert und für den Domainnamen noch mit dem Präfix „xn--“ versehen.

Contentbär Live-Ranking mit Umlautproblem

So sieht das dann z.B. im Contentbär-Liveranking aus, wenn man das für die Darstellung nicht zurück konvertiert.

Sowohl Beispiel 1 „xn--contentbr-vergleich-nwb.de“ als auch Beispiel 2 „/contentb%C3%A4r-21660193/“ sind nicht wirklich gut lesbar. Dabei ist die Umsetzung in lesbaren Text für die Anzeige je nach verwendeter Programmiersprache recht einfach. In PHP z.B. gibt es dafür die Funktionen

idn_to_utf8()
urldecode()

Auch bei meinem Contentbär Ranking-123 hatte ich mit dem Problem zu tun, obwohl es nicht der erste SEO-Contest mit Umlauten im Keyword ist. Bereits 2011 träumte so mancher SEO seine Kubaseoträume. Damals gab es meine Seite Ranking-123 in der Form aber noch nicht.

Wie auch immer, ich habe die entsprechenden Anpassungen am PHP-Code vorgenommen und nun werden die Umlaute ordentlich dargestellt.

6  ⇗ contentbär-vergleich.de/
68  ⇗ www.reddit.com/r/contentbaer...np39ws/contentbär_halbzeit/
88  ⇗ de.quora.com/wie-gewinnt-man...für-den-begriff-contentbär
118  ⇗ pixabay.com/de/users/contentbär-21660193/
131  ⇗ podcasts.apple.com/mx/podcas...ntest-2021/id1567047693?l=en
140  ⇗ www.amazon.de/contentbär-bÃ...ttbewerb-ebook/dp/b095frs3zg
149  ⇗ contentbär-seogewinnspiel.de/produkt/contentbaer/

Das sind aktuell (Montag, 14.06.2021 10:00) alle URLs im Ranking, die den Contentbär mit ä enthalten. Sind gar nicht so viele, an die echten Umlaute traut sich kaum jemand ran. Immerhin gibt es aber mit contentbär-vergleich.de eine Umlautdomain im Ranking.

Contentbär Keyword-Domain mit oder ohne Umlaut?

Mal davon abgesehen, daß dem Vernehmen nach Keyword-Domains keinen Rankingvorteil mehr haben, werden sie gerade bei SEO-Wettbewerben immer noch gerne verwendet. Warum das so ist, keine Ahnung.

Bei einem Umlaut im Suchbegriff stellt sich nun die Frage, was als Keyworddomain betrachtet werden kann. Gut, Contentbär mit „ä“ ist ja exakt der Suchbegriff, also wäre z.B. contentbär.de in jedem Fall eine EMD (Exact-Matsch-Domain).

Aber was ist mit der durchaus gebräuchlichen Ersetzung ä => ae? Streng genommen ist das keine Keyword-Domain, weil der Suchbegriff ja nicht genau so im Domainnamen vorkommt. Allerdings sind diese Umlautumschreibungen sehr verbreitet und daher auch beliebt.

Aktuell findet man im Contentbär-Ranking folgende Keyword-Domains (EMD, PMD, EMS und PMS):

6  ⇗ contentbär-vergleich.de/
34  ⇗ contentbaer-in.jimdosite.com/
38  ⇗ contentbaer.myportfolio.com/
48  ⇗ contentbaer.wordpress.com/
56  ⇗ contentbaer.puzl.com/
62  ⇗ contentbaer-in.weebly.com/
67  ⇗ www.contentbaer.com/
109  ⇗ dercontentbaer.de/
125  ⇗ contentbaer-contest.de/
142  ⇗ contentbaer.rocks/
148  ⇗ contentbaerseo.de/
149  ⇗ contentbär-seogewinnspiel.de/produkt/contentbaer/
152  ⇗ contentbaeren.de/nahrung
156  ⇗ contentbaer-gewinner.de/
157  ⇗ www.contentbaer-seocontest.com/
159  ⇗ www.contentbaer-seo.com/

Da findet man nur eine echte Umlautdomain, den oben schon erwähnten Contentbär-Vergleich, alle anderen setzen auf die „ä -> ae“-Substitution, sei es nun Domain oder Subdomain. Vielleicht sollte ich mal wieder meine keintext-Subdomain an den Start bringen, mit echtem Umlaut natürlich.

Na mal sehen, was daraus wird…

(Cimtamtpör)

Weitere Artikel mit Bezug zu diesem:
8 Kommentare »

Google Bildersuche – Bildgrößen (BxH in Pixel) anzeigen

Früher war alles Besser

Google Bildersuche mit Bildgrößen

Früher konnte man sich in der Google-Bildersuche über „Weitere Tools“ -> „Größen anzeigen“ zu jedem Bild ein kleines Overlay mit der Bildgröße (Breite x Höhe in Pixel) einblenden lassen. Bei der Funktion „Weitere Größen“ wurde das sogar standardmäßig angezeigt (siehe Screenshot oben).

Das geht nun nicht mehr und auch die Einblendung dieses Overlays beim Überfahren des Vorschaubildes mit der Maus ist verschwunden. Man muß jetzt das Bild erst anklicken und im aufgeklappten Frame mit dem großen Bild wird die Bildgröße beim Überfahren mit der Maus angezeigt. Sehr umständlich.

Das „Google Bilder Größen“ Bookmarklet

Bookmarklets sind feine Sachen, denn man kann tolle Dinge damit machen. :-)

Ein Bookmarklet ist ein Browser-Lesezeichen, welches aber nicht die URL einer Webseite speichert, sondern Javascript-Code. Dieser kann dann auf eine gerade im Browserfenster angezeigte Webseite losgelassen werden.

Das Bookmarklet hat Zugriff auf den kompletten Seiteninhalt, kann diesen verändern oder Daten extrahieren und z.B. in einem neuen Fenster darstellen.

Vor einiger Zeit hatte ich bereits ein Bookmarklet für die Google-Bildersuche erstellt. Dabei werden die relevanten Informationen aus der Ergebnisseite extrahiert und als Tabelle auf einer neuen Seite dargestellt.

Das heutige Bookmarklet ist viel einfacher, denn es manipuliert nur die aktuelle Seite und blendet bei jedem Thumbail oben Links ein kleines Overlay mir der Bildgröße ein.

Nach der „Installation“ genügt ein Klick auf den Button [Google Bilder Größen] in der Bookmarkleiste und schon werden die Bildgrößen angezeigt:

Bookmarklet Google Bilder Größen

Ein erneuter Klick blendet die Overlays wieder aus. Allerdings werden zunächst nur die Bilder mit der Information versehen, die Google komplett darstellt. Beim scrollen werden die weiteren Suchergebnisse dynamisch nachgeladen und diesen neuen Bildern fehlt das Overlay. Dann einfach den Butten erneut ein- oder zweimal klicken und alles ist wieder gut. :-)

Das Bookmarklet

Google Bilder Größen

Ein Bookmarklet ist zwar ein Link, es macht aber wenig Sinn, diesen hier direkt anzuklicken. Vielmehr müßt Ihr ihn als Lesezeichen im Browser speichern, also z.B. einfach in die Bookmarkleiste ziehen.

Getestet habe ich das Bookmarklet bisher mit Firefox 77.0.1, Google Chrome 83.0.4103.116 und Microsoft Edge 83.0.478.56, damit funktioniert es.

3 Kommentare »

Google Bilder-Liste 2.0 – Update des Bookmarklets für die Google Bildersuche

Google HTML-Markup und JavaScript-Daten

Google-Bildersuche: html und js-Daten 2020

Google hat vor wenigen Wochen mal wieder das HTML-Markup der Bildersuche-Ergebnisseite (SERP) verändert und auch die Metadaten zu den Bildern sind an anderen Stellen gespeichert. Mein Google-Bildersuche Bookmarklet benötigt aber genau diese Informationen (und noch ein paar mehr), damit es funktioiert.

Also mußte ich die SERPs untersuchen und den Javascript-Code meines Bookmarklets anpassen. Alle Informationen, die Google zu einem Bild anzeigt, müssen ja irgendwo gespeichert sein, die Frage ist nur wo. Erschwerend kommt hinzu, das nicht alles direkt im Quelltext zu finden ist, sondern teilweise erst dynamisch per JavaScript nachgeladen wird.

Netterweise haben die modernen Webbrowser ganz brauchbare Entwicklerwergzeuge gleich mit an Bord, da muß man nicht wie früher erst Browserplugins installieren, um sich auf die Suche nach den Daten begeben zu können. Dabei ist mir wieder aufgefallen, was für ein Monster aus tief verschachtelten DIV-Elemeten (div-Suppe) und hunderten von JavaScript-Objekten und -Funktionen so eine Google-Ergebnisseite ist.

Letztendlich habe ich aber alles, was ich für das Bookmarklet benötige, auch gefunden. Allerdings hatte sich während der Entwicklungs- und Testphase bereits der Name des Objektes, das die nachgeladenen Bild-Metadaten enthält, verändert.

Neue Anzeige und Filterfunktionen

Bookmarklet Google-Bilderliste 2.0

Wenn ich den JavaScript-Code sowieso anfassen muß, kann ich auch gleich ein paar schon länger fällige Erweiterungen implementieren. In der Ausgabeliste wird nun der Titel der Webseite angezeigt, auf der das Bild zu finden ist. Außerdem werden die Urheberinfos, falls vorhanden, mit aufgelistet.

Neu ist ein Filter für das vorhandensein der Urheberinfos („Mit Urheberinfos“) und die Möglichkeit beim Textfilter das zu filternde Feld auswählen zu können. Bisher wurde immer in der Seiten-URL („Website“) gesucht. Jetzt könnt Ihr zwischen „Webseite“, „Bild-URL“, „Bild-Id“, „Seiten-Titel“, „Ersteller“, „Urheber“ und „Urheberrecht“ wählen.

Na mal sehen, wie lang das jetzt Bestand hat und wann Google das nächste Mal die Ergebnisseite verändert…

Das aktuelle Google-Bildersuche Bookmarklet findet Ihr hier.

Keine Kommentare »

Alte PHP-Version 5.6 bei Strato jetzt auf PHP 7.2 umstellen

Freundliche Nachricht von Strato

Gestern erreichte mich eine E-Mail von meinem Webhoster Strato:

„Wichtig: Ihre PHP-Version ist veraltet
Seit Januar 2019 ist Ihre PHP-Version 5.6 veraltet und es stehen keine Sicherheitsupdates mehr zur Verfügung.
Wir lassen Sie nicht im Regen stehen! Bis zum 15.07.2019 führen unsere Entwickler kostenlos die Sicherheitsupdates für Ihre Websites fort.
…
Sie möchten weiterhin Ihre alte PHP-Version behalten?
Dann übernehmen wir die Aufgabe der PHP Community und führen weiterhin selbst die Sicherheitsupdates für PHP 5.6 durch. Bitte haben Sie Verständnis, dass hierdurch Wartungsaufwand entsteht, den wir ab dem 16.07.2019 mit 5,33 Euro pro Auftrag pro Monat in Rechnung stellen. Dies nennt sich PHP Extended Support. …“

Eigentlich hatte ich mein Webhostingpaket bei der STRATO AG schon auf PHP 7.2 umgestellt, dachte ich.

Alles eine Einstellungssache

Also habe ich mich schnell im Strato-Kundenmenü angemeldet und wurde gleich mit einem Popup-Fenster begrüßt.

Strato-Webhosting: Veraltete PHP-Version-Hinweis

Ja aber ich habe doch schon vor Wochen auf PHP 7.2 umgestellt. Also fix mal auf den Button [PHP-Versio ändern] geklickt und siehe da:

Strato-Webhosting: PHP-Version einstellen

Hab ich es doch gewußt:
„Sie verwenden zur Zeit folgende PHP-Version: PHP 7.2“

Stimmt im Prinzip auch, nur weiter unten steht dann der entscheidende Hinweis:
„Achtung: Sie nutzen in mindestens einer .htaccess Datei auf Ihrem Webspace PHP 5.6/7.0.“

Also gammelt da in einem nicht mehr aktiven Projekt irgendwo noch eine .htaccess-Datei herum, in der ich eine PHP 5er Version aktiviert hatte. Nur welche das ist, sagt mir die freundliche Strato-Meldung nicht.

Suchen und Finden

Mit meinem Basiswissen Unix/Linux sollte das aber kein Problem sein, zumal es bei meinem Paket auch ein SSH-Login gibt.
Also einfach per SSH im Paket anmelden und mit „grep -r …“ den Übeltäter aufspüren. Denkste. Bei SunOS/Solaris, das auf den Webservern bei Strato läuft, gibt es kein rekursives grep.

Aber es gibt ja das Internet und so habe ich schnell die passende Kombination aus find und grep gefunden:

find . -type f -name ".htaccess" -exec grep -l "application/x-httpd-php5" {} +

Und tatsächlich habe ich drei .htaccess-Dateien mit einer alten PHP5-Konfiguration gefunden.

Strato-Webhosting: ssh

In zwei Fällen war die Zeile

# AddType application/x-httpd-php5 .php

auskommentiert, also nicht mehr aktiv. Nur beim Test-Projekt /neueseite/test/ war der Eintrag „aktiv“, allerdings war die Installation nicht mehr mit einer Domain/Subdomain verknüpft und somit nicht aufrufbar.

Die beiden Ordner /schnurpsel_29/ und /neueseite/test/ habe ich einfach komplett entsorgt und bei der Gelegenheit auch sonst noch ein wenig im Webspace aufgeräumt.

Das ist mit „rm -r …“ in NullKommaNix erledigt, viel schneller als beim rekursiven Löschen per FTP.
Allerdings sollt man sich sicher sein, was man tut, denn „rm -r“ haut ohne Nachfrage alles weg. Und weg ist weg. :-)

Weitere Artikel mit Bezug zu diesem:
Ein Kommentar »