[php] advies met betrekking tot beveiliging

[tombo_inc]

beste mensen,

ik ben momenteel met een groot project van mij bezig. het betreft een soort van template engine. nu bestaat de core uit een aantal objecten die allemaal het een en ander afhandelen. er komen uiteraard ook database query's in voor, en die query zijn soms variabel. nu komen deze variabelen niet van de client kant af maar gewoon uit een van de andere core objecten. is het nodig of verstandig om deze variabelen in mijn query's ook te beveiligen tegen eventuele attacks of andere narigheid die er misschien op een of andere manier zou kunnen ontstaan, of is dit gewoon overbodig en kost het me alleen maar parsetime en extra programmeer werk.
graag jullie mening hierover

[Morrar]

Tsja als je gegevens uit de input gebruikt *moet* je die altijd controleren, anders ontstaan er veiligheidslekken. De controle van de gegevens is ook afhankelijk van waarvoor ze uiteindelijk gebruikt worden. Als ze naar de browser gaan codeer / beveilig je andere zaken dan wanneer je ze in een SQL query stopt. In eerste geval wil je iets als html_entities() gebruiken, in het tweede geval eerder mysql_escape_string().

[tombo_inc]

ja dat snap ik, maar in mijn geval komt er geen userinput binnen. het gaat hier over data die van script naar script gaat.

[Brakkie]

Tombo_inc schreef op vrijdag 25 maart 2005 @ 13:14:
ja dat snap ik, maar in mijn geval komt er geen userinput binnen. het gaat hier over data die van script naar script gaat.

Beetje vaag verhaal als je het mij vraagt. Je weet zelf toch wat voor data je script te verwerken krijgt en of daar eventueel dingen mee kunnen gebeuren die niet de bedoeling zijn. Als er tekens in staan die query's kunnen beinvloeden moet je die gaan escapen. Bijv: ' ;

Ik zorg zelf altijd dat ik zeker weet dat data van het juiste type is en dat er geen fouten door kunnen ontstaan wanneer ik data gebruik in een query.

[raptorix]

In ieder geval een database gebruiken met een fatsoenlijke security, daarnaast gebruik maken van stored procedures, en deze stored procedures onder een fatsoenlijke account laten uitvoeren.
Voorts geen dynamische SQL in je stored procedures gebruiken anders kom je daar weer mee in problemen.

Tip: Gebruik een echte database en geen prut.

[NMe]

Wanneer je klassen maakt, dan zijn die losstaand, en moeten ze op input van elke bron kunnen reageren. Wat als je eenzelfde object wil gebruiken als nu, maar je wil er deze keer wel input van buitenaf mee verwerken?

Ikzelf heb eens een object gemaakt, dat eerst alleen voor intern gebruik was, en geen input te verwerken kreeg. Later besloot ik dat dat object ook wel voor input vanaf een form te gebruiken was, die afhandeling was gewoon veel handiger. Maar ik had in dat object natuurlijk geen beveiliging ingebouwd, en bij de aanroep/het gebruik ervan ook niet. Beveiligingslek dus.

Wanneer ik nu een object heb dat redelijkerwijs ooit eens hergebruikt zou kunnen worden voor user input, dan bouw ik toch gewoon beveiliging in, zelfs als dat betekent dat die beveiliging dan dubbelop gebeurt. (Bijvoorbeeld addslashes in het aanroepende object, èn in het aangeroepen object.)

[Brakkie]

Tip: Gebruik een echte database en geen prut.

Advies waar je wat mee kan! Verklaar je nader...

[simon]

raptorix schreef op vrijdag 25 maart 2005 @ 15:34:
In ieder geval een database gebruiken met een fatsoenlijke security, daarnaast gebruik maken van stored procedures, en deze stored procedures onder een fatsoenlijke account laten uitvoeren.
Voorts geen dynamische SQL in je stored procedures gebruiken anders kom je daar weer mee in problemen.

Tip: Gebruik een echte database en geen prut.

no offence, maar dat is gebral. Het gaat erom dat je de boel gebruikt waarvoor het gemaakt is, MySQL opzich kan best veilig werken.. Zolang je de boel eromheen maar niet pruttig regelt

[tombo_inc]

-NMe- schreef op vrijdag 25 maart 2005 @ 15:41:
Wanneer je klassen maakt, dan zijn die losstaand, en moeten ze op input van elke bron kunnen reageren. Wat als je eenzelfde object wil gebruiken als nu, maar je wil er deze keer wel input van buitenaf mee verwerken?

