3

There seems to be an explosion of new databases, especially in the non-relational and "NotOnly SQL" offerings. How does this database fad affect data integrity and security? What are some ways that programmers can hang themselves by not accounting for strange database behavior? This question is more about flaws like Time of Check to Time of use (TOCTU) than the usual SQL Injection and Insecure Direct Object Reference.

Does anyone know of interesting attack scenarios or real world vulnerabilities (CVE numbers, papers, exploit code!) that fall under this category of attacks?

rook
  • 46,916
  • 10
  • 92
  • 181

1 Answers1

1

Interesting question. I don't have any specific knowledge of any new DBMS systems that have caused a vulnerability when using a traditional RDBMS would have not led to the same outcome. As far as integrity goes, I think you make that compromise when you add in "eventually consistent" as a platform goal for a lot of the highly distributed NOSQL offerings.

I don't think it's going on a limb to say that the ecosystem isn't nearly as developed as RDBMS solutions. That said a lot of the logic that can be found in a RDBMS has moved to the application and is dependent on the developer, which is likely a potential weakness.

Given the reason for implementation is largely scaling related (for Enterprise), would attacks against this platform more likely be attacks against it's distributed nature at least initially. As an example the Citigroup e-payment flaw, though they probably are using traditional RDBMS.

M15K
  • 1,182
  • 6
  • 7
  • +1 Perfect, this question is about developers accidentally introducing flaws due to unexpected database behavior. – rook Jan 11 '13 at 23:24