Aanroepen db met php. Hide username password

[Verwijderd]

Goedendag,

Ik heb een Joomla website met wat custom php scripts, waarmee ik data in de mysql databse wegschrijf en/of ophaal.

Deze php scripts heb ik in de root van de site staan, in een folder "Scripts"

De connectie met de database maak ik op volgende manier:

$host = "localhost";
$user = "user";
$pass = "pass";
$dbname = "database";
$connection = mysql_connect($host,$user,$pass) or die (mysql_errno().": ".mysql_error()."<BR>");
mysql_select_db($dbname);

Ik vraag mij af in hoeverre dit safe is en of er betere manieren zijn om je inloggegevens op je site op te slaan.

Met vr gr
Mesjoggah

[Wiethoofd]

Zet ze buiten je root en include de file als er een database connectie nodig is?

[alex3305]

Wiethoofd schreef op woensdag 14 december 2011 @ 20:48:
Zet ze buiten je root en include de file als er een database connectie nodig is?

Alhoewel de TS wat vaag hierover is, zegt ie wel dat ze al buiten de root staan, in een map Scripts.

Maar inderdaad heb je wel gelijk, gebruik zo weinig mogelijk onnodige includes. Daarnaast is het slim om een generieke foutmelding te genereren en niet de standaard foutmelding te gebruiken. Daarin wil namelijk nog weleens gevoelige gegevens staan.

Om te testen kun je natuurlijk expres foutieve gegevens opgeven om te verbinden naar de database.

[Wiethoofd]

alex3305 schreef op woensdag 14 december 2011 @ 20:52:
Alhoewel de TS wat vaag hierover is, zegt ie wel dat ze al buiten de root staan, in een map Scripts.

Dan heb jij de TS toch verkeerd gelezen:

Verwijderd schreef op woensdag 14 december 2011 @ 20:47:
Deze php scripts heb ik in de root van de site staan, in een folder "Scripts"

---

Sowieso is het voor live websites zoals alex3305 terecht opmerkt beter om een errorpagina naar de user te geven met een generieke melding dat er iets nukt. Gewoon een if($connection == false) { /* Magic voor errorpagina */ } in plaats van de huidige error(nummer)s laten zien.

[RobIII]

Waar hoort mijn topic?
WEB >> PRG

[posttoast]

Ik vind het wel een interessant punt trouwens. Het is inderdaad de netste oplossing om dit soort zaken buiten je webroot te zetten, maar... veel hostingproviders staan dat niet toe. Als workaround maak ik in .htaccess een aantal directories ontoegankelijk, maar ik vind dat eigenlijk een lapmiddel. Want als iemand per ongeluk de .htaccess van de server haalt is die beveiliging ook weg.

[Osiris]

Tja, uiteindelijk zal toch echt een scriptje in de root bij de inloggegevens moeten kunnen, dus hóe je het ergens ook neerzet (encrypted? ) of wáár je het ook neerzet: uiteindelijk kan 'men' er toch wel bij als 'men' toegang heeft tot je root.

[Verwijderd]

Omdat ik blijkbaar wat onduidelijk ben geweest met mijn beschrijving van de locatie van de mijn php scripts:
Ze staan in een folder: /folder/anything.php

[Voutloos]

Osiris schreef op woensdag 14 december 2011 @ 21:40:
Tja, uiteindelijk zal toch echt een scriptje in de root bij de inloggegevens moeten kunnen, dus hóe je het ergens ook neerzet (encrypted? ) of wáár je het ook neerzet: uiteindelijk kan 'men' er toch wel bij als 'men' toegang heeft tot je root.

Daar gaat die maatregel ook helemaal niet om. Dat iets een PHP file is betekent gewoon nog niet dat het een entry point hoeft te zijn. Weet je dat je (bijv. ) config.php enkel als include wordt gebruikt en niet direct aangeroepen hoeft te worden? Mooi, zorg dan ook dat het niet direct aangeroepen kan worden.

