PHP MYSQL Sicherheit - Ansätze, Vorschläge, Fragen ...

[bizzylee]

Hi !
ich bastel an einer shop - seite und beschäftige mich gerade mit sicherheitsthemen, schließlich geht es bei so einer seite um geld und das ganze muss sicher sein.
ich habe mich jedoch bisher nicht wirklich mit sicherheit usw auseinandergesetzt, daher ein paar fragen:

- bisher habe ich mit htaccess die wichtigen seiten und dateien, die nicht einsehbar und manipulierbar sein sollen, unzugänglich gemacht .. so dass aber trotzdem alle seiten miteinander kommunizieren können und es keine einschränkung in der funktionalität der seite gibt

- was sql injections und xss angeht habe ich folgenden ansatz bisher probiert:

htmlentities(strip_tags(mysql_real_escape_string($_GET['was_auch_immer'])), ENT_QUOTES)

(egal ob jetzt $_GET $_POST $_SERVER $_COOKIE oder was auch immer)

-> das scheint soweit erstmal zu funktionieren .. wenn man iwas in der art versucht: <script>ach ich bin so böse</script> bleibt nur ach ich bin so böse übrig und es kann, wenn ich das bis hierhin richtig sehe, kein schadcode ausgeführt werden.
mysql abfragen funktionieren auch fehlerlos damit.

meine fragen:
reicht der obige ansatz was sql injections und xss angeht, wenn ich das konsequent bei jeder möglichen user - eingabe, die in irgendeiner form ausgeführt / ausgegeben werden könnte, anwende oder gibt es weitere maßnahmen, die ich ergreifen muss um sql inj und xss weitgehend unmöglich zu machen ?
- muss ich vor ausgabe / weiterverarbeitung von daten aus der datenbank nach der abfrage nochmal aus besondere weise behandeln:

htmlentities(strip_tags(mysql_real_escape_string($zeile['was_auch_immer'])), ENT_QUOTES)

oder reicht das, dass ichs vor der abfrage schon entschärft habe und kann das dabei belassen:

$zeile['was_auch_immer']

$zeile stammt aus einer while-schleife, anhand welcher ich die daten aus der datenbank in ein array hole

- eine weitere frage: in meiner config_inc.php datei habe ich die erforderlichen daten für das aufbauen der verbindung zur datenbank stehen, reicht es, dass die datei durch htaccess geschützt ist, oder bedarf es weiterer maßnahmen um es unmöglich zu machen, dass die datei von unbefugten eingesehen wird ?

- desweiteren hab ich gelesen, wenn man die website veröffentlicht sollte man sämtliche fehlermeldungen seitens PHP abschalten, also als weitere generelle sicherheitsmaßnahme

was gibt es noch für sicherheitsaspekte, um die man sich kümmern sollte ?

ich überlege soweit es mir selbst möglich ist sicherheitsprobleme zu beseitigen, die website dann aber nochmal jemanden sozusagen korrerkturlesen zu lassen, da mir die sicherheit halt sehr wichtig ist - sicher ist sicher .. eine idee wieviel geld ich da investieren müsste/sollte ?

 

[Duddle]

AW: PHP MYSQL Sicherheit - Ansätze, Vorschläge, Fragen ...

desweiteren hab ich gelesen, wenn man die website veröffentlicht sollte man sämtliche fehlermeldungen seitens PHP abschalten, also als weitere generelle sicherheitsmaßnahme

Für einen Angreifer sind Informationen über das System wichtig. Je mehr davon einsehbar sind, desto einfacher ist die Suche nach einem Angriffsvektor.
Das ist die Begründung für das Abschalten der Meldungen aus Sicht der Sicherheit.

in meiner config_inc.php datei habe ich die erforderlichen daten für das aufbauen der verbindung zur datenbank stehen, reicht es, dass die datei durch htaccess geschützt ist, oder bedarf es weiterer maßnahmen um es unmöglich zu machen, dass die datei von unbefugten eingesehen wird ?

