online gegevens beveiligen php/mysql

[Bert Bierhuis]

Hallo,

Voor een online ledenbestand willen we graag uitzoeken wat de meest
optimale manier is om gegevens te beveiligen. We maken gebruik van een
webapplicatie die is gebouwd in PHP/MySQL. Wat zijn de beste
technische manieren om de gegevens te beveiligen? (sessions, htpasswd,
shtml, etc?)

Grtn, Bert

[PietHein]

Bert Bierhuis wrote:
> Voor een online ledenbestand willen we graag uitzoeken wat de meest
> optimale manier is om gegevens te beveiligen. We maken gebruik van een
> webapplicatie die is gebouwd in PHP/MySQL. Wat zijn de beste
> technische manieren om de gegevens te beveiligen? (sessions, htpasswd,
> shtml, etc?)
>
Als je enkel de data wilt beschermen zou ik voorstellen om de stekkers uit
de server te trekken en hem in een bankkluis te stoppen. Als je nog wel wat
met die data moet doen, is het wel handig om te weten wat voor data er in
zit, wie er wel en wie er niet bij mag etc.

gr. Piet Hein

[Michiel de Roo]

Bert Bierhuis wrote:
> Hallo,
>
> Voor een online ledenbestand willen we graag uitzoeken wat de meest
> optimale manier is om gegevens te beveiligen. We maken gebruik van een
> webapplicatie die is gebouwd in PHP/MySQL. Wat zijn de beste
> technische manieren om de gegevens te beveiligen? (sessions, htpasswd,
> shtml, etc?)
>
> Grtn, Bert
>

Ik neem aan dat je bedoelt dat je de pagina met gegevens wilt afschermen
d.m.v. een login ?

Het beste in de zin van moeilijk te hacken, is een obscure php
implementatie die over ssl (https) loopt, waarschijnlijk wil je dit dan
met sessies doen.

Maar het beste in de zin van makkelijk te implementeren en gewoonlijk goed
genoeg is een http authenticatie (htpasswd).

[Vincent De Baere]

On Mon, 16 Aug 2004 16:36:47 +0200, Michiel de Roo wrote:

> Bert Bierhuis wrote:
>> Hallo,
>>
>> Voor een online ledenbestand willen we graag uitzoeken wat de meest
>> optimale manier is om gegevens te beveiligen. We maken gebruik van een
>> webapplicatie die is gebouwd in PHP/MySQL. Wat zijn de beste
>> technische manieren om de gegevens te beveiligen? (sessions, htpasswd,
>> shtml, etc?)
>>
>> Grtn, Bert
>>
>
> Ik neem aan dat je bedoelt dat je de pagina met gegevens wilt afschermen
> d.m.v. een login ?
>
> Het beste in de zin van moeilijk te hacken, is een obscure php
> implementatie die over ssl (https) loopt, waarschijnlijk wil je dit dan
> met sessies doen.

Ik dacht eerlijk gezegd net anders: ik dacht dat die HTTP-authentificatie
nu net beter was, al was het maar omdat je de toegangscontrole ook kunt
afdwingen op niet-php-geparste bestanden. Als je bovendien met de
combinatie digest auth + SSL werkt, lijkt dat me toch al een goed aanzet
te zijn, in ieder geval beter dan die php-sessies.

Anyway: het interesseert me eigenijk wel te weten te komen waarom je die
obscure php zou verkiezen boven de bovenstaande combinatie?

grtz

Vincent

[Michiel de Roo]

Vincent De Baere wrote:
> On Mon, 16 Aug 2004 16:36:47 +0200, Michiel de Roo wrote:
>
>
>>Bert Bierhuis wrote:
>>
>>>Hallo,
>>>
>>>Voor een online ledenbestand willen we graag uitzoeken wat de meest
>>>optimale manier is om gegevens te beveiligen. We maken gebruik van een
>>>webapplicatie die is gebouwd in PHP/MySQL. Wat zijn de beste
>>>technische manieren om de gegevens te beveiligen? (sessions, htpasswd,
>>>shtml, etc?)
>>>
>>>Grtn, Bert
>>>
>>
>>Ik neem aan dat je bedoelt dat je de pagina met gegevens wilt afschermen
>>d.m.v. een login ?
>>
>>Het beste in de zin van moeilijk te hacken, is een obscure php
>>implementatie die over ssl (https) loopt, waarschijnlijk wil je dit dan
>>met sessies doen.
>
>
> Ik dacht eerlijk gezegd net anders: ik dacht dat die HTTP-authentificatie
> nu net beter was, al was het maar omdat je de toegangscontrole ook kunt
> afdwingen op niet-php-geparste bestanden.

