Mark’s Site

Real world example

This site has public content (what you are reading now) and secure content (pages that control what you are reading now, among other things).

For my public site, I have a MySQL user setup who only has SELECT privileges. This way, if someone does manage to find a way around my class security and tries some SQL injection code, the worst they can do is SELECT (no harm to my database).

In the secure section however, I open up permissions by using a different mysql user, one who has SELECT/INSERT/UPDATE and DELETE permissions (S/I/U/D). This allows them everything they need to manage their content. So it is safe to say I trust users that I let into my administration area because I don’t want someone who fancies themselves as a hacker into an area where I have writable permissions (such as INSERT and DELETE).

Why are writable permissions bad?

The INSERT permission is problematic, because a hacker could use it to flood my database and possibly crash my server.

The UPDATE permission is problematic because a hacker could use it to modify existing data, leading to data corruption.

The DELETE permissions is problematic, because, well, use your imagination

So you can see why you need to be careful about what permissions you allow on your public site which is accessible to anyone online. I know many applications that accept public user input and just have a single MySQL user setup with S/I/U/D permissions. This is really a hacker’s dream I imagine.

And for goodness sakes people, make sure your data is slashed before going into your SQL statement (if you don’t use prepared statements that is). Just today I added a comment into a very popular website and had it return a SQL error to my eyes because I had a single quote character in my comment. It broke the INSERT statement and showed me that if I wished, I could very easily inject SQL code into their database. The warning told me two important pieces of data:

1. that their system did not add slashes to unsafe characters, so the site was vulnerable to simple SQL injection techniques
2. the name of the comment table (because it showed me the broken SQL statement), which I could then write a series of INSERT statement to flood their system

Luckily I’m not a hacker