And so we come full circle
you design something cos there's things in the old way you dont like and just a few years later you find you've had to add them all back in to your new product and the differences between the two are mere accents.
We are becoming more and more accustomed to reading about losses of online data through malicious hack attacks, accidents, and downright carelessness – it’s almost as if we don’t know how to secure data against the most common forms of attack. Of course, that isn’t really true as best practice, legislation, and education on …
This post has been deleted by its author
"NoSQL is, or was meant to be (you pick) the future architecture, an opportunity, almost, to start afresh. Given that and with the wealth of knowledge that's amassed from decades of SQL, you'd think NoSQL databases and systems wouldn’t fall into the same traps as the previous generations of RDBM systems"
The problem is not the RDBM systems, as any DBA will tell you. Any of the major products has more than enough security - the issue is poorly-trained or lazy developers who allow the users to access database tables by executing ad-hoc SQL. Doing this means that the user has to have read, update and delete permissions on all tables. The correct way to access data is through stored procedures and views so that the user has no direct access to anything in the database other than the procedures/views they need to perform the task. Doing this effectively precludes the possibility of SQL injection. However, whilst the people who do the training/teaching have little or no knowledge of database security, data breaches will continue to happen
"as any DBA will tell you. Any of the major products has more than enough security - the issue is poorly-trained or lazy developers who allow the users to access database tables by executing ad-hoc SQL."
The reason why developers are giving users access to the DB is because of poorly trained, lazy and stupid DBAs who grant full access to developers including "grant" privileges and even worse, let developers have those permissions on UAT and LIVE systems.
Don't get me started on the DBAs who don't bother even exercising proper change control and allow developers to make changes directly to production.
I really hope you're not a DBA - Security is the responsibility of the DBA.
No, I'm not a DBA, and I do appreciate that it's not only developers who have training or other issues. However, maybe I should have also added that sometimes commercial or managerial pressures have forced people who do know better to take short cuts they would prefer not to
The reason why developers are giving users access to the DB is because of poorly trained, lazy and stupid DBAs who grant full access to developers...Security is the responsibility of the DBA.
NO. Security is the responsibility of EVERYONE. Yes, the DBA should not be allowing developers to set access controls. But even if a DBA makes such a mistake, that doesn't excuse the developers employing boneheaded programming practices that extend such weaknesses to the users.
The correct way to access data is through stored procedures and views so that the user has no direct access to anything in the database other than the procedures/views they need to perform the task.
No, that is one correct way and like all silver bullets it isn't always appropriate. Pretending otherwise ignores a wide range of legitimate end user requirements.
Two particular cases come to mind right away. The first is the "any and all" requirement for management reporting. Usually that boils down to "I can't be bothered to think about what I actually need in advance" but if it is there in an agreed spec there's not much that can be done about it.
The second is tracing a particular record. If you can guarantee that any access is always from a limited set of possibilities, for example account number, invoice number, phone number or a limited set of alternatives such as surname and date of birth then no problem. If on the other hand you need to be able to use anything you have available to find what you need the possibilities quickly exceed anything remotely manageable.
So yes, stored procedures are a powerful defence and have their place, but for many tasks there is no real substitute for dynamically composed SQL.
There is a NoSQL exploitation toolkit available, but does not seem very active:
Also, a good article by IBM researchers:
And another good article posted earlier this year covering MongoDB, Redis, Memcache and ElasticSearch:
The right way to deal with this is to provide a stored-procedure based interface for the app servers to access the database, not directly using raw SQL/NoSQL, which should be reserved for the DBA or database programmer (you have one, right?).
This takes care of injection attacks, but also confidentiality. Most reasonable systems have the concept of definer/invoker access, similar to the setuid bit in UNIX, where a stored procedure has access to an underlying table with the rights of the definer but the invoker calling the procedure doesn't. If you have a table of users and passwords, for instance, you could have a procedure authenticate(user, password) that can read the table and can be called by the app server but does not leak passwords, even hashed/salted ones. It's much harder to exploit such finer-grained access for data theft.
One of the irritations with many nosql solutions (the lack of a generalised query language) turns out to be a help when it comes to security.
The nosql DB we use most (AWS DynamoDb) is just an API whose commands are composed in JSON, and you usually use an SDK (AWS's) to make the API calls. So if you're doing an update of a record (item in Dynamo parlance), there are a number of things standing in the way of a malicious user trying to subvert this operation to do something entirely differently. Even the clueless developer's code is pretty well impossible to maliciously hack to your own evil ends.
None of this protects you from other types of exploit (such as someone managing to acquire your AWS credentials), but it does remove a whole class of vulnerabilities. However, the maxim still stands that you should apply best-practise (whatever that means with your chosen technologies) to defeat the baddies.
Except there are cases where you can inject nested JSON data into a MongoDB query (with potentially destructive consequences) just like you would inject directives into an SQL query. It doesn't "remove a whole class of vulnerabilities", it just changes the parameters.
Fundamentally "NoSQL" is a meaningless buzzword, and schemaless document stores are *not* an alternative to relational schemaful database systems. They are different toolsets that solve different problems. You can't meaningfully replace one with the other.
> You can't meaningfully replace one with the other.
Yes you can. That would be the case where you have been misusing one to do something that the other turns out to be better suited for. I have heard from people moving in both directions, having at first made the wrong decision as to which technology to use--note that the right decisions might not have been immediately obvious during the first iteration of the requirements.
Aside from that nitpick, I agree with your comment.
Biting the hand that feeds IT © 1998–2020