Overigens zit het grootste probleem in de ts code in het tonen van mysql_errno() en mysql_error() : Output van deze functie mag je nooit aan derden tonen.

edit:
Osiris:
Ik weet dat jij slim genoeg bent om het voordeel van dingen buiten de webroot houden te begrijpen, dus doe ff je best.

[ Voor 31% gewijzigd door Voutloos op 14-12-2011 22:19 ]

[Osiris]

Voutloos schreef op woensdag 14 december 2011 @ 22:02:
[...]
Daar gaat die maatregel ook helemaal niet om. Dat iets een PHP file is betekent gewoon nog niet dat het een entry point hoeft te zijn. Weet je dat je (bijv. ) config.php enkel als include wordt gebruikt en niet direct aangeroepen hoeft te worden? Mooi, zorg dan ook dat het niet direct aangeroepen kan worden.

Mjah, als je config.php door een webserver-configuratie-fout opeens niet uitgevoerd wordt bij (per ongeluk/hacking) aanroepen, maar als plain-text zichtbaar is o.i.d., dan zal een eventuele exploitable index.php of welke .php dan ook 't ook niet meer doen nee..

[borft]

en dus moet je eigenlijk al je scripts behalve de index.php buiten de webroot knallen. Als dan om wat voor reden dan ook de php interpreter faalt, dan zien mensen alleen een paar includes. Als je daar dan nog wat slimme html omheenzet, dan zien ze dat ook niet meer

[NMe]

posttoast schreef op woensdag 14 december 2011 @ 21:35:
Ik vind het wel een interessant punt trouwens. Het is inderdaad de netste oplossing om dit soort zaken buiten je webroot te zetten, maar... veel hostingproviders staan dat niet toe. Als workaround maak ik in .htaccess een aantal directories ontoegankelijk, maar ik vind dat eigenlijk een lapmiddel. Want als iemand per ongeluk de .htaccess van de server haalt is die beveiliging ook weg.

Als iemand de toegang heeft om die .htaccess te verwijderen heeft hij sowieso ook de toegang om die wachtwoorden direct vanaf de file te lezen.

[Patriot]

NMe schreef op donderdag 15 december 2011 @ 01:12:
[...]

Als iemand de toegang heeft om die .htaccess te verwijderen heeft hij sowieso ook de toegang om die wachtwoorden direct vanaf de file te lezen.

Er zijn natuurlijk ook situaties waarin de combinaties van falende onderdelen zo is dat men bij de gegevens kan, zonder veel moeite te doen. Iets wat dan mogelijk te voorkomen geweest zou zijn als het mogelijk was geweest de files buiten de root te zetten.

Of dat een zinvol punt is, is nog maar de vraag. Zeker voor relatief simpele websites is de moeite/kosten die gemoeid zijn bij het oplossen van dat soort fantoomproblemen het meestal niet waard. En als het dat wel is, zit je waarschijnlijk niet in een situatie waarin je het slechts moet doen met een hostingpakketje.

[Cartman!]

Verwijderd schreef op woensdag 14 december 2011 @ 20:47:
Ik heb een Joomla website.....
*snip*
Ik vraag mij af in hoeverre dit safe....

Vooral eerst zorgen dat je altijd de laatste versie draait. En zoals gezegd nooit mysql_error() op je scherm tonen maar een eigen error tonen of een eigen error pagina tonen.

[NMe]

Patriot schreef op donderdag 15 december 2011 @ 07:43:
[...]

Er zijn natuurlijk ook situaties waarin de combinaties van falende onderdelen zo is dat men bij de gegevens kan, zonder veel moeite te doen. Iets wat dan mogelijk te voorkomen geweest zou zijn als het mogelijk was geweest de files buiten de root te zetten.

Ik zeg natuurlijk ook niet dat dat een slecht plan is. Echter, als je in een situatie zit waarin je .htaccess compromised is dan is je config buiten de webroot doorgaans ook niet veilig.

[djexplo]

Verwijderd schreef op woensdag 14 december 2011 @ 20:47:
Ik vraag mij af in hoeverre dit safe is en of er betere manieren zijn om je inloggegevens op je site op te slaan.

