According to this question looks that connect a SQL database from javascript is strongly recommended against and has security issues.
Could you please specify what exactly is problematic and why?
-
4If it is JavaScript in the browser is a bad idea because: View Source - see connection info or query - create own query, delete all your dataepascarello– epascarello2015-04-17 12:53:50 +00:00Commented Apr 17, 2015 at 12:53
-
If the SQL statements are clientside, your database would be wide open to anyone who chooses to send any SQL statement to you DB.adeneo– adeneo2015-04-17 12:54:23 +00:00Commented Apr 17, 2015 at 12:54
-
"connect a sql database from javascript is strongly in recommended" You mean: strongly recommended against?Tim Schmelter– Tim Schmelter2015-04-17 12:59:12 +00:00Commented Apr 17, 2015 at 12:59
-
What if along with the query I send its (custom/encrypted) hash, and the receiving side makes sure the query wasn't modified or isn't even completely uncalled for? The potential intruder won't know the hash to send with their "delete all_users". I've seen this method used in thumbnail urls with downscale options in the address when the full sizes are behind a paywall. You'd want to change the res to get one for free, but the hash doesn't match.Seedmanc– Seedmanc2023-03-13 15:25:07 +00:00Commented Mar 13, 2023 at 15:25
Add a comment
|
3 Answers
delete all_users
No, for real! Do you really want to allow anyone to access your database and edit it as they like? There is no way to secure access in any way if you just give anyone access!
Your username and password will be exposed so everyone can alter your database. Javascript is not safe for saving passwords!
5 Comments
YAKOVM
can`t user run it from sqlcmd?
Patrick Hofman
From the web, I hope not. Else you should check your DMZ, something like right now.
Neil Smithline
@Yakov - you need a DB uname/pwd to access the database. You normally keep that on your middleware. But if your JavaScript accesses the DB you'll need your uname/pwd in the client. So, even if your firewall allows DB access, the creds need to stay private.
Patrick Hofman
@lloydm I would love to see that happen ;)
Patrick Hofman
@Yakov: need more help?
Lets honestly break this down here..
So you have an application that requires data. That data needs to come from somewhere. You can get that data from an SQL database.
Now while SQL has permission based access etc, to properly secure something that is literally "open to the wild" you would have to lock it down pretty hardcore. This is not particularly easy with SQL (compared to other technologies) and can leave you open to a few things.
An SQL server is designed to be in a closed environment where only the server-side code will communicate with it. To get data from it you need a username/password. So this would have to be stored client-side. So you can now get your data. And you only get the data you need. But what is stopping any real-world user trying to get more. Well unless you locked down every table and every stored proc and all the other stuff - nothing. Also, what is stopping the user just leaching the entire database? From what I know about SQL you can't limit a user at getting a certain number of rows.
What a proxy service - or web service, or any kind of front end service designed to be used by the public does is provide some way for you to filter or set limits on what can be accessed. If your application only requires certain data, then the service will only ever provide that data. The call is fixed - getUserProfile(). The server already knows the current user so it will only get that user's details. If there were a getUserProfile(65), how would you really know if user '65' was actually the one requesting it?
SQL doesn't understand the complexities of cookies or session variables, it just says 'hey, there's a valid username and password, give them all the things they have access to!' It is not designed to only return one row based on the user.
So to summarise, you cant control how much data a user can access so you use a web service that understands what the user should be seeing, and only provide that information.
...And this is just reading from the database - writing is a whole new level of pain and suffering.
TL;DR This is a bad idea
Comments
Can you say : where is javascript executed? If you say : user's browser, your answer is correct. So you have sent codes with connection string, all to users, all around the worls. Many don't know how to use it, but many know it very well. They have lock and key. Hope it helped you.
