Dear Dev,
Hope you and everyone else are enjoying Chrismas time out there.
I’ve been reading much about the dangers of SQL injects and wonder if the Coronium Core API safeguards against this?
I assume as much, but just need a confirmation for my peace of mind.
Regards,
Anaqim
Anyone else have anything to contribute on the subject? 
Looks like the client side coronium api support only coronium api commands, whereas serverside support direct sql queries. Could it be that the coronium api only allow bidrectional communication and that the sql database is only exposed to the serverside coronium api and code?
This isn’t a subject I know too much about but I’ve taken several steps so to prevent userids, tablenames and similar vital info from ever being transmitted to clients. keys are validated on the server before sql is accessed. even error logs obscure table names, but i have to admit that I am still worried about this potential hazard.
The only way to protect against SQL injection is to use parameters for every value on every statement. This stops the simple attacks such as entering
'; SELECT \* FROM \<some table that should not be exposed\>
as a search parameter.
I do that but i read that the hijacked statement can be alteret so that the server will return a list of available tables, which is why I wonder if the coronium api just doesn’t expose the SQL directly at all.
I know you have a large userbase and experience so your reply is reassuring.
What happens on my clients is they always only call custom routines on the server, and the only thing sent is username and payload.
The username is on the server side used to confirm that the user exists and lookup the 36 char alphanumeric userid which every SQL query require.
Table names are alphanumeric 40+ chars that are stored in servers side code and not tables. These table names are never returned to clients, neither are user ids. Only resulting payload is returned, and in case of errors, table names are anonymised before being stored in any error log, both on server and client side.
My main concern is if a hacker can somehow hijack the statements sent and change it to a standard SQL statement that will return a list of available tables, which is what I mean by asking if the SQL is exposed to the client side directly or not?
I am not proficient enough to test it out myself
I can’t comment on coronium as I haven’t used it but I assume the backend is MySQL. It is very easy to inject APIs if they are not hardened against such attacks. I will also assume that access to MySQL is locked down to localhost only so remote injection cannot be done against the DB unless done in a local process.
The question is what is the likely hood of coronium being incorrectly configured (to allow external access) to allow this to happen?
Given the circumstances, I would be looking for a different solution?
Yeah, i know.
I suspect it is handled properly in coronium so i’ll hold for a reply from develephant for now.
An alternative solution at this point when my app is approaching release, would be a learning curve i’d like to avoid if i can
Just wish there was another coronium user out there with experience/opinion on the issue.
Thanks for you input SGS!
Hi,
No raw SQL is sent over the wire as the API on the server handles that aspect. Additionally, all server side action is properly formatted to repel any injections even if someone could do such a thing. The payload is SSL secured and hashed in a special format that can only be decoded by the server side.
Hope that helps anyone in the future.
-dev
Chris,
Good to see Develephant on the forums again. I hope you are feeling much better.
Bob
I feel my calmer about this part of security now.
Thanks!
Anyone else have anything to contribute on the subject?
Looks like the client side coronium api support only coronium api commands, whereas serverside support direct sql queries. Could it be that the coronium api only allow bidrectional communication and that the sql database is only exposed to the serverside coronium api and code?
This isn’t a subject I know too much about but I’ve taken several steps so to prevent userids, tablenames and similar vital info from ever being transmitted to clients. keys are validated on the server before sql is accessed. even error logs obscure table names, but i have to admit that I am still worried about this potential hazard.
The only way to protect against SQL injection is to use parameters for every value on every statement. This stops the simple attacks such as entering
'; SELECT \* FROM \<some table that should not be exposed\>
as a search parameter.
I do that but i read that the hijacked statement can be alteret so that the server will return a list of available tables, which is why I wonder if the coronium api just doesn’t expose the SQL directly at all.
I know you have a large userbase and experience so your reply is reassuring.
What happens on my clients is they always only call custom routines on the server, and the only thing sent is username and payload.
The username is on the server side used to confirm that the user exists and lookup the 36 char alphanumeric userid which every SQL query require.
Table names are alphanumeric 40+ chars that are stored in servers side code and not tables. These table names are never returned to clients, neither are user ids. Only resulting payload is returned, and in case of errors, table names are anonymised before being stored in any error log, both on server and client side.
My main concern is if a hacker can somehow hijack the statements sent and change it to a standard SQL statement that will return a list of available tables, which is what I mean by asking if the SQL is exposed to the client side directly or not?
I am not proficient enough to test it out myself
I can’t comment on coronium as I haven’t used it but I assume the backend is MySQL. It is very easy to inject APIs if they are not hardened against such attacks. I will also assume that access to MySQL is locked down to localhost only so remote injection cannot be done against the DB unless done in a local process.
The question is what is the likely hood of coronium being incorrectly configured (to allow external access) to allow this to happen?
Given the circumstances, I would be looking for a different solution?
Yeah, i know.
I suspect it is handled properly in coronium so i’ll hold for a reply from develephant for now.
An alternative solution at this point when my app is approaching release, would be a learning curve i’d like to avoid if i can
Just wish there was another coronium user out there with experience/opinion on the issue.
Thanks for you input SGS!
Hi,
No raw SQL is sent over the wire as the API on the server handles that aspect. Additionally, all server side action is properly formatted to repel any injections even if someone could do such a thing. The payload is SSL secured and hashed in a special format that can only be decoded by the server side.
Hope that helps anyone in the future.
-dev
Chris,
Good to see Develephant on the forums again. I hope you are feeling much better.
Bob
I feel my calmer about this part of security now.
Thanks!