Joomla! Plugin PXLCompressor – Image compression made simple

PXLCompressor is a free Joomla! plugin, which allows you to compress and resize every image uploaded with the media manager automatically. This is especially useful if the uploaded images are not preprocessed and allows you to speed up your website drastically.

Features:

  • Automagically resize every image uploaded with the media manager component on the fly
  • Improve page speed by decreasing file sizes
  • Chose a scale method according to your needs (scale inside / outside / fit / fill)
  • Set compression levels for png/jpeg files
  • Supported file formats: JPG, PNG and GIF
  • Create thumbnails

Currently, the following image compression services are supported, but there might be more to come:

  • ReSmush.it: a free image optimization service with unlimited number of compression. It supports the most common file types like (PNG, JPG, GIF, BMP and TIF). However: The JImage class of Joomla! framework does not seem to support TIF, so compression of .tif files is currently not enabled.
    Only downside: the maximum size of a file is 5MB, but if you enable resizing, which is done before, it is very unlikely that you will ever reach this size
  • TinyPNG: the web service allows you to compress your PNG and JPG files. You can subscribe for a free plan enabling you to compress 500 images per month without any charges. Simply fill in your API key to get started.

If you enable both compression services and TinyPNG fails for any reason, ReSmush will be used as a fallback.

It is planned to support local compression using optipng/gifsicle/jpegoptim in later versions.

Special thanks to Viktor Vogel for creating the plugin EIR, from which I took larger parts of the code.

If you found a bug or have a feature request, please file a report on github or leave a comment.

Changelog:

v. 1.0.2 fixed bogus error message
v. 1.0.1 minor Bugfixes

Grab the latest version here: https://github.com/pixelstunde/joomla_plg_pxlcompressor/releases or at JED

Vollbild-Suchfenster ohne JavaScript (reines CSS)

Ich habe letztens auf einer Website eine clevere Variante einer Vollbild-Suchfunktion gesehen. Es gab einen Suchbutton, der auf einen Klick ein Overlay mit einer Suchbox aktivierte. Dazu wurde JavaScript (jQuery) genutzt.

Auch wenn ich die Idee und die optische Umsetzung ganz gut fand, war ich von der technischen Realisierung nicht besonders begeistert, obwohl grundsätzlich nicht mehr viel gegen JavaScript einzuwenden ist. Allerdings erfordert diese Art der Umsetzung das Einbinden und Laden bestimmter JavaScript Libraries und Plugins, die wiederum Einfluss auf Ladezeit und Performance haben.

Ich habe mich also mal an eine einfache Lösung gesetzt, die auf reinem CSS beruht. Dabei habe ich den :target „Hack“ genutzt. Ein Klick auf einen Anchor-Link „aktiviert“ dabei das Overlay. Der Browser springt auf einen bis dahin verborgenen Bereich der Website, der erst als aktives Ziel (:target-Selektor) sichtbar wird.

 

Ich habe dazu eine kleine Demo auf CodePen veröffentlicht:

https://codepen.io/pixelstunde/pen/QvMxVR

Den Code kann natürlich jeder frei und ohne Angabe einer Quelle nutzen (CC0-Lizenz).

Das JavaScript wurde nur eingebunden um verschiedene Animations-Arten zu demonstrieren.

Joomla! Blank Template

Als Basis für viele meiner Templates habe ich bis vor kurzem Bloggerschmidts Blank Template benutzt. Da das Ganze aber scheinbar nicht mehr gewartet wird, habe ich mich dazu entschlossen, die Arbeit weiterzuführen. Ich habe das Template ein wenig modernisiert: akutelle Versionen von normalize.css eingebaut, den Code aufgeräumt und bereinigt, diverse CSS-Frameworks wie Bootstrap, Materialize und Skeleton eingebunden etc.

Die aktuelle Version des Blank Templates gibt es hier: https://github.com/pixelstunde/joomla-blank-template