Im Idealfall liegt diese Datei nicht im nach aussen offenen Ordner (htdocs, usw.), dein include() kann ja auch solche Pfade einlesen (wenn gescheit konfiguriert).
Falls das nicht möglich ist, sind die einzigen Weg auf den Inhalt der Datei a) ein Versagen des PHP-Prozesses (d.h. sie wird nicht ausgewertet und als Klartext übermittelt) oder b) Klartext-Ausgabe seitens eines deiner Scripte oder c) der Zugriff über das Betriebssystem, aber dann ist eh alles zu spät. Nur für Fall a) ist .htaccess hilfreich. Das ist unwahrscheinlich, passiert aber.

bisher habe ich mit htaccess die wichtigen seiten und dateien, die nicht einsehbar und manipulierbar sein sollen, unzugänglich gemacht .. so dass aber trotzdem alle seiten miteinander kommunizieren können und es keine einschränkung in der funktionalität der seite gibt

Das ist der allgemeinere Fall der config_inc.php-Sache. Wenn der Nutzer keinen direkten Zugriff haben soll, ist der einfachste Weg diese Daten nicht in einem Webserver-zugänglichen Ordner zu haben.
Ansonsten verhindert der PHP-Parser wie gesagt sowieso die Einsicht in die Daten, wenn korrekt konfiguriert.

wenn ich das konsequent bei jeder möglichen user - eingabe, die in irgendeiner form ausgeführt / ausgegeben werden könnte, anwende

Das ist der richtige Ansatz: vertraue niemals Nutzereingaben.

SQL-Injections werden durch Prepared Statements verhindert, mysqli bietet dafür prepare() an. Du brauchst dafür keine eigenen Bereinigungsfunktionen.

Ansonsten solltest du dir filter_var() anschauen. Das hat jede Menge vorgefertigte und durchdachte Filter zur Bereinigung von Eingaben.

Du solltest an die Sache Sicherheit mit dem Denken herangehen, dass ohne langjährige Erfahrung du nicht jeden Fall und jeden Angriffsvektor bedacht haben wirst. Deine selbst gebastelten Lösungen verhindern vielleicht 90% (Zitat: "das scheint soweit erstmal zu funktionieren") oder sogar 95%, aber die letzten paar Prozent wirst du stets übersehen. Reiz die Fähigkeiten und Funktionen der Sprache aus bevor du das Rad neu erfindest, in der Regel haben die Entwickler länger und härter drüber nachgedacht.


Duddle

 

[bizzylee]

AW: PHP MYSQL Sicherheit - Ansätze, Vorschläge, Fragen ...

danke, dass du dir zeit genommen hast !

Im Idealfall liegt diese Datei nicht im nach aussen offenen Ordner (htdocs, usw.)

da hab ich 2 fragen. zum einen, könntest du mir ein pfad-struktur-beispielmodell skizzieren und wo du meinst, wo die dateien am besten unterkommen sollten ?

hab die seite momentan testweise shared - hosting - mäßig untergebracht und folgende struktur:

hauptordner/index.php
hauptordner/unterordner/htaccess_geschützte_dateien(bzw. verzeichnis)

und das andere - was meinst du mit gescheit konfiguriert ?

dein include() kann ja auch solche Pfade einlesen (wenn gescheit konfiguriert).

wie würde eine gescheite konfiguration aussehen ?

filter_var() und prepared statements werd ich mir gleich mal anschauen.
prepared statements gehen auch bei mysql oder nur mysqli ?

lieben gruß

 

[Duddle]

AW: PHP MYSQL Sicherheit - Ansätze, Vorschläge, Fragen ...

was meinst du mit gescheit konfiguriert ?

Ignorier die Anmerkung, das gilt in fast allen Fällen sowieso automatisch.

könntest du mir ein pfad-struktur-beispielmodell skizzieren

Wie gesagt, wichtig ist nur, dass sie nicht Welt-lesbar sind. Wenn bspw. der Apache /foo/bar/htdocs/ als Stammverzeichnis nimmt, dann ist alles in /foo/bar/ "sicher", da der Nutzer schlichtweg nicht höher als htdocs/ gehen kann.
Ich sage nicht, dass das ideal ist, aber wenn du rein an Sicherheit denkst, ist das der direkteste Ansatzpunkt.

