Google Analystics datenschutzkonform(er) nutzen

Auf spreerecht.de findet sich seit einiger Zeit eine Anleitung, wie Google Analystics datenschutzrechtkonform genutzt werden kann. Dazu sind 4 Schritte notwendig:

  1. Einbindung der Funktion “_anonymizeIp()” im Analytics-Code, um die letzten 8 Bit der IP-Adresse entfernen.
  2. Den Vertrag über Auftragsdatenverarbeitung ausfüllen und mit einem frankiertem Rückumschlag an Google schicken. Die Adresse steht im Vertrag.
  3. Aufklärung der Besucher in der Datenschutzerklärung.
  4. Löschen aller bisher durch Google Analytics erhobenen Daten.

Genauere und ausführlichere Informationen und das Muster der Datenschutzerklärung finden Sie im Beitrag von spreerechts.de: Google Analytics rechtssicher nutzen – Anleitung und Muster für Webmaster

Probleme mit GnuTLS

Seit einigen Wochen versuche ich verzweifelt GnuTLS genau so zum Laufen zu bekommen wie mod_ssl, doch bisher ist mir nur der Standard gelungen, dass HTTPS sauber funktioniert. Doch was ich eigentlich erreichen möchte, dass ich eine Client-Authentifizierung mittels Zertifikat und mod_gnutls erreiche, ist mir bisher immer noch nicht gelungen. Bisher trete ich auf der Stelle rum, und das Importierte Client-Zertifikat kommt anscheinend nicht mal bei Webserver an, daher habe ich mich nun an Personen gewandt, die hoffentlich mehr Ahnung zu dem Thema haben:

debianforum.de: GnuTLS und Client-Authentifizierung mittels Zertifikat

Aktuell kann ich nur über mod_gnutls sagen, dass ganz simplen Standards gesicherter Verbindungen bereitstellen kann, aber für erweitere Optionen, welche mit mod_ssl ohne große Probleme funktionierten, findet man bei mod_gnutls kaum Quellen zu. Also aktuell wäre ich schon froh eine saubere Anleitung für GnuTLS zu finden, welche sich auch mit diesen Thema auseinander setzt.

So lange muss wohl eine reine Passwort-Authentifizierung reichen mit langen Passwort, sonst muss ich mir was neues einfallen lassen.

PHP Extention: Wann MySQLi statt MySQL benutzen?

Beim Starten eines Projektes oder bei Verwendung einer fertigen Webapplikation, welche/s auf PHP basiert, kommt man unweigerlich oftmals zu der Frage: Soll ich die MySQLi- oder MySQL-Bibliothek von PHP nutzen.

Die Frage lässt sich heute in 99,9% der Fälle mit MySQLi beantworten. Ausnahmen hierbei sollte es eigentlich nur sehr wenige geben. Eine Ausnahme könnte sein, dass man ein Module für eine Applikation schreibt, welche immer noch die MySQL-Erweiterung nutzt, nur dann stellt sich auch die Frage, ob diese Applikation noch genutzt werden sollte. Alternativ zu MySQLi lässt sich natürlich auch der Datenbankabstraktion-Layer PDO verwenden.
Wieso gerade MySQL nicht mehr verwendet werden soll, ist recht simple. MySQL wird nicht mehr wirklich gewartet, es werden nur noch die nötigsten Dinge erledigt (kritische Sicherheitsupdates), und ab PHP 6 wird es auch nicht mehr unterstützt werden, das heißt lieber jetzt umstellen, um später weniger Arbeit mit der Umstellung zu haben. Als Plus gibt es bei MySQLi zudem noch eine komplett Unterstützung von MySQL 4.1+.

Als kleine Übersicht nochmal die Tabelle von php.de zu diesen Thema ergänzt mit den bisherigen Informationen zu PHP 6:

Funktion MySQLi PDO MySQL
SSL-Verbindung
Eingeführt in PHP Version 5.0 5.0 3.0 und früher
In PHP 5.x verfügbar Ja Ja Ja
In PHP 6.0 verfügbar Ja Ja Nein
MySQL Entwicklungsstatus aktive Entwicklung aktive Entwicklung (as of PHP 5.3) nur Wartung
Empfehlung von MySQL für neue Projekte Ja – vorzugsweise Ja Nein
API Unterstützt Zeichensätze Ja Ja Nein
API Unterstützt serverseitige Prepared Statements Ja Ja Nein
API Unterstützt clientseitige Prepared Statements Nein Ja Nein
API Unterstützt Stored Procedures Ja Ja Nein
API Unterstützt Multiple Statements Ja weitestgehend Nein
Unterstützt alle MySQL 4.1+ Funktionen Ja weitestgehend Nein