Für Support, Fehlermeldungen und Ähnliches bitte ich darum, den Issue-Tracker auf GitHub zu bemühen.

 

In English:

I’ve been using Bloggerschmidt’s Blank template as a base for my own ones, but since development seems to have stopped, I decided to create a fork and updated the whole thing a bit. Some improvements: current version of normalize.css, cleaned and re-organized code, added some CSS-Frameworks like Bootstrap, Materialize and Skeleton.

Grab the latest version of blank-template here: https://github.com/pixelstunde/joomla-blank-template

Please use the GitHub issue tracker if you found a bug or need support.

Neue Website für das Hotel Schloss Rabenstein

Das Hotel Schloss Rabenstein ist wahrscheinlich eine der besten Adressen für eine Übernachtung, Veranstaltungen und Hochzeiten in Chemnitz. Das liebevoll restaurierte Barockschlösschen besticht durch ein exklusives Ambiente und die ruhige Lage im Rabensteiner Wald.

Pixelstun.de bekam den Auftrag für die „digitale Renovierung“ des Schlosshotels. Die veraltete statische Website ist im Rahmen der Arbeiten einem dynamischen, vollkommen responsivem Design gewichen, das sich an alle Bildschirmgrößen anpasst und insbesondere für mobile Geräte wie Tablets und Smartphones optimiert wurde.

Der Inhalt wurde neu strukturiert und gegliedert. Anpassungen sind dank des eingesetzten CMS (Content Management System) „Joomla!“ nun direkt und einfach durch die Mitarbeiter des Hotels möglich.

Hotel Schloss Rabenstein Website

Include bootstrap in your custom Joomla! 3.x Template

Just a quick reference on how to include bootsrap in your custom Joomla! template the right way.

Simply add those two lines of code and the Joomla Core will include all the needed files automagically:

<?php

JHtmlBootstrap::framework();
JHtmlBootstrap::loadCSS(true, $direction);

?>

You may replace $direction with „ltr“ or „rtl“ according to your preferred text direction. (defaults to „ltr“)

Keep in mind, that this most probably won’t add the latest version of bootstrap.

In German:

Bootstrap zu eigenen Joomla! Templates hinzufügen

Ein kurzer Tipp, wie man bootstrap einfach und auf die richtige Art und Weise zu eigenen Templates hinzufügen kann.

Diese beiden Zeilen zum Template hinzufügen und der Joomla!-Core kümmert sich um den Rest.

<?php

JHtmlBootstrap::framework();
JHtmlBootstrap::loadCSS(true, $direction);

?>

Die Variable $direction sollte dabei mit „ltr“ oder „rtl“ ersetzt werden, je nach bevorzugter Textrichtung.

Man sollte dabei im Hinterkopf behalten, dass wahrscheinlich nicht die aktuellste Version geladen wird.

Gallery CSS Slider Module

This is a simple responsive image slider module (altough it doesn’t slide, but fade) by https://pixelstun.de. It uses the awesome gallery CSS by Ben Schwarz.

Simply chose the categories you want to get your slider elements from, create some articles, assign them an intro image and you’re ready to go.

Features

  • only about 2 KiB additional CSS (gzipped)
  • does not use any JS
  • easy to customize
  • fully responsive
  • free and open source (GPL v2)

FAQ

How to add elements to the slider?

Simply create an article, assign an intro image and you’re good to go. Make sure your article matches all the filter criteria.

How to use advanced routing?

Create a menu element or select an existing one. Every link to the articles in the slider will be routed using this element.

Demo

https://pixelstun.de/demojoomla/gallery-slider

Download

https://github.com/pixelstunde/joomla-mod-galleryslider/archive/master.zip

 

Joomla! reCAPTCHA-Plugin in eigene Erweiterungen (Joomla 3/3.5/3.x) einbinden

Kürzlich habe ich ein Kontaktformular-Modul entwickelt, welches ich später noch vorstellen und frei verfügbar machen werde.