prepared statements gehen auch bei mysql oder nur mysqli ?

Soweit ich weiß, bieten PDO und erst mysqli das an. Im besten Fall hast du sowieso eine Abstraktionsschicht zwischen deiner Anwendung und der Datenbank und du musst nur das DB-Interface anpassen; ansonsten ist die Umstellung von mysql auf mysqli auch kein großes Unterfang.


Duddle

 

[bizzylee]

AW: PHP MYSQL Sicherheit - Ansätze, Vorschläge, Fragen ...

Wie gesagt, wichtig ist nur, dass sie nicht Welt-lesbar sind. Wenn bspw. der Apache /foo/bar/htdocs/ als Stammverzeichnis nimmt, dann ist alles in /foo/bar/ "sicher", da der Nutzer schlichtweg nicht höher als htdocs/ gehen kann.
Ich sage nicht, dass das ideal ist, aber wenn du rein an Sicherheit denkst, ist das der direkteste Ansatzpunkt.

und dann so ansprechen ?

include('../irgendeine.php');

momentan hab ich die halbfertige website testweise bei nem shared-hoster, das sollte ich, denk ich, nun ändern.
kannst du mir ne empfehlung geben wo ich meinen shop unterbringen könnte ?
1und1 beispielsweise sagt mir nicht so zu, gibt da, wenn ich mich nicht täusche, auch komische limits ( datentransfer und so zeugs .. ) ..
vielen dank !

 

[cythux]

AW: PHP MYSQL Sicherheit - Ansätze, Vorschläge, Fragen ...

Eventuell wäre für Dich HostEurope interessant

 

[bizzylee]

AW: PHP MYSQL Sicherheit - Ansätze, Vorschläge, Fragen ...

danke für den tipp cythux !

ich hab versucht ne säuberungsfunktion zu schreiben, mit der alle $_GET, $_POST, etc. gesäubert werden sollen, aber es funktioniert leider nicht. ich bin auch ( noch ) nicht so gut darin funktionen zu schreiben, muss ich sagen.
hat jemand ne idee wo der ( bzw. die ) fehler ist/sind ?

function cleanArray($array){
    if(is_array($array)){
        foreach($array as $key=>$value){

            $value = str_replace("script","scrip t",$value);
            $value = str_replace("union","uni on",$value);


            $value = htmlentities($value, ENT_QUOTES);

            $value = strip_tags($value);

             if($key == "menge" || $key == "pageid" || $key == "cookiefavid"){ 
                $value = filter_var($value, FILTER_SANITIZE_NUMBER_INT);
                    $value = str_replace("-","",$value);
                    $value = mysql_real_escape_string($value);
                 $value = substr(trim($value),0,100);

              }elseif($key == "searchfield" || $key == "searchfieldbl" || $key == "category" || $key == "subcategory"){
                $value = substr(trim($value),0,100);
                $value = trim(filter_var($value, FILTER_SANITIZE_STRING, FILTER_FLAG_STRIP_LOW)); 
                    $value = mysql_real_escape_string($value);
             } else {
                $value = trim(filter_var($value, FILTER_SANITIZE_STRING, FILTER_FLAG_STRIP_LOW)); 
                                }

            $array[$key] = $value;
                }
        } else {

        return false;
      }
    return $array;
}
cleanArray($_GET);
cleanArray($_POST);
cleanArray($_COOKIE);

vielen dank !

 

[Duddle]

AW: PHP MYSQL Sicherheit - Ansätze, Vorschläge, Fragen ...

aber es funktioniert leider nicht

"Funktioniert nicht" ist keine Fehlerbeschreibung.

Was ist anders als erwartet? Ab welchem Punkt tritt diese Abweichung auf und was sind daher die möglichen Fehlerquellen?


Duddle

 

[dmtw2107]

AW: PHP MYSQL Sicherheit - Ansätze, Vorschläge, Fragen ...

hallo, zum thema empfehlung eines webhosters mal ein kurzer beitrag.