Als je dat graag wilt, dan is dat beter. OP heeft het daar echter niet
over. Ik heb het alleen over moeilijk te hacken.

> Als je bovendien met de
> combinatie digest auth + SSL werkt, lijkt dat me toch al een goed aanzet
> te zijn, in ieder geval beter dan die php-sessies.

SSL staat hier los van. Het is extra. Ook een PHP sessie authenticatie kan
via SSL lopen.

>
> Anyway: het interesseert me eigenijk wel te weten te komen waarom je die
> obscure php zou verkiezen boven de bovenstaande combinatie?

HTTP Authenticatie is een open standaard, Apache is open source. Bovendien
worden beide op grote schaal gebruikt. De kans dat een hacker hierin een
bug vindt en kan exploiteren is vele malen groter dan dat een hacker een
bug vindt in jouw eigen obscure PHP implementatie waarvan hij niet eens de
source code heeft. Ik denk eerlijk gezegd niet eens dat iemand de moeite
neemt om het te gaan proberen. Dit ongeacht het feit dat de kans op zich
groter is dat er in jouw PHP implementatie een lek zit.

>
> grtz
>
> Vincent

[Daniel Tryba]

Michiel de Roo <yourlove@welovespam.nl> wrote:
>> Anyway: het interesseert me eigenijk wel te weten te komen waarom je die
>> obscure php zou verkiezen boven de bovenstaande combinatie?
>
> HTTP Authenticatie is een open standaard, Apache is open source. Bovendien
> worden beide op grote schaal gebruikt. De kans dat een hacker hierin een
> bug vindt en kan exploiteren is vele malen groter dan dat een hacker een
> bug vindt in jouw eigen obscure PHP implementatie waarvan hij niet eens de
> source code heeft. Ik denk eerlijk gezegd niet eens dat iemand de moeite
> neemt om het te gaan proberen. Dit ongeacht het feit dat de kans op zich
> groter is dat er in jouw PHP implementatie een lek zit.

Wat een onzin... security door obscurity werkt _helemaal_ niet... Het
bewijs is het aantal fouten wat wordt gevonden in CSS.

--

Daniel Tryba

[Robrecht Jacques]

Michiel de Roo wrote:
> Vincent De Baere wrote:
>> Anyway: het interesseert me eigenijk wel te weten te komen waarom je die
>> obscure php zou verkiezen boven de bovenstaande combinatie?
>
> HTTP Authenticatie is een open standaard, Apache is open source.
> Bovendien worden beide op grote schaal gebruikt. De kans dat een hacker
> hierin een bug vindt en kan exploiteren is vele malen groter dan dat een
> hacker een bug vindt in jouw eigen obscure PHP implementatie waarvan hij
> niet eens de source code heeft. Ik denk eerlijk gezegd niet eens dat
> iemand de moeite neemt om het te gaan proberen. Dit ongeacht het feit
> dat de kans op zich groter is dat er in jouw PHP implementatie een lek zit.

De kans dat een exploit (door een _cr_acker) gevonden wordt in Apache of
HTTP-Authenticatie is misschien groter, maar de kans dat het door
_capabele_ mensen wordt gefixt nog groter (hopelijk voordat er een
exploit is). ``Many eyes make all bugs shallow´´ (Torvalds)

Een fout in een eigen implementatie zal je zelf moeten vinden en
herstellen. Ik betwijfel of jij zo'n crack bent in het schrijven van een
veilige obscure beveiliging. Hoeveel keer gebeurt het niet dat iemand
denk het warm water uitgevonden te hebben, maar SQL-code-injection of
string-termination problemen verkeerd heeft ingeschat en heel z'n
database kapot ziet gaan? Hiervoor heeft een cracker echt geen code nodig.

Mvg,
Robrecht

[Michiel de Roo]

Robrecht Jacques wrote:
> Michiel de Roo wrote:
>
>> Vincent De Baere wrote:
>>
>>> Anyway: het interesseert me eigenijk wel te weten te komen waarom je die
>>> obscure php zou verkiezen boven de bovenstaande combinatie?
>>
>>
>> HTTP Authenticatie is een open standaard, Apache is open source.
>> Bovendien worden beide op grote schaal gebruikt. De kans dat een
>> hacker hierin een bug vindt en kan exploiteren is vele malen groter
>> dan dat een hacker een bug vindt in jouw eigen obscure PHP
>> implementatie waarvan hij niet eens de source code heeft. Ik denk
>> eerlijk gezegd niet eens dat iemand de moeite neemt om het te gaan
>> proberen. Dit ongeacht het feit dat de kans op zich groter is dat er
>> in jouw PHP implementatie een lek zit.
>
>
> De kans dat een exploit (door een _cr_acker) gevonden wordt in Apache of
> HTTP-Authenticatie is misschien groter, maar de kans dat het door
> _capabele_ mensen wordt gefixt nog groter (hopelijk voordat er een
> exploit is). ``Many eyes make all bugs shallow´´ (Torvalds)

