databasebevoegdheden
Een website kent verschillende gebruikers: bezoeker, ingelogde gebruiker, beheerder, etc.
Een beheerder zal meer/andere bevoegdheden hebben dan een bezoeker.
Bijvoorbeeld: om een bezoeker informatie te tonen, volstaat in veel gevallen alleen een select-query.
Als die bezoeker echter een bericht/vraag wil posten (bv gastenboek), zal ook een insert-query tot de mogelijkheden moeten behoren.
Update-query (en eventueel delete-query) is meer iets voor ingelogde gebruikers / beheerder.
Dan zijn er nog mogelijkheden als ‘create table’ en ‘drop table’.
Houden jullie, bij het maken van een databaseverbinding, rekening met deze zaken? Of krijgt elke bezoeker dezelfde, uitgebreide, bevoegdheid.
Ikzelf zou als het echt maatwerk was wel baseren op de MySQL-toegangsrechten. Zo zou ik DROP-rechten in de frontend uit hebben gezet, iets verwijderen kan dan prima met een delete-field. De backend heeft dan wat meer rechten.
Een website-gebruiker krijgt sowieso geen SQL-bevoegdheid. De queries worden uitgevoerd door de PHP-backend, en niet door de gebruiker. De backend-software dient te controleren of de gebruiker rechten heeft voor een bepaalde operatie.
een gebruiker (ingelogd of wat dan ook) doet geen query's. Hij gebruikt mogelijkheden die jij als programmeur beschikbaar stelt
" een website " of bedoel je misschien iets anders... ?
@Willem, Roland: een programmeur zal een script maken waar een gebruiker gebruikt van maakt. Uiteraard.
En natuurlijk dient er (middels het script wat een programmeur heeft uitgewerkt) gecontroleerd te worden of de gebruiker de bevoegdheid heeft om een actie uit te voeren.
Maar met de vaak terugkerende opmerkingen over sql-injectie, ddos-aanvallen en ander internetgespuis en de documentatie die ik onlangs las, vroeg ik me af of, naast de taken/verantwoordelijkheden die een programmeur heeft t.a.v. het scripten, ook andere manieren, zoals beperkte MySQL-toegangsrechten, vaak gebruikt wordt.
Of dat iedereen vertrouwt op de code van de programmeur.
Obelix en Idefix op 08/04/2013 20:03:44:
Maar met de vaak terugkerende opmerkingen over sql-injectie, ddos-aanvallen en ander internetgespuis en de documentatie die ik onlangs las, vroeg ik me af of, naast de taken/verantwoordelijkheden die een programmeur heeft t.a.v. het scripten, ook andere manieren, zoals beperkte MySQL-toegangsrechten, vaak gebruikt wordt.
Of dat iedereen vertrouwt op de code van de programmeur.
Of dat iedereen vertrouwt op de code van de programmeur.
Dat heeft in principe niets te maken met gebruikersrechten op je database. Je backend maakt verbinding met de database en gebruikt daar een gebruikers-id voor. De gebruiker zelf heeft echter geen eigen userid op die database en het is in dat kader dan ook niet relevant om over gebruikersrechten te praten.
De minimale rechten die de gebruikersaccount van je backend nodig heeft wordt bepaald door de maximale rechten die nodig zijn om je gebruikers te kunnen laten werken. Het is op zich verstandig om die account niet meer rechten dan dat te geven. Maar inserten en wellicht ook deleten van records zal daar altijd wel bijhoren.
Daarnaast heb je nog een aantal functies die alleen toegankelijk zouden moeten zijn voor administrators (denk aan dingen die een drop table veroorzaken); het is te overwegen om daar een aparte database-user voor te gebruiken die extra rechten heeft.
SQL-injectie is inderdaad een link fenomeen, maar als het voorkomt, is het eigenlijk altijd de fout van de programmeur. Die heeft dan het eerste basisprincipe van gebruikersinteractie genegeerd: vertrouw nooit de input van de gebruiker.
DDOS-attacks zijn in dit verhaal volkomen irrelevant. Daar kun je je niet tegen indekken met wat permissies op je database. Bovendien is dat in de basis geen securityrisico, maar meer een continuïteitsrisico.
Hebben we het over 1 database dat word benadert door diversen users?
Of hebben we het over 1 database per user?
Want daar zit een groot verschil in natuurlijk.
Ikzelf heb bijvoorbeeld meerdere databases voor verschillende users.
De users hebben verder geen rechten.
Maar ze kunnen wel hun database die dingen doen die nodig zijn.
Denk aan updaten deleten e.d.
Willem vp op 08/04/2013 21:00:40:
De minimale rechten die de gebruikersaccount van je backend nodig heeft wordt bepaald door de maximale rechten die nodig zijn om je gebruikers te kunnen laten werken. Het is op zich verstandig om die account niet meer rechten dan dat te geven. Maar inserten en wellicht ook deleten van records zal daar altijd wel bijhoren.
Daarnaast heb je nog een aantal functies die alleen toegankelijk zouden moeten zijn voor administrators (denk aan dingen die een drop table veroorzaken); het is te overwegen om daar een aparte database-user voor te gebruiken die extra rechten heeft.
Daarnaast heb je nog een aantal functies die alleen toegankelijk zouden moeten zijn voor administrators (denk aan dingen die een drop table veroorzaken); het is te overwegen om daar een aparte database-user voor te gebruiken die extra rechten heeft.
Dus jouw advies: indien mogelijk (zoals Aart al aangaf ondersteunt niet elke hosting het) werken met rechten voor een gebruikersaccount (en ik noem(de) dat dan databasebevoegdheden voor gebruikers/bezoekers).
Bart V B op 08/04/2013 21:20:36:
Even voor de beeldvorming, waar praten we nu over?
Hebben we het over 1 database dat word benadert door diversen users?
Of hebben we het over 1 database per user?
Hebben we het over 1 database dat word benadert door diversen users?
Of hebben we het over 1 database per user?
1 Database (met meerdere tabellen) voor diverse users.
Denk als voorbeeld aan een site als phphulp:
Je hebt bezoekers: zij kunnen alleen topics inzien.
Je hebt leden: zij kunnen reageren. Daarvoor moet je wel ingelogd zijn.
Als moderator kun je ook in een topic ingrijpen.
Gewijzigd op 08/04/2013 21:32:18 door Obelix Idefix
Obelix en Idefix op 08/04/2013 21:27:17:
Denk als voorbeeld aan een site als phphulp:
Je hebt bezoekers: zij kunnen alleen topics inzien.
Je hebt bezoekers: zij kunnen alleen topics inzien.
Dat wil overigens niet zeggen dat je voldoende hebt aan een database-account met alleen leesrechten. Waarschijnlijk wil je bijvoorbeeld ook een tellertje bijhouden hoevaak een topic is gelezen. Daarvoor heb je schrijfrechten nodig (beter gezegd: update-rechten). Of stel dat ze het forum zo interessant vinden dat ze een account willen aanmaken, dan zal er een nieuw userrecord moeten worden aangemaakt in de database.
Hier lopen twee dingen door elkaar denk ik?
Enerzijds de database-permissies die gekoppeld zijn aan een database-user, en anderzijds de bevoegdheden die iemand heeft bij gebruikmaking van een applicatie (bijvoorbeeld een website - die via deze applicatie op zijn beurt dus weer gebruik maakt van een database-user).
Deze vraag is wel relevant in die zin dat je een (aantal) keuze(s) moet moet maken waar (op welke plaats(en)) je je database (en daarmee je) applicatie beveiligt (en andersom).
Uit gebruikersgemak kun je overwegen om een database-user alle rechten te geven op een database (noot: ik zeg niet dat dit DE oplossing is, het is EEN oplossing), zodat je applicatie vervolgens ook alles kan (zowel data als structuur toevoegen/wijzigen/verwijderen).
Hiermee komt de nadruk dan wel te liggen op de veiligheid van je applicatie zelf. Maar je kunt ook heel rigoreus te werk gaan (denk aan HTTPS, wel verschillende database-gebruikers, code screening, gebruiker screening (lol), uitgebreide logging en backups et cetera). Tis maar net hoe veilig (en redundant) je je applicatie wilt maken (uitvoeren) en hoeveel tijd en geld je hier in wilt steken...
Je moet het eigenlijk omdraaien. Gegeven applicatie X bepaal je voor jezelf wanneer het veilig genoeg is. Je kunt hier op voorhand geen algemeen advies voor opstellen. En dan kun je drie simpele vragen stellen:
1. is er geld voor
2. is er tijd voor
3. is er capaciteit voor
Als het antwoord op 1 van de 3 vragen "nee" is dan ben je meteen klaar :).
Een applicatie logt in met een database user. De gebruiker van de (web)applicatie komt niet anders dan via applicatieschermen bij de gegevens die hem gepresenteerd worden voor inzage, wijzigen of verwijderen. Alles wordt bestuurd door de applicatie en de database user waarmee de applicatie inlogt kan gewoon alle rechten behorende bij de applicatie hebben, inclusief drop table en dergelijke.
Dan over: Of dat iedereen vertrouwt op de code van de programmeur.
Nee, de code van programmeur moet degelijk en monkey proef getest en goed gekeurd worden inclusief alle bekende mogelijkheden van intrusion waaronder bijvoorbeeld sql-injectie. Het is niet voor niets dat Tester (in ICT) inmiddels al een apart vak geworden is. Helaas zie je doorgaans dat bij kleine bedrijven en kleine webapplicaties het testen vrijwel nihil is uitgevoerd en dan ook nog eens door de opdrachtgever die "even een paar functies probeert"