Sicherung des User Input

[hajo]

x!sign war nicht meiner Meinung und habe deswegen mit nem Freund von mir gesprochen der auch PHP coded um meine Idee zu modernisieren. Wollte es euch jetzt Mal allgemein vorstellen, da ich mir hier schon ewig lange Überlegungen gemacht habe und mir recht sicher bin den zu 99% idealsten Fall getroffen zu haben:

Bereich der Absicherung

Da $_GET und $_POST von Php zu $_REQUEST zusammengeführt werden würde ich direkt dieses absichern anstatt get und post gesondert zu behandeln, da die Grenzen dazwischen mehr und mehr verschmelzen und vieles inzwischen auch per URL übertragen wird um es leichter an Andere weitergeben zu können wie z.B. Suchstrings oder Angaben über Zeiten, Daten, usw.

Art der Absicherung

Denke hier an eine Klasse um die Daten vorallem einzeln und Verwendungsspezifisch vor der Nutzung abzusichern, anstatt wie es von x!sign klang alles im vorhinein komplett abgesichert anzubieten was ich im Sinne von Performance und Flexibilität schon im Ansatz ausgeschlossen hatte

Verwendung der Absicherung

Die Klasse sollte für jede Art der Absicherung spezifische Methoden besitzen wie z.B. Prüfungen auf Pfadangaben, ICQ-Nummern, Email-Adressen oder formfeste Eingaben anderer Art. Als Beispiel könnte es dann beim überprüfen eines Pfades so aussehen:

$check_plugin_path = check->request('plugin','path');

dies würde in der Klasse check die Methode request aufrufen, diese würde $_REQUEST['plugin'] heranziehen und die Methode path benutzen um es zu formatieren bzw. zu überprüfen und anhand von dessen Rückgabe den return liefern

SQL Sicherung

Da 90% der Daten die von User Input kommen und nicht eh geprüft werden müssen auf spezifische Problematiken lediglich eine SQL-Sicherung benötigen wäre es evtl. ratsam von vornherein einen SQL gesicherten Array aus dem Inhalt von $_REQUEST zu generieren oder dies optional mit Default auf 1 in oben erwähnter Methode zu integrieren.

That's it

Feedback erwünscht und Ideen willkommen

[xsign.dll]

ok - eigenltich dachte ich zwar ein wenig strikter, aber ok

Mein vorschlag:

Klasse: input.class.php (wie schon gehandhabt)

Dort gibts eben Funktionen wie folgt:

clean_input( $string='', $modifier='' )
=> säubert den string

check_input( $string='', $contain='' )
=> wirft fasle oder true

Als globales Objekt würde ich eben wie gehabt $input nehmen... wäre im Prinzip nur $input = $_REQUEST; Für mich klingt $input eben logischer - vorallem mit den oben genannten funktionen hätte man dann z.b.

$id = $security->clean_input( $input, 'tags' );

nun muss man sich halt noch die modifikatoren überlegen, aber da kommt man schnell drauf
- tags
- escape
- dots
- abc
- int
- ?

was noch ?

[xsign.dll]

ok vllt. bin ich da auch einfach nen beranntmarktes Kind, der bei rohen $_GET,$_POST und $_REQUEST statements nen Kollaps kriegt

Also nochmal zur Verdeutlichung: $_REQUEST vereint $_POST,$_GET und $_COOKIE

puuh... da gibts tausende von Ansätzen, die erelativ richtig sein könnten - ich hab jetzt schon 4 stück gesehn, aber keine befriedigt mich richtig.
Also was ich direkt mal vermeiden will, ist, dass in den Modulen auf einmal nen $_REQUEST auftaucht. da bin ich einfach strikt dagegen. Ich erachte sowas nicht als clever und auch nicht als sicher - und als guten source hab ich das noch nie erachtet.
Es verleitet einfach zu stark, einfach mal auf die schnelle nen $_REQUEST['id'] hinzuschreiben.

Also wie wärs mit ner Klasse und folgender Funktion:

$input->get_input('request_var', 'modifikator');

Dasselbe Prinzip hat ja hajo oben schon beschrieben - ich denke damit kommen wir klar.

simple, schlank und befriedigend. Keine tausend funktionen, kein $_REQUEST Statement und wir können aus der funktion ableiten, was sie macht.

so - ich trink nu nen wein

PS: Modfikatoren ? welche ? naja ich bastel einfach mal drauf los

[hajo]

würde da die verfügbaren methoden listen, also email bzw. msn, path, icq, steam id, usw. und zudem vll. noch integer

[xsign.dll]

also msn is doch immer ne mail, oder?

Und wie siehts mit logging aus - was ist, wenn einer manipuliert? Soll das geloggt werden?
Also z.b. wenn ich jetzt nen hack angriff aufs bxcp gemacht hätte und da wäre gekommen: Der Administrator wurde über blabla benachrichtigt, hätt ich schlagartig aufgehört.

[hajo]

meinte ja msn BZW. email

keine schlechte idee vll. diverse verdächtige dinge wie union oder eval mitzuloggen

[xsign.dll]

done... siehe repository... noch ohne logging, da kein db layer

[Jens-A. Koch]

Verwendung von $_REQUEST

Ich halte das für ne Stilfrage. Generell stimme ich xsign zu, die Superglobale $_REQUEST nicht als Schmelztopf anzusehen.
Für Fälle in denen mittels Post (also irgendwelche Formulare,etc. ) gesendet wird bitte auch nur $_POST verwenden. $_SESSION und $_SERVER sind ja sowieso nur direkt ansprechbar, jedoch sollte dies auch bei $_COOKIE so gemacht werden. Das ist sauberer, nachvollziehbarer und auch sicherer, denn man vertauscht nich irgendwelche Variablennamen miteinander, die sich dann gegenseitig im $_REQUEST überschreiben würden.

Nötige Inputfilter

Erstmal Standards abdecken: Zahlen, Buchstaben, Sonderzeichen, dann etwa speziellere Tags.

$input->get_input('request_var', 'modifikator');
ist eigentlich ok!

eine andere möglichkeit wäre alle Superglobalen immer zu beginn zu filtern und gesäubert neu zu assignen.
$_POST = filter($POST) bzw. $_COOKIE = filter($COOKIE).
dann kann man ganz normal mit allen vars arbeiten.

Logging

Definitiv! Benachrichtigungen senden (wobei einstellbar ob per EMail oder zur Db LoggingTable).

[hajo]

genau das mit dem vorab alles  gesamt filtern wollte ich ja vermeiden, die performance leidet bei größeren datenmengen dann unnütz mit!

anstatt eines modifikators könnte man auch direkt die methoden aufrufen und damit evtl. den switch sparen. ob die daten nun aus $_POST oder $_GET kommen ist wurst, da überlagert sich eh nix und wenn führt php das ja logisch zusammen, je nachdem wo etwas enthalten ist. das $_COOKIE auch bei $_REQUEST drin ist wäre mir neu ...

[Jens-A. Koch]

Verwendung von $_REQUEST

$_REQUEST beinhaltet eine Zusammenfassung von $_POST, $_GET und $_COOKIE.
Ich kann aber nicht sagen, in welcher internen Reihenfolge das verarbeitet wird.

Die Performance-Bremse seh ich nicht so recht. Die Sachen müssen auch so gefiltert werden.
Ich glaube das mehrmalige Einsteigen in eine filternde Classfunction zieht mehr Performance, als der einmalige Durchlauf der Superglobals dort. Die Menge der zu filternden Daten ist aus meiner Sicht nicht so hoch.

$_POST
$_GET
$_COOKIE
$_REQUEST (obige 3 zusammen)
$_SESSION
$_SERVER

Es wäre gut wenn wir das mal Benchmarken könnten, also GlobalerFilter vs. VorortFilter.
Eigentlich kann man sich am Leerlauf der Anwendung orientieren.
Also einfach von Seite zu Seite.

