ResponseCode 404 für robots.txt

Wer WordPress verwendet und für die Domain eine “robots.txt” automatisch generieren möchte, kann Probleme mit den Headern / Response Codes bekommen.

Falls man z.B. das WordPress MultiSite Feature verwendet, um eine WordPress Installation für mehrere Domains / Subdomains zu verwenden, kann keine “robots.txt” im Hauptverzeichnis (/) der Hauptdomain abgelegt werden, da ALLE Domains / Subdomains auf das gleiche Verzeichnis (das WordPress Installations-Verzeichnis) verweisen! Man möchte für jede Domain jedoch eine andere “robots.txt” verwenden. Die einzige Möglichkeit ist dann, ein Script laufen zu lassen, dass die “robots.txt” abhängig von der verwendeten Domain generiert und man so für jede Domain unterschiedliche Dateien hat.

Dies kann in WordPress z.B. mit folgendem Code-Snippet in der “functions.php” des verwendeten Templates durchgeführt werden:

Das Problem beim Verwenden dieser virtuellen “robots.txt” zeigt sich, wenn man den Statuscode der Datei im Browser betrachtet:

Man erhält ein “404 Not Found” (im Response Header!), der Inhalt der Datei wird im Browser jedoch angezeigt. Dies ist besonders schwierig festzustellen, da man üblicherweise nicht auf den Statuscode achtet,  wenn der Inhalt korrekt angezeigt wird.

Für Webcrawler / Suchmaschinen wie Google, Bing, Yahoo etc. ist der Statuscode enorm wichtig, teilweise wird die Bearbeitung der Seite abgebrochen, sobald der Statuscode einen Fehler diagnostiziert.

Bei Zugriff auf den Server kann man dieses Problem lösen, indem man in der Webserver-Konfiguration (hier für den NGINX Webserver) folgenden Eintrag im “server” Block der jeweiligen Domain definiert:

Wichtig ist die markierte Zeile 5, hier wird der Aufruf an die “index.php” (und somit an die oben generierte WordPress -Funktion “do_robots” geleitet) falls die Datei in dem root-Verzeichnis nicht gefunden wird!

Defekte Shift-Taste auf MacBook Pro deaktivieren

Falls jemand  ein MacBook Gerät besitzt, bei dem die Shift-Taste eingeklemmt ist oder durch einen Wackelkontakt zu zufälligen Zeitpunkten aktiviert wird, der hat ein echtes Problem – das Betriebssystem startet immer im “gesicherten Modus”, weil die defekte Shift-Taste angeblich gedrückt ist. Dumm nur, dass man aus diesem Modus nicht mehr heraus kommt, es hilft weder eine Neuinstallation des Betriebssystems noch der Austausch der Festplatte. Auch eine Hardware-Diagnose lässt sich nicht durchführen (“H”-Taste während des Boot-Vorgangs gedrückt halten). Was kann man dagegen tun? Es gibt zum Glück eine akzeptable Lösung, ohne die defekte Tastatur oder das Gerät austauschen zu müssen!

Zunächst muss jedoch der sichere Modus deaktiviert werden, da im abgesicherten Modus nur die wichtigsten Treiber / Software geladen werden. Für die Deaktivierung der Shift-Taste wird eine spezielle Software benötigt, mit OS X Bordmitteln ist die Deaktivierung nicht möglich. Der sichere Modus lässt sich ebenfalls nicht einfach abschalten, eine ausgiebige Recherche ergab folgenden Trick:

Mit der Hilfe von Zusatzsoftware kann die Shift-Taste deaktiviert werden, zuvor muss das MacBook aber im normalen Modus gestartet werden. Damit dies gelingt, muss der sichere Modus deaktiviert werden.

Firmware-Kennwort zur Deaktivierung des sicheren Modus

Wird in Mac OS X das Firmware Passwort aktiviert, dann kann nicht mehr in den sicheren Modus gebootet werden! Das kann genutzt werden, um das MacBook Pro normal starten zu lassen – die Shift-Taste ist dann zwar weiterhin aktiv, dies lässt sich mit einem speziellen Programm deaktivieren (siehe nächstes Kapitel). So lässt sich das Firmware-Passwort in OS X 10.8 Mountain Lion und OS X 10.7 Lion aktivieren:

  • MacBook neu starten
  • Während des Bootvorgangs die Tastenkombination “Cmd” (Befehlstaste) + “R” gedrückt halten, um in den Wiederherstellungs-Modus (Recovery Mode) zu gelangen
  • Im Menü den Menüeintrag “Dienstprogramme” (Utilities) wählen und das Programm “Firmware-Kennwort” auswählen
  • Falls das Firmware-Kennwort deaktiviert ist, mit dem Button “Firmware-Kennwort aktivieren …” das Passwort aktivieren
  • das neue Firmware-Kennwort eingeben und bestätigen
  • die Information “Kennwortschutz aktiviert” bestätigen und das Gerät durch Beenden des Recover-Modus neu starten
  • im neu erscheinenden Fenster das Firmware-Kennwort eingeben, danach startet das MacBook im normalen Modus!

