back to article NoSQL: Injection vaccination for a new generation

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 …

  1. Tom 7

    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.

  2. This post has been deleted by its author

  3. BCSSDO

    It's not about the product

    "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

    1. AceRimmer

      Re: It's not about the product

      "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.

      1. BCSSDO

        Re: It's not about the product

        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

      2. Steve Knox
        Holmes

        Re: It's not about the product

        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.

    2. JLV

      Re: It's not about the product

      That's a possible architectural decision indeed. But it is not without significant implications. One of which being that you can kiss any notion of ANSI-sql based vendor portability goodbye when you move to procs.

    3. the spectacularly refined chap

      Re: It's not about the product

      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.

  4. abchaudhri

    NoSQL Injection Toolkit

    There is a NoSQL exploitation toolkit available, but does not seem very active:

    http://nosqlmap.net

    Also, a good article by IBM researchers:

    http://arxiv.org/pdf/1506.04082v1.pdf

    And another good article posted earlier this year covering MongoDB, Redis, Memcache and ElasticSearch:

    http://blog.binaryedge.io/2015/08/10/data-technologies-and-security-part-1/

  5. Destroy All Monsters Silver badge

    Kinda faddish

    > future architecture

    More like "niche architecture"

  6. Infernoz Bronze badge

    NoSQL would seem to have another major security disadvantage

    If it can't run stored procedure and stored functions to remove direct access to all tables, and possibly pre-validate data before it is stored or used to search for data, all protected by a database user login.

  7. Fazal Majid

    Stored procedures are the way

    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.

  8. a_yank_lurker

    It's not the DB

    Good security practices in coding and db administration are well known. The problem is when short cuts are taken usually because of PHB pressure to push something out the door. All systems are vulnerable to the PHBs.

  9. smartypants

    JSON API != SQL

    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.

    1. joepie91

      Re: JSON API != SQL

      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.

  10. Anonymous Coward
    Anonymous Coward

    > 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.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like