PHP/MySQL Security-Frage

[Rickard]

Guten Abend TPler,
da ich jetzt am Ende meines Projektes bin möchte ich gerne wissen ob jemand ein paar Tipps in Bezug auf PHP und SQL Sicherheit hat?
Folgende Funktionen sind enthalten:
- Login-System
- Profil bearbeiten
- Artikel anzeigen/kaufen (ohne Warenkorb-Funktion)
Alle möglichen Daten werden in eine Datenbank (SQL) geschrieben.

Folgende Sicherheitsaspekte hab ich bereits vorgenommen:
- Alle Eingaben die vom Benutzer kommen und irgendwie mit SQL verarbeitet werden habe ich mit mysql_real_escape_string(xxx) abgesichert.
- Das Passwort vom Login-System wird mit sha1() "verschlüsselt"

Was ist noch wichtig? Mir fällt leider nichts ein.

Das ganze wäre mir sehr wichtig, später würde ich auch jemanden ein paar Euro zahlen der die Seite mal auf Sicherheit "testet".
Hoffe aber das auch so gute Tipps kommen, auf jeden Fall schonmal vielen Dank.

Rickard

[Bruecksen]

schau mal in die angepinnten Threads, da findest du diesen mit folgendem für dich interessanten Punkt:
Sichere Webanwendungen programmieren

viele Grüße
Matthias

[Rickard]

Ich bin ja auch blind ne -.-
danke für den hinweis! werde mir das auf jeden fall mal studieren, kann mich ja danach nochmal melden

Danke nochmal

[Rickard]

so wie versprochen meld ich mich nochma zurück

hab den ersten artikel mal durchgelesen und teilweise überflogen...
jetzt hab ich ne frage... ich hab keine php.ini...
hab ja alles selbstprogrammiert... also meine seiten greifen halt alle per include auf die "include.php" zu (diese befindet sich in einem per htaccess geschützten verzeichniss)...

sonst hab ich eigentlich nichts... also keine php.ini
wofür brauche ich diese? und wo bzw. wie binde ich diese ein?

vielen dank
Rickard

[fuchzga]

Kannst du uns mal einen Hinweis geben, auf was (welcher Artikel/Link) du dich beziehst? Was soll denn mit der php.ini sein?

Hast du bei einem Provider Webspace gemietet? Dann wirst du keinen Zugriff auf die php.ini haben. Man kann allerdings einige PHP-Parameter in der .htaccess konfigurieren. Das ist aber auch wieder abhängig davon, was der Provider zulässt.

[Rickard]

Hallo
Sorry meinte diesen Artikel: http://www.heise.de/security/Sicherh...rtikel/84149/4 (hab mal zur letzten Seite verlinkt) dort stehen halt die wichtigsten Sicherheitsoptionen der php.ini.
Habe einen gemieteten Webspace, dachte mir schon dass nur der Provider diese datei hat weil ich die bei mir nur einmal lokal gesehen hab, also lokaler server.

Ich werd wohl erstmal weiterlesen, melde mich dann nochmal

[Rickard]

So habe mal die Sicherheitsoptionen bei mir getestet.
Und zwar:

echo "<br>register_globals:".ini_get('register_globals');
echo "<br>allow_url_fopen:".ini_get('allow_url_fopen');
echo "<br>safe-mode:".ini_get('safe-mode'); #Auch als safe_mode probiert
echo "<br>display_errors:".ini_get('display_errors');
echo "<br>magic_quotes_gpc:".ini_get('magic_quotes_gpc'); 

Gibt folgendes aus:
register_globals:1
allow_url_fopen:1
safe-mode:
display_errors:1
magic_quotes_gpc:

Nachdem ich eine htaccess angelegt habe mit folgenden Werten (empfohlen im genannten Heise-Artikel):
php_flag register_globals 0
php_flag allow_url_fopen 0
php_flag safe-mode 1
php_flag display_errors 0
php_flag magic_quotes_gpc 1

Gibt er folgendes aus:
register_globals:0
allow_url_fopen:1
safe-mode:
display_errors:0
magic_quotes_gpc:1

Fazit: Safe-Mode kann ich nicht auslesen (wohl falscher code). Und allow_url_fopen kann ich nicht ändern -.-

Aber wieso hat mein Provider (All-inkl.com) denn register_globals auf ON?

[phpBuddy]

Aber wieso hat mein Provider (All-inkl.com) denn register_globals auf ON?