Um Spam zu vermeiden wollte ich das Joomla!-eigene Captcha-Plugin nutzen, was sich als gar nicht so einfach herausstellte. In der Dokumentation lässt sich dazu nichts finden. Es gibt zwar einen Thread dazu bei stackoverflow, aber die dort vorgestellte Lösung funktionierte nicht mit reCAPTCHA v2. Das Captcha wurde einfach nicht angezeigt. Also half hier ein Blick in die Datei „/plugins/captcha/recaptcha/recaptcha.php“.

Um das Captcha in eigene Erweiterungen (Komponenten und Modulen) einzubinden sind folgende Schritte nötig:

  1. Laden des Plugins
    JPluginHelper::importPlugin('captcha');
    (JEventDispatcher::getInstance())->trigger('onInit', 'dynamic_recaptcha_1');
  2. Einbinden des Captchas
    echo (JEventDispatcher::getInstance())->trigger('onDisplay', array(null, 'dynamic_recaptcha_1', 'class=""'))[0];
  3. Überprüfen des Captchas
    $res = (JEventDispatcher::getInstance())->trigger('onCheckAnswer',$_POST['recaptcha_response_field']);
    if($res[0]){
        //captcha gelöst
    }
    else{
        //captcha konnte nicht verifiziert werden
    }
    

Joomla Modul – Minimal Responsive Menu

Vorgeschichte: Da unsere Kundenwebsites ausschließlich im responsive Design erstellt werden und oft eigens geschriebene Templates verwenden, habe ich lange Zeit nach einem Modul für die Hauptnavigation gesucht, was folgende Punkte vereint:

  1. Darstellung der Menüeinträge als einfache Liste ohne dutzende Wrapper, wie im Standard Joomla Modul
  2. Einfaches Einbinden eines Modules (nicht noch ein zusätzliches, verstecktes Menü)
  3. Einfache optische Anpassung möglich (ohne große Veränderungen im Modul selbst oder 1000 !important Regeln im CSS)
  4. Geringer Einfluss auf die Ladezeit (wenige Requests, geringe Größe)

Ein fertiges Modul was dem relativ nahe kommt, ist das Menü von TheGrue. Problematisch fand ich daran aber den großen Funktionsumfang. Das Modul ist ready-to-use und bietet viele Anpassungsmöglichkeiten im Backend, zu viele für meinen Geschmack (und das harmoniert nicht mit Punkt 3 in meinen Ansprüchen).

Simple Responsive Menu – Joomla-Modul

Blieb also nur noch der Ausweg selbst ein Modul zu schreiben. Gesagt getan: Ich habe das Standard Joomla Modul (mod_menu) nach meinen Vorstellungen angepasst, ohne dass es sich anders verhält als das Original. Für ein optisch ansprechendes responsive Menü habe ich analog zu TheGrue das jQuery Plugin SIDR benutzt.

Normale Ansicht des Menüs auf einem Desktop-PC
Normale Ansicht des Menüs auf einem Desktop-PC
Mobiles (responsive) Menü geöffnet
Ansicht mit geöffnetem mobilem Menü

Funktionsumfang:

  • Alle Einstellungsmöglichkeiten des klassischen Moduls
  • Breite, ab der das mobile Menü angezeigt werden soll, einstellbar
  • Laden eines einzelnen Moduls für die normale und responsive Navigation
  • Keine versteckten Menüs –  somit barriefrei und suchmascheinenfreundlich, da doppelte Links vermieden werden
  • Geringer Einfluss auf die Ladezeit: 2 Requests, ca. 11,3kb unkomprimiert, kein Abruf externer Dateien. (jQuery muss geladen sein)
  • Das Laden der JavaScript und CSS-Dateien lässt sich in den Einstellungen unterbinden, wenn gewünscht. (Inhalte der Dateien müssen dann ins Template übernommen werden)
  • Einfaches bearbeiten der Optik, da nur wenige Style-Regeln definiert wurden