Schwachstelle CA/SSL-Zertifikat?

Die gewollte Designschwäche von HTTPS-Verbindungen sollte nicht ignoriert werden. Sie kann wohl nicht als direkte Schwäche von SSL und SSL-Zertifikaten selbst betrachtet werden, doch durch die schiere Anzahl von CAs können wir uns nie ganz sicher sein, dass nicht ggf. doch jemand mithört.

Durch den kurzen veröffentlichen Blogbeitrag von Matt Blaze, habe ich nochmal kurz über die Sicherheit von SSL nachgedacht, und habe es einfach mal selber mit gesponnen. Selbst wenn nun eine Sachen fiktiv sind, so sind sie nicht komplett abwegig.

Ok, es hört sich für den Einen oder Anderen abwegig an, dass jemand eine Man-In-The-Middle-Attacke machen kann, wenn eine Website (o.ä.) mittels SSL-Zertifikat gesichert wird. Trotzdem ist es denkbar, wenn die angreifende Person Zugriff auf ein verbreitetes CA-Zertifikat hat. Immerhin müssen wir uns hier vor Augen führen, dass viele CA-Zertifikate bereits standardmäßig mit dem Betriebssystem oder Browser ausgeliefert werden. Und genau das kann der Knackpunkt sein.
So haben einige Open-Source-Distributionen bspw. CAcert als CA-Zertifikat hinzugefügt, bei welcher durchaus Missbrauch möglich ist. Aber auch wissen wir nicht, wie die kommerziellen Anbieter mit ihren CAs umgehen, ob nicht ggf. sogar den Geheimdiensten im entsprechenden Land Zugriff auf die CA gewährt wird, so dass beliebige SSL-Zertifikate ausstellt werden könnten, oder es selber missbrauchen, kann wohl keiner so einfach widerlegen (oder beweisen). Auch gibt es immer wieder Firmen, die sogenannte kostenlose SSL-Zertifikate anbieten. StartCom, eine israelische Firma, ist eine solche CA, dessen kostenlose Zertifikate werden nur mittels E-Mail validiert. Das CA-Zertifikat von StartCom ist auch entsprechend verbreitet, so dass es schnell in einen Browser zur Verfügung steht. Ich selber habe bei der letzten Neuinstallation es noch händisch entfernt.

Daher sollte wohl immer im Hinterkopf gehalten werden, SSL-Zertifikate sollen zur Absicherung des Datenverkehrs dienen, daher ist es sehr ratsam, diese zu verwenden. Doch muss hier auch sensibilisiert werden, dass nicht jeder CA vertraut werden sollte, und das jeder selber dafür Verantwortlich ist, bedenkliche Zertifikate zu löschen, welche ggf. durch Betriebssystem oder Browser mitgeliefert werden. Selbst dann bleibt immer noch das übliche Restrisiko.
Wer also sehr sicher gehen möchte beim Datentransfer, legt seine eigene CA an, verbreitet Sie auf seine Clients und wirft danach alle anderen CAs raus.

Altersbeschränkung für Websites – Publizierung nach Uhrzeit

Jugendschutz ist wichtig, nur der jetzige Gesetzesentwurf scheint nicht nur auf mangele Grundkenntnis des Internets zu gehen, sondern wohl auch auf Ignoranz begründet sein. Ignoranz, die sowohl die Logik und die Interessen der Allgemeinheit ignorieren zu scheint.

Neu ist das Thema wohl nicht, bereits 2001 berichtete der Heise Verlag ausführlich unter Telepolis über dieses Thema: Operation Jugendschutz. Doch nun scheint es wieder einmal Thema zu werden.

Worum geht es?

Es geht um den Gesetzesentwurf für das neue Jugendschutzgesetz. Nach diesen sollen die Websites in Deutschland in Altersgruppen unterteilt werden. Das ist ja soweit ganz in Ordnung, doch nun kommt es: Websites mit der Altersklassifizierung ab 16 dürfen dann nur noch von 23:00 Uhr bis 6:00 Uhr veröffentlicht werden.