Weil all-inkl ein Massenhoster ist und somit so wenige Steine wie irgend möglich den Kunden in den Weg legen möchte. Viele CMS, zumal ältere Versionen, setzen diese Einstellung so voraus. Werden diese vielen Kunden dadurch beschnitten, suchen sie sich eben einen anderen Anbieter.

Ansonsten ist auch logisch, dass Du nicht jede Einstellung frei ändern kannst, weil es dieser Einstellung sonst schlicht den Sinn nehmen würde. Zum Thema Sicherheit bietet sich diese Dokumentation auf PHP.net an. Was die php.ini angeht, lohnt ein Blick auf Konfigurationsänderungen und die Liste der Werte, die man ändern kann - oder eben auch nicht.

[Rickard]

OK,
habe meinen Server nun wie folgt per htacces abgesichert:
php_flag register_globals 0
php_flag display_errors 0
php_flag magic_quotes_gpc 1

All-inkl hat aber auch zb. die open_basedir schon automatisch auf den pfad des kunden gesetzt. Das habe ich in phpinfo() nachgelesen.

Ich denke mal von der Sicherheit dürfte es (erstmal) reichen.

Ich danke euch vielmals!

Rickard

[Master_T2]

An XSS-Angriffe und SQL-Injection gedacht?

[Rickard]

An XSS-Angriffe und SQL-Injection gedacht?

Ja zumindest das was ich zur Zeit weiß...
Habe folgendes:
Gegen SQL-Injections:
- Generell alle änderbaren Werte die per POST oder GET (zb. ids) übergeben werden habe ich mit mysql_real_escape_string(xxx) escapet (also eigentlich alles was irgendwo in einer sql abfrage landet)
- Sicherheitsoption magic_quotes_gpc = 1 gesetzt (wobei das ja eigentlich das gleiche wie oben ist)

Ansonsten:
Weitere Sicherheitsoptionen
php_flag register_globals 0
php_flag display_errors 0
php_flag magic_quotes_gpc 1
open_basedir auf mein Verzeichnis (Vom Provider bereits so eingestellt)
disable_functions (Auch vom Provider so eingestellt):
exec,
system,
passthru,
shell_exec,
popen,
escapeshellcmd,
proc_open,
proc_nice

- Login Passwörter per sha1 "verschlüsselt"
- Die include-datei (die unter anderem ja die db-verbindungsdaten enthält) noch mit einem verzeichnissschutz (htacces) versehen

Mehr fällt mir jetzt eigentlich nicht ein.
Wüsstest du noch irgendwas spezielles was gefährlich sein könnte? hab jetzt eigentlich alle Artikel durch und alle Sicherheitstipps beachtet/angewendet.

Viele Dank.

Rickard

[phpBuddy]

Gegen SQL-Injections:
- Generell alle änderbaren Werte die per POST oder GET (zb. ids) übergeben werden habe ich mit mysql_real_escape_string(xxx) escapet (also eigentlich alles was irgendwo in einer sql abfrage landet)
- Sicherheitsoption magic_quotes_gpc = 1 gesetzt (wobei das ja eigentlich das gleiche wie oben ist)

Hallo Rickard,

magic_quotes_gpc schaltet man normalerweise aus, weil das nur Streß macht und nicht wirklich so effektiv ist, wie man denkt.
Desweiteren ist magic_quotes_gpc keineswegs das Gleiche wie mysql_real_escape_string. Wenn man es mit einer PHP Funktion vergleichen könnte, dann wohl am ehesten mit addslashes. Wieso man sich aber nicht auf addslashes verlassen sollte um Injection abzuwehren, kannst Du hier nachlesen.

Ansonsten wäre noch anzumerken, dass das Programmieren von sicheren Anwendungen ein Konzept ist, dass bereits bei der Planung anfängt und stark vom Skill des Programmierers abhängig ist. Wie soll ein Programmierer auch Attacken abwehren können, wenn er nicht weiß wie diese ausgeführt werden, oder im schlimmsten Fall, nicht mal weiß das es diese oder jene Attacke überhaupt gibt.

[Rickard]

