[PHP] - server variable

[E.Greidanus]

Ik ben bezig om een beveiliging in mijn PHP project aan te brengen. Het project draait straks bij klanten en ik wil zoveel mogelijk mijn PHP code beschermen. Uiteindelijk wil ik alle code in een MySQL database hebben en de MySQL login wil ik d.m.v. een server variabele kunnen instellen. Wanneer Apache gestopt wordt moeten deze variabelen opnieuw ingesteld worden op een aparte PHP pagina.

Ik dacht dit simpel te kunnen doen door:

$_SERVER["mysql_username"] =$_POST["mysql_username"];
$_SERVER["mysql_password"] =$_POST["mysql_password"];

en dan de $_SERVER variabelen gebruiken voor de MySQL login, maar $_SERVER is voor zover ik weet een read-only collectie.

Is hier een andere variabele collectie of doe ik iets fout met $_SERVER?

[Erkens]

Die $_SERVER wordt iedere request opnieuw opgebouwd, waardoor deze hiervoor niet te gebruiken is. Je zal hiervoor een config file oid moeten gebruiken waarin je de username/password insteld.

Maar ehm, lees ik het goed dat je alle PHP code _in_ je database gaat zetten?

[vriesdude]

E.Greidanus schreef op woensdag 21 maart 2007 @ 13:48:
Ik ben bezig om een beveiliging in mijn PHP project aan te brengen. Het project draait straks bij klanten en ik wil zoveel mogelijk mijn PHP code beschermen. Uiteindelijk wil ik alle code in een MySQL database hebben en de MySQL login wil ik d.m.v. een server variabele kunnen instellen. Wanneer Apache gestopt wordt moeten deze variabelen opnieuw ingesteld worden op een aparte PHP pagina.

Ik dacht dit simpel te kunnen doen door:

$_SERVER["mysql_username"] =$_POST["mysql_username"];
$_SERVER["mysql_password"] =$_POST["mysql_password"];

en dan de $_SERVER variabelen gebruiken voor de MySQL login, maar $_SERVER is voor zover ik weet een read-only collectie.

Is hier een andere variabele collectie of doe ik iets fout met $_SERVER?

In plaats van $_SERVER moet je met $_SESSION werken..
_{Vreemde constructie trouwens}

edit: $_SESSION werkt ook niet, alleen binnen de sessie zelf,
maak gebruik van een config file of handel de beveiliging af op een fatsoenlijke manier

[ Voor 7% gewijzigd door vriesdude op 21-03-2007 13:53 ]

[Erkens]

vriesdude schreef op woensdag 21 maart 2007 @ 13:52:
[...]


In plaats van $_SERVER moet je met $_SESSION werken..

_{Vreemde constructie trouwens}

session is niet geschikt hiervoor aangezien je dan per client opnieuw je database settings moet instellen, en als ik het goed begrijp is dat niet de bedoeling

edit:
ah, snel editen he

[ Voor 5% gewijzigd door Erkens op 21-03-2007 13:54 ]

[E.Greidanus]

Nee $_SESSION of $GLOBALS is inderdaad niet geschikt.

Een config file is eigenlijk ook toereikend aangezien mijn programma op een RAID schijf wordt geplaatst en door deze en gene mee naar huis wordt genomen en de sleutel dan in de config file staat.

Een server variabele zou naar mijn idee de enige goede oplossing bieden om de MySQL database te beveiligingen.

[NMe]

Erkens schreef op woensdag 21 maart 2007 @ 13:51:
Maar ehm, lees ik het goed dat je alle PHP code _in_ je database gaat zetten?

Mag ik daar een smiley aan toevoegen? Deze dus:

Je denkt toch niet dat je code veiliger is wanneer deze in een database zit? Alsof dezelfde mensen daar niet net zo makkelijk/moeilijk aan zouden kunnen als wanneer de code gewoon op je file system staat.

[TeeDee]

PHP:

$poepcodeuit = eval("select code_contents from t_code where code_id=1")

I love it.

Als je je code wil beschermen zou je aan de slag met Zend kunnen gaan.

[Verwijderd]

Afgezien van alles... uh... Je mysql gebruikersnaam en passwd komt via een post binnen? ga je gebruikers vragen om een mysql gebruikersnaam en wachtwoord?

[Xof]

Je kunt je code toch ook gaan coderen net zoals bijv. Vbulletin en Invision Power Board dat doen?

[Grijze Vos]

kijk eens hier naar: http://www.php.net/manual/en/ref.bcompiler.php

[E.Greidanus]

Het is de bedoeling om de MySQL gebruikersnaam en wachtwoord eenmalig in een server variabele te stoppen via post (en dus niet dat elke gebruiker dat opnieuw moet invullen).

De PHP code in de database is inderdaad een beetje overdreven ... zoiets als Zend / Phrozen met beveiliging op bestandsniveau is ook goed, maar ook deze sleutel het liefst in een server variabele en niet op de schijf ...

Het is een redelijk groot project geworden (3 man werken er al 3/4 jaar aan) dus ons kroonjuweel liefst wel goed beschermen.

[Erkens]

E.Greidanus schreef op woensdag 21 maart 2007 @ 14:42:
Het is de bedoeling om de MySQL gebruikersnaam en wachtwoord eenmalig in een server variabele te stoppen via post (en dus niet dat elke gebruiker dat opnieuw moet invullen).

Je kan prima dmv een post die username/password in een file wegschrijven, dus dat is het probleem ook niet lijkt me?

[E.Greidanus]

Erkens schreef op woensdag 21 maart 2007 @ 14:44:
[...]