Das Modul kann hier heruntergeladen werden: mod_simpleresponsivemenu

GitHub und Demo folgen demnächst.

Barrierefreies Webdesign: Eine Einführung

Das Internet ist für alle Menschen gemacht, egal welche Hautfarbe, Herkunft oder körperliche Fähigkeiten sie besitzen. Doch besonders Menschen mit beeinträchtigter Sicht und Blinde haben schwer im Web. Sie sind auf technische Hilfsmittel wie Screenreader angewiesen um sich im Internet zurechtzufinden, doch die wenigsten Website-Betreiber machen sich darüber Gedanken.

Dabei stoßen insbesondere blinde Menschen immer wieder auf Hindernisse die so nicht sein müssten. Vor allem veralte Websites mit Layouts auf Basis von Tabellen machen ihnen zu schaffen. Doch beim barrierefreiem Webdesign gibt es noch viel mehr zu beachten. In diesem Beitrag sollen die häufigsten Stolpersteine bei der Gestaltung einer Website aufgedeckt und Hinweise zu deren Beseitigung gegeben werden.

Wie sehbehindete und Blinde Menschen eine Website sehen

Die barriefreie Gestaltung einer Website geht eng mit der Suchmaschinenoptimierung einher. Sowohl Suchmaschinen als auch blinde Menschen sind auf eine korrekte Struktur des Inhaltes und sachgemäße Verwendung von HTML-Elementen angewiesen um eine Website benutzen zu können und zu verstehen.

Betrachten wir einmal die Startseite von Pixelstun.de mit Lynx, einem Textbrowser, der die Inhalte ähnlich wie ein Screenreader verarbeitet.

Screenreader: Darstellung einer Website im Lynx-Browser

Man sieht, dass jegliche Design-Elemente Fehlen und nur strukturiertes HTML angezeigt wird.

Im Gegensatz zum richtigen Screenreader, werden hier auch versteckte HTML Elemente angezeigt. Eine Übersicht, wie man Inhalte exklusiv für Screenreader oder Displays zugänglich machen kann, findet sich hier.

Das Ausblenden bestimmter Elemente funktioniert am besten mit CSS Media Queries und kann in folgender Form stattfinden:

@media tty, braille, speech{
  element{
    display: none;
  }
}

Aber auch die „neuen“ ARIA Attribute sind dafür geeignet.  So kann man auch mit aria-hidden="true" Elemente verstecken. Die Unterstützung in den verschiedenen Browsern und Screenreadern ist jedoch sehr unterschiedlich. Hier gibt es einen sehr guten Artikel dazu.

Layouts auf Tabellenbasis

Eigentlich sind Layouts auf Basis von Tabellen ein Relikt der 90er Jahre, doch immer wieder findet man auch heute noch Websites die Tabellen zweckentfremden und für Designs nutzen. Dabei bringen Tabellen prinzipiell nur Nachteile: sie lassen z.B. sich nicht ohne weiteres für’s responsive Design nutzen und sind schwer zu pflegen. Minimale designtechnische Änderungen  ziehen oftmals sehr viel Aufwand nach sich, sobald Tabellen im Spiel sind.

Besonders problematisch sind Tabellen zudem für alle Menschen die unter einer Sehbehinderung leiden. Screenreader lesen eine Tabelle Zelle für Zelle und der Inhalt der Website wird damit unter Umständen entstellt. Nutzen Sie Tabellen also ausschließlich dafür, wofür sie gedacht sind – um (statistische) Daten darzustellen.

Kontraste

Sehr wichtig sind auch Kontraste. Prüfen Sie ob sich der Inhalt genug vom Hintergrund abhebt. Dies betrifft nicht nur Texte, sondern auch Bilder. Der WCAG 2.0 Level AA-Test erfordert mindestens ein Kontrastverhältnis von 4,5:1 für normalen Text bzw. 3:1 für großen Text. Für das Level AAA sind Kontrastverhältnisse von 7:1 für normalen Text und 4,5:1 für großen Text nötig. Großer Text wird dabei definiert als: 14pt+ und fett, oder 18pt+.

