Sind Passwörter im PHP-Script sicher?



  • Hi,

    wenn ich meine MySQL-Zugangsdaten im selben PHP-Script abspeichere, das vom Browser aufgerufen wird, kann doch ein Betrachter, der keinen FTP-Zugang auf den Server hat, da nicht ran, oder?

    Also soweit ich weiß, erhält der Browser ja durch den Server eine daraus erstellte HTML Datei, auch wenn er eine PHP-Datei aufruft.
    Stutzig macht mich nur, weil sie mit *.php Kennung in der Adressliste aufgerufen wird.
    Wenn er PHP-Parser gerade mal nicht aktiv ist, kann es dann dann passieren, dass der Browser die unbearbeite Quelltextdatei erhält?

    thx,
    Sepp



  • Hi,
    also PHP-Dateien sind (an sich) absolut sicher... (sonst währe auch diese Forum z.B. unsicher - auch beim phpBB stehen die MySqlPasswörter im phpCode...)

    Zu beachten währen dann nur noch Möglichkeiten des Codeinsertings oder Sql-Injections...

    MfG

    Alexander Sulfrian



  • Hi,

    @Alexander Sulfrian: Kannst du mir mal bitte kurz erklären, was Codeinsertings sind? Google war wieder mal kaum hilfreich.

    Und ... Thx für die Erwähnung der Sql-Injections ... da muss ich morgen gleich n paar Codes umarbeiten 😃

    M.T.



  • @Sepp:
    wenn PHP nicht läuft, wirst du 100% einen Fehler vom Webserver bekommen. Ich hab das noch nie gehabt, ich hab noch nie gesehen, dass "php" down ist und der apache Server (bei Windows Server weiß man nie) mir den PHP Code schreibt.

    Wenn du über _POST die Passwörter kriegst, kann ein dritter sie bekommen, da hilft nur eine ssl verbdindung, also wenn dein Server https hat, dann das benutzen.

    Also soweit ich weiß, erhält der Browser ja durch den Server eine daraus erstellte HTML Datei, auch wenn er eine PHP-Datei aufruft.

    Ob die datei index.php oder index,html oder index.pl oder index.wasweissich im Webserver heißt, ist dem Webbrowser völlig egal, wichtig sind für den Browser, die vom Webserver gesendeten Headers und Datei-Daten, also wird der Webbrowser unabhängig von der Endung der Datei den Inhalt in den cache speichern. Der Webserver ist daüfür verantwortlich die Headers zu setzen oder die Skriptsrpache wie PHP oder Perl.

    @manu: ich glaube, dass er mit Codeinserts die Funktion include meint. Oder hab ich das falsch verstanden?



  • Hallo!

    supertux schrieb:

    ...Ob die datei index.php oder index,html oder index.pl oder index.wasweissich im Webserver heißt, ist dem Webbrowser völlig egal, ...

    Definitiv falsch.

    Denn: Was denkst du, warum Confixx o.ä. programme alle ihre Includes mit config.inc.php oder definitions.inc.php oder functions.inc.php etc nennen?

    Wenn es so wäre, dass es egal ist, wie die datei heißt, dann könnte man diese ja auch nur config.inc nennen. Dies ist aber definitiv NICHT sicher, denn sobald die Datei nicht mehr so heißt, wie der Apache angewiesen wurde, sie zu interpretieren, kannst du die seite runterladen (auch per http) und du siehst den Code & die passwörter.

    Der PHP - Parser interpretiert nur die dateien mit der endung .php - .phpX (je nachdem was im apache alles eingestellt ist)

    Ansonsten würde er ja auch .exe oder .zip parsen wollen 🙄

    Also: der PHP - Parser parst nur die Dateien, die mit .php oder phpX (X eine version z.b. 3 oder 4) enden.

    Deshalb auch immer: Include - Dateien am besten auch mit .php enden lassen, denn dann kann diese auch niemand einsehen, sofern diese passwörter oder wichtige funktionen enthalten.

    Solange das beachtet wird, sollten Passwörter im PHP - Code keine Sicherheitslücke sein, wie gesagt, so gut wie alle software (sogar confixx oder pdadmin oder ähnliches) haben die passwörter im code (bzw. in definitionsdateien a la config.inc.php)

    Liebe grüsse 😉

    P.S.: für all diejenigen, die sich gerade fragen warum ich andauernd auf Confixx zurückgreife: Nein, ich kriege dafür kein geld 😃 (leider)
    Ich arbeite nur grad damit, und beschäftige mich intensiver mit dem code. Ausserdem ist es eines der grösseren programme, was ja nun auch sicherheisbasiert arbeiten sollte (Betonung liegt auf sollte). Deshalb dies als beispiel...



  • defintiv eine falsche Ausssage von beiden.

    Ob eine Dateiext php oder was auch immer ist stellt man im Apche bzw. php.ini ein.
    Somit wäre es theoretisch egal weil man da auch alles *.html *.htm u.s.w durch php schicken kann.

    Die Passwörter sind nicht sicher wenn sie in einem PHP-Script sind.
    Wenn die Konfig des Server geändert wird (Fehler und passiert eigentlich oft) und das Script wird nicht mehr durch php geparsed dann wird das Script ausgegeben und der User sieht den Code. Warum es includes gibt: Genau aus diesem Grund.
    Der User kann damit lediglich den Includebefehl sehen und nicht den Inhalt der Includedatei.
    Diese sollte immer in einen eigenen Ordner sein den man nochmals mit htaccess absichert.
    Erst dann sind die Passwörter fast sicher.



  • Unix-Tom schrieb:

    Diese sollte immer in einen eigenen Ordner sein den man nochmals mit htaccess absichert.
    Erst dann sind die Passwörter fast sicher.

    jo.
    und vielleicht kann man ja auch die passwortdatei in ein verzeichnis stecken, das nicht unter DOCUMENT_ROOT steht.
    ich hab mir angewöhnt, die passwortdatei woanders hinzustecken als den ganzen rest, nachdem ich mal voller stolz die dateien gepackt und jemandem gegeben habe und erst nachher dran gedacht hatte, daß das passwort drin war. und ich gebe eigentlich gerne source-code weiter. jedesmal vor dem packen das passwort unenntlich zu machen, macht keinen spaß.



  • Unix-Tom schrieb:

    defintiv eine falsche Ausssage von beiden.

    Wieso auch von mir? Wo habe ich was falsches gesagt?

    mrchat schrieb:

    ...wie der Apache angewiesen wurde...

    Das ist doch was ich gesagt habe, apache != webbrowser und ich habe extra so einen Test gemacht, indem ich meinen apache dazu gebracht habe, die html Dateien durch php interpretiert werden und dann wurden <?php ... ?> Tags innerhalb der HTML Datei auch von PHP ausewertet. Und wie Tom schon sagte, das liegt an der Konfiguration in php.ini und in httpd.conf und darauf kommt es an. Für den Webbrowser ist eigentlich egal, schließlich kannst du auch php Datei als Bilder darstellen und der Webbrowser öffnet sie auch als Bild, aber nur wegen header("Content-Type: image/png") und weil sie php heißen.

    volkard schrieb:

    Unix-Tom schrieb:

    Diese sollte immer in einen eigenen Ordner sein den man nochmals mit htaccess absichert.
    Erst dann sind die Passwörter fast sicher.

    jo.
    und vielleicht kann man ja auch die passwortdatei in ein verzeichnis stecken, das nicht unter DOCUMENT_ROOT steht.

    ja, ich mach meinstens dasselbe



  • Ich speichere Passwörter meistens in einen mit .htaccess-geschützten Ordner in *.inc Dateien, die bei vielen Hostern in der webserver-config gesperrt sind und somit nicht downloadbar sind.



  • Ok, danke an alle.

    Ich hab das schon geahnt, dass ein falsch laufender PHP-Parser ein Problem darstellen könnte, obwohl das sicherlich selten vorkommen sollte.
    Hauptsache, ein Betrachter kann bei richtig laufenden Webserver nichts manipulieren.

    Das mit den .htaccess Includes klingt schon ganz vertrauenswürdig.
    Obwohl natürlich dann auch hier der Server falsch konfiguriert sein könnte und .htacess nicht auswertet 😉

    Aber ist das richtig, das die Übertragung durch "post" nicht sicher ist?
    Ich denke, die läuft über StdIO, also Serverintern 😕



  • Ohne SSL werden die Daten eben unverschlüsselt vom Client zum Server übertragen (egal, ob GET oder POST - bei POST sieht man sie nur nicht in der URL) 😉



  • SeppSchrot schrieb:

    Ok, danke an alle.

    Aber ist das richtig, das die Übertragung durch "post" nicht sicher ist?
    Ich denke, die läuft über StdIO, also Serverintern 😕

    Nein, der Computer des Betrachters schickt per POST die Daten an den Webserver, also die Daten gehen dann durchs Netz, das ist die Gefahr, jemand stellt sich zwischen dir und dem Server und empfängt die Daten, bevor die Server sie bekommen hab.

    Standardmässig ist die Methode GET voreingestellt. Es ist sinvoller POST zu benutzen, denn wenn man man ohne method oder mit GET ein Formular ausstattet, dann werden die Daten an der URL angehängt und das kann unter Umständen sehr lästig werden (für den Programmier). Man kann nicht in 5 Sätzen den Unterschied zwischen POST und GET erklären, mehr zu diesem Thema findet man unter http://www.cs.tut.fi/~jkorpela/forms/methods.html

    Ohne POST werden die Daten per GET geschickt und an der URL angehängt.

    SSL (Secure Socket Layer) ist dann die Lösung, weil der Server und der Benutzer tauschen Daten verschlüsselt, also ein dritter kann sie nicht verstehen, obwohl sie vor dem Server bekommen hat. Deshalb rate ich immer https zu benutzen, wenn dein Host Server das unterstützt und Passwörter geschickt werden müssen 🙂



  • Der Unterschied zw. POST und GET ist.

    Der Client öffnet einen Socket auf Port 80 und sendet bei POST vereinfacht

    www.c-plusplus.net/forum

    POST /forum HTTP/1.0\nHost: www.c-plusplus.net:80\n\nMYPASSWORD=passwort\n\n

    Bei GET wenn in URL www.c-plusplus.net/forum?MYPASSWORD=passwort

    GET /forum?MYPASSWORD=passwort HTTP/1.0\nHost: www.c-plusplus.net:80\n\n

    Das ist der einzige Unterschied.
    Beides geht aber immer vom Client zum Server da HTTP ein Verbindungsloses Protokoll ist sollange die Verbindung nicht aufrechtz erhalten wird mit speziellen HTML-Commandos.

    Client senden an Server und server Antwortet auf der selben Socketverbindung. Dann wird der Socket geschlossen.



  • also passwörter usw. in .php dateien sind schon relativ sicher (hat schon einer gesagt hier) es muss schon ein übler bug im webserver sein, wenn er die .php-dateien unverändert ausliefert. selbst wenn die php-engine kaputt ist sieht man nix. bestenfalls stürzt der webserver ab. an die php-sources im klartext kommt man nur, wenn man nicht über den webserver geht (z.b. über ftp etc.)



  • supertux schrieb:

    @Sepp:
    wenn PHP nicht läuft, wirst du 100% einen Fehler vom Webserver bekommen. Ich hab das noch nie gehabt, ich hab noch nie gesehen, dass "php" down ist und der apache Server (bei Windows Server weiß man nie) mir den PHP Code schreibt.

    Ich schon, dummerweise sogar von meiner Seite :o
    Was dann hilft ist Passwörter in einer Datei speichern die includet wird und diese eventuell noch da speichern wo niemand mit dem Browser hinkommt.



  • hallo

    kleine nebengeschichte:
    schön ist es, wenn auf einem server eine umstellung erfolgte, und (so habe ich es mal beim surfen erlebt und mir den fall nachrecherchiert) php4 auf php umgestellt wurde in der apache.conf.

    dann kann man ohne probleme alle .php4 skripte runterholen, denn: der apache nimmt dann nur das suffix php, und alles andere wird als txt interpretiert, und je nach browsereinstellung zum download angeboten, oder geöffnet.
    herrlich. vor allem, wenn dann keine indexe in den ordnern liegen, da liegt einem dann die welt offen ...
    bekommt man solche umstellungen zu spät mit, hat man pech. klar, kein richtiger webadmin würde php und php4 nicht beide eingestellt lassen. aber wie gesagt, schon erlebt.
    was macht man in einem solchen fall? den betroffenen 'snell' mal eine email schreiben. (auch wenn man sie nicht kennt)



  • net schrieb:

    also passwörter usw. in .php dateien sind schon relativ sicher (hat schon einer gesagt hier) es muss schon ein übler bug im webserver sein, wenn er die .php-dateien unverändert ausliefert. selbst wenn die php-engine kaputt ist sieht man nix. bestenfalls stürzt der webserver ab. an die php-sources im klartext kommt man nur, wenn man nicht über den webserver geht (z.b. über ftp etc.)

    das ist eine falsche aussage.

    es muss kein Bug sein. schon wenn der Provider ein Update einspielt kann es dazu kommen das PHP-Dateien nicht als das interpretiert werden waqs sie sind sondern als Text-File ausgegeben werden.
    Eine Teilsicherheit bekommt mann/frau nur wenn man es so macht wie ich oben beschrieben habe.



  • Anstelle zu diskutieren, wie ihr möglichst riskant irgend wo Passwörter rumfliegen lasst, benutzt doch einfach Hashes und ihr seid schon mal viel sicherer, PHP hat doch AFAIK sogar Funktionen für SHA1 und MD5 integriert. Tut euch den gefallen, dann habt ihr auch nicht so einfach ein blaues Auge (oder gar einen total Schaden) wenn irgend wo ein kleiner Fehler ist und auf einmal jemand per SQL-Injection oä. an die Passwörter kommt, gerade wenn es nicht nur um eure Passwörter geht.

    Man muss ja nicht immer versuchen mit minimaler Sicherheit durchzukommen, vorallem wenn ein höherer Sicherheitsstandard ohne große Mehrkosten zu erreichen ist.

    @volkard
    *fg*
    aber warum trennst du Entwicklung und Anwendung nicht? Integrierst du auch Änderungen sofort in den aktiven Code?



  • @kingruedi: Ich glaube es geht um die Passwörter des (R)DBMS. Die kann man IMHO leider nicht hashen, ansonsten natürlich ACK!

    Die beste Lösung wurde doch schon von volkard und Unix-Tom gesagt: Legt die Passwörter nicht im Document-Root/htdocs ab. Dann kann man auch ruhig schlafen, wenn mal der PHP-Parser ausfällt. 😉

    Gruss



  • und was mach ich, wenn ich einen anbieter habe (sql und php) aber nur auf die root kann, und von da an aufwärts. wo soll ich in so einem fall meine datei mit den passwörtern ablegen?


Log in to reply