Je kan prima dmv een post die username/password in een file wegschrijven, dus dat is het probleem ook niet lijkt me?

Nou dan staat de sleutel op de schijf en dat hebben we liever niet.

[ReverendBizarre]

Dit gaat nooit werken. In PHP bestaat niet zoiets als een server variabele die je een keer kan setten en die vervolgens onthouden wordt zolang Apache blijft draaien (dat is tenminste wat ik uit je post begrijp dat je wilt bereiken). Je zou dan dus inderdaad de gegevens in een file of iets dergelijks moeten schrijven, maar dan is het dus gewoon een nutteloze beveiliging want dan kunnen mensen alsnog gewoon achter de login informatie komen en alles uit je database trekken.

Los daarvan is code in een database opslaan gewoon in het algemeen not-done. Als het echt zo'n serieus project is, investeer dan gewoon in Zend Guard of kijk naar de gratis/opensource alternatieven die ervoor zijn (ik heb er zelf geen ervaring mee dus geen idee of die ook daadwerkelijk wat voorstellen of niet).

[Erkens]

E.Greidanus schreef op woensdag 21 maart 2007 @ 14:48:
Nou dan staat de sleutel op de schijf en dat hebben we liever niet.

ehm, het gaat hier toch om de database settings?
Daarnaast als PHP ergens bij kan dan is het een koud kunstje om alsnog die "sleutel" eruit te halen met een simpel scriptje

Maargoed, je kan anders eens kijken naar Shared Memory. Maar bedenk je wel dat je iedere keer als er iets aan onderhoud aan de server gedaan moet worden je opnieuw die "sleutel" moet invullen...

[NMe]

E.Greidanus schreef op woensdag 21 maart 2007 @ 14:48:
[...]


Nou dan staat de sleutel op de schijf en dat hebben we liever niet.

En je denkt dat het in een "server variabele" niet op de schijf terechtkomt? Of op zijn minst in het geheugen, wat net zo makkelijk uitleesbaar is?

[Janoz]

In het geheugen opgeslagen gegevens zijn natuurlijk wel een stuk lastiger te achterhalen dan op de schijf weggeschreven variabelen. Verder is er genoeg te zeggen voor servervariabelen. Het wegschrijven in een bestand is (of eventueel opslaan in een database) is een beperkte vervanging aangezien je met race problemen zit. Het dichtste dat voor php nog in de buurt komt is shared memory, maar ook dat is eigenlijk nauwlijks bruikbaar.

[E.Greidanus]

Erkens schreef op woensdag 21 maart 2007 @ 14:54:
[...]

ehm, het gaat hier toch om de database settings?
Daarnaast als PHP ergens bij kan dan is het een koud kunstje om alsnog die "sleutel" eruit te halen met een simpel scriptje

Maargoed, je kan anders eens kijken naar Shared Memory. Maar bedenk je wel dat je iedere keer als er iets aan onderhoud aan de server gedaan moet worden je opnieuw die "sleutel" moet invullen...

Dit is precies wat ik zoek! Ik post mijn resultaten als het gelukt is en de sleutel ook echt alleen in het geheugen staat en niet op de schijf.

[Icelus]

E.Greidanus schreef op woensdag 21 maart 2007 @ 13:48:
Ik ben bezig om een beveiliging in mijn PHP project aan te brengen. Het project draait straks bij klanten en ik wil zoveel mogelijk mijn PHP code beschermen. Uiteindelijk wil ik alle code in een MySQL database hebben en de MySQL login wil ik d.m.v. een server variabele kunnen instellen.

Je kunt dan beter een product als Zend Guard gebruiken.

[Verwijderd]

Dus de eerste gebruiker na een reset moet eerst de mysql gebruikersnaam en wachtwoord invullen ? Deze word dus op een geel noteblock papiertje aan een monitor geplakt bij iemand op het kantoor

[LuCarD]

Icelus schreef op woensdag 21 maart 2007 @ 15:10:
[...]
Je kunt dan beter een product als Zend Guard gebruiken.

Of ioncube, een stuk goedkoper voor het encoderen van enkele bestanden.

[HuHu]

Als je je product aan bedrijven gaat leveren, dan moet je de code afschermen middels licenties en niet middels allerlei vage en obscure constructies in je code.

[E.Greidanus]

Ik gebruik nu de volgende manier om de PHP scripts te beveiligingen:

- sleutel instellen d.m.v. environment variabele (volgens mij wordt deze alleen in het geheugen opgeslagen).
- script coderen met de Mcrypt module
- script decoderen en parsen met eval

[Xof]

E.Greidanus schreef op donderdag 22 maart 2007 @ 11:57:
Ik gebruik nu de volgende manier om de PHP scripts te beveiligingen:

- sleutel instellen d.m.v. environment variabele (volgens mij wordt deze alleen in het geheugen opgeslagen).
- script coderen met de Mcrypt module
- script decoderen en parsen met eval

En wat is je vertraging? Ben ik wel benieuwd naar (dus even een timer eromheen gooien).

[Cartman!]

Tja, als ik nou zolang bezig ben en er dus een berg geld tegenaan is gegooid kan een licentie Zend Guard er wel tegenaan. Heb je al die bullshit niet nodig. Het is precompiled dus nog sneller ook en zover ik weet vele malen onkraakbaarder dan een custom oplossing.
Het nadeel met vergelijkbare pakketen als bijv. Ioncube vind ik de loaders die je nodig hebt. Zend Optimizer heeft bijna iedere host wel aanstaan of kan ie aanzetten voor je. Stukje compabiliteit.