Der Unsinn dieser Regelung

Jeder der nun noch alle 7 Sinne irgendwie beisammen hat, kann sich vermutlich mit seinen wenigen Internetkenntnissen zusammenreimen, dass nicht nur von Deutschen Websites ins Netz gestellt werden, sondern auch von anderen Ländern. Im deutschsprachigen Raum gäbe es da sehr gute Ausweichmöglichkeiten Richtung Schweiz und Österreich. Doch wo liegen wirklich gefährdende Inhalte? Nun viele gefährdende Inhalte, wie Pornographie ohne sichere Altersverifizierung gibt es eher im Ausland. In Deutschland gibt es hier bereits sehr strickte Richtlinien darüber, ab wann eine Altersverifikation notwendig ist, und ab wann diese als Zuverlässig gilt (die Überprüfung der Personalausweis-ID zählt nicht als zuverlässig). Und zu guter Letzt, ist noch nicht mal gegeben, dass Sie alle daran halten, Seiten die so wie so bereits rechtlich Bedenklich sind (rechtsextreme Website usw.), werden sich vermutlich nicht dran halten.

Was wäre eine bessere Alternative?

Eine definitiv bessere Alternative wäre eine technische Altersverifikation, so dass im Gesetzt nur festgeschrieben werden muss, dass die Website eine solche Altersangabe richtig zu pflegen hat. Hintergrund wäre eine ähnliches Verfahren wie beim Datenschutz mit dem P3P-Verfahren. Bei einen solchen Verfahren wäre es möglich, die Altersverifikation mittels einer hinterlegend XML-Datei durchzuführen. Hierbei wäre es dann technisch sogar möglich, die Verifikation mit einen Regelwerk zu versehen, die die gesamte Website bewertet, aber auch ermöglicht einzelne Bereiche der Website anders zu bewerten (ähnlich der Suchmaschinensteuerung über die robots.txt).
Die Datei sollte vorzugsweise, wie beim P3P-Verfahren, in der HTML-Datei angegeben (damit nicht weitere 404-Fehler erzeugt werden). Nun könnte im Browser eingestellt werden, bis zu welcher Altersstufe die Websites angezeigt werden sollten, und wie Verfahren werden soll, wenn die Dateiangabe der XML-Datei fehlt, die angegebene Datei nicht vorhanden oder nicht dem XML-Shema entspricht. Diese Optionen müssen natürlich vor Veränderung geschützt werden.
Somit ließe sich nicht nur ein wesentlich besserer Schutz integrieren, sondern würde auch nicht die informationelle Selbstbestimmung jedes einzelnen Bürgers einschränken. Natürlich wäre es bis zu dieser Methode ein weiter Weg. Es müsste es eine technische Beschreibung des Verfahren existieren inklusive der Entwurfes des XML-Shemas erfolgen (eine RFC), doch dies ist nur der kleinste Aufwand. Viel schwieriger und aufwändiger wird es, diese Technik in die Browser zu bekommen, ob nun über den Browserhersteller selber oder per Erweiterung. Wenn hiervon jedoch eine Organisation, wie der W3C, mit ins Boot geholt kann, wird diese Art der Altersverifikation nicht nur in Deutschland zum Standard werden, sondern könnte sich sogar weltweit verbreiten.
Wer nun denkt: “Ha ha, dann stell ich meine Seite einfach für ab 12 rein.”, hat damit wohl grundsätzlich diesen Schutz ausgehebelt. Da es sich hier aber um eine XML-Datei handelt, könnte man in diesen Standard ein weiteres Feld einbauen, welche eine Signierung dieser Angaben ermögliche, die an der Domain gebunden wird. Damit könnte bspw. eine Altersverifikation von einem Institut vergeben werden. Im Browser würde ein weiteres Feld hinzugefügt, ob man nun der Datei so vertraut, oder nur signierte Dateien und ggf. selektiv die Vergabestellen sich aussuchen kann.