En hoe lang duurt het voor die patch wordt toegepast ?

> Een fout in een eigen implementatie zal je zelf moeten vinden en
> herstellen. Ik betwijfel of jij zo'n crack bent in het schrijven van een
> veilige obscure beveiliging.

En zo betwijfel ik of jij er de ballen verstand van hebt.....

> Hoeveel keer gebeurt het niet dat iemand
> denk het warm water uitgevonden te hebben, maar SQL-code-injection of
> string-termination problemen verkeerd heeft ingeschat en heel z'n
> database kapot ziet gaan? Hiervoor heeft een cracker echt geen code nodig.

Dit soort problemen zijn toch eenvoudig te voorkomen, iig onder PHP/mySQL.

Als je een slecht systeem schrijft is dat natuurlijk eenvoudig te kraken,
dat kan ik moeilijk ontkennen. Maar om maar weer eens die SQL injection
van stal te halen als "bewijs" dat je zelf geen authenticatie systeem moet
gaan schrijven, vind ik een beetje flauw.

[Michiel de Roo]

Daniel Tryba wrote:
> Michiel de Roo <yourlove@welovespam.nl> wrote:
>
>>>Anyway: het interesseert me eigenijk wel te weten te komen waarom je die
>>>obscure php zou verkiezen boven de bovenstaande combinatie?
>>
>>HTTP Authenticatie is een open standaard, Apache is open source. Bovendien
>>worden beide op grote schaal gebruikt. De kans dat een hacker hierin een
>>bug vindt en kan exploiteren is vele malen groter dan dat een hacker een
>>bug vindt in jouw eigen obscure PHP implementatie waarvan hij niet eens de
>>source code heeft. Ik denk eerlijk gezegd niet eens dat iemand de moeite
>>neemt om het te gaan proberen. Dit ongeacht het feit dat de kans op zich
>>groter is dat er in jouw PHP implementatie een lek zit.
>
>
> Wat een onzin... security door obscurity werkt _helemaal_ niet... Het
> bewijs is het aantal fouten wat wordt gevonden in CSS.
>

Het grote aantal beveiligingslekken dat al gevonden is in IIS, Windows,
Linux etc., bewijst dat het vertrouwen op de juistheid van de software
die je gebruikt ook niet erg op schiet. Zelfs niet als je regelmatig
patches installeert.

[Jaap-Andre de Hoop]

In article <41236965$0$568$e4fe514c@news.xs4all.nl>, Michiel de Roo <yourlove@welovespam.nl> wrote:
>
>Dit soort problemen zijn toch eenvoudig te voorkomen, iig onder PHP/mySQL.

hier kunnen ook exploitable bugs inzitten hoor, is ook open source, dus
'makkelijk' te kraken (volgens iemand uit deze draad tenminste).

Jaap-Andre

[Michiel de Roo]

Jaap-Andre de Hoop wrote:
> In article <41236965$0$568$e4fe514c@news.xs4all.nl>, Michiel de Roo <yourlove@welovespam.nl> wrote:
>
>>Dit soort problemen zijn toch eenvoudig te voorkomen, iig onder PHP/mySQL.
>
>
> hier kunnen ook exploitable bugs inzitten hoor, is ook open source, dus
> 'makkelijk' te kraken (volgens iemand uit deze draad tenminste).

Ik zeg nergens dat wat dan ook 'makkelijk' te kraken is. Ik heb het alleen
over de kans dat iemand iets gaat proberen te kraken en de kans dat dat lukt.

Maar, op zich heb je gelijk. De veiligheid van een systeem is natuurlijk
in grote mate afhankelijk van de zwakste component.

[John Bokma]

Robrecht Jacques <Robrecht.Jacques@advalvas.be> wrote in
news:41236605$0$329$ba620e4c@news.skynet.be:

