Jun 28 2007
Version 0.2.3 ist erschienen, wenn die weiter son Tempo machen komm ich nie dazu meinen Bericht darüber zu machen 
Links:
Comments Off
Jun 21 2007
HTML Purifier wurde gestern endlich in der Version 2.0 released. Er ist Whitelist basiert und der beste Filter der mir bisher bekannt ist.
Ein blick/test lohnt sich auf jeden Fall. 
Jun 18 2007
Die neuere Version 0.2.2 ist nun gestern erschienen, ich habe das IDS in einem neuen Projekt, welches ich am Wochenende fast fertig gestellt habe eingesetzt und bin nun mit diesem Projekt am testen. Bis auf ein paar false positive matches, was nicht so schlimm ist, da das Impact-Level dafür lediglich 3 war, funktioniert es sehr sehr gut.
Die Pagegeneration time ist auch nicht spürbar gestiegen und liegt jetzt bei ca 0.2 - 0.4 Sekunden statt 0.07 - 0.2 Sekunden. Sehr fein, zwar schon messbar, aber nicht spürbar. Werde demnächst den Laufzeit verbrauch des IDS separat messen und einen ausführlicheren Artikel darüber verfassen und hier ein FAQ auf Deutsch anbieten und extra noch ein paar Beispieldateien von mir. Bin zur Zeit nur etwas ausgelastet, deswegen ist hier nicht viel los.
Weiterlesen “PHP-IDS 0.2.2″
Jun 14 2007
Hm, darüber bin ich vor ein paar Minuten gespeichert. Schon beängstigend das man die Passwörter so einfach stehlen könnte. Ein kleines Javascript erledigt die Arbeit dafür, es kann zwar nur lokal ausgeführt werden, aber dennoch, seien wir mal ehrlich, wie einfach ist es jemand per Social Engineering dazu zu bringen eine .html Datei anzunehmen und diese auszuführen.
Hier ist der Original Artikel dazu, inkl einem Beispiel Script, das Script kann bedenkenlos heruntergeladen und geöffnet werden, es ist nur ein PoC und übermittelt die Passwörter nicht.
Jun 11 2007
So, nun ist es endlich so weit, das PHPIDS ist erschienen, ich habe es mir heute mal angeschaut und etwas getestet und muss sagen, sieht schon sehr gut aus.
Für alle die nicht Wissen was das ist, es ist ein Intrusion Detection System für XSS Attacken und konsorten. SQL-Injections soll es wohl auch erkennen und abfangen können. Aber wir schauen mal.
Ausführlich werde ich mich am Wochenende einarbeiten und es auf Herz und Nieren testen. Vorallem interessant dürfte hierbei sein wieviel false positives werden erzeugt. Was nutzt einem das beste IDS wenn es zu restriktiv ist, sollte man es denn dann auch nutzen um Angriffe zu blocken.
Allerdings nutzt es hier schon ein Impact funktion welche je nach schwere des Angriffes höher ist und man auf die unterschiedlichen Werte/Level auch unterschiedlich reagieren kann. Ab einem bestimmten Impactlevel wird es dann auch kein false positive mehr sein.
Desweiteren wird noch interessant sein wie man den Filter umgehen kann, aber dazu muss ich mir ersteinmal in aller Ruhe die Regelsets anschauen und testen 
Mai 22 2007
Es ist ein Exploit aufgetaucht, welches die Fehlende Validierung in der admin-ajax.php ausnutzt. Nur in Version 2.1.3
Bitte die aktuelle Version 2.2 Deutsch downloaden oder die Englische
Dies behebt das Problem 
Mai 13 2007
Ich hatte gerade mal wieder 30 Minuten Luft und habe mir gedacht “Schaust du dir mal wieder mehr oder minder bekannte Seiten an” . Und prüfst sie natürlich auch gleich auf etwaige XSS-Luecken .
Nunja was soll ich sagen. Ich habe wohl knapp 15 Seiten geprüft und 9 und mehr davon weisen XSS-Lücken auf. Danach hatte ich ehrlich gesagt keine Lust mehr. Einige weisen auch andere Lücken auf, welche sogar sehr Sicherheitskritisch sind. Selbst die Firma “Proforma” die selbst Internetauftritte erstellt, weist Lücken auf. Wo ich zu meiner nächsten Frage komme. Wieso sind 98% aller Eingabefelder auf einer Seite validiert und 2% nicht. Was dann meist 1-2 Felder sind. Wer Codet diesen Müll bitteschön zusammen?
Warum unterschätzen alle den Imageschaden dieser Lücken? Durch solche Nachlässigkeiten könnten immense Schäden entstehen wenn es jemand mit viel potentieller Energie auf eine dieser Seiten abgesehen hat.
Um nur ein paar zu nennen . Wer also schon immer einmal das Suchen von solchen Lücken üben wollte, diese Seiten weisen definitiv Lücken auf, findet sie
Mai 12 2007
Als ich letztens wieder auf einer meiner Streiftouren durch das WWW war, stolperte ich mal wieder über blog.de und die Stellenausschreibung eines Freiberuflichen PHP-Entwicklers für die Seite. Also schnell Bewerbung getippert und mit den nötigen Unterlagen abgeschickt. Nun wie nicht anders zu erwarten erstmal keine Rückmeldung.
Also hab ich mir die Seite mal etwas genauer angeschaut. Zwecks XSS Lücken. Siehe da nicht lange musste man suchen, hatte man auch schon das erste nicht ordentlich validierte Eingabefeld gefunden, nun ganz dumm waren sie nicht, das muss man ihnen schon lassen, wenn man versucht aus dem Tag auszubrechen wird das gefiltert. Aber wer will schon aus einem Eingabefeld ausbrechen wenn er diesem auch einfach weitere properties und javascript Eventhandler hinzufügen kann .
Nun mehr sei an dieser Stelle nicht gesagt, Leute die sich etwas damit auskennen werden die Lücken schon selbst finden, vorhanden sind Sie auf jeden fall. Dazu braucht man noch nicht mal einen Account dort, wer weiß was sich damit dann noch alles anstellen lässt.
Was lernen wir wieder einmal daraus, nunja Validierung und Testing insbesondere auf XSS Lücken scheint immernoch einen viel zu geringen Stellenwert bei Unternehmen zu haben, zieht man schließlich keinerlei Profit daraus. Solange bis es zu mittelschweren Imageschäden kommt, siehe StudiVz und konsorten. Ja diese ganzen Web 2.0 möchtegern startups.
Mai 08 2007
Nach aktuellen berichten ist es bei AOL egal was man nach der 8ten Stelle im Passwort angibt, da der Anbieter ab dieser Stelle die Eingaben abschneidet. So Brian Krebs von der Washington Post
Noch schlimmer ist, das AOL angeblich 16 Stellen speichert und sich Nutzer die komplexe Passwörter nutzen in vermeintlicher Sicherheit wiegen, da ihr Passwort welches mehr als 8 stellen hat, mit 8 stellen vielleicht sogar schon gegen Wörterbuchangriffe anfällig sein könnte.
Also auf wen dies zutrifft, der sollte schnellstens sein Passwort ändern und die Gegebenheit mit den 8 stellen beachten.
Mai 01 2007
Es sind mehrere Exploits zu Wordpress Plugins aufgetaucht. Alles sogenannte RFI Exploits. RFI steht für “Remote File Include”, sprich es können externe Dateien in das Script eingebunden werden, welche dann auf eurem Webserver mit den Rechten eures Webservers laufen.
Betroffen sind die folgenden Plugins:
Angeblich soll es nötig sein das die php-option “register_globals” aktiviert ist. Nach einem kurzen Blick auf die Datei scheint es aber so, als wäre es nicht zwingend notwendig das diese Option aktiviert ist. Denn wenn man diese Datei mittels POST Request aufruft und die entsprechenden Formularfelder setzt kann man ein Script auch so einbinden. Aber man sollte ja sowieso die php-option “allow_url_include” deaktiviert haben, da kann einem so eine Lücke nicht gleich so sehr gefährlich werden, wenn dann noch open_basedir gesetzt ist und register_globals deaktiviert ist.
