[MySQL] secure of niet?

[Verwijderd]

ik ben op het moment bezig met een project waar waarshijnlijk veel gebruikers bij komen kijken en er zullen betalingsgegevens verwerkt worden.
ik heb nu een tabel waar de account gegevens in staan en ook de betalingsgegevens.
nu is mijn vraag:
is het voor iemand met kwade bedoelingen makkelijk om hier bij te komen?
kan ik beter 2 tabellen maken (1 account en 1 betalingsgegevens) en die tabel beveiligen?
moet ik werken met https, zo ja, hoe.

[CaptBiele]

volgens mij haal je 2 zaken door elkaar:
1) het beveiligen van je mySQL data. Hiervoor heb je verschillende mogelijkheden. Wat heb je zelf al uitgezocht?
2) het beveiligen van het dataverkeer. Als je een https verbinding opzet, kunnen buitenstaanders geen data uitlezen op de lijn. Om dit te realiseren moet je een certificaat aanvragen.

lijkt me toch niet dat je de enige bent met zo'n probleem.

Overigens lijkt het me niet zo verstandig om je tabellen te gaan splitsen voor beveiliging. Een goede structuur is meer afhankelijk van de business logic.

[ Voor 18% gewijzigd door CaptBiele op 23-05-2006 12:43 ]

[Keiichi]

Een methode die ik gebruik is gewoon de MySQL enkel op localhost laten luisteren. Een server in een private network zou nog iets beter wezen aangezien als iemand op de server inbreekt, dat deze nog steeds niet bij de MySQL server is.

Als de server ergens anders op het internet zich bevind: Of met SSL werken, of een IPSEC tunnel gebruiken.

[Gomez12]

Verwijderd schreef op dinsdag 23 mei 2006 @ 12:19:
ik ben op het moment bezig met een project waar waarshijnlijk veel gebruikers bij komen kijken en er zullen betalingsgegevens verwerkt worden.
ik heb nu een tabel waar de account gegevens in staan en ook de betalingsgegevens.
nu is mijn vraag:
is het voor iemand met kwade bedoelingen makkelijk om hier bij te komen?
kan ik beter 2 tabellen maken (1 account en 1 betalingsgegevens) en die tabel beveiligen?
moet ik werken met https, zo ja, hoe.

Aangezien ik er vanuit ga dat geen enkele gebruiker rechtstreeks toegang heeft tot de mysql dbase, maar alles via php / asp / weet ik veel wat voor serverside language gaat lopen, is je dbase veilig hoe je het ook inricht.

Zorg er gewoon voor dat je gebruikers maar 1 ingangspunt hebben ( website??? ) dan is dat het enige zwakke punt. Laat jij daarin steken vallen dan dondert de rest toch wel om, maakt niet uit of je 1 tabel of 2 tabellen hebt.

[Suepahfly]

Als je mysql draait op de zelfde server als je webserver kan je gebruik maken van sockets en tcp connecties in mysql uitzetten. Dan kan alleen een applicatie op dezelfde machine als waar mysql draait ook daadwerkelijk met mysql communiceren.

Verder moet je er natuurlijk voor zorgen dat je applicatie tegen xss is beveiligd en dat je alle variabelen check voor je ze in een query gooit.

[frickY]

Toen ik eens een online betaalsysteem heb moeten opzetten hebben we het ongeveer zo aangepakt;
- MySQL database directory (de map waarin mysql alles opslaat) enkel en alleen toegankelijk voo een aparte gebruiker, waar MySQL onder draait
Zo voorkom je dat als iemand toegang krijgt tot de server. Danwel fysiek, danwel via een lek PHP script, de map onbenaderbaar is zonder het watchtwoord te weten waaronder MySQL draait.

- Vanuit PHP de betaalgegevens laten coderen met RSA256, met een MySQL gebruiker zonder lees (maar wel schrijf) op de betaalgegevens kolommen.
Mocht je MySQL gebruiker, om wat voor reden dan ook, uitlekker (bijv een stagiair upgrade je ebserver waardoor je php bestanden plots niet meer geparsed worden, en al je sources publiek zichtbaar zijn (seen it happen)) dan is die nog steeds nutteloos.

- Uiteraard een HTTPS verbinding tussen de gebruiker en de PHP applicatie
Lijkt me duidelijk