kannst du mir ne empfehlung geben wo ich meinen shop unterbringen könnte ?
1und1 beispielsweise sagt mir nicht so zu, gibt da, wenn ich mich nicht täusche, auch komische limits ( datentransfer und so zeugs .. ) ..
vielen dank !

ich bin seit, weis nicht, so ungefähr 18 jahre bei 1und1 und bin absolut top zu frieden.

es ist zwar nicht egal welchen hoster man nimmt, aber sollte sich im vorfeld klar werden was man hosten will und ob man sich selbst um den host kümmern kann.
das heist, will ich einen shared host, einen virtual host oder einen cloud server, oder aber einen managed server oder einen dedicated server.
das sind dinge die muss man vorher wissen und sich dann auch angebote holen. auch der support sind nicht zu unterschätzen auch evtl. kostenpflichte zusatzkosen oder kostenfreie leistungen müssen vorher geklärt werden.
auch ein upgrade auf eine höhere leistung bei bedarf ist wichtig zu wissen.

zukünftig zu erwartender traffic sind abzuschätzen und somit die vertraglichen punkte zu kennen und dann danach zu suchen. also einfach eine empfehlung ist schwer ohne direkt mehr angaben zu haben.

das zum thema empfehlung.

ich werde mich mit dem thread hier noch ein bischen beschäftigen denn das thema sicherheit ist wichtig, ich benutze einige dinge die angesprochen wurden. werde mal die snipes raussuchen und etwas dazu posten.

bis dahin noch viel spaß und ich bin gespannt welche empfehlungen zum thema sicherheit und hosting noch kommen.

 

[dmtw2107]

AW: PHP MYSQL Sicherheit - Ansätze, Vorschläge, Fragen ...

Wie versprochen mein snipes

function var_param($feld, $default)
{
    global $conn;
    $var[$feld] = $default; $var["get"] = 0; $var["post"] = 0;
    if (isset($_POST[$feld]) && $_POST[$feld] != "")
    {
        $var[$feld] = $_POST[$feld];
    } elseif (isset($_GET[$feld]) && $_GET[$feld] != "")
    {
        $var[$feld] = $_GET[$feld];
    }
    return $var[$feld];
}

Diese Funktion habe ich mal aus einem Lehrbuch für PHP entnommen und verwende diese auch. Durch zusätzliche Prüfungen ob die Variable auch die notwendigen Typ hat, z.B. zahl, text, string, o.a. kann noch weiter an sicherheit gewonnen werden.

benutzt wird das ganze über

$user_name = var_param("user_name", "default_wert");

wobei user_name hier ein beispiel ist.

ich habe sie dann erweitert zu

function var_param($feld, $default)
{
    global $conn;
    $var[$feld] = $default; $var["get"] = 0; $var["post"] = 0;
    if (isset($_POST[$feld]) && $_POST[$feld] != "")
    {
        $var[$feld] = $_POST[$feld];
    } elseif (isset($_GET[$feld]) && $_GET[$feld] != "")
    {
        $var[$feld] = $_GET[$feld];
    }
[U][I]echo "<br>Vorher - ".$feld." :".$var[$feld];
    $var[$feld] = mysqli_real_escape_string($conn, $var[$feld]);
echo "<br>Nachher - ".$feld." :".$var[$feld[/I][/U]];
    return $var[$feld];
}

$conn ist hier die variable der datenbankverbindung.

die funktion kann man auf session und anderes erweitern.

bin auf eure meinungen gespannt, vielleicht auch verbesserungen.

 

[Duddle]

AW: PHP MYSQL Sicherheit - Ansätze, Vorschläge, Fragen ...

$var["get"] = 0; $var["post"] = 0;

hat keine Verwendung.

Globale Variablen sind oft ein Zeichen für schlechtes Design.

Es gibt keinen Grund dafür, die Variable $var als Array zu deklarieren.

Die Funktion ist nicht aussagekräftig benannt.


Mir fällt auch spontan kein Fall ein, in dem ich so eine Funktion benötigen würde. Ein Default-Wert kann bei der Deklaration mitgegeben werden. Und wenn ich mir je unsicher bin, ob ein Wert aus $_GET oder aus $_POST kommt, habe ich einen viel tieferen Fehler gemacht.


