[CakePHP] Verschillende database users binnen controller

[Caddy]

In mijn ProductController.php heb ik bijvoorbeeld een functie die het product laat zien aan de bezoeker. (SELECT query)

Maar in deze controller heb ik bijvoorbeeld ook een functie voor de admin om het product te bewerken. (UPDATE Query)

Voor veiligheid maak ik zoveel mogelijk apparte database users aan voor verschillende taken en tabellen.
Stel dat ik nou een apparte database user wil hebben met enkel select rechten voor de view functie, en weer een apparte database user wil gebruiken voor de edit functie binnen dezelfde controller.

Oftewel, met Cakephp doe ik in mijn model:

public $useDbConfig = 'alternate';

Eigenlijk zou ik dit dus in mijn controller willen kunnen.
Mocht iemand dan namelijk de view functie kunnen misbruiken met injections of iets, dan kan ie enkel selecten in die tabel.

Iemand enig idee?

[djluc]

Je lost het op met de verkeerde tools. Je hebt het over controllers maar je moet vele lagen dieper:
http://book.cakephp.org/2.0/en/models/behaviors.html
http://book.cakephp.org/2.0/en/models/datasources.html

Daarnaast: Meerdere databases hiervoor gebruiken kan maar komt niet veel voor. Je kunt gewoon MySQL users met rechten aanmaken mocht je dit willen beveiligen. Maar in het algemeen wordt deze beveiliging toch op applicatieniveau verwerkt.

[Caddy]

Nee ik was niet van plan om apparte databases aan te maken, maar juist database users.

Deze kan je volgens mij maar 1 keer defineren in je Model tot zover ik begrijp.
Waardoor dus die hele controller die eronder zit die ene user gebruikt.

[Caddy]

Bij mij is de situatie nu dus zoiets:

PHP: filename

Model:

class Example extends AppModel {
    public $useDbConfig = 'ExampleDBUser';
}


Controller:

class ExampleController extends Controller {

      public function find() {

       $this->Example->find('all');   <--- Hier wil ik apparte user voor met select only rechten op tabel

       }


      public function save() {

       $this->Example->save($this->request->data);      <--- Hier wil ik apparte user voor met insert rechten op tabel

       }

}

[Gomez12]

Wat is het praktische nut van meerdere db-users binnen 1 app?

Ik bedoel :
- Gaan ze bruteforcen krijgen ze alletwee de users.
- Krijgen ze je code te pakken hebben ze alletwee de users
etc. etc.

Normaal gesproken ben ik er 100% voorstander van om meerdere users aan te maken als je meerdere ingangen tot je db hebt. Maar als je enige ingang 1 app is dan zie ik de toegevoegde waarde niet om binnen die app meerdere users te gebruiken.

Enige wat ik zie is dat je sql-exploits enigszins tegen kan houden, maar daar zijn effectievere en betere manieren voor.

En het nadeel van wat jij wilt is dat de meeste frameworks er niet op gebouwd zijn.

[Caddy]

Het is idd ook overbodig in mijn situatie, Ik was gewoon benieuwt of dit makkelijk kon want dan zou ik hier wel gebruik van maken. Tis ook niet om SQL exploids tegen te gaan, meer als extra maatregel.

Maargoed, heeft dus blijkbaar meer nut om gewoon 1 user te maken die van alles kan ( natuurlijk geen drop of shutdown en dat soort dingen) dan voor elke query een apparte user want dat idee ga je dan wel krijgen...

[djluc]

Caddy schreef op zondag 06 januari 2013 @ 15:54:
[...]
Maargoed, heeft dus blijkbaar meer nut om gewoon 1 user te maken die van alles kan ( natuurlijk geen drop of shutdown en dat soort dingen) dan voor elke query een apparte user want dat idee ga je dan wel krijgen...

Huh, volgens mij schrijf je het niet goed of zie je iets anders: Je maakt gewoon 1 gebruiker aan voor toegang, niet 1 user per query.

Je idee is goed en ook zeker niet verkeerd. Je hebt een extra layer of defense wat absoluut een goede optie kan zijn. Wel moet je bedenken of dit ook echt nodig is voor de applicatie waar je op dit moment mee bezig bent en of dit mogelijk is op je hosting platform.

Mocht je dit willen kan het best. Bijvoorbeeld, je maakt 2 gebruikers aan voor MySQL:
website_user: read-only + schrijven in log tabel bijvoorbeeld
admin_user: schrijven in data tabellen

Vervolgens kijk je bij iedere request of er een gebruiker ingelogd is, bijvoorbeeld op basis van je sessie. Zoja: Maak verbinding met de admin_user. In alle andere gevallen met de website_user.