Nach etwas suchen findet sich auch tatsächlich bereits Ansätze und Überlegungen zu genau solchen Überlegung, schaut man sich beim W3C PICS (Platform for Internet Content Selection) an, findet man hier eine Möglichkeit, Internetinhalte zu bewerten und mittels einer Filtersoftware zu blocken. Weitere Definitionen, wie und wofür es genutzt wird, überlässt das W3C den Verwendern. Interessant ist hier natürlich das Datum der Version 1.0 von PICS 27.05.1998. Etwas genauer zu diesen alternativen System der Bewertung finden sich bei omen.org: Die Standardisierung der Zensur.

Mutmaßungen im Netz

Im Netz machen sich natürlich bereits Mutmaßungen einer neuen Internetzensur breit, was sich natürlich verstehen lässt, denn diese Methode grenzt den Bürger irgendwo auch in seiner informationellen Selbstbestimmung ein, denn viele Informationen sind auf einmal nur noch zu bestimmten Uhrzeiten verfügbar. Zu schweigen von den Schwierigkeiten, dass mit Suchmaschinen und/oder Besuchern, wenn die Website nicht verfügbar sein soll.

Fazit

Grundsätzlich ist eine Altersangabe für Websites nicht verkehrt, doch der Gesetzesentwurf geht hier weit an der Realität vorbei. Die Methode zur Sperrung der Websites ist hier mehr als fragwürdig, hinzu kommt noch seine Unzulänglichkeit für ausländische Websites.
Eine Umsetzung der hier vorgestellten Möglichkeit zur Beschränkung erfordert wohl allgemein mehr Überzeugungsarbeit, und auch mehr Arbeit insgesamt, stellt aber später wohl eine sehr gute Alternative da, die von allen begrüßt werden werden könnte. Und ließe sich im Zweifelsfalle nicht so einfach aushebeln. Den Eltern bleibt es außerdem überlassen, was sie ihren Kindern an Inhalten erlaubt, und welche nicht, auch nach von 23:00 bis 6:00 Uhr.

Quellen

Apache Sicherheit bei Verwendung von PHP

Sicherheit in Webanwendungen ist immer ein großes Thema, dazu gehört auch die sichere Einbindung des PHP-Modules in den Apache httpd Webserver. In diesen Artikel behandele ich kurz, wie PHP in den Apache eingebunden wird und nur von Dateien mit der Endung .php oder .php5 ausgeführt wird, und weshalb hier eine Sicherheitslücke lauern kann.

Wieder mal ist ein sogenanntes Future vom Apache Httpd Auslöser eines Exploits, diesmal bei WordPress.

Grundlegend kann man sich nun Fragen, liegt der Fehler nun beim Apache Httpd, bei WordPress oder beim Administrator des Apache Httpds? Nun, bei gesamter Betrachtung hat jeder etwas Schuld, aber das tut nichts zu Rolle. Interessanter ist es, wie ich als Administrator eines Apache Httpds nicht Opfer dieses Exploits geworden wäre, bzw. der Exploit keine Auswirkungen auf mein System hat.

Um zu verstehen, was hier passiert ist, eine kurze Erklärung des Exploits. Hier entsteht eine Lücke durch ein Future vom Apache Httpd, welche vom WordPress nicht abgefangen wurde. Dieses Future greift vornehmlich bei mehrfachen Dateiendung (bspw. archive.tar.gz oder image.php.jpg), es arbeitet den Dateinamen von rechts nach links ab, um einen diese einen entsprechenden Dateityp zu zuordnen. Wenn bei nun die für die Endung .jpg kein Dateityp im Apache httpd hinterlegt ist, nimmt er sich die nächste Stelle, was bei einer Datei mit den Namen image.php.jpg, die Endung .php wäre. Somit wird die Datei den Typ PHP zugeordnet und wird durch den PHP Parser geschickt und ausgeführt.

[…]
Files with Multiple Extensions

Files can have more than one extension, and the order of the extensions is normally irrelevant. For example, if the file welcome.html.fr maps onto content type text/html and language French then the file welcome.fr.html will map onto exactly the same information. If more than one extension is given that maps onto the same type of meta-information, then the one to the right will be used, except for languages and content encodings. For example, if .gif maps to the MIME-type image/gif and .html maps to the MIME-type text/html, then the file welcome.gif.html will be associated with the MIME-type text/html.

Languages and content encodings are treated accumulative, because one can assign more than one language or encoding to a particular resource. For example, the file welcome.html.en.de will be delivered with Content-Language: en, de and Content-Type: text/html.