Dat ligt er aan:
- Zet inloggegevens nooit plain-tekst in je code, maar gebruik een simpele str_rot13
- Maak voor je website een mysql gebruiker met weinig rechten en apart wachtwoord
- Noem je inlog niet db.php of database.php, en gebruik niet standaard $user, $pass, $password
Voordeel is dat als collega toevallig op je scherm kijkt hij niet gelijk het wachtwoord weet, en een hacker vaak tools gebruikt om hacken te automatiseren wat minder goed werkt als je geen standaard benamingen gebruikt.

[Cartman!]

djexplo schreef op donderdag 15 december 2011 @ 10:55:
[...]

Dat ligt er aan:
- Zet inloggegevens nooit plain-tekst in je code, maar gebruik een simpele str_rot13

Wat heeft dat voor nut behalve dat het onhandig is?

- Maak voor je website een mysql gebruiker met weinig rechten en apart wachtwoord

Zeker een goed idee.

- Noem je inlog niet db.php of database.php, en gebruik niet standaard $user, $pass, $password
Voordeel is dat als collega toevallig op je scherm kijkt hij niet gelijk het wachtwoord weet, en een hacker vaak tools gebruikt om hacken te automatiseren wat minder goed werkt als je geen standaard benamingen gebruikt.

Zie ik het nut ook niet van in. Als iemand toegang heeft tot jouw server dan boeit de naam van de variabele echt niet meer.

[djexplo]

[b][message=37328537,noline]Cartman! schreef op donderdag 15 december 2011 @
Zie ik het nut ook niet van in. Als iemand toegang heeft tot jouw server dan boeit de naam van de variabele echt niet meer.

10,000 Web Sites Rigged with Advanced Hack Attack

sophisticated hacking scheme seen early last year is affecting an increasing number of Web servers ...

It appears that a single gang is behind the attacks, since the malicious software it spreads is storing login and password details on one server...

Ten eerste hoeft de hacker geen FTP toegang te hebben maar misbruiken ze een lek via:
b.v. image.php?picture23.jpg met image.php?.../../db.php waarbij je dus de bestandsnaam moet weten.

En het is echt niet zo dat je 10.000 websites hackt door eerst alle bestanden van die websites downloaden en dan met een text-editor de code gaan door kijken (stel dat je handmatig 5min per website nodig hebt, dan ben je in dit geval 21 werkweken kwijt ). Nee, dit doe je via wat zelf geschreven scriptjes, die de bekende variablen etc. opvragen .

[ Voor 4% gewijzigd door djexplo op 15-12-2011 11:25 ]

[Cartman!]

Als je vatbaar bent voor path traversal dan heb je een groter probleem dan enkel je database-pass volgens mij Zorg sowieso dat die credentials enkel vanaf localhost gebruikt kunnen worden en iemand heeft er weer niks aan tot ie zelf files kan uploaden en executen.

[Patriot]

Ah, security through obscurity, we gaan het lek niet fixen, we makken het alleen lastiger om het lek te misbruiken

NMe schreef op donderdag 15 december 2011 @ 10:43:
[...]

Ik zeg natuurlijk ook niet dat dat een slecht plan is. Echter, als je in een situatie zit waarin je .htaccess compromised is dan is je config buiten de webroot doorgaans ook niet veilig.

I know, ik doelde specifiek op situaties waarbij htaccess an sich niet compromised is, maar waarbij dat om andere redenen (tijdelijk) is uitgeschakeld. In die zin kan ik me voorstellen dat het voor posttoast aanvoelt als een lapmiddel. Maar dat het in de praktijk een uitzonderlijke situatie is weet ik ook, vandaar de nuance in het tweede deel van mijn post. Ik ben het verder met je eens dat het een prima oplossing is voor situaties waar je om wat voor reden dan ook niet buiten de webroot kunt komen.

Dat het misschien niet zo duidelijk was schuif ik dan voor het gemak maar even af op het tijdstip