The concept I have uses a central MySql database which has many Java clients running and using this database (connecting directly). The clients would be publically available, so security becomes an issue.
As Java can be decompiled, I cannot put the security part of this system into the client application. I’ll need to have an initial username/password to access the database, but beyond that, I can’t really secure anything in the client, as a hacker could just extract the connection data and write his own app for hacking.
So, this led me to paramaterised stored procedures. This would allow me to secure the database a little by restricting permissions to just SELECT & EXECUTE. And, I was thinking about having each SP have username/password paramaters, so a users permission level could be verified with each call to the SP to prevent low level users from being able to hack/use admin SPs.
This appears to give a certain amount of security, and allows for multi-level access to the database, but then I got to SQL injection.
If I’m using paramaterised SPs, how can I clean the paramaters before the SP runs them onto the database? In PhP this is simple, but with a locally run Java client, I have no server side application to do this work. I know I could put some kind of server-side application inbetween the database & the client, but I want to avoid that if at all possible.
Is this possible to achieve?
Will it then be ‘secure’?
Is this the right way to go about this, or is there a better way to implement security of this kind using this architecture?
I think you need to go three-tier. You cannot expose your database directly to untrusted clients. You want an application server to sit in between. The end users would log in to the application server (ideally with a separate username/password for every single user, that that user enters, and that is not contained in the application). Only the application server connects to the database, and it only does what it deems fit (as in: not directly running any kind of SQL that it gets from clients, but defining a number of methods/queries that are allowed).
If you still want to directly go from client to database, at least create individual database user accounts (and no hard-coded passwords). But this (managing all the permissions appropriately) may end up to be too big a hassle for the DBA, and a configuration mistake can lead to huge security problems.