Sicherheit der Queries

Es ist ja die PEAR:Db in Verwendung, in wie weit sind da überhaupt Vorbereitungsmaßnamen für Queries erforderlich, wie zB escaping etc.? Macht das die Db Klasse oder läuft der Filter auch vor jedem Query? 

[xsign.dll]

Also bei dem Thema herrscht echt Verwirrung...
Ich habe nun schlichtweg die $_REQUEST Methode gewählt, da die Variable superglobal ist und keine weitere initilisierung in jeder Funktion benötigt. Gefiltert wurden von mir $_REQUEST['mod'], $_REQUEST['action'] und $_REQUEST['id']

Das escapen ist Aufgabe des DB Layers (PEAR::DB wurde übrigens abgesetz, HaJo will da was ganz eigenes schreiben), daher habe ich mich nur auf addslashes() beschränkt, und nicht auf mysql_real_escape_string() gesetzt.
Die methoden direkt aufrufen? Ja, theoretischer weise schon... dann kann ich aber auch gleich die php-funktionen anwenden. Außerdem hat man somit nur 2 Funktionen, die sich durch den ganzen Source ziehen - das sorgt weniger für Verwirrung.

Klar sollte auch sein, dass der einmalige Filter am Anfang performanter wäre, als mehrmalige Zusatzfilter pro $_REQUEST Key. Aber das ist ernsthaft zu vernacchlässigen und reine Formsache. Ich habe mich für eine Mischlösung entschieden - ähnlich wie beim BXCP. Ich persönlich hätte auch $_POST und $_GET getrennt, sehe aber die notwendigkeit nicht, wenn wir die Namensgebung drauf haben. also cookie variablen auch mit 'cs_cookie_id', 'cs_cookie_name', ...
Ansonsten überschneiden sich wei gesagt die Variablen von $_GET und $_POST oder $_COOKIE

[hajo]

Die Klasse muss beim Vorort-Filter ja auch nur einmal am Anfang initialisiert werden und ist dann überall verfügbar. Es wird einfach träge jeden Input gegen jede Art von Fälschung und attacken abgesichert anzubieten ohne das dies angefordert wird, was in max. 10% der Fälle passieren wird.

Bei der DB-Anbindung ist denke ich noch eine Frage offen bevor ich schaue was das beste wäre:

Transaktions-Management Ja/Nein ?

Da aus Speed-Gründen meist MyISAM in MySQL zum einsatz kommt werden eh Ein-Aktion-Transaktionen ausgeführt und php script basierte künstliche Transaktionen stehe ich skeptisch gegenüber was effizienz und fehlerfreiheit angeht ...

[xsign.dll]

So bevor ich mich jetzt über das Thema todsuche und unterhalte, musst du mir erstmal erklären, was Transaktions-Management genau ist.

[hajo]

stell dir vor jemand bucht nen flugzeug ticket, dafür gibts 3 sql abläufe die nötig wären:

1. blockieren eines freien platzes zur reservierung

2. reservieren eines freien platzes

3. freie plätze um einen vermindern bei erfolg

wenn nun eines der drei fehl schlägt ist es beim ersten ja nicht schlimm, aber wenn jetzt bei 2. oder 3. fest hängst würdest wenn es in eine transaktion packst alles zurück rollen können das es so wird als wäre der teil ablauf garnicht passiert, transaktion geht nur ganz oder garnicht.

[xsign.dll]

...und MyISAM vernachlässigt das zu gunsten der performance? gut - gerallt.
Hat aber immer nur dann seine Gültigkeit, wenn die Packages vom PHP Interpreter zur SQL DB Korrupt sind, ja? Dürfte relativ selten der Fall sein.

[hajo]

genau, dafür wäre sonst innodb die alternative mysql tabellen variante mit transaktions management und es gäbe halt auch noch die möglichkeit es php script basiert zu lösen auf kosten von evtl. fehlern und performance.

die varianten bei der transaktion werden meist commit und rollback genannt

[xsign.dll]

