7 ms·

a nice side-benefit of nosql databases is this massively underestimated problem (usually, depends on the product) going away

tptacek 17y ago
There is a huge "maybe" attached to that statement. It's also possible that several of the popular NoSQL databases could have key patterns that will corrupt memory in their C-code runtimes. There are good reasons to consider NoSQL databases, but security isn't one of them yet.
- dm_mongodb 17y ago
  trying to understand what you just said: do you mean they may have buffer-overrun vulnerabilities, just as they are new projects? a lot of nosql projects are written in erlang and java btw.
  - tptacek 17y ago
    I don't like the term "buffer overflow" because things haven't been that simple since the '90s (the recent Aurora kerfluffle happened because IE freed memory in the wrong order, no overrun involved). But yes, the point is you're trading a problem in a domain where we know how to mitigate problems for a maybe less likely problem in a domain where we have no idea how to mitigate problems.
    - euccastro 17y ago
      Is there any reason why sql databases should be less vulnerable to that other type of problems?
      - tptacek 17y ago
        Yes: because they've been tested extensively for over a decade for them, especially over the attack vectors exposed on web applications.
chrischen 17y ago
I'm pretty sure couchdb has a query language which can receive injections. If you pass JavaScript into mongodb theoretically you could open an injection problem if you don't use parametrization. But unless your nosql database has a native API, it still probably is vulnerable to command injection in the same way SQL databases are. Nothing really special about nosql itself that prevents this.
- dm_mongodb 17y ago
  Preferred and typical use of MongoDB is with no javascript in the queries. There really is a huge reduction of risk for this one particular attack.
- dm_mongodb 17y ago
  you may be right that i've overgeneralized to the other products based on my experience with mongodb; all i know for sure is mongodb has some nice properties here.
  - chrischen 17y ago
    Yes mongo language drivers do make it harder to open up injection problems, but php extension like mysqli also provide similar protection. However the SQL-oriented nature does make it more likely that someone merges uncleaned input into a command.
jasonkester 17y ago
That's the same side benefit that every SQL database has built in too, right? Pretty much every relational database has supported parameterized queries for, like, ten years. They're uninjectable and actually less work than constructing strings. It's amazing that people are still constructing SQL queries as strings in 2010.
- ars 17y ago
  Sometimes you also need to change the query itself, i.e. the tables that are joined, or the sort order.
  - jasonkester 17y ago
    Indeed. And you either do that in Stored Procedures using parameters that you've passed in (without manipulating them as strings), or you construct your parameterized query on the webserver with the joins and sorts that you need, and then pass it to the database along with the parameters it needs to stick in. Like I said. It's a solved problem, and has been so for a dozen years now.

tptacek 17y ago

There is a huge "maybe" attached to that statement. It's also possible that several of the popular NoSQL databases could have key patterns that will corrupt memory in their C-code runtimes. There are good reasons to consider NoSQL databases, but security isn't one of them yet.

dm_mongodb 17y ago
trying to understand what you just said: do you mean they may have buffer-overrun vulnerabilities, just as they are new projects? a lot of nosql projects are written in erlang and java btw.
- tptacek 17y ago
  I don't like the term "buffer overflow" because things haven't been that simple since the '90s (the recent Aurora kerfluffle happened because IE freed memory in the wrong order, no overrun involved). But yes, the point is you're trading a problem in a domain where we know how to mitigate problems for a maybe less likely problem in a domain where we have no idea how to mitigate problems.
  - euccastro 17y ago
    Is there any reason why sql databases should be less vulnerable to that other type of problems?
    - tptacek 17y ago
      Yes: because they've been tested extensively for over a decade for them, especially over the attack vectors exposed on web applications.

chrischen 17y ago

I'm pretty sure couchdb has a query language which can receive injections. If you pass JavaScript into mongodb theoretically you could open an injection problem if you don't use parametrization. But unless your nosql database has a native API, it still probably is vulnerable to command injection in the same way SQL databases are. Nothing really special about nosql itself that prevents this.

dm_mongodb 17y ago
Preferred and typical use of MongoDB is with no javascript in the queries. There really is a huge reduction of risk for this one particular attack.
dm_mongodb 17y ago
you may be right that i've overgeneralized to the other products based on my experience with mongodb; all i know for sure is mongodb has some nice properties here.
- chrischen 17y ago
  Yes mongo language drivers do make it harder to open up injection problems, but php extension like mysqli also provide similar protection. However the SQL-oriented nature does make it more likely that someone merges uncleaned input into a command.

jasonkester 17y ago

That's the same side benefit that every SQL database has built in too, right? Pretty much every relational database has supported parameterized queries for, like, ten years. They're uninjectable and actually less work than constructing strings. It's amazing that people are still constructing SQL queries as strings in 2010.

ars 17y ago
Sometimes you also need to change the query itself, i.e. the tables that are joined, or the sort order.
- jasonkester 17y ago
  Indeed. And you either do that in Stored Procedures using parameters that you've passed in (without manipulating them as strings), or you construct your parameterized query on the webserver with the joins and sorts that you need, and then pass it to the database along with the parameters it needs to stick in. Like I said. It's a solved problem, and has been so for a dozen years now.