Tools mit dem die Kontrastverhältnisse überprüft werden können, finden sich am Ende des Beitrages.

Inline Styles, Schriftgrößen und Überschriften

Vermeiden Sie die Nutzung von Stil-Deklarationen in HTML. Als inline-Style wird z.B. folgendes definiert:

<div style="border:1px solid red">...

Verwenden Sie stattdessen ausgelagerte CSS-Dateien um Ihre Website zu gestalten. Tückisch sind dabei immer WYSIWYG-Editoren, denn diese legen meist alle Stil-Definitionen als inline-Attribute an, ohne dass sich der Autor darüber bewusst ist.

Versuchen Sie immer relative Größenangaben zu verwenden, insbesondere bei der Schrift. Dies ist nicht nur für responsive Design günstig, sondern ermöglicht auch ein flexibles Anpassen der Schriftgröße für alle Elemente der Website. Sie müssen nur die Basisschriftgröße verändern. 😉

Auch für Überschriften sollten Sie nur die dafür vorgesehenen HTML-Elemente verwenden (<h1>-<h6>).

Bilder und alt-Attribute

Das alt-Attribut ist für die Beschreibung von Bildern gedacht. Im Textbrowser oder bei einem fehlgeschlagenen Ladevorgang wird dieses Attribut angezeigt. Vergeben Sie also für jedes Bild eine Bildbeschreibung und lassen Sie diese nur in Ausnahmefällen leer, z.B. wenn das Bild ein reines Design-Element ist und sich nicht anders einfügen lässt. Verwenden Sie die Beschreibung nicht um Keywords zu platzieren. Auch wenn das früher eventuell funktioniert hat: Suchmaschinen kennen diese Tricks seit langem und analysieren die Bilder nun selbsständig.

Alt-Attribute sind für valides HTML5 übrigens zwingend vorgeschrieben.

<img src="pfad/zum/bild.jpg" alt="Bildbeschreibung" />

JavaScript, Videos und Flash

Manche Elemente können von verschiedenen Programmen (Screenreader, Browser) und Geräten nicht wiedergegeben werden. Fast kein Smartphone kann Flash wiedergeben aber auch Textbrowser und Screenreader haben Probleme mit JavaScript und Adobe Flash.

Prüfen Sie daher ob sich Ihre Website ohne Flash-Plugin und mit deaktiviertem JavaScript nutzen lässt.

Suchmaschinen gehen zwar langsam dazu über JavaScript auszuführen und CSS-Dateien zu laden und die Website zu inspizieren wie Sie in einem „echtem“ Browser angezeigt wird, für Screenreader sind diese Techniken allerdings immer noch ein riesiges Hindernis.

Verwenden Sie Videos auf ihrer Website? Beachten Sie, dass es auch Nutzer mit beeinträchtigtem Hörvermögen gibt. Erstellen Sie ein Transkript zu jedem Video.

Ist meine Website barrierfrei?

Sie möchten Ihre Website auf Barrierefreiheit testen? Die folgenden Tools funktionieren dazu sehr gut und decken prinzipiell alle relevanten Tests ab und geben Hinweise zur Verbesserung:

achecker.ca – Prüft Websites nach folgenden Standards:  BITV 1.0 (Level 2) , Section 508, Stanca Act, WCAG 1.0 (A/AA/AAA), WCAG 2.0 (A,AA,AAA)

wave.webaim.org – Prüft Websites und stellt alle problematischen Elemente  dar

Verlassen Sie sich allerdings nicht nur auf diese Tools. Versetzen Sie sich in die Lage eines seh- oder hörbehinderten Menschen und testen Sie ihre Website auf jede erdenkliche Art und Weise, insbesondere mit einem Textbrowser.