Care should be taken when a file with multiple extensions gets associated with both a MIME-type and a handler. This will usually result in the request being handled by the module associated with the handler. For example, if the .imap extension is mapped to the handler imap-file (from mod_imagemap) and the .html extension is mapped to the MIME-type text/html, then the file world.imap.html will be associated with both the imap-file handler and text/html MIME-type. When it is processed, the imap-file handler will be used, and so it will be treated as a mod_imagemap imagemap file.

[…]

Quelle: http://httpd.apache.org/docs/2.2/mod/mod_mime.html

Also was sollte man als Administrator eines Apache Httpds machen?

Nun, erstmal sollte dafür gesorgt werden, dass Dateien nur durch den PHP Parser gelangen, wenn die Dateiendung auch wirklich den Abschluss der Datei bildet. Bei Debian Lenny kann dies wie folgt erreicht werden:

/etc/apache2/mods-enabled/php5.conf

<IfModule mod_php5.c>
  AddType text/plain .php .phtml .php3 .php4 .php5
  <FilesMatch "\.php5?$">
    AddType application/x-httpd-php .php .php5
    AddType application/x-httpd-php-source .phps
    SetHandler application/x-httpd-php
  </FilesMatch>
</IfModule>

Damit hätte man als Administrator eines Apache Httpds schon mal sorgfältiger gehandelt und der beschriebene Exploit wäre gar nicht möglich gewesen. Trotz allen müssen PHP-Anwendung, wie WordPress, umsichtig genug entwickelt werden, dass der Exploit gar nicht erst vorhanden ist.

Hinweis: Falls nun jemand meint, der SetHandler würde reichen, der irrt, zu mindestens bei Debian Lenny wird es nicht funktionieren, erst mit den oben gezeigten Beispiel arbeitet der Apache 2.2 zuverlässig, so wie es gewollt ist.

Virenattacke der anderen Art, oder wieso ich meinen Rechner trotzdem absichern sollte

Immer wieder darf ich mir von Personen anhören, die nicht ein Deut vom Fach sind: “Was kümmert es mich, wenn mein Rechner gehackt wird? Da ist eh nichts wichtiges drauf und ich habe auch keine persönlichen Daten darauf.”
Doch was ist es, wenn man genau wegen einer solchen Attacke oder durch einen Virus eine ordentliche Tortur durchmachen darf. Dieser, wenn auch recht ungewöhnliche Fall, zeigt doch nochmal hervorragend, wieso es doch besser ist sich immer Gedanken, um die Sicherheit eines Computersystems machen sollte. In den Fall infiziert ein Virus einen Rechner und lädt auf diesen Kinderpornos, dadurch verliert die entsprechende Person Freunde, Arbeit und einiges mehr, von den Stress mit den Behörden, der Presse und einigen Personen, die Pädophilie nicht gerade freundlich gesinnt sind (klar irgendwie auch verständlich, kaum jemand mag solche Leute). Doch letztendlich stellte sich heraus, dass in Wirklichkeit ein Virus auf den Rechner war, der auch nachweislich entsprechende Websites aufrief und belastendes Material herunterlud. Danach wurde die Anklage nach 11 Monaten fallen gelassen, doch was ist mit allen Anderen?
Die ganze Geschichte ist unter spiegel.de Virenattacke mit Kinderpornos zu finden.

Gut, die gängigere Methode wäre wohl, dass jemand von dem infizierten Rechner weitere Attacken durchgeführt, die ggf. den Betroffenen in eine missliche Lage bringt. Beispiele dafür wäre ein Botnetz, was ggf. an DDoS-Attacken tätig ist, Brute-Force-Angriffe durchführt, oder jemand sich über den Rechner in empfindlichere Systeme häckt, wie Banken, Militär-, Nachrichtendienste u.ä.. Was wohl auch unangenehm genug werden könnte.

PHP: Dateinamen für Windows / CIFS