In je applicatie zelf werk je met bijvoorbeeld: http://book.cakephp.org/2...nents/authentication.html en ACL voor meer gedetailleerde rechten.

Wat win je op deze manier: Je moet eerst een login hebben voor je de database aan kan passen wat er dus meteen voor zorgt dat je extra veiligheid hebt. Maar vergeet niet dat het gaat om de zwakste schakel. Je login zal dat in eerste instantie dus zijn. Daar moet je dus de beste security maatregelen implementeren.

In basis moet je gaan lezen over security layers om die aanpak te begrijpen. Wat je met je idee maakt is een extra drempel. Zo kan je er nog veel meer verzinnen. Zie bijvoorbeeld een overzicht met wat concrete voorbeelden:

ftp://ftp.software.ibm.co...p_securityrichwebapps.pdf

In basis is het sowieso te adviseren om je framework heel goed te kennen als je serieus met beveiliging aan de slag wilt, bijvoorbeeld het security component: http://book.cakephp.org/2...s/security-component.html

[Caddy]

Thanks! Ik ben nu ruim een half jaartje bezig met CakePHP.
Reden waarom ik CakePHP zo aangenaam vind is met name hun documentatie, dus daar heb ik uiteraard al vaak in gekeken.

ACL en Security Component gebruik ik sowieso om admin functies te beschermen voor buitenstaanders.
Host is Amazon AWS dus ik kan van alles instellen.

Maar het lijkt er dus op dat ik dit niet ff makkelijk vanaf de controller kan defineren.
Wat ik opzich jammer vind omdat je bijvoorbeeld voor een nieuwsbrief inschrijf functie geen database user hoeft te gebruiken die je hele tabel (of alle tabellen met 1 user) kan update en delete..

Was gewoon benieuwd of iemand hier een goede oplossing voor had omdat ik voor mijn werk wel vaak met dit soort dingen te maken heb.

Thanks

[ Voor 0% gewijzigd door Caddy op 06-01-2013 17:09 . Reden: spelfoutje ]

[Barryvdh]

Maar kan je het dan niet gewoon in je model aanpassen?
Dus dat je 2 modellen maakt, 1 voor je front-end, waar dus je find/display functie in zit bijvoorbeeld, en 1 voor je admin-deel.
Dan gebruik je in je controller gewoon het desbetreffende Model.

[djluc]

Caddy schreef op zondag 06 januari 2013 @ 17:06:
[...]
Maar het lijkt er dus op dat ik dit niet ff makkelijk vanaf de controller kan defineren.
Wat ik opzich jammer vind omdat je bijvoorbeeld voor een nieuwsbrief inschrijf functie geen database user hoeft te gebruiken die je hele tabel (of alle tabellen met 1 user) kan update en delete..

Was gewoon benieuwd of iemand hier een goede oplossing voor had omdat ik voor mijn werk wel vaak met dit soort dingen te maken heb.
[...]

Zo specifiek doe je dat met ACL, dat is de standaard oplossing daarvoor. Afhankelijk van je wensen kan dat role-based, controller based of nog specifieker. In de documentatie staat daar alles over. Het ACL systeem is goed getest dus een implementatie daarmee moet volstaan in de meeste gevallen.

Probeer het vooral niet zelf te bouwen maar gebruik de standaard hiervoor, het is erg lastig om dit soort zaken goed en veilig te doen.

Gezien het om nieuwsbrief inschrijvingen gaat: Je zou website_user alleen insert rechten kunnen geven op die tabel met GRANT. http://dev.mysql.com/doc/refman/5.1/en/grant.html Je moet je wel echt afvragen hoe ver je wilt gaan. Je zult al deze extra maatregelen ook in je testprocedures e.d. mee moeten nemen. Het moet niet te complex worden, dat brengt ook risico's met zich mee.

Barryvdh schreef op zondag 06 januari 2013 @ 17:30:
Maar kan je het dan niet gewoon in je model aanpassen?
Dus dat je 2 modellen maakt, 1 voor je front-end, waar dus je find/display functie in zit bijvoorbeeld, en 1 voor je admin-deel.
Dan gebruik je in je controller gewoon het desbetreffende Model.

In basis is dit geen goed plan in CakePHP omdat je dan code duplication krijgt en daarnaast krijg je problemen met relaties tussen records. CakePHP ondersteund geen inheritance op models. Je zou ACL wel op de models toe kunnen passen: http://stackoverflow.com/...-2-0-row-record-level-acl

[ Voor 20% gewijzigd door djluc op 06-01-2013 17:49 ]

[Caddy]

Precies, Het gaat allemaal een beetje ver. Nieuwsbrief was ff een voorbeeld.
En ACL is idd al goed genoeg voor de meeste gevallen.

Bedankt!