> Michiel de Roo wrote:
>> Vincent De Baere wrote:
>>> Anyway: het interesseert me eigenijk wel te weten te komen waarom je
>>> die obscure php zou verkiezen boven de bovenstaande combinatie?
>>
>> HTTP Authenticatie is een open standaard, Apache is open source.
>> Bovendien worden beide op grote schaal gebruikt. De kans dat een
>> hacker hierin een bug vindt en kan exploiteren is vele malen groter
>> dan dat een hacker een bug vindt in jouw eigen obscure PHP
>> implementatie waarvan hij niet eens de source code heeft. Ik denk
>> eerlijk gezegd niet eens dat iemand de moeite neemt om het te gaan
>> proberen. Dit ongeacht het feit dat de kans op zich groter is dat er
>> in jouw PHP implementatie een lek zit.
>
> De kans dat een exploit (door een _cr_acker) gevonden wordt in Apache
> of HTTP-Authenticatie is misschien groter, maar de kans dat het door
> _capabele_ mensen wordt gefixt nog groter (hopelijk voordat er een
> exploit is). ``Many eyes make all bugs shallow´´ (Torvalds)

Soms blijft een bug behoorlijk lang in OSS zitten, ik meen mij iets te
herinneren met bind.

> Een fout in een eigen implementatie zal je zelf moeten vinden en
> herstellen. Ik betwijfel of jij zo'n crack bent in het schrijven van
> een veilige obscure beveiliging. Hoeveel keer gebeurt het niet dat
> iemand denk het warm water uitgevonden te hebben, maar
> SQL-code-injection of string-termination problemen verkeerd heeft
> ingeschat en heel z'n database kapot ziet gaan? Hiervoor heeft een
> cracker echt geen code nodig.

Klopt. Aan de andere kant, als je een beveiling maakt (wat jij
beschrijft is geen zwakke beveiliging, het is slechte code), en er zit
een fout in (en dus niet the obvious), is de kans klein dat deze ontdekt
wordt door een cracker.

OTOH, ik geef bij het ontwikkelen nog steeds de voorkeur aan libraries
die door zoveel mogelijk mensen gebruikt worden. Ben lui :-D.

--
John Voorbeeldscripts in Perl:http://johnbokma.com/perl/
Website design: http://johnbokma.com/websitedesign/
Ervaren Perl / Java programmeur beschikbaar: http://castleamber.com/
Tevreden opdrachtgevers: http://castleamber.com/testimonials.html

[John Bokma]

Michiel de Roo <yourlove@welovespam.nl> wrote in
news:41236965$0$568$e4fe514c@news.xs4all.nl:

> Robrecht Jacques wrote:
>> Michiel de Roo wrote:
>>
>>> Vincent De Baere wrote:
>>>
>>>> Anyway: het interesseert me eigenijk wel te weten te komen waarom
>>>> je die obscure php zou verkiezen boven de bovenstaande combinatie?
>>>
>>>
>>> HTTP Authenticatie is een open standaard, Apache is open source.
>>> Bovendien worden beide op grote schaal gebruikt. De kans dat een
>>> hacker hierin een bug vindt en kan exploiteren is vele malen groter
>>> dan dat een hacker een bug vindt in jouw eigen obscure PHP
>>> implementatie waarvan hij niet eens de source code heeft. Ik denk
>>> eerlijk gezegd niet eens dat iemand de moeite neemt om het te gaan
>>> proberen. Dit ongeacht het feit dat de kans op zich groter is dat er
>>> in jouw PHP implementatie een lek zit.
>>
>>
>> De kans dat een exploit (door een _cr_acker) gevonden wordt in Apache
>> of HTTP-Authenticatie is misschien groter, maar de kans dat het door
>> _capabele_ mensen wordt gefixt nog groter (hopelijk voordat er een
>> exploit is). ``Many eyes make all bugs shallow´´ (Torvalds)
>
> En hoe lang duurt het voor die patch wordt toegepast ?

Dat hangt extreem af van het nivo van de systeembeheerder, en de
prioriteiten. Ik hoor nog steeds van mensen die op systemen moeten
werken met Perl versie 5.0xxxx. (Wat met het OS kwam, men wil er
minimaal dingen op installeren, vanwege... security!)

--
John Voorbeeldscripts in Perl:http://johnbokma.com/perl/
Website design: http://johnbokma.com/websitedesign/
Ervaren Perl / Java programmeur beschikbaar: http://castleamber.com/
Tevreden opdrachtgevers: http://castleamber.com/testimonials.html

[Branko Collin]

Daniel Tryba wrote:

> security door obscurity werkt _helemaal_ niet...

Het grootste probleem in beveiliging is het blindelings volgen van dogma's
als de bovenstaande. Niet vanwege de vermeende waar- of onwaarheid van zo'n
dogma, maar vanwege het 'blindelings'. Je moet altijd alert blijven, en
alle middelen gebruiken die tot je beschikking staan.