Ich weiß nicht, ob das nun der Weisheit letzter Rat ist, aber bei mir hat er mit Hilfe dieser kleinen Funktion sauber auf CIFS (SMB 1) geschrieben. Vielleicht hilft es ja den Einen oder Anderen etwas.

  1. /**
  2.  * tranform the filename inclusive path to the cifs filename charset
  3.  *
  4.  * @param string $filename;
  5.  * @return string
  6.  */
  7. function cifs_file_charset ( $filename )
  8. {
  9.    if ( !is_string($filename) )
  10.    {
  11.       exit('wrong parameter for $filename');
  12.    }
  13.  
  14.    /* first the lower bit encodings, otherwise the higher bit encoding will be
  15.     * detected and the next step will return strange results or nothing
  16.     * mb_convert_encoding without the three parameter will fail as well
  17.     * Bug: If the real encoding of the string is utf-8, it detect the ISO-encoding first
  18.     *   (PHP 5.3.0)
  19.     */
  20.    $encoding = mb_detect_encoding($filename, 'iso-8859-1, iso-8859-15, utf-8, auto', true);
  21.    /* CP1252 seems to be the right file charset für CIFS (aka SMB 1) */
  22.    $filename = mb_convert_encoding($filename, 'CP1252', $encoding);
  23.  
  24.    return $filename;
  25. }

DualBoot Windows Vista / Linux

Diese Anleitung müsste auch für Windows 7 funktionieren, ich habe es bisher aber noch nicht ausprobieren können, über eine Rückmeldung würde ich mich freuen.

Über den Windows Bootmanager

Voraussetzung hierfür, ist dass Linux Grub als Bootmanager verwendet.

Schritt 1 – Eine Kopie von der Linux-Bootpartition erstellen

Als erstes muss Windows beigebracht werden, wie es Linux booten kann, dafür muss ein kleines Abbild erstellt werden von der Bootpartition (z.B. wo GRUB installiert ist), dies muss natürlich als root angelegt werden und dann nach Windows transferiert werden (per USB-Stick, CD o.ä.):
dd if=/dev/sda1 of=/tmp/linux.bin bs=512 count=1

Schritt 2 – Windows Vista installieren

Schritt 3 – Dual Boot unter Windows Vista konfigurieren

Nun wird ein Eintrag für GRUB im Windows Vista Bootmanager erstellt unter Verwendung von bcdedit.

  • In Windows Vista die Kommandozeile mit administrativen Rechten starten (Rechtsklick auf cmd und “Als Administrator ausführen”/”Run as Administrator” auswählen)
  • Den Linuxbootsektor auf die (aktive) Windows Bootpartition kopieren, die Partition enthält die bootmgr.
  • Eintrag für GRUB erstellen:
    bcdedit /create /d "GRUB" /application BOOTSECTOR
    Hinweis: bcdedit liefert eine ID für den Eintrag zurück, welche hier {LinuxID} genannt wird. Die {LinuxID} muss mit der erhaltenen ID in diesen Schritt ersetzt werden. Ein Beispiel einer {LinuxID} ist {81ed7925-47ee-11db-bd26-cbb4e160eb27}.
  • Angabe des Laufwerks, welches eine Kopie des Linuxbootsektors enthält.
    bcdedit /set {LinuxID} device boot
  • Angabe des Pfads zum kopierten Linuxbootsektor.
    bcdedit /set {LinuxID} PATH \linux.bin
  • Hinzufügen eines Linuxeintrags, welcher im Bootmenü angezeigt wird.
    bcdedit /displayorder {LinuxID} /addlast
  • Zeit das Menü für 10 Sekunden an, um die Betriebssystemauswahl zu ermöglichen.
    bcdedit /timeout 10

Quelle: http://port25.technet.com/…-Support.aspx

Über GRUB

Schritt 1 – Windows installieren

Schritt 2 – Linux mit Grub installieren

Schritt 3 – Grubeintrag für Windows Vista erstellen

Einfach vor oder nach den Linux-Booteinträgen folgendes hinzufügen. Wobei x und y in (hdx,y) durch die entsprechenden Zahlen zu Ersetzen sind.

  • x = Festplatte (heraus findbar über die device.map im Grubverzeichnis, welche Angabe hier erfolgen muss)
  • y = Partition (Die Partition auf der der entsprechenden Platte, wobei bei 0 angefangen wird zu zählen und bis 4 geht zu erweiterten Partition mehr dazu hier: GRUB Manual – 2. Naming-convention)

/boot/grub/menu.lst
title Windows Vista
rootnoverify (hdx,y)
chainloader +1

makeactive