Webanwendung: zentraler Sicherheitspunkt.

C

cd_brenner

Aktives Mitglied
Hallo Community,

Um eine Webanwendung sicher zu machen müssen zu mindest alle bösen Sonderzeichen maskiert werden. Zusätzlich muss ich in meinem speziellen Fall auch noch Templatevariablen, Snippet-Markierungen und Sprachvariablen aus der Benutzereingabe entfernen. Auch ein Bad-Word-Filter könnte hier ansetzen.
Die meisten Anfragen an die Webanwendung laufen über einen Front-Controller ab.

Ist es vertretbar Dinge wie

CODE mysql_query(SELECT id FROM database WHERE name = "$_GET["name"]'');


zu machen, wenn zuvor an zentraler Stelle das $_GET, $_POST und $_SESSION Array durchlaufen wird, und dabei alle Maskierungen und Entfernungen vorgenommen werden?


Vielen Dank,
Markus
 
Nein, da die Filterung entsprechend für den Anwendungsfall durchgeführt werden sollte, eine pauschale Filterung ist nett, um nach SQL-Injections oder XSS-Angriffen zu suchen, so wie es mit phpids realisiert werden kann.
Aber die Filterung der einzelnen Variablen sollten doch ganz genau auf den Anwendungsfall abgestimmt werden. Hat auch einen sehr simplen Grund, laufen alle Variablen durch so etwas durch, muss man dieses für die Überprüfung von String-Längen oder ähnlichen auch erst wieder entfernen, sonst werden diese Prüfungen verfälscht.
Jedoch kann man sich für das Filtern entsprechende Funktionen zur Vereinfachung erstellen, welche an zentraller Stelle angepasst werden.
 
Danke für deine Antwort.

Also die Methoden, die Werte in die Datenbank schreiben prüfen selbstverständlich ob der eingegebene Datentyp und die Länge zum Datenfeld passt. Eine Methode die einen Integer Wert erfordert verweigert ihren Dienst wenn sie "abc" kriegt.

Allerdings fühle ich mich besser, wenn eine zentrale Instanz eine grobe Filterung vornimmt - insbesondere weil in diesem Projekt Strings wie {title}, #_edit_button#, #SNPT_benchmark# etc auch geparst werden, was bedeutet, dass diese Strings aus der Benutzereingabe entfernt werden müssen.
Weiters möchte ich alle SQL Steuerzeichen maskieren, im Notfall mit einem # irgendwo (DELETE -> DELE#TE).

Reicht es alle ", <, und > in ihre Entitäten umzuwandeln, um HTML und JavaScript auszuschalten?

Vielen Dank vorerst,
Markus


 
QUOTE (cd_brenner @ Mi 18.04.2012, 15:21) Die meisten Anfragen an die Webanwendung laufen über einen Front-Controller ab.

Ist es vertretbar Dinge wie


CODE mysql_query(SELECT id FROM database WHERE name = "$_GET["name"]'');


zu machen

Nein, SQL-Querys so zusammenmzufrickeln ist m.E. nicht mehr vertretbar - Geschweige denn vernünftig oder gar sinnvoll. Angenommen du hast irgendwo ein "Freitext" - und wenn dort innerhalb des Texts jemand irgendwas mit "Delete" schreiben/speichern möchte wird sein Text automatisch auf "DELE#TE" umgeändert?
blink.gif


Du musst das Rad hier allerdings nicht neu erfinden. Dafür gibts unter PHP "ab Werk" z.B. PDO
 
QUOTE (cd_brenner @ Mi 18.04.2012, 16:33)Weiters möchte ich alle SQL Steuerzeichen maskieren, im Notfall mit einem # irgendwo (DELETE -> DELE#TE).

So was ist quatsch, da es mehr Probleme verursacht als löscht, wenn Du ein für Dich gefährlichen String ausmachst, solltest Du eher die Ausführung der Anwendung stoppen, statt versuchen es zu maskieren und dann weiter zu machen. Wobei ich es trotz allen nicht so sinnig finde DELETE oder SELECT so zu verändern, da es ja normale Wörter aus dem englischen Sprachgebrauch sind.


QUOTE (cd_brenner @ Mi 18.04.2012, 16:33)Reicht es alle ", <, und > in ihre Entitäten umzuwandeln, um HTML und JavaScript auszuschalten?

Nein, tut es nicht. Für HTML muss noch mindestens noch & maskiert werden, besser auch noch den Single Quote, aber dann würde ich davon absehen es an zentraler Stelle zu filtern, dies sollte erst kurz vor der Ausgabe erfolgen. Wenn es um JavaScript alleine geht, weil der Text in HTML-Code eingesetzt wird, reicht dieser Art der Filterung aber nicht mehr.
 
Danke für die zahlreichen Antworten, die mir schon einiges weitergeholfen haben.

Ich hätte jetzt allerdings einen weiteren Ansatz um das Ding zentral zu Lösen:

Alle relevanten externen Datenquellen sind ja bekannt - von daher sollte es kein Problem sein diese abzuprüfen.
Im Frontcontroller wird dann quasi geprüft ob $_GET["xyz"] erlaubt ist, und ob dort der erwartete Datentyp (z.B. nur Integer) gegeben ist - wenn nicht wird alles verworfen.

Somit sollte doch schon mal relativ gut gefiltertes Ausgangsmaterial aus $_GET, $_POST und eventuell $_COOKIE kommen. Wenn das noch nach essenziellen HTML, JavaScript und SQL Steuerzeichen filtert/maskiert sollten wir doch klarkommen oder?

ad "Rad neu erfinden": Bei diesem Projekt möchte ich bewusst Dinge selbst entwickeln um daraus zu lernen. Lernen ist der Grundgedanke bei dem Projekt.

Vielen Dank vorerst,
Markus
 
Wie ich oben schon geschrieben habe, halte ich es eher für wenig sinnvoll es so zu lösen. Ich sähe nur eine Möglichkeit, dass Du entsprechende eigenständige Arrays baust, zum Einfügen in SQL, und ein separates für die Ausgabe auf der Seite, und wie gesagt alles wegwirfst, wenn eine Variable daneben liegt.
Ich würde aber wohl eher dazu abraten, so vorzugehen.
 
zu dem Thema hab ich auch noch ne Frage....

ist es sinnvoll, bestimmte Zeichen bei der Eingabe in ein Formular schon zu verhindern?

CODE IF((preg_match('/[^A-Za-z0-9 -]/', $username )) OR ( preg_match('/[^A-Za-z0-9 -]/', $passwort ))){
$_SESSION['Sonderzeichen'] = "keine Sonderzeichen....<br/>";// wird beim erneuten Laden des Formulars angezeigt
$_SESSION['counter']=$_SESSION['counter'] + 1;// dient als Zähler für Fehlversuche
ECHO XXXX.....; //diese Seite wird neu geladen
EXIT;
}

dadurch verhindere ich doch, dass der User irgendwelchen Unfug eingibt, oder sehe ich das falsch?

Möchte noch hinzufügen, dass mein Nickname was php und co. betrifft vollkommen zutrifft...
wink.gif
 
"frontcontroller" durchsucht die GET und POST arrays nach verdächtigen Zeichen oder Zeichenfolgen, wie z.B. INSERT, DELETE, EXEC, usw. und wenn fündig stoppt die Ausführung des PHP Skripts.

Dieser Frontcontroller müsste in jedem Skript an den Anfang gebaut werden.

Das Hauptproblem dabei ist, sich wirklich sicher zu sein, dass man nichts verpasst hat und wirklich alle Sicherheitsprobleme mit dem Frontcontroller abfängt.
Richitg sicher wäre ich mir dabei nie.

Ich würde so einen quick & dirty fix nur kurzlebig als Überbrückungslösung anwenden, solange wie gebraucht wird um die Anwendung abzusichern, wenn diese denn nicht abgeschaltet werden kann.
 
Solche Dinger, wie es auch das PHP IDS ist dienen nur als zusätzlichen Schutz, können aber keine vollständige Applikationssicherheit gewährleisten, und im schlimmsten Falle sogar neue Lücken reißen, da es ja auch ein weiteres Stück Software ist.

@NullAhnung Prinzipell ja, aber durch den Programmcode wird dies Auswahl etwas zu stark eingeschränkt, sowohl für's Passwort als auch für den Benutzernamen. Und letztendlich kommt es eben auch stark darauf an, was am Ende mit den einzelnen Feldern geschicht, so kann das Passwortfeld anders zu filtern sein, als das Feld eines Benutzernamens.
 
Danke für die Antwort... da beruhigt mich...grins

ich denke man muss auch den User dazubringen gewisse Regeln einzu halten... und _ oder '# etc haben in einem Namen, Ort und auch in einem Passwort nichts verloren...ist meine Meinung
 
Falsch in einen Passwort muss man gerade eine breite Masse an Zeichen zu lassen und kann es nicht so dermaßen beschränken, wie in dem Falle. Da spielt Deine Meinung eher eine untergeordnete Rolle, und würde ich insbesondere beim Passwort als völlig falsch ansehen.

In Passwörtern müssen auch Sonderzeichen zur Verfügung stehen.

Zeichengruppen in Passwörtern sind noch immer folgende:
  • große Buchstaben
  • kleine Buchstaben
  • Zahlen
  • Sonderzeichen
Bei Benutzernamen gibt es in Deutschen aber auch durchaus Namen wie René, was Du da oben auch nicht erlaubst.
 
gut an den rene hab ich nicht gedacht....aber wenn er in der db mit rene drin ist, ist es auch nicht schlimm....grins

aber große firmen wie microsoft verbieten ja auch die eingabe von sonderzeichen....und hunderte millionen menschen können damit leben, und ich denke, dass viele user es aktzeptieren, wenn es anscheinend um die sicherheit ihrer daten geht....
 
Hmm, also ich kann in meinen Windows Sonderzeichen verwenden. Und nein, ich habe in meinen Live-Account auch Sonderzeichen drin.

Na ja, ich nicht, da es ja gerade eben um die Sicherheit meiner Daten geht, keine Sonderzeichen im Passwort heißt für mich, ich melde mich mal besser nicht an dem Dienst an, wer weiß welchen Bockmist die noch veranstaltet haben.
Besonders toll auch immer wenn man keine gültigen E-Mail-Adressen eingeben kann, weil so ein Depp vom Anwendungsentwickler meinte gewisse Zeichen nicht zu akzeptieren.

Aber wenn Softwareentwickler oftmals schon keinen Plan von Sicherheit haben. Wie willste dann bitte davon ausgehen, dass ein Anwender weiß was sicher ist?
 
QUOTE Ich würde aber wohl eher dazu abraten, so vorzugehen.


Lassen wir das 'wo' mal im Hintergrund und beachten nur das 'was':
Wie macht man's richtig/am Besten?

Wir ist klar, dass SQL, HTML, Javascript und die internen Steuerzeichen in den Templates maskiert entfernt werden müssen. Zusätzlich sollten alle eingehenden Variablen (egal ob via GET, POST etc) möglichst fein selektiert werden.

Als Beispiel:
$_GET["id"] > darf nur numerisch sein [0-9], darf max. x lang sein.
$_POST["cloudkey"] > darf nur Buchstaben enthalten [A-Za-z], darf max. y lang sein


Was ist noch essenziell um eine Webanwendung sicher zu gestalten?

Da mir jetzt schon einigemale geraten wurde das nicht global zu lösen könnte ich mir auch vorstellen eine einfache Funktion zu schreiben, die die Eingangsvariablen mit dem entsprechenden RegEx prüft und reagiert.

Allerdings muss ich zugeben, dass mir der Mehrwert gegenüber der globalen Methode noch nicht klar ist.

Mich reizt das sorglose Verwenden der Superglobalen nach dem Frontcontroller irgendwie...


QUOTE Angenommen du hast irgendwo ein "Freitext" - und wenn dort innerhalb des Texts jemand irgendwas mit "Delete" schreiben/speichern möchte wird sein Text automatisch auf "DELE#TE" umgeändert?


Was passiert mit einem DELE<span style="display: none;"></span>TE ??

Es sollte eher in die Richtung Web Application Firewall gehen:

http://de.wikipedia.org/wiki/Web_Application_Firewall
und noch ein recht interessantes Paper: https://www.owasp.org/images/1/1b/Best_Prac...s_Guide_WAF.pdf

Vielen Dank.
Markus
 
Sie müssen sich einloggen oder registrieren, um hier antworten zu können.
Zurück
Oben