Duddle

 

[dmtw2107]

AW: PHP MYSQL Sicherheit - Ansätze, Vorschläge, Fragen ...

hallo und vielen dank für ihre interessante und hilfreiche antwort.

bei dieser funktion ging es weniger darum um zu prüfen wo die variablen herkommen, als sie aus get und post zu holen und zu prüfen.

man kann das ganze ja auch session umschreiben, so mach ich das zu mindest.

ok danke für den hinweis mit $var[...].

für mich ist die funktion nutzbringend um werte varieblen zu zuweisen und gleich zu prüfen.

Globale Variablen sind oft ein Zeichen für schlechtes Design.

die aussage versteh ich nicht, wäre ihnen dankbar wenn sie darauf etwas genauer eingehen.

 

[Duddle]

AW: PHP MYSQL Sicherheit - Ansätze, Vorschläge, Fragen ...

http://c2.com/cgi/wiki?GlobalVariablesAreBad


Duddle

 

[dmtw2107]

AW: PHP MYSQL Sicherheit - Ansätze, Vorschläge, Fragen ...

danke für die url werde ich mal durcharbeiten und ggf. einarbeiten.

 

[afr0kalypse]

AW: PHP MYSQL Sicherheit - Ansätze, Vorschläge, Fragen ...

hab gerade nicht so viel zeit deshalb erstmal nur nen link:
http://en.wikibooks.org/wiki/Web_Application_Security_Guide

einige wichtige punkte

 

[msa1989]

AW: PHP MYSQL Sicherheit - Ansätze, Vorschläge, Fragen ...

Hallo Bizzylee,

bezüglich Sicherheit habe ich eine Idee für dich. Ich benenne wichtige Dateien, wie deine "config_inc.php" z.B. mit "config.inc". In meiner .htaccess steht dann folgendes:

<FilesMatch "(\.(bak|config|inc)|~)$">
  Order allow,deny
  Deny from all
  Satisfy All
</FilesMatch>

Das verhindert dann generell den Zugriff auf solche Dateien von außen. Eventuell sind ja diese Zeilen für dich auch relevant

 

[Curanai]

AW: PHP MYSQL Sicherheit - Ansätze, Vorschläge, Fragen ...

Moinsen,

vorab: Ich bin seit 1999 u. a. bei 1&1 (Server; root wie managed) ... kann auch gar nicht meckern. Klar stolpert mal das eine oder andere Vorhaben, aber richtig verbockt wurde in der Zeit sehr wenig. Bei Hoster-Wahl gibt es immer einiges zu beachten: "wen will ich erreichen" (wenn Du für China was anbietest, brauchst in GER keinen Hoster etc.), Redundanz und "fallback" bei Ausfall, Erreichbarkeit, Backup, Support (gern auch eine kostenlose Hotline!), Premium-Service (wenn echt mal Alarm ist!) usw.

Das Thema Sicherheit ... hierzu gibt es wunderbare Bücher, die Dir das sehr detailliert aufzeigen. Auch in diesem Thread kommt wieder viel "aus unserer Erfahrung", also stinke ich ein wenig darüber mit: mysql_(real_)escape_string und htmlentites() ist zu wenig! Gut, dass hier schon nachgelegt wurde ...

Fakt ist aber: Eine "config.inc.php" muss nicht mit einer weiteren .htaccess "versiegelt" werden - diese rennt eh aufgrund Endung durch den Interpreter (PHP). Eine htaccess macht nur dann - IMO - Sinn, wenn das Teil "config.inc" einfach nur heißt - eine htaccess wäre dann:

<Files ~ "\.inc$">
Order allow, deny
Deny from all
</Files>

Hüte Dich in der "config.inc.php" vor "god modes" (bspw. deplatzierter "autoload"-Call, wenn was fehlt - brich lieber ab!), Rückgabewerten (via return) o. ä. Konstanten mit hochindividuellen Namen "fits it".