Hey Rizzo,
ja da hast du wohl recht!
Also ich habe schon recht viel wert auf Sicherheit gelegt... wusste ja auch dass es diverse attacken gibt.
Nur konnte ich natürlich nur das in punkto sicherheit anwenden was ich auch weiß und das sind ja im groben die sachen vom letzten post.
Das Problem bei mir wegen "Skill des Programmierers" ist einfach dass ich sozusagen ein Quereinsteiger bin, ich habe PHP gelernt wie ich damals HTML gelernt hab, durch ausprobieren, wobei das bei HTML natürlich noch krasser war da ich ja garnix wusste^^ aber das ist was anderes...
Will halt sagen auch wenn ich ne komplette Seite, bzw. schon mehrere programmiert habe kenn ich noch lange nicht alles von php.
Ich kenne halt das was ich brauche (so sammelt sich nach und nach allerdings auch sehr viel )
War ja eher Zufall mit PHP, wollte halt öfters nen fertiges php script anpassen und wusste so paar sachen über php ... nach und nach immer mehr und irgendwann wollte ich das richtig lernen...
Ich wollte eigentlich ein richtiges Seminar besuchen, davon wurde mir aber abgeraten. Das einzige was ich in Richtung Seminar gemacht hab ist eine DVD "PHP5 / MySQL5 Seminar". Allerdings habe ich durch diese DVD leider nicht viel dazugelernt weil ich das meiste doch schon so wusste, trotzdem empfehlenswert die dvd.

Um auf das eigentliche Thema zurück zu kommen.
Solange mich die Option "magic_quotes_gpc" nicht stört kann ich sie ja lassen...
werde das aber im hinterkopf behalten dass sie nicht so wichtig ist

Also im Endeffekt muss ich schon sagen dass Sicherheit in der Programmierung doch ein großes und vorallem kompliziertes thema ist... weil wie du schon sagtest, wie soll man etwas abwehren was man nicht kennt.
Gibt es eigentlich nicht ein "Rundum-AntiHacker-LogTool"?
was halt alles loggt was nicht sein sollte, weil so wüsste man wenigstens dass was nicht stimmt und sieht evtl. wo die sicherheitslücke ist und wie der hacker diese ausgenutzt hat.
Ich erinnere mich zb. an meine anfangszeiten mit phpkit, da gab es so ein tool (also ein script zum einbauen), das wehrte zum einen ab und zum anderen loggte das auch jeden hack-versuch

Wüsstest du vllt. ob oder wo es sowas gibt?

Rickard

[Rickard]

Sorry muss mich doch noch einmal melden, das Thema lässt mich irgendwie nicht mehr los... Hab ganz gute XSS-Beispiele gefunden, nun hab ich einfach den ersten code in ein input feld bei mir eingegen (Code etwa so: <input type=text name=test value='{$_POST['test']}'>) gesichert habe ich den Input ja erst wenn er irgendwie in SQL vorkommen soll...
Nun war ich doch recht erschrocken, teste den Code also von der Seite und was sehe ich tatsächlich die Javascript Textbox!

So nun hab ich mir so meine Gedanken gemacht... Ich könnte ja eine Blacklist machen, also bei jedem Input zb > mit &gt; ersetzen, würde mich absichern und den Text optisch so lassen.
Lieber wäre mir aber eine Whitelist, also nur das lassen was ok ist (a-z usw...) Problem dann würde das Zeichen ja zb > komplett wegfallen, also kommt das auch nicht in frage.
Nun bin ich auf die Funktion htmlentities() gestossen, verhindert zumindest in diesem Beispiel das aufrufen von JS.
Aber wie sicher ist diese Funktion? Gibt es noch mehr? oder bessere?

Hab übrigends magic_quotes_gpc doch ausgeschaltet, weil das ja dann auch als input value escapet wird, das ist natürlich doof wenn ein user zb. einen text schreiben will, drückt vorschau und dann sowas...

Und kann man das nicht irgendwie globalisieren? dass alle POST und GET Werte erst durch htmlentities müssen?

EDIT:
Hab mich jetzt für folgende Variante entschieden:

function post($wert) {return htmlentities($_POST[$wert]);}
function get($wert) {return htmlentities($_GET[$wert]);}
function sql($wert) {return mysql_real_escape_string($wert);} 

Ausgegeben wird das dann halt so:

$valtest = post(test_me);
echo "<form method=post>
<input type=text name=test_me value='$valtest'>
<input type=submit></form>"; 

[phpBuddy]

Was ein Benutzer schickt ist, etwas krass ausgedrückt, vollkommen egal. Der kann jeden x-beliebigen Code schicken den er will. Wichtig sind im Prinzip nur 2 Dinge (ebenfalls wieder etwas übertrieben ausgedrückt):
1) Daten vor dem abspeichern escapen
2) jede Art von Benutzereingabe wird bei der Ausgabe mit htmlspecialchars entschärft