3 ms·
How can you say everyone should be fine using a simple construct like that, have you ever had to write a complex query on a non-trivial database?
by xd 16y ago
How can you say everyone should be fine using a simple construct like that, have you ever had to write a complex query on a non-trivial database?
- albertzeyer 16y agoYou will be able in a straight-forward way to extend this to allow any possible query.
- tptacek 16y agoThus arriving, via the most circuitous and expensive plausible path, right back at the problem we have today.
- albertzeyer 16y agoWhat do you mean? 1. It would be much cheaper and faster. Right now, you are: constructing a string first, doing some escaping, then sending this more bloated pure-text query to the server, then parse the SQL language, unescape, convert back into some machine representation. I.e. a) Most of this extra handling (escaping, string-conversions, parsing) would go away. b) Less data need to be send around. 2. It would actually make SQL injections impossible and thus solve all these problems.
- tptacek 16y agoYou've made "SQL injection" impossible by inventing "albertzeyerql", which will inevitably be vulnerable to "AZQL injection". Many of the NoSQL's have similar problems; expect to hear more about them in Blackhat presentations yet to come. It's not pointless to discuss how query languages can be made simpler to parse and thus less susceptible to injection, but the technique isn't foolproof and is (obviously) expensive; meanwhile, the proper defense against SQLI (being mindful about query inputs, and using the framework to abstract and normalize dynamic queries) is available today and works well.
- albertzeyer 16y agoI am not really talking about a language at all (at least not on a byte-alphabet). Maybe we misunderstood a bit. For example, take a look at the [new Redis 2.0 protocol](http://redis.io/topics/protocol http://redis.io/topics/protocol). In this protocol, injections are simply impossible. This may not be the best example because you don't really have more complicated queries but you could just do the same for tree-like structures.
- tptacek 16y agoI think you're wrong, both in your general point and about the possibility about Redis query injection; unfortunately, you're wrong in ways I'm not at liberty to correct. I can only ask that you take my word for it that you need to be as mindful with the code that constructs Redis keys as you do with code that concatenates SQL queries. And, as with SQL, much (perhaps most) production-quality code isn't susceptible to attack; but the lines that are tend to blindside you.
- albertzeyer 16y agoNow that made me curious... Can you say when/where I could read about that?
- stephth 16y agotptacek, are you claiming you are aware of critical vulnerabilities in Redis?
- kalleboo 16y agoI don't see why you couldn't inject a CR LF? Sure it might not be that dangerous (although it could be depending on what validation the server does on # of args), but you're still modifying the query.
- albertzeyer 16y agoBecause you are sending the byte-size of the key/value. So whatever there comes, it will be covered, you can just pass any possible binary string.