WebApplication-Security - Prävention und Fernhaltung krimineller Energien.

[pro2sell]

auf mehrfachen wunsch eröffnen wir diesen thread .

ausdrücklich sei erwähnt, dass es hierbei *nicht* darum geht, wie ich fremde daten illegaler weise auf meinem server spiegeln kann oder das konto meines bösen nachbarn leerräume. maßnahmen zur bekämpfung dieser vorfälle sind ebenfalls offTopic und unerwünscht, da wir hierzu keinen rechtsbeistand leisten und auch keinen juristen empfehlen werden.

zur diskussion stehen aktuelle themen wie XSS (Cross-Site-Scripting), SQL-Injection und weitere sicherheitsrisiken, die bei web-anwendungen ein mögliches angriffsziel bieten. in erster linie geht es um das verständnis dieser exploits und deren vermeidung durch patches oder workarounds.

nun denn, viel spaß beim posten

[Jürgen Donauer]

PHP:

ich würde mal behaupten, dass sich eine große Angriffsfläche schon mal unterbinden ließe, wenn man die Variablen $_POST und $_GET auf validen Inhalt überprüft.

preg_match() und eregi() sind kein Hexenwerk und können viel Unfug verhindern.

Die Verwendung von mysql_real_escape_string() beugt SQL-Injections vor.

Alle Leser dieser Box haben nun keine Entschuldigung mehr, wenn auf Grund nicht geprüfter Eingaben Blödsinn mit ihren Systemen getrieben wird oder sich einer ohne Passwort einloggen kann

Jürgen

[pro2sell]

lol...hätt ich nicht besser schreiben können!
evtl. sollten wir uns den matchcode mal etwas näher anschauen.



und als simples beispiel

if($_POST['action'] == "register") {
// sollte jedem klar sein, oder?
     if (preg_match("/^[a-z0-9]*$/is", $_POST['nickname'])){
         echo "okay";
      }
} 

selbstverständlich sollte man auch darauf achten, dass register_globals nicht ein zufälliger parameter ist und in der php.ini auf OFF gesetzt wird. aber das soll, soweit ich informiert bin, mit PHP6 wegfallen und man braucht sich darum keine gedanken mehr zu machen.

worauf kommt es nun an und welche prüfungen sind lästig, bzw. serverlastig und wie kann ich das ermitteln?
ein vergleich zwischen eregi()

$myString = 'myEregiStringTangaPregVeryMatch';
 
for($i = 0; $i <= 1000000; $i++)
{
var_dump(eregi('^[A-Z\.]+$', $myString));
} 

und preg_match()

$myString = 'myEregiStringTangaPregVeryMatch';
 
for($i = 0; $i <= 1000000; $i++)
{
    var_dump(preg_match('/^[A-Z\.]+$/i', $myString));
} 

liefern bei einem benchmark recht interessante ergebnisse. der unterschied liegt zwar annähernd im nano-bereich, aber es kann bei stark frequentierten anwendungen schon wertvolle 'lebenszeit' bedeuten.

weiterhin ist die methode der parameter-übergabe auch ein wichtiges kriterium und bedeutet ebenfalls kostbare zeit

$query = sprintf("INSERT INTO products (`name`, `description`, `user_id`) VALUES ('%s', '%s', %d)",
                    mysql_real_escape_string($product_name, $link),
                    mysql_real_escape_string($product_description, $link),
                    $_POST['user_id']); 

in dem beispiel wird sprintf() verwendet um den string in eine query zu übergeben. nun, das ist zwar sicher, aber sicherlich auch zeitintensiver als

$query = "INSERT INTO products (`name`, `description`, `user_id`) VALUES ('".mysql_real_escape_string($product_name, $link)."','".mysql_real_escape_string($product_description, $link)."','". $_POST['user_id']."')" ; 

dies sollte jeder mal ausprobieren und für sich selbst entscheiden. der apache bietet hierfür beste voraussetzungen

Das Programm ab finden Sie im Verzeichnis /usr/local/apache2/bin auf ihrem Server. (Das Verzeichnis kann abhängig von Ihrer Installation auch ein anderes sein.) Ab Suse 9.1 geht's mit dem Aufruf von ab2

Starten Sie ab mit folgenden Parametern:

ab –n 1000 ihrserver/test1.php

Statt "ihrserver" geben Sie die URL Ihres Testservers ein oder tippen einfach "localhost". Nach einem Tastendruck auf Return geht es los. Das Benchmark ruft 1000mal nacheinander die Testdatei auf und führt sie aus. Danach gibt es eine hübsche Zusammenfassung. Am interessantesten für den schnellen Test ist darin die Angabe der "Time per request:". Hier steht der Zeitraum in Millisekunden, den ein Aufruf der Datei gebracht hat.

aber von der optimierung des codes zurück zum eigentlichen thema. mit pattern-matching kann ich vorbeugen und bösen absichten etwas weniger angriffsvektoren bieten. man sollte sich stets darüber im klaren sein das: je weniger raum ich gebe, desto weniger kann darin passieren - aber bitte nicht zu lasten der features!
deswegen ist ein gut strukturierter code das A & O jeglicher anwendungen. nur allzu oft passiert es, dass wir mal eben eine routine oder zusätzliche funktionen erweitern und mehr oder weniger schnell den überblick verlieren, da es inzwischen hunderte dieser spaghetties geworden sind. wirklich nicht zu empfehlen, aber im alltag nicht immer so einfach umzusetzen...jeder kennt es, das zeit-und-raum-problem

hilfreich kann auch kann dieser eintrag in der php.ini sein: expose_php = Off
es verhindert die ausgabe der php-version. weitere informationen die misbraucht werden können, kann ich in der httpd.conf vorwegnehmen:
APACHE_SERVERSIGNATURE="off"
APACHE_SERVERTOKENS="Prod"
in meinem fall muss ich /etc/sysconfig/apache2 editieren, damit der eintrag permanent bleibt.

sinn und zweck ist ganz einfach. wenn ich keine eigenen fehlerdokumente definiert habe, kann ich die ausgabe der version des web-servers und weiteren modulen verhindern. dies ist zwar kein wirksamer schutz, bietet aber wiederum weniger info, die sich böse jungs nunmal als erstes holen wollen, um bereits bekannte exploits anzuwenden

ich habe einen gesprächigen XAMPP:

Error 404
localhost
06/28/08 09:47:16
Apache/2.2.8 (Win32) DAV/2 mod_ssl/2.2.8 OpenSSL/0.9.8g mod_autoindex_color PHP/5.2.5

und einen nicht so freizügigen server im netz ohne eigene fehlerseiten:

Error 404
schranz.tv
Sat Jun 28 10:08:35 2008
Apache

diesmal mit

Not Found
The requested document was not found on this server.


--------------------------------------------------------------------------------

Web Server at schranz.tv

bitte nicht unbedingt die domain aufrufen. dort ist (noch) nix gescheites und es poppen die werbebanner, die eh nix bringen

BTW: falls jemand ne idee zu schranz.tv hat, bin ich zu jeder schandtat bereit

[Jürgen Donauer]

hier kann ich vielleicht noch ne potentielle Fehlerquelle beisteuern. Mir hat letztens der Webserver einen Fehler geschmissen, den ich noch nie zuvor gesehen hatte:

Warning: preg_match() [function.preg-match]: Compilation failed: range out of order in character class at offset 14 in datei.php on line 34

huh?! ... ok irgendwas faul mit dem regulären Ausdruck (ich hab den gekürzt wegen einfacherer Darstellung) ...

preg_match("/^([A-Za-z0-9.-,]{1,200})$/", $_POST['variable']) 

Der Ausdruck würde zulassen: Bereich von A bis Z, von a bis z, von 0 bis 9 und von Punkt bis Komma. Letzteres ist natürlich grober Unfug. Stattdessen hätte sich ein so genanntes "Escape" vor das Minus gehört:

preg_match("/^([A-Za-z0-9.\-,]{1,200})$/", $_POST['variable']) 

Nun weiß der Ausdruck, dass es nicht zum Befehlssatz gehört, sondern dieser das Zeichen einfach als Zeichen behandeln soll.

Sollte jemand mal auf den Fehler stoßen, hat er wahrscheinlich einen ähnlichen Mist geschrieben