Ok dann gleichmal nochwas zum Thema Sicherheit.

Ich liste mal kurz auf, was ich grob kenne, um an Passwörter zu kommen:

- SQL Injection (Hash rausziehn)
- Keylogger auf dem Opfer-PC
- Man in the middle (D.h. jmd. im Netzwerk schneidet die ganzen $_REQUEST Variablen mit)
- Andere Portale hacken, wo der User registriert ist, und hoffen, dass er immer dasselbe Passwort verwendet
- XSS - Crosssite Scripting

Gegen nen Keylogger und das Hacken von anderen Portalen kann man schlichtweg nichts machen.
Bei Man in the middle,SQL Injection und XSS jedoch schon.

Wie schon angesprochen, wird es einen SALT geben. Dieser ist random, also von Portal zu Portal unterschiedlich und wird in der config.class.php gehalten. Warum nicht in der DB? Nungut, das liegt ganz einfach daran, dass ein Hash ohne den zugehörigen SALT nutzlos ist. Hat man nun schon den Zugang zur DB durchs hacken erlangt, so kann man (wenn der SALT in der DB ist), den SALT sowie den HASH bekommen. Somit kann man das ganze wieder zurückführen und erhält den orginalen Hash.
Deshalb trennt man diese Komponenten und speichert den SALT in der config.class.php - somit brauch der Angreifer Zugang zum Apache UND zur DB - und das ist sehr unwahrscheinlich.

Bei Man in the Middle geht man wie folgt vor: Man lässt den User sein Passwort eingeben und ein JS überprüft zu allererst ob die Mindestlänge erfüllt ist (generell 6-stellig), danach ob das Passwort in einer Passwortliste ist (kann ggf. auch von PHP übernommen werden). Nach der Überprüfung schickt man das Passwort nicht einfach so weiter, sondern tätigt noch während des JS Prozesses eine MD5 Verschlüsselung. Diese geschieht zwar ohne SALT, aber besser als nichts. Der Sinn dahinter ist: Es wird das Passwort nicht unverschlüsselt versandt. Normalerweise nimmt man hierfür HTTPS, aber man kann nicht davon ausgehen, dass die User sowas bereithalten.

Zu guter letzt XSS - dabei versucht ein Angreifer z.b. in das Gästebuch ein JS-Script einzuleusen, welches die Eingabe des Users mitloggt und an eine URL sendet. Nun stellt sich die Frage, wie man sowas verhindern kann... dafür benötigt man schlichtweg Programmierer-Skill - Und zwar muss man alle TAGs von Usereingaben Filtern - und das ist z.B. in einem Forum recht schwierig, da manche ja auch mal HTML Code posten wollen oder ähnliches. Ein Allheimittel dagegen gibt es leider nicht

Nun die Frage: Warum der ganze Aufwand?
Antwort: Es gibt clansphere eine enorm gute Reputation. Ich höre fast jeden Tag: "Hast schon gehört, die Site von Clan xyz wurde gehackt". Unsere Sicherheitsfunktionen wären dann repräsentativ für Clansphere. Ich wüsste auf Anhieb 3 Clans, die auf ein Portal umsteigen würden, welches sicher ist. Somit sehe ich die Sicherheitsfunktionen als reine Marketingstrategie - nicht etwa um den Usern wirklichen einen Gefallen zu tun

So long...

[hajo]

html würde ich einfach überall sperren und per htmlentities oder htmlspecialchars escapen bei z.b. gbook oder comment texten. bei news und ähnlichem könnte man es ja erlauben das über den acp freizuschalten manuell, aber generell sollte eher ein vernünftiger bbcode dafür herhalten.

[xsign.dll]

Also wenn dann htmlentities - generell sperren in news,gbook - bei Forum halt nur in den dafür vorgesehenen Tags ( [ code] [ /code] )

[Jens-A. Koch]

wie sieht das mit register_globals on aus???
htaccess setzt das auf aus?

falls die einstellung nicht greift, trotzdem filtern?