Joomla/WordPress gehackt, was nun?

Vorgeschichte

Neulich stand ich vor der Situation, drei gehackte Joomla Installationen wiederherstellen zu müssen. Die Content-Management-Systeme befanden sich mehr als 1,5 Jahre nach Ende des Supports noch in der Version 2.5.28 und lagen auf dem gleichen Webspace.
Nicht nur, dass sich das Aktualisieren schwierig gestaltete, da der Auto-Updater nicht funktionierte und direkte Updates auf Joomla 3.6 nicht möglich waren, stand ich nun vor der Herausforderung die veränderten Dateien zu finden und zu bereinigen. Der Hack wurde über mehrere Monate nicht bemerkt und das System war zu weiten Teilen infiziert, Backups lagen keine vor.

Eins vorab: Es ist unwahrscheinlich alle kompromittierten Dateien zu finden und es stellt einen großen Aufwand dar. In den meisten Fällen ist es besser, die Software komplett neu aufzusetzen und die Website von Grund auf neu zu erstellen.

Hier möchte ich nun darlegen wie ich zur Bereinigung und Wiederherstellung vorgegangen bin. Gute Dienste haben mir vorwiegend die Tools grep und sed geleistet.  Diese Anleitung lässt sich natürlich auch auf andere Content-Management-Systeme übertragen, ein gehacktes WordPress lässt sich auf die gleiche Art wiederherstellen.

Alle genutzten Tools sind Bordmittel einer jeden vernünftigen Linux-Distribution. Windows Nutzer können ein Live-System, eine Virtuelle Maschine oder ihren Webserver nutzen.

Disclaimer: Obwohl ich im folgenden häufiger den Begriff „Hacker“ benutze, meine ich damit keinesfalls die ethischen Hacker, sondern den umgangssprachlichen „bösen“ Cracker.

Gehacktes CMS wiederherstellen

Schritt 1: Website offline nehmen

Sperren Sie mittels .htaccess oder ähnlicher Methoden sämtliche Verzeichnisse für Besucher oder richten Sie eine Weiterleitung ein. Sie können dazu folgende htaccess-Regeln nutzen:

Options +FollowSymlinks
RewriteEngine on
RewriteCond %{REMOTE_ADDR} !=123.45.67.89
RewriteRule index.php$ /fehler.php [R=301,L]

Ersetzen Sie die IP-Adresse „123.45.67.89“ durch Ihre Eigene. Alle anderen Besucher werden nun auf die Seite „fehler.php“ weitergeleitet.

Schritt 2: Backup der Daten

Nachdem eine Joomla Installation gehackt und dies bemerkt wurde, sollten Sie unbedingt und schnellstmöglich ein Backup der Daten und Datenbank anlegen. Hierzu eignet sich zum Beispiel die Software Akeeba Backup. Bereinigt man die Dateien, ohne vorher eine Sicherung zu erstellen, besteht zu jeder Zeit die Gefahr dass der/die Hacker versuchen alle Ihre Spuren zu verwischen und sämtliche Daten löschen. Auch für eventuelle Strafanzeigen ist es wichtig ein Backup mit allen infizierten Daten zu haben.

Sollte ein Backup der Daten mit Akeeba nicht möglich sein, bleibt noch ein manuelles Sichern über FTP, MySQL, phpMyAdmin o.ä.

Schritt 3: Ändern aller Passwörter

Ändern Sie alle Passwörter. Das beinhaltet Passwörter von Benutzern, FTP Passwörter, SSH Passwörter, MySQL Passwörter etc.

Informieren Sie alle Nutzer über die Probleme und zwingen Sie diese, wenn möglich, ihr Passwort zu ändern.

Schritt 4: Analyse des Schadens

Wie Sieht der Eingeschleuste Schadcode aus?

