[PHP] veiligheid connectie gegevens, wat is veiliger?

[isomis]

Ik zit met het volgende probleem. Op dit moment heb ik wat klanten die gebruikmaken van hetzelfde cms. De klant maakt verbinding met het cms via zijn usergegevens (domeinnaam) en de klant kan zijn website beheren met hetzelfde cms dat andere klanten ook gebruiken.


Wat is veiliger?

1. Op het moment dat de klant inlogt wordt er via zijn inloggegevens in de database van het cms gekeken om welke klant het is. Daarna maakt het cms verbinding met de database van de klant

2. Op het moment dat de klant inlogt wordt er via zijn inloggevens in de database gekeken om welke website het gaat en dan wordt er gekeken in het config bestand op de desbetreffende website wat de gegevens zijn om verbinding te maken met de database van desbetreffende klant.

Ik zat hiermee, want optie 1 heeft als nadeel dat als er iemand op één of andere manier in de database komt van je CMS. hij toegang heeft tot alle inloggegevens van alle klanten die gebruik van het CMS. Bij optie 2 heb je dat niet.

Alleen ik vraag mij af wat nou veiliger is, zulke gegevens in een config.inc.php te zetten of in de db. Bij optie 2 parkeer je de config.inc.php file gewoon bij degene in zijn host map. In de db van je cms hoef je alleen dan te refereren naar dat config bestand.


Ik hoop dat het ik het duidelijk heb beschreven wat mijn probleem is.

edit: eigenlijk is ook de vraag: is het veilig om zulke gegevens te plaatsen in een php file?

[ Voor 3% gewijzigd door isomis op 12-08-2007 19:59 ]

[Verwijderd]

Nouja, ik weet niet of je Google's codesearch kent. Maar die zoekt dus gewoon tussen de code van bestanden. Ik hoop daarmee ook dat ik jouw heb aangegeven dat logingegevens in een config niet zomaar gaan.

Je kunt er wel voor kiezen om deze config te includen, en daarvoor met "define" de situatie veilig te stellen.