Und msa1989 muss ich leider sagen: Backup-Dateien haben auf einem produktiven Webserver GAR NICHTS verloren!!! (ich komme drauf wegen der Berücksichtigung von "bak" in Deiner htaccess). Unter Umständen machst Du das "für den Fall, dass mal was durchrutscht", aber das darf schon nicht ...

Ist das Dein eigener geschriebener Shop oder verwendest Du einen Drittanbieter? Ist mir nicht ganz klar ... bedenke, dass die Administrationsoberflächen haben (gilt für Foren, CMS etc. genauso). Und darin sind wieder Plugins ... diese sind angreifbar, wenn nicht "versiegelt" (erinnere mich immer nur ungern an den JCE-Editor von Joomla ... *kotz*).

Als Angreifer schaue ich mir zuerst eine "robots.txt" an - hier geben die Leute gern an, was Suchmaschinen nicht spidern sollen ...

Directory-Listing unbedingt aus ...

Kommentare, die Usernamen oder Pfadangaben im Quellcode enthalten, unbedingt raus ...

Ausgelieferten Header an den Client runterkürzen: Verzeichte auf Angaben zur PHP-Version, Apache usw. ... so wenig Angriffsfläche wie möglich anbieten. Dazu gehört: phpinfo() gehört nicht auf ein Produktivsystem - egal wo!

Konform gehe ich auch nicht mit "wenn es in dem Verzeichnis 'drüber' liegt, kommt man da nicht hin" - regulär nicht, mit einer Webshell, die per Bildupload hochgeschickt wird, definitiv! Ich kann nicht schreiben - aber lesen (und zwar ganz runter!; Linux).

Was noch? Cookie-Poisoning, -Stealing, Session-Capturing ... verwende niemals nicht für Deine Session oder Cookies das Standardverzeichnis ... schon gar nicht bei "sharedHosting" oder "Webpaketen" ... 1x am Tag spätestens alle Sitzungen für ungültig erklären. Cookies behandeln wie Eingabedaten vom User ... = hochgiftig!

Vor Speichern Sonderzeichen immer maskieren - was passiert bei Dir in folgendem Szenario? = javascript ... eine andere Schreibweise ... IE führte das bspw. mal direkt in den Ursprung übersetzt aus ... berücksichtige also mit hexedezimal kodierte Tabulatoren, Newlines, Nullbytes und Blanks etc. Denn: Aus "<" mache ich auch "< oder "< ... ein Filter ist also nicht permissiv, sondern sollte restriktiv agieren! Heißt: Nicht säubern! Ablehnen!!! (ja, hier greift das Minimum aus htmlentities() - keine Bange)

Hässlich wird es in der Kombination aus XSS, CSRF und DOM-Manipulation - da sind die Möglichkeiten irgendwie "grenzenlos".

Für Deine App gilt, nimm das an, was Du erwartest und versuche vorab mit Cast-Operatoren zu hantieren. Gib nie irgendwas ungeprüft in die Datenbank und diese sollte mit "prepared statements" arbeiten, damit keine ganzen SQL-Queries abgegeben werden - sondern nur noch die überarbeiteten Daten (maskiert usw.).

Nur bedenke: Es gibt keine 100%ige Sicherheit - das ist Utopia und sollte Dir auch niemand verkaufen. Du kannst vieles unternehmen, um es einem Angreifer schwerer zu machen ... und je mehr Du unternimmst, umso größer die Chance, dass er aufgibt ...

Finaler Tipp: Alles, was Fehler auf Deinem Projekt produziert, kommt direkt per E-Mail mit $_POST, $_GET, IP, Query(-Versuch) usw. zu Dir ...

Sorry für den Umfang, aber das Thema "Sicherheit" ist eben sehr umfangreich, wobei hier längst nicht alles erwähnt ist.

Viel Erfolg und ein schönes Wochenende.

 

[Curanai]

AW: PHP MYSQL Sicherheit - Ansätze, Vorschläge, Fragen ...

Aus "<" mache ich auch "< oder "< ... ein Filter ist ...

Und da hast Du sofort das Beispiel ... dort stand nämlich der hexCode für dieses Zeichen!!