Möchte man Probleme beseitigen, muss man sie erkennen: der eingeschleuste Schadcode kann die unterschiedlichsten Formen annehmen, ist aber meist auf den ersten Blick ersichtlich. Im Folgenden finden sich ein paar Beispiele. Im Interesse der Sicherheit werde ich hier nur Ausschnitte aus Dateien als Bilder einfügen:

Schadcode 1
Verschleierter Code
Schadcode 2
Schadcode mit Passwort-Login, nur teilweise verschleiert
Schadcode 3
Unlesbarer Schadcode
Schadcode 4
Weiterer verschleierter Schadcode
schadcode5
Kreativer Schadcode mit weiterer „Verschlüsselung“
Fall 1:Backup Vorhanden

Für die Analyse des Schadens sollte man sich viel Zeit nehmen. Sollte die Möglichkeit bestehen die Dateien mit einem Backup vergleichen zu können, bietet sich hier ein rekursiver diff an.

Dafür erstellt man am Besten einen Ordner mit den gehackten Daten, einen Ordner mit dem entpackten Backup und führt folgendes Kommando aus:

diff -r ordner_mit_gehackten_daten/ backup/ | sed '/Binary\ files\ /d' >hacked.txt

In der Datei hacked.txt finden sich jetzt sämtliche Änderungen in allen Unterordnern und Dateien. Anhand der Daten lässt sich eine Beseitigung des eingeschleusten Codes durchführen, auch wenn zwischen Backup und Hack schon Änderungen gemacht wurden.

Fall 2: Kein Backup vorhanden

Hier lässt sich nur manuell prüfen, wo Schadcode eingeschleust wurde. Findet man eine Datei, sollte man versuchen das Muster zu erkennen und sämtliche anderen Dateien nach dem Muster zu durchsuchen. Hierfür nimmt man am besten grep. Dieses Kommando durchsucht alle Dateien und Unterordner des aktuellen Verzeichnisses nach einem gegebenen Muster:

grep -r "Muster" .
Hilfreiche Kommandos um Infizierte Dateien zu finden

Finden die in den letzten n-Tagen verändert wurden:

find . -mtime 0

Dieses Kommando listet alle Dateien und Ordner auf, die in den letzten 24 Stunden verändert wurden. Die Anzahl der Tage lässt sich über den Parameter mtime einstellen.

Finden aller PHP-Dateien die nicht mit einem Kommentar beginnen

In meinem vorliegenden Fall wurde viel Schadcode direkt hinter das PHP-Start-Tag injiziert. Das ergibt natürlich Sinn, denn es ist davon auszugehen, dass die meisten PHP Dateien mit <?php  beginnen und eine blinde Injektion von Schadcode nach diesem Tag geht fast immer gut. Außerdem liegt einem böswilligen Hacker meist nichts daran, den Code zu erklären den er eingeschleust hat 😉 .

grep -rvlz $'^[[:space:]]*<?php\n/\*' --include='*.php' | xargs head -v -n 10 > hacked.txt

Dieses Kommando listet alle php-Dateien auf, die nicht mit einem Kommentar beginnen, gibt die ersten 10 Zeilen der Datei sowie den Dateinamen aus und schreibt alles in die Datei hacked.txt. Vielen Dank an anubhava für den RegEx.

Finden verdächtiger Dateien

Suche anhand verwendeter Funktionen

Auch hier leistet grep wieder wahre Wunder. Durchsuchen Sie Dateien, wie oben beschrieben und prüfen Sie diese auf folgende häufig von Hackern verwendete Funktionen:

  • mail()
  • fsockopen()
  • pfsockopen()
  • stream_socket_client()
  • exec()
  • system()
  • passthru()
  • shell_exec()
  • eval()
  • base64_decode()
  • str_rot13()
  • ord()
  • chr()
  • hexdec()

Eine Suche nach diesen Funktionen wird bei einem Content-Management-System sehr viele Resultate liefern und es ist sehr aufwändig alle zu analysieren.

Auch die Variablen $_COOKIE, $_GET, $_POST und $_REQUEST sollte man auf jeden Fall prüfen.

Häufig findet man auch einen @-Operator in der manipulierten Zeile, der das Logging unterbinden soll.

Gute Dienste leistet in diesem Kontext auch jamms (nicht nur für Joomla!).

Suche anhand von Dateinamen

Oft wählen Angreifer Dateinamen unauffällige Dateinamen die in Log-Dateien nicht auffallen. Prüfen Sie Ihre Unterverzeichnisse auf Dateinamen wie:

  • 404.php
  • admin.php
  • ajax.php
  • cache.php
  • contacts.php
  • controller.php
  • config.php
  • configuration.php
  • css.php
  • defines.php
  • dump.php
  • do.php
  • error.php
  • file.php
  • functions.php
  • global.php
  • help.php
  • list.php
  • model.php
  • index.php (dort wo diese nicht hingehört)
  • solo.php
  • test.php

Die Dateinamen enthalten häufig auch Zahlen. Finden Sie also eine Datei wie index14.php, error26.php oder cache7.php sollte sofort allerhöchste Alarmstufe herrschen.

Schritt 5: Installation von Updates

Installieren Sie alle verfügbaren Updates, prüfen Sie jede Erweiterung von Hand auf neue Versionen. Trennen Sie sich von nicht länger unterstützten Erweiterungen und suchen Sie  Ersatz für veraltete Plugins, Komponenten und Module.

Schritt 6: Analyse der Log-Files

Wird der Angriff zeitnah bemerkt, sollte zunächst versucht werden, den Angriff anhand der Log-Dateien nachzuvollziehen. Dies gibt einen Einblick in eventuell weiterhin vorhandene Sicherheitslücken. Oft sind die problematischen Codezeilen jedoch so gut versteckt, dass der Provider keine Log-Dateien für den Angriffszeitpunkt mehr zur Verfügung stellt. Sind die Hacker nicht auf Daten oder blinde Zerstörung aus, ist Ihnen oft daran gelegen, möglichst unbemerkt zu bleiben um den Server so lange wie möglich nutzen zu können.

Ist der Schadcode (teilweise) beseitigt, ist die Arbeit lange noch nicht getan. Nun heißt es überwachen der Logs und das am besten mehrmals täglich. Eine Anfrage an den Webserver sieht in den Log-Dateien in der Regel wie folgt aus:

173.208.198.50 - - [20/Jul/2016:04:55:42 +0200] "POST 
/modules/modules/modules.php HTTP/1.1" 200 440 "website" "Mozilla/5.0 
(Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0" "website"

Erklärung der Anfrage: Typ der Anfrage, Angefragte Seite der Domain, HTTP Status Code, Größe der Anfrage in Bytes

Interessant sind vor allem POST-Requests die nicht auf die Datei index.php, sondern gezielt auf andere Dateien gehen und mit Status 200 beantwortet werden. Diese Dateien sind in jedem Fall manuell zu prüfen und das nach jeder Anfrage am besten mehrere Wochen lang.

Nach dem Hack ist vor dem Hack

Achten Sie immer darauf, dass System und Erweiterungen stets auf dem neusten Stand sind. Installieren Sie Zusatzsoftware für besseres Logging, zum Schutz gegen Angriffe und zum Prüfen der Datei-Integrität. Und am wichtigsten: erstellen Sie regelmäßig Backups, wenn möglich automatisiert.

Zusammenfassung:

  1. Website deaktivieren
  2. Backup
  3. Passwörter ändern
  4. Schadcode entfernen
  5. Updates installieren
  6. Logs prüfen

Ist das alles erledigt, stehen die Chancen gut, dass die Angreifer in die Flucht geschlagen wurden. Eine Garantie dafür gibt es aber keinesfalls.

Ihre Website wurde gehackt?

Kontaktieren Sie uns mit den Details und fordern Sie eine unverbindliche Beratung an.