Tipp: Bei der Eingabe des Kennworts sollte auf das eingestellte Tastatur-Layout (oben rechts in der Menüleiste) geachtet werden, um Probleme bei der Passwort-Eingabe beim Bootvorgang zu vermeiden. Außerdem sollte bedacht werden, dass die Shift-Taste auch bei der Eingabe gedrückt bleibt, sodass Groß- Kleinschreibung vermieden werden sollte (auch wenn es allgemeinen Sicherheitsrichtlinien widerspricht. An dieser Stelle ist es wichtiger, dass mit dem MacBook überhaupt gearbeitet werden kann)!

Shift-Taste deaktivieren mit KeyReMap4MacBook

Nachdem das Betriebssystem im normalen Modus startet, ist die Shift-Taste trotzdem immer noch aktiviert und stört bei der Arbeit mit dem Gerät, so lassen sich mit der Tastatur z.B. nur Großbuchstaben eingeben. KeyReMap4Macbook ist die Software-Lösung um die Shift-Taste zu deaktivieren, sie funktioniert auch unter der neuesten Mac OS X Version Mavericks. Nach der Installation der Software kann in den Einstellungen die linke Shift-Taste gewählt und ihr die Funktion “deactivated” zugeordnet werden, womit sie im Betriebssystem deaktiviert wird.

Apple GoToFail – Kritische SSL-Sicherheitslücke in iOS und Mac OS X

Am Freitag, den 21.02.2014 wurde eine kritische Sicherheitslücke in Apple Betriebssystemen bekannt. Das am 21.02.2014 veröffentlichte Apple Support-Dokument beschreibt nur grob eine SSL-Sicherheitslücke in iOS. Details werden nicht genannt.

Apple hat am Freitag ebenfalls Updates für iOS 6 und iOS 7 sowie Apple TV, die das Problem lösen sollen, zur Verfügung gestellt. Die Lücke wird als kritisch eingestuft, Updates auf iOS 6.1.6 und iOS 7.0.6 sollten schnellstmöglich eingespielt werden. Heise.de gibt Tipps, was man gegen die Sicherheitslücke tun kann.

Details zu der Sicherheitslücke werden von Apple selbst nicht genannt. Etliche Quellen beziehen sich auf einen groben Programmierfehler in iOS bei der Signaturprüfung (Verifizierung) von SSL-Zertifikaten (u.a. Adam Langley vom Google Sicherheitsteam, MacRumors, 9to5Mac und John Gruber von DaringFireball). Kritisch ist diese Sicherheitslücke, weil dem Anwender beim Ansurfen einer Internetseite gefälschte Zertifikate untergeschoben werden können und so z.B. das Onlinebanking nicht mehr sicher ist!

Im Handshake Code stehen zwei “goto fail;” Anweisungen (Zeile  10 und 11) direkt hintereinander. Dies ist kritisch, da die “if()” Anweisung keine geschweiften Klammern aufweist und somit nicht als Block gewertet wird, sondern nur die erste “goto fail;” Anweisung zum “if()” Teil gehört. Die zweite Anweisung wird immer ausgeführt, falls die ersten “if()” Fälle nicht zutreffen! Die letzte “if()” Anweisung, der letzte Schritt bei dieser Signaturprüfung (und der wichtigste!) wird somit niemals ausgeführt.

Der folgende Code-Ausschnitt stammt aus der Datei “sslKeyExchange.c” der Sicherheitsbibliothek von Apple:

Für Nutzer von Mac OS X gilt diese Sicherheitslücke ebenfalls, es gibt jedoch noch keinen Sicherheits-Patch von Apple. Die Lücke betrifft Nutzer des Desktop-Betriebssystems ab OS X Mavericks. Versionen vor 10.9 haben diesen Bug nicht. Die Lücke betrifft viele wichtige Betriebssystemfunktionen wie Safari, Mac App Store aber auch iMessage. Zumindest beim Browser kann man als Abhilfe Google Chrome oder Mozilla Firefox verwenden, beide haben eigene Implementierungen der Zertifikatsprüfung, sodass der Bug bei Nutzung nicht greift.

Am Freitag veröffentlichte der Sicherheitsexperte Stefan Esser einen Patch für die Sicherheitslücke unter Mac OS X Mavericks. Dieser Patch soll den Bug beheben, ist von anderen Experten noch nicht geprüft worden. Auf der Seite “gotofail.com” lässt sich überprüfen, ob auf dem Betriebssystem die Lücke ausgenutzt werden kann.

Der Fehler in der Sicherheitsbibliothek von Apple hätte durch bessere Coding Guidelines (if() Anweisungen immer mit geschweiften Klammern) oder Code Reviews vermieden werden können. Im Bereich von Sicherheitsanwendungen / Bibliotheken können kleine Fehler große Auswirkungen haben, wie Apple jetzt lernen musste.

Recent Posts Widget in WordPress um Title Text in Links erweitern