Verder al het logische. Zoals een gefirewallde web en database server. Bij voorkeur had ik ook de PHP-sourcecodes nog willen coderen met ZEND-encoder om de RSA-key veilig te stellen, maar dat werd even een tikkeltje te duur
En natuurlijk, gegevens vernietigen zodra je deze niet meer nodig hebt, om bij een eventueel lek de schade tot een minimum te beperken.

[ Voor 40% gewijzigd door frickY op 27-05-2006 18:58 ]

[Sv3n]

Gomez12 schreef op zaterdag 27 mei 2006 @ 18:19:
[...]


Aangezien ik er vanuit ga dat geen enkele gebruiker rechtstreeks toegang heeft tot de mysql dbase, maar alles via php / asp / weet ik veel wat voor serverside language gaat lopen, is je dbase veilig hoe je het ook inricht.

Dat zou ik niet zo snel zeggen. Als jij poort 3306 op laten staan en sockets staan gewoon aan in mysql heb je dus wel een probleem. Verder moet je bij het coden verdomd goed opletten dat er nergens dingen als sql injecties mogelijk zijn.

Https moet absoluut, anders gaat wachtwoorden en dergelijke als tekst over de lijn en kan het gemakkelijk gefilterd worden.
Tabellen splitsen lijkt me niet nodig, als iemand eenmaal bij de database kan, kan hij toch wel bij alle gegevens komen.

[eamelink]

frickY schreef op zaterdag 27 mei 2006 @ 18:54:
Toen ik eens een online betaalsysteem heb moeten opzetten hebben we het ongeveer zo aangepakt;
- MySQL database directory (de map waarin mysql alles opslaat) enkel en alleen toegankelijk voo een aparte gebruiker, waar MySQL onder draait
Zo voorkom je dat als iemand toegang krijgt tot de server. Danwel fysiek, danwel via een lek PHP script, de map onbenaderbaar is zonder het watchtwoord te weten waaronder MySQL draait.

Mjah, maar als iemand fysiek bij de bak komt is het een kwestie van single user mode booten en het root- en daarna mysql password veranderen.

Het beveiligen daartegen is ook wel te doen; maar dat is meer algemeen dan specifiek mysql beveiligen

- Vanuit PHP de betaalgegevens laten coderen met RSA256, met een MySQL gebruiker zonder lees (maar wel schrijf) op de betaalgegevens kolommen.
Mocht je MySQL gebruiker, om wat voor reden dan ook, uitlekker (bijv een stagiair upgrade je ebserver waardoor je php bestanden plots niet meer geparsed worden, en al je sources publiek zichtbaar zijn (seen it happen)) dan is die nog steeds nutteloos.

Dat is inderdaad wel handig. Overigens is het ook wel handig om je configfiles in een directory te hebben waar apache niet uit serveert, en die met een include binnen te halen; mocht er dan niets meer geparsed worden kan je nog steeds niet bij die wachtwoorden

- Uiteraard een HTTPS verbinding tussen de gebruiker en de PHP applicatie
Lijkt me duidelijk

Bij voorkeur had ik ook de PHP-sourcecodes nog willen coderen met ZEND-encoder om de RSA-key veilig te stellen, maar dat werd even een tikkeltje te duur

Ach, php gebruikt die key, dus die is ongetwijfeld weer uit te halen . Het encoden is meer een soort combinatie van obfuscaten en omzetten naar bytecode; de compiler moet het tenslotte gewoon weer kunnen lezen PHP code zal je er niet uit kunnen halen, maar zo'n key waarschijnlijk wel

En natuurlijk, gegevens vernietigen zodra je deze niet meer nodig hebt, om bij een eventueel lek de schade tot een minimum te beperken.

Dat is inderdaad heel verstandig

[StevenK]

frickY schreef op zaterdag 27 mei 2006 @ 18:54:
Mocht je MySQL gebruiker, om wat voor reden dan ook, uitlekker (bijv een stagiair upgrade je ebserver waardoor je php bestanden plots niet meer geparsed worden, en al je sources publiek zichtbaar zijn (seen it happen)) dan is die nog steeds nutteloos.

Precies de reden waarom in de stukken code met dit soort belangrijke informatie altijd include van buiten de http root.