Zu SQL-Injections wollte ich noch nachtragen, ohne potentielle Exploit-Code zu veröffentlichen (wegen Bösi-Hacker-Dummgesetz):
Man sollte unter allen Umständen verhindern, dass eine SQL-Anfrage der Art:

SELECT * FROM users WHERE user='testdoedel' AND password='' OR ''=''

an den Server weitergegeben wird. Dies würde dem Nutzer "testdoedel" eine Abfrage OHNE zugehöriges Passwort erlauben. mysql_real_escape_string() verhindert dies.

Gruß,
Jürgen

[pro2sell]

um allen anschuldigungen eines arbeitslosen paragraphenreiters im voraus zu sein, empfehle ich einen linik zur wikipedia. dort (wo sonst!) ist SQL-Injection mal etwas ausführlicher erklärt, als wir es hier wollen. würde keinen sinn machen das rad neu zu erfinden...

SQL-Injection – Wikipedia

und sein äquivalent zu XSS

E-Mail-Injektion – Wikipedia

oder

E-Mail-Injection

alle guten dinge sind drei - 1 0, parität

cheers

[Jürgen Donauer]

es verhindert die ausgabe der php-version. weitere informationen die misbraucht werden können, kann ich in der httpd.conf vornehmen:
APACHE_SERVERSIGNATURE="off"
APACHE_SERVERTOKENS="Prod"
in meinem fall muss ich /etc/sysconfig/apache2 editieren, damit der eintrag permanent bleibt.

sehr schöner Tipp übrigens!

Unter Ubuntu (sollte auch für Debian zutreffen glaub ich) findet man diese Einstellungen in der Datei

/etc/apache2/apache2.conf

die Variablen hierfür müssten als Äquivalent

ServerTokens Prod
ServerSignature Off

heißen. Vielleicht kanns mal einer für Red Hat, Mandriva,... nachguggen ... hab grad keines am Laufen. Bzw hab keinen Rechner mit dem ich alle 140.358 (<- leichte Übertreibung!) auf distrowatch gelisteten Distris einspielen kann

[pro2sell]

jetzt, wo wir unseren oberindianer so schön verstecken können, wollen natürlich böse buben wissen, welche version sich dahinter verbirgt! ist es der apache 1.3.x oder apache22 oder 3 oder 4711...?

es wird nun damit angefangen den webserver zu stressen und über meinen port 80 geht eine menge traffic ab, den ich schlecht kontrollieren/einschränken kann.

da ich

1. die logfiles langsamer lesen kann, als sie geschrieben werden
2. ich irgendwann meine blechtrommel hole
3. keine lust auf nervige sachen habe

also was tun? jenseits von gut & böse sitze ich nun da und überlege wie ich am schnellsten herausfinde, was dort abgeht...#@!

tipp:ähnliche mittel verwenden, wie die vermeindlichen angreifer!

die sitzen nämlich auch nicht ständig mit der klampfe in der hand vorm screen, sondern es läuft entweder ein bot, daemon oder sonstiges tool. damit werden komplette ip-ranges in kurzer zeit gestresst und fein als human-readable log über den äther geschickt.

intrusion detection bietet hier einen vorteil.

aus eigener erfahrung:

ich setze gern den snort ein, denn es ist wirklich ein kleines schweinchen

ich kann seine rules frei definieren und/oder regelmäßig updaten lassen. die ALERTS kann ich entweder als flat-file schreiben lassen ODER in eine MySQL-DB

letzteres bietet den entscheidenden vorteil, dass ich ein front-end nutzen kann und habe wirklich alles im überblick. sogar der request und response wird mit geloggt. eine gute kombination sind snort + ACID = Analysis Console for Intrusion Databases

so! ab jetzt kann ich mitreden und diesen bengels den gar aus machen - oder?

nö, noch nicht ...

ich kann jetzt fein säuberlich und chronologisch sortiert (oder wie auch immer) die attacken nachvollziehen, aber nix passiert. eine gute hilfe hierzu ist ein kleines shell-script, das als daemon die alerts vom snort mitliest und die source IP mal eben für einen gewissen zeitraum in die iptables via add drop einträgt

will ich mehr?

[pro2sell]

JA, den guardian

cheers!

[pro2sell]

noch mehr?

ok, hier ist ein hilfreiches tool, um den traffic zu beobachten