In WordPress lassen sich die letzten Beiträge automatisch in einer Übersicht als Widget in der Seitenleiste darstellen. Leser sehen schnell die zuletzt erstellten Artikel und können mit einem Klick zu dem Beitrag springen.

Das Widget “Recent Posts” wird standardmäßig von WordPress bereitgestellt. Es hat jedoch einen kleinen Haken – das “Title”-Attribut für Links wird bei der Darstellung nicht verwendet. Gerade Suchmaschinen können das Fehlen des Attributs negativ werten.

WordPress ist modular aufgebaut, so kann man die Standard-Konfiguration leicht erweitern. Mit folgendem Code-Snippet kann das “Title”-Attribut für alle Links im “Recent Posts” Widget hinzugefügt werden:

Composer Bug geschlossen

Composer, der Dependency Manager für PHP, hat eine Sicherheitslücke geschlossen. Composer erlaubt es, für eigene PHP-Projekte Abhängigkeiten zu anderen PHP-Bibliotheken zu definieren. Diese Bibliotheken können von anderen Entwicklern stammen, die Libraries liegen meist auf Packagist / GitHub. Die Abhängigkeiten werden durch Aufruf von Composer aufgelöst und die benötigten Bibliotheken in das Projektverzeichnis automatisch heruntergeladen. Dies vereinfacht enorm die Aktualisierung / Verwaltung von abhängigen Bibliotheken.

Das Problem an dem Dependency-Manager war, dass Composer die Namen von abhängigen Bibliotheken nicht exakt abgleicht. Falls es mehrere Bibliotheken mit dem gleichen Namen gibt und man die Funktion “replace” von Composer verwendet (mit der Bibliotheken ausgetauscht werden), dann lädt das Tool eine zufällige Bibliothek aus der Liste mit den gleichen Namen herunter!

Böswillige Entwickler könnten auf dem Haupt-Repository eigene Bibliotheken hochladen, die den gleichen Namen wie gängige Bibliotheken (z.B. “Symfony”) haben. Falls in den Abhängigkeiten des PHP-Projektes nicht der exakte Anbieter angegeben wird, dann kann Composer eine zufällige Bibliothek wählen, so z.B. die vom böswilligen Entwickler. Dadurch lässt sich beliebiger Code in PHP-Projekte einschleusen, wenn beim Verwenden von Composer nicht genau auf die Bibliotheken geachtet wird.

Der Bugfix erlaubt dem Composer nicht mehr, eine zufällige Bibliothek auszuwählen, es muss der exakte Name der Abhängigkeit bekannt sein, damit die Bibliothek geladen wird. Benutzer des Tools sollten schnellstmöglich ein Update mit folgendem Befehl (Unix-Shell) einspielen:

Wer genauere Details zu der Sicherheitslücke wissen will, sollte sich den Blog-Eintrag von Pádraic Brady zu dem Thema durchlesen.

MySQL root Passwort zurücksetzen

Mit der folgenden Anleitung kann man bei Passwort-Verlust des Benutzers “root” in MySQL zurücksetzen, in dem ein neues Passwort festlegt wird. Das alte Passwort muss nicht bekannt sein. Für die Neuvergabe des Passworts werden root-Rechte auf dem Server benötigt!
Nach Aufbau einer SSH-Verbindung zum Server werden folgende Befehle eingegeben:

Erklärung des Codes:
Zunächst wird der MySQL-Dienst gestoppt (Zeile 1), anschließend wird das Startscript für den MySQL-Server verwendet, um ihn neu zu starten. Die Option “skip-grant-tables” deaktiviert das Berechtigungssystem für die Datenbanken, d.h. dass jeder Benutzer, der Zugriff auf den Server hat auch uneingeschränkten Zugriff auf alle Datenbanken hat. Aus Sicherheitsgründen für den Produktiv-Einsatz nicht zu empfehlen, da man in diesem Modus z.B. Passwörter ändern kann. Deshalb wird der MySQL-Server nach dem Ändern des Passworts mit dem Berechtigungssystem neu gestartet!

WICHITG: Das Und-Zeichen / Ampersand (&) am Ende des Befehls darf nicht vergessen werden, es bewirkt, dass der Befehl im “Hintergrund” als Background-Prozess des Servers weiterläuft. Falls das Zeichen nicht eingegeben wird, läuft MySQL solange das Terminal (die SSH-Verbindung) geöffnet bleibt! In dem geöffneten Terminal lassen sich keine weiteren Befehle eingeben, also das Zeichen nicht vergessen.

Nachdem der MySQL-Server ohne Berechtigungssystem gestartet wurde, kann man als “root”-Benutzer bei MySQL anmelden (Zeile 3). Es wird kein Passwort benötigt. In MySQL wird die “mysql”-Datenbank verwendet (Zeile 4). Anschließend kann für den “root”-User das Passwort “neues-Passwort” gesetzt werden. Damit die Berechtigungen und somit das neue Passwort aktualisiert werden, müssen die Benutzer-Privilegien zurückgesetzt werden (Zeile 6). Zum Schluss wird der MySQL-Server im normalen Modus neu gestartet.