Ikzelf heb eens een object gemaakt, dat eerst alleen voor intern gebruik was, en geen input te verwerken kreeg. Later besloot ik dat dat object ook wel voor input vanaf een form te gebruiken was, die afhandeling was gewoon veel handiger. Maar ik had in dat object natuurlijk geen beveiliging ingebouwd, en bij de aanroep/het gebruik ervan ook niet. Beveiligingslek dus.

Wanneer ik nu een object heb dat redelijkerwijs ooit eens hergebruikt zou kunnen worden voor user input, dan bouw ik toch gewoon beveiliging in, zelfs als dat betekent dat die beveiliging dan dubbelop gebeurt. (Bijvoorbeeld addslashes in het aanroepende object, èn in het aangeroepen object.)

ok hier heb ik wat aan. gewoon die handel beveiligen dus (je weet ook maar nooit waar kwaadwillende allemaal gaten kunnen vinden). ook al is het nu niet expliciet nodig dan kan het altijd voor later nog handig zijn als ik het goed begrijp.

ps. wat zijn stored procedures?

[NMe]

Tombo_inc schreef op vrijdag 25 maart 2005 @ 17:01:
ok hier heb ik wat aan. gewoon die handel beveiligen dus (je weet ook maar nooit waar kwaadwillende allemaal gaten kunnen vinden). ook al is het nu niet expliciet nodig dan kan het altijd voor later nog handig zijn als ik het goed begrijp.

Euh, zolang er geen input van gebruikers in komt, dan is het ook gewoon veilig als je geen addslashes en dergelijke gebruikt in je queries. Ik pas het zelf alleen met het oog op de toekomst toe, voor het geval dat. Kwaadwillende gebruikers kunnen niets met lekken in je code als ze er geen invoer in gooien.

ps. wat zijn stored procedures?

Vooraf opgeslagen procedures in je DBMS; worden door MySQL niet ondersteund voor zover ik weet.

[raptorix]

Simon schreef op vrijdag 25 maart 2005 @ 16:27:
[...]

no offence, maar dat is gebral. Het gaat erom dat je de boel gebruikt waarvoor het gemaakt is, MySQL opzich kan best veilig werken.. Zolang je de boel eromheen maar niet pruttig regelt

En dat is juist het hele punt, om je database te beschermen dien je vanuit je code allerlei zaken te securen, en dat is precies het zwakke punt. Als je een fatsoenlijke database met een fastsoenlijk security model gebruikt, hoef je daar niet meer wakker om te liggen.

Mensen die MySql gebruiken, doen dat voor 97% uit macht der gewoonte, niet omdat het een goede database is.

Maargoed, een op feiten gebaseerde discussie aangaan met PHP/MySql gebruikers is zinloos, bovendien zal ik wel weer het argument naar me kop krijgen dat ik aan het flamen ben.

[simon]

raptorix schreef op vrijdag 25 maart 2005 @ 17:06:
[...]

En dat is juist het hele punt, om je database te beschermen dien je vanuit je code allerlei zaken te securen, en dat is precies het zwakke punt. Als je een fatsoenlijke database met een fastsoenlijk security model gebruikt, hoef je daar niet meer wakker om te liggen.

Mensen die MySql gebruiken, doen dat voor 97% uit macht der gewoonte, niet omdat het een goede database is.

Maargoed, een op feiten gebaseerde discussie aangaan met PHP/MySql gebruikers is zinloos, bovendien zal ik wel weer het argument naar me kop krijgen dat ik aan het flamen ben.

Dat kan ik wel zien, maar als je neem nou MSSQL draait zijn er nog genoeg zelfde manieren om de boel te slopen, en nu lijkt me de keuze voor MSSQL op bijvoorbeeld een kleine site vreemd. Dat je dan consessies moet doen vind ik logica, en om dan te zeggen "MySQL is bagger" vind ik vreemd, want het werkt heel goed waar het gemaakt voor is, zolang je er maar geen écht belangrijke gegevens in propt, want voor je 't weet ben je ze kwijt...

[tombo_inc]

-NMe- schreef op vrijdag 25 maart 2005 @ 17:06:
[...]

Euh, zolang er geen input van gebruikers in komt, dan is het ook gewoon veilig als je geen addslashes en dergelijke gebruikt in je queries. Ik pas het zelf alleen met het oog op de toekomst toe, voor het geval dat. Kwaadwillende gebruikers kunnen niets met lekken in je code als ze er geen invoer in gooien.


