php met mysql database. is dat veilig?

[Verwijderd]

Hallo,

Ik heb en mysql database aangemaakt met informatie die eigenlijk niet op straat mag komen te liggen.
Nu benader ik deze database op de normale manier middels php en is het systeem verder beveiligd met sessions.

Is dit veilig of kan een iemand hier moedwillig toch nog op inbreken. Ik snap dat als er ergens een 'open deur' is iemand wel in het systeem kan komen maar ik wil eigenlijk de veiligheid weten van mysql en php sessions.
Bestaat er een programma/script/site die de veiligheid van je site kan meten/bekijken??

en wat zijn de mogelijkheden van https? weet iemand misschien een (liefst nederlandstalige) site waar meer informatie hierover te vinden is.. Ik google wel wat maar blijkbaar niet met de juiste zoekterm..:(

[mithras]

Er bestaat inderdaad software waarmee je bepaalde veiligheidschecks kan uitvoeren, om te kijken of je bestand bent tegen XSS, SQL injection etc.

De veiligheid van je systeem heb je echt compleet zelf in de hand. Het hebben van sessies is niet per definitie onveilig, maar in meerdere mate afhankelijk van hoe je ermee omgaat. Stop je direct een username/password combinatie erin of een sessie id? Verifieer je die sessie ook nog serverside bijvoorbeeld in een tabel? Verloopt die sessie automatisch? Lock je aan ip-adres (of is die optie aanwezig?).

Er zijn zoveel mogelijke lekken, dit bovenstaande gaat nog slechts over authenticatie. Dan heb je nog vele stappen te gaan, denk aan bijvoorbeeld authorisatie. Is je php zo geconfigureerd dat als php stopt, je nooit bij configuratiebestanden kan komen via de webroot?

Https heeft hier in die zin weinig mee te maken, omdat het voornamelijk gaat over een versleutelde verbinding: je wil niet dat de data over de lijn af te luisteren is. Als je alsnog een prutser bent in programmeren (nofi) dan komen ze er nog steeds in.

Veiligheid in een groot net waar heel veel gaten in kunnen zitten. Daarom is het ook niet achteraf even te fixen, je zal er bij de opzet van het systeem al aan moeten beginnen Voor security moet je een budget stellen. Je kan er zelf kijken, of tegen betaling test-software aanschaffen. Is je data echt strict geheim kan je ook een l33t h4cker inhuren om je systeem te kraken. Hoe meer geld er is, hoe beter je het kan beveiligen

[ Voor 9% gewijzigd door mithras op 01-09-2009 16:13 ]

[Mike2k]

HTTPS = tegen eavesdropping.

Als je bijv geen beveiligd php script hebt (inlog script) kan je nog zoveel HTTPS er tegen aan gooien als je wil...ik kan er nog steeds bij...

In principe kun je het zelf zo veilig mogelijk maken als je wil...gewoon googlen op php login script of php autenticatie

[IStealYourGun]

Https beveiligd enkel je lijn en zelfs dat is een beetje achterhaald.
De communicatie tussen PHP en MYSQL is enkel zo veilig als dat de developer het heeft gemaakt.

Een goede developer zal een veilig script maken
Een slechte developer en onveilig script.

Kleine nota: Een goede developer is onmogelijk te meten aan hand van diploma's

[Juup]

De kans dat je als (gevorderde) amateur een goed beveiligde php webapp maakt is m.i. gering.

Als ik jou was zou ik de data offline halen en me eerst eens stevig verdiepen in veiligheid. Zoals fok recent al demonstreerde: zelfs een simpele SQL injection vulnerability heb je zo te pakken (en dat is _echt_ basis).

[André]

Move naar Programming

[Verwijderd]

Als je echt twijfelt moet je het niet aan software overlaten maar een ander bedrijf een security audit laten doen.

[curry684]

Fastex schreef op dinsdag 01 september 2009 @ 16:12:
HTTPS = tegen eavesdropping.

En niet minder belangrijk: tampering....

[GlowMouse]

Juup schreef op dinsdag 01 september 2009 @ 16:24:
De kans dat je als (gevorderde) amateur een goed beveiligde php webapp maakt is m.i. gering.

Als ik jou was zou ik de data offline halen en me eerst eens stevig verdiepen in veiligheid. Zoals fok recent al demonstreerde: zelfs een simpele SQL injection vulnerability heb je zo te pakken (en dat is _echt_ basis).

Eens met Jaaap. Dat jij dit vraagt betekent al dat je geen idee hebt wat voor aanvallen er mogelijk zijn. En zonder dat te weten kun je de veiligheid van je code ook niet controleren.

[cariolive23]

Behalve veilig programmeren, zul je ook de diverse onderdelen goed moeten configureren. Dus het OS, de firewall, webserver, databaseserver, etc. etc.

De database (mijn aandachtsgebied) zal ook verschillende databaserollen moeten hebben met de verschillende rechten op het gebruik van de database. Wanneer het echt veilig moet zijn, geef je niemand rechten op het directe gebruik van de tabellen, maar alles indirect via views en stored procedures. Die mogen heel simpel zijn, maar je kunt er al heel eenvoudig de noodzakelijke controles uitvoeren. Wanneer je dit combineert met gebruikers die ieder hun eigen databaserol hebben, kun je er voor zorgen dat niemand data van een ander kan zien. En zo kun je nog veel verder gaan met de beveiliging.

Wel jammer dat je nu pas serieus over de beveiliging gaat nadenken, dat is wat laat. Maar beter laat dan nooit!

[Verwijderd]

Net alsof iedereen hier bij zijn eerste web-app meteen de security vlag heeft gehesen, or er uberhaupt lang bij stil heeft gestaan...

@TS:

Het is misschien handig om het internet eens te raadplegen, een mooi startpunt is dit artikel, wat uit 4 sub-artikelen bestaat: http://www.addedbytes.com/php/writing-secure-php/ in dit artikel worden verschillende veiligheidstrucjes en hoe daar mee om te gaan besproken.

[ Voor 5% gewijzigd door Verwijderd op 02-09-2009 10:05 ]

[RobIII]

Verwijderd schreef op woensdag 02 september 2009 @ 10:02:
Net alsof iedereen hier bij zijn eerste web-app meteen de security vlag heeft gehesen...

Eerste web-app of niet:

Verwijderd schreef op dinsdag 01 september 2009 @ 16:04:
Ik heb en mysql database aangemaakt met informatie die eigenlijk niet op straat mag komen te liggen.

Daar had je dan eerder bij stil moeten staan. Kwestie van boerenverstand.

[Verwijderd]

Ik zeg ook niet dat het bijzonder slim is, maar ik kan me voorstellen dat men pas in een later stadium stil staat bij security vraagstukken, vooral pas nadat de roes van 'het werkt' weggebt is
Wat me meer zorgen baart is het linkje naar bsdesign... Een professionele dienstverlener die niet op de hoogte is van elementaire securitylekken is...
Anyhow, er zijn inmiddels al zoveel kreten langsgekomen waar TS iets aan moet hebben, dat ik hem alleen nog maar succes kan wensen. Succes

[ Voor 18% gewijzigd door Verwijderd op 02-09-2009 10:21 ]

[MueR]

Er zijn zeker wel programmas voor, maar die zijn vaak niet goedkoop. Een voorbeeld is de Acunetix vulnerability scanner. Mits je een volledige versie hebt, kan je gruwelijk veel informatie achterhalen. De gratis versie zal echter alleen XSS attacks scannen. Niet onbelangrijk, maar zeker niet alles. Zelfs als ervaren programmeur kreeg ik nog op mn donder van dat ding, ik had op 2 plaatsen een (minimaal) XSS lek.

[Hydra]

Verwijderd schreef op woensdag 02 september 2009 @ 10:19:
Ik zeg ook niet dat het bijzonder slim is, maar ik kan me voorstellen dat men pas in een later stadium stil staat bij security vraagstukken, vooral pas nadat de roes van 'het werkt' weggebt is

Euh. Als je je pas zorgen gaat maken over security als je alles al geimplementeerd hebt, ben je toch echt verkeerd bezig.

[Verwijderd]

Absoluut een zeer nuttige toevoeging. Het is nou eenmaal gebeurd, laten we hopen dat het niet vaker gebeurt.Mensen hebben TS gewezen op mogelijke oplossingen. Die deur stond al open voor je deze probeerde in te trappen.

[ Voor 17% gewijzigd door Verwijderd op 02-09-2009 12:03 ]

[Hydra]

Verwijderd schreef op woensdag 02 september 2009 @ 11:56:
Absoluut een zeer nuttige toevoeging. Het is nou eenmaal gebeurd, laten we hopen dat het niet vaker gebeurt.Mensen hebben TS gewezen op mogelijke oplossingen, de deur stond al open voor je deze probeerde in te trappen.

Ik reageer niet op de TS, ik reageer op jouw reactie. Jij stelt dat je je voor kunt stellen dat als alles geimplementeerd is, je je zorgen gaat maken over security. Ik kan me dat, als een klant aangeeft dat informatie gevoelig is, helemaal niet voorstellen.

[Verwijderd]

Ik kan me inderdaad voorstellen dat iemand met een zeer beperkte ervaring daar in eerste instantie niet bij stil staat. Dat jij dat niet kunt geeft verder niet, maar het is wel de dagelijkse realiteit, zie TS.
Daarmee keur ik het niet goed, maar het gebeurt, blijkbaar, nou eenmaal. dat het binnen een serieus project is gebeurd is helemaal jammer (zoals ik al aangeef baart het linkje naar bsdesign me meer zorgen). Temeer reden om TS met bruikbare tips naar huis te sturen.

[ Voor 65% gewijzigd door Verwijderd op 02-09-2009 12:07 ]

[Voutloos]

Verwijderd schreef op woensdag 02 september 2009 @ 12:04:
Daarmee keur ik het niet goed

Nuanceer het dan niet.

[Verwijderd]

Hmm, het is niet mijn bedoeling een lansje te breken voor een dergelijke andersom aanpak. Ik zal de toekomst mijn posts verder verduidelijken om misverstanden te voorkomen.

[ Voor 20% gewijzigd door Verwijderd op 02-09-2009 12:26 ]

[Grijze Vos]

cariolive23 schreef op woensdag 02 september 2009 @ 09:00:
Wanneer het echt veilig moet zijn, geef je niemand rechten op het directe gebruik van de tabellen, maar alles indirect via views en stored procedures.

Dit hoor ik wel vaker, maar heb ik nooit goed begrepen. Wat voor extra veilgheid biedt dit bovenop goede access control op de tabellen en geparametriseerde queries?

( Los van de situaties waar je die views nodig hebt om accessibility op gedeeltes van tabellen te regelen voor verschillende klassen users. )

[ Voor 14% gewijzigd door Grijze Vos op 02-09-2009 13:02 ]

[Hydra]

Grijze Vos schreef op woensdag 02 september 2009 @ 12:59:
Dit hoor ik wel vaker, maar heb ik nooit goed begrepen. Wat voor extra veilgheid biedt dit bovenop goede access control op de tabellen en geparametriseerde queries?

Nou, je kunt op die manier zorgen dat een aparte gebruiker alleen rechten op die views heeft (niet op de oorspronkelijke tabellen) en dus alleen de dingen kan zien/updaten waar 'ie recht op heeft. Als iemand dan de applicatie 'hacked' heeft 'ie alleen de gegevens van die DB user en niet de gegevens van een admin user die "overal" bij kan.

Dat is dus de theorie, maar hij zal hoe dan ook toegang hebben tot gevoelige info (mailadress, passwords, etc.), dus het is zeker geen kapstok waar je je hele beveiliging aan op wilt hangen.

[cariolive23]

Grijze Vos schreef op woensdag 02 september 2009 @ 12:59:Dit hoor ik wel vaker, maar heb ik nooit goed begrepen. Wat voor extra veilgheid biedt dit bovenop goede access control op de tabellen en geparametriseerde queries?

Wanneer je per user een databaserol hebt, kun je per record bijhouden wie de eigenaar is. Vervolgens maak je een VIEW (of SP) die alleen records opvraagt van de databaserol waarmee de databaseconnectie is gemaakt. Deze rol kan dan onmogelijk andere records zijn, wat je ook probeert.

In SP's kun je dit soort controles ook inbouwen, dat is weer handig bij UPDATE en DELETE-queries. Je kunt dan uitsluitend je eigen records bewerken, nooit de records van een ander.

Uiteraard gebruik je prepared statements, dat is de meest eenvoudige methode om SQL injection tegen te gaan.