Dus zeg dat je het bestand opent vanaf index.php, dan doe je daar "define(ACCESS, "TRUE"); oid. En vervolgens include je config.php, de eerste lijn in config.php gaat dan kijken of die ACCESS erin zit met "if(defined(ACCESSFILE))"
zo niet, exit je het script...kan het nergens meer bij. Dat zou je veilig moeten stellen van alles dat het script direct probeert te benaderen. (Dus, de link naar "www.jouwdomein.nl/config.php" werkt dan niet, maar de inhoud ervan blijft wel operationeel voor gebruik op dezelfde server.

Ik sla inloggegevens altijd op de database...maar ik weet niet wat jouw het makkelijkst uitkomt.

[Harm]

Verwijderd schreef op zondag 12 augustus 2007 @ 20:35:
Nouja, ik weet niet of je Google's codesearch kent. Maar die zoekt dus gewoon tussen de code van bestanden. Ik hoop daarmee ook dat ik jouw heb aangegeven dat logingegevens in een config niet zomaar gaan.

Googles codesearch kan alleen maar code doorzoeken die als zodanig op het web geplaatst is, oftewel je moet expliciet je php-bestand (de broncode dus, niet het resultaat van het uitvoeren van dat bestand) op het internet plaatsen om in Googles codesearch terug te komen. Het zou wat zijn als Google gewoon de (php-, java-, .net-, etc.) broncode van je website zou kunnen opvragen.

Verwijderd schreef op zondag 12 augustus 2007 @ 20:35:
Ik sla inloggegevens altijd op de database...maar ik weet niet wat jouw het makkelijkst uitkomt.

Waar sla je dan de gegevens op waarmee je de database benaderd?

[Verwijderd]

Verwijderd schreef op zondag 12 augustus 2007 @ 20:35:
Nouja, ik weet niet of je Google's codesearch kent. Maar die zoekt dus gewoon tussen de code van bestanden. Ik hoop daarmee ook dat ik jouw heb aangegeven dat logingegevens in een config niet zomaar gaan.

Als je configuratiebestanden (ongeparset) via HTTP kunnen worden geserveerd ben je een prutser. Google's codesearch of niet, configuratiebestanden zijn voor de server, niet voor de client, en mogen dus nooit geserveerd worden. Het is een koud kunstje om dat even in te stellen.

Je kunt er wel voor kiezen om deze config te includen, en daarvoor met "define" de situatie veilig te stellen.

Zie vorige opmerking. Jouw oplossing slaat alleen ergens op als de eerste bescherming niet in orde blijkt te zijn. En die bescherming was configuratiebestanden moeten niet worden geserveerd.

Dus zeg dat je het bestand opent vanaf index.php, dan doe je daar "define(ACCESS, "TRUE"); oid. En vervolgens include je config.php, de eerste lijn in config.php gaat dan kijken of die ACCESS erin zit met "if(defined(ACCESSFILE))"
zo niet, exit je het script...kan het nergens meer bij. Dat zou je veilig moeten stellen van alles dat het script direct probeert te benaderen. (Dus, de link naar "www.jouwdomein.nl/config.php" werkt dan niet, maar de inhoud ervan blijft wel operationeel voor gebruik op dezelfde server.

Dat kan ook niet als je configuratiebestanden niet serveert.

Leg toch eens de nadruk op wat belangrijk is, en niet op een halfzachte oplossing.

[isomis]

idd dan ben je een prutser.

Echter de vraag is wat is nou veiliger. Zulke gegevens in db opslaan of db die bestand benaderd met zulke gegevens erin.

Ik zit te twijfelen waar ik nou beter mee af ben.

[imp4ct]

Om eerlijk te zijn zit ik op dit moment een beetje met hetzelfde probleem. Alhoewel... De kans dat je CMS-databank gekraakt wordt is denk ik redelijk klein. Zorg er ten eerste al voor dat het adminwachtwoord een fatsoenlijk wachtwoord is dus.. caps, cijfers, speciale tekens.. dat help normaal gezien al. Mij lijkt het toch niet zo makkelijk een phpMyAdmin DB te kraken, maar goed ik kan natuurlijk mis zijn.

Wat je gebruikers info dan betreft. Gho... normaal gezien zet je nooit letterlijk een wachtwoord van een gebruiker in een DB, logischerwijs zou je hierover al een MD5 hash ofzoiets zetten, natuurlijk kunnen die gekraakt worden, maar goed.

De ultieme beveiliging bestaat volgens mij niet en gho jah... als je echt investeringen wilt doen dan kan je, je CMS natuurlijk nog meer gaan beveiligen. Nu weet ik wel niet en dat is een beetje een vraag van mij uit, het gebruik van het 'https://' domein, kan dit enige extra beveiliging met zich meebrengen?

[Grijze Vos]

Verwijderd schreef op zondag 12 augustus 2007 @ 20:42:
[...]

Als je configuratiebestanden (ongeparset) via HTTP kunnen worden geserveerd ben je een prutser. Google's codesearch of niet, configuratiebestanden zijn voor de server, niet voor de client, en mogen dus nooit geserveerd worden. Het is een koud kunstje om dat even in te stellen.

Mee eens. Maar in sommige gevallen is het niet jouw schuld, want dan beheert iemand anders die bak.
Je config moet je iig altijd buiten de webroot zetten, heb ik een keer niet gedaan bij een oude versie van mn forumsoftware, gelukkig kreeg ik mail van een oplettende bezoeker en heb ik snel de mysql passwords gewijzigd. (De 'admin' van de machine, tenminste, we hadden met 3 man root op die bak, en hij vond dat ie iets up moest graden, die had iets verkeerd ingesteld, waardoor mijn php gewoon plain eruit ging, heel fijn.)

[ Voor 12% gewijzigd door Grijze Vos op 13-08-2007 00:09 ]

[dB90]

Offtopic:
@Impact
Nofi maar... gast waar heb je het allemaal over? Dit is toch geen antwoord op de vraag van de TS? Je klinkt niet echt alsof je weet waar je het over hebt, maar dat kan ook aan mijn interpretatie liggen natuurlijk.

Ontopic:
Ik zou kiezen voor het opslaan in de database, maar dat is persoonlijke voorkeur. Zolang je de juiste maatregelen neemt m.b.t. het beveiligen, zijn beide oplossingen prima volgens mij. Misschien dat de database-oplossing sneller is?

[Kalentum]

edit: eigenlijk is ook de vraag: is het veilig om zulke gegevens te plaatsen in een php file?

Ja hoor. PHP bestanden worden door PHP geinterpreteerd. Je zal ook wel moeten, al was het maar omdat je applicatie niet spontaan weet hoe er op welke database server geconnect moet worden.

Enige nadeel van dit is dat als php op de 1 of andere manier niet goed werkt, de bestanden mogelijk wel toegankelijk zijn. Het beste is daarom om alles wat niet direct aan geroepen (hoeft) te worden buiten de document root van je webserver te plaatsen en te includen vanaf een php script dat wel via de webserver te bereiken is.

[Verwijderd]

rutgerw schreef op maandag 13 augustus 2007 @ 09:16:

Ja hoor. PHP bestanden worden door PHP geinterpreteerd. Je zal ook wel moeten, al was het maar omdat je applicatie niet spontaan weet hoe er op welke database server geconnect moet worden.

Enige nadeel van dit is dat als php op de 1 of andere manier niet goed werkt, de bestanden mogelijk wel toegankelijk zijn. Het beste is daarom om alles wat niet direct aan geroepen (hoeft) te worden buiten de document root van je webserver te plaatsen en te includen vanaf een php script dat wel via de webserver te bereiken is.

Kort gezegd: de beveiliging moet niet anders zijn dan bij niet-PHP-configuratiebestanden. In het ergste geval worden PHP scripts ongeparset aan de client geserveerd, en (nogmaals) dat laatste moet dus sowieso niet kunnen gebeuren.

[isomis]

dB90 schreef op maandag 13 augustus 2007 @ 00:14:
Offtopic:
@Impact
Nofi maar... gast waar heb je het allemaal over? Dit is toch geen antwoord op de vraag van de TS? Je klinkt niet echt alsof je weet waar je het over hebt, maar dat kan ook aan mijn interpretatie liggen natuurlijk.

Ontopic:
Ik zou kiezen voor het opslaan in de database, maar dat is persoonlijke voorkeur. Zolang je de juiste maatregelen neemt m.b.t. het beveiligen, zijn beide oplossingen prima volgens mij. Misschien dat de database-oplossing sneller is?

De gegevens liggen nu vast in de database. Alleen ik zat ermee, omdat het op 1 punt vastligt. De andere oplossing heeft als gevolg dat elke klant in zijn eigen host die gegevens heeft. Je verspreid het eigenlijk.

Ik heb een dedicated server. Het CMS ligt in de root en is bereikbaar via www.domeinnaam.nl/cms voor elke klant. Klanten hebben alleen maar het gebruiksrecht van het CMS en alle modules die draaien op de website. De frontend modules liggen ook in de root, dus niet bereikbaar voor klant. Via een syslink is de map wel aanwezig in hun hostmap. Echter niet toegankelijk.

[ Voor 11% gewijzigd door isomis op 13-08-2007 09:28 ]