[...]

Vooraf opgeslagen procedures in je DBMS; worden door MySQL niet ondersteund voor zover ik weet.

ok, maar in princiepe hoef je dus niks te beveiligen als je er zeker van bent dat er geen userinput bij kan komen.

[NMe]

Tombo_inc schreef op vrijdag 25 maart 2005 @ 17:20:
ok, maar in princiepe hoef je dus niks te beveiligen als je er zeker van bent dat er geen userinput bij kan komen.

Nee, maar dan ook echt alleen als je dat zeker weet, IMO.

raptorix schreef op vrijdag 25 maart 2005 @ 17:06:
Mensen die MySql gebruiken, doen dat voor 97% uit macht der gewoonte, niet omdat het een goede database is.

Ik denk dat het meer komt omdat hosters liever een Linux server in combinatie met Apache gebruiken, en dat MySQL voor Linux servers nog altijd een van de betere gratis keuzes is. Ik zie MS SQL Server er nog niet op draaien iig. ;)[/]

Maargoed, een op feiten gebaseerde discussie aangaan met PHP/MySql gebruikers is zinloos, bovendien zal ik wel weer het argument naar me kop krijgen dat ik aan het flamen ben.

Tot aan deze zin vond ik je argumentatie nog redelijk netjes en onderbouwd, maar dit vind ik inderdaad gewoon stomweg een troll. Ik ben de laatste die zal zeggen dat MySQL een goeie database is, en ik zou het graag beter zien. Maar het is nou eenmaal het meest ondersteunde systeem, en daar doe je niet veel tegen. Geen reden om zo onder de gordel te slaan iig.

[ Voor 64% gewijzigd door NMe op 25-03-2005 17:37 ]

[Grijze Vos]

raptorix schreef op vrijdag 25 maart 2005 @ 17:06:
[...]

En dat is juist het hele punt, om je database te beschermen dien je vanuit je code allerlei zaken te securen, en dat is precies het zwakke punt. Als je een fatsoenlijke database met een fastsoenlijk security model gebruikt, hoef je daar niet meer wakker om te liggen.

Mensen die MySql gebruiken, doen dat voor 97% uit macht der gewoonte, niet omdat het een goede database is.

Nee, omdat het makkelijk toegankelijk is, door veel hosters ondersteund wordt, en daarnaast een prima RDMS is voor regulier gebruik.

Maargoed, een op feiten gebaseerde discussie aangaan met PHP/MySql gebruikers is zinloos, bovendien zal ik wel weer het argument naar me kop krijgen dat ik aan het flamen ben.

Je bent ook aan het flamen, sterker nog, je komt zelf niet eens met feiten aanzetten.

Over je argument: Stel jij aan een windows gebruiker ook voor om maar meteen over te stappen op NetBSD, omdat Windows een prut security heeft?

[raptorix]

Grijze Vos schreef op vrijdag 25 maart 2005 @ 18:21:
[...]
Nee, omdat het makkelijk toegankelijk is, door veel hosters ondersteund wordt, en daarnaast een prima RDMS is voor regulier gebruik.


[...]

Je bent ook aan het flamen, sterker nog, je komt zelf niet eens met feiten aanzetten.

Over je argument: Stel jij aan een windows gebruiker ook voor om maar meteen over te stappen op NetBSD, omdat Windows een prut security heeft?

MySql is zoals bij de meeste mensen gebruikt geen RDMS, daarnaast waar baseer je het op dat Windows een prut security heeft? Dat de meeste mensen niet verder kijken als hun neus lang is op gebied van windows security is niet mijn zorg. Zo kan je prima een service draaien onder minimale rechten.

Bovendien zijn er prima gratis alternatieven voor Linux, neem bijvoorbeeld het veel betere Postgres.
En tjah dat de meeste hosters alleen PHP/MySql aanbieden, kom ik weer terug op mijn eerste zin: Macht der gewoonte. Als je het over security van een applicatie hebt, moet je verder kijken als het afvangen van problemen op ScriptLevel Niveau.

[Suepahfly]

offtopic:
MySQL is prima te beveiligen hoor. Op de meeste webservers hoef je geen connectie naar buiten te maken, dus gooi je poort 3360 dicht op de firewall. Daarnaast wou je tcp networking helemal kunnen uitschakelen en alleen gebruikmaken van sockets.

Het feit dat de meeste ISP's voor MySQL kiezen is denk ik meer van wege de snelheid (MySQL is volgens veel rapporten als PostGre) en dingen als stored procedures / relaties heb je vaak niet nodig voor de gemmidelde web app. Daarnaast is het onderhoudt aan mysql vrij simpel.

Het wordt alleen lastig als je machine crashed. Dan kun je er wel van uit gaan dat je corrupte tabbellenn krijgt. Voor meer kritieke applicaties zou ik toch eerder voor een commerciele oplossing gaan.

Als MySQL echt zo enorm bagger zou zijn hadden ze het waarschijnlijk ook niet voor GoT gebruikt

[NMe]

raptorix schreef op zaterdag 26 maart 2005 @ 12:21:
MySql is zoals bij de meeste mensen gebruikt geen RDMS, daarnaast waar baseer je het op dat Windows een prut security heeft? Dat de meeste mensen niet verder kijken als hun neus lang is op gebied van windows security is niet mijn zorg. Zo kan je prima een service draaien onder minimale rechten.

offtopic:
Zet maar eens een verse Win2k install zonder firewall van een extern bedrijf op je netwerk, dat op internet is aangesloten dan.

Bovendien zijn er prima gratis alternatieven voor Linux, neem bijvoorbeeld het veel betere Postgres.
En tjah dat de meeste hosters alleen PHP/MySql aanbieden, kom ik weer terug op mijn eerste zin: Macht der gewoonte. Als je het over security van een applicatie hebt, moet je verder kijken als het afvangen van problemen op ScriptLevel Niveau.

Die alternatieven zijn er inderdaad. Maar hoe wil je ervoor zorgen dat je site, die met Postgres gemaakt is, werkt op het grootste deel van de webservers? Je bent nou eenmaal afhankelijk van wat hosters installeren. Verder, bieden steeds meer hosts de mogelijkheid om InnoDB-tabellen te maken, die dat wel weer relationeel te maken zijn, en waarmee je integriteit kan afdwingen. Het maakt geen goed DBMS van MySQL, maar het gaat de goeie kant op. En als je goed programmeert, dan maakt het verder ook niet uit.

[tombo_inc]

wat een simpele vraag over beveiliging wel niet allemaal los kan maken
maar zo leer ik ook wat over mysql ed.

[raptorix]

-NMe- schreef op zaterdag 26 maart 2005 @ 13:38:
En als je goed programmeert, dan maakt het verder ook niet uit.

Nogmaals zeg ik dan weer, veiligigheid dwing je vanuit je database af, niet vanuit je applicatie.

[simon]

raptorix schreef op zaterdag 26 maart 2005 @ 21:55:
[...]

Nogmaals zeg ik dan weer, veiligigheid dwing je vanuit je database af, niet vanuit je applicatie.

Ik weet niet wat voor applicaties jij maakt, maar blijkbaar staat veiligheid niet voorop bij die applicaties.

[Suepahfly]

raptorix schreef op zaterdag 26 maart 2005 @ 21:55:
[...]

Nogmaals zeg ik dan weer, veiligigheid dwing je vanuit je database af, niet vanuit je applicatie.

Dus jij schrijft gewoon:

PHP:

if($admin)
{
    //hier je admin verhaal
}
else
{
   echo "je bent geen admin";
}

en dat met register_global=on ?

Ik zie niet hoe je dit met een database wilt afvangen.

[NMe]

raptorix schreef op zaterdag 26 maart 2005 @ 21:55:
Nogmaals zeg ik dan weer, veiligigheid dwing je vanuit je database af, niet vanuit je applicatie.

Veiligheid dwing je af waar dat mogelijk is. Wordt je database gelimiteerd op dat gebied, dan doe je het gewoon in je applicatie. Geen enkel probleem. Het is ook zo'n groot probleem om addslashes te gebruiken om elke string die je erin stopt he?

[raptorix]

Modbreak:

Prima. En nu weer ontopic verder....

[ Voor 90% gewijzigd door Creepy op 27-03-2005 00:25 ]

[Suepahfly]

Even back ontopic.

Of het nu om user input of applicate gegenereerde intput gaat, alles wat ik in query stop wordt gecontroleerd en ge-escaped. Daarvoor gebruik ik een database abstraction layer die queries afhandeld.

Userinput controleer ik altijd nog een keer voor dat ik het in een queriylaat schrijven. Dat wordt dus dubbel gecheckt.

Hoewel ik weinig ervaring met databases anders als mysql/myisam lijkt het mij zeer mogelijk om
"; select * from admin;" te doen om maar een voobeeld te noemen.