41–50 of 58 posts
Because it's easy to do things the wrong way and a site built the wrong way still works , it's just insecure.
i.e., the problem is that "properly secures access to data" is all too often not part of the definition of "works" applied to systems.
Earlier quoted context omitted.
I'll move my reply here, then. You make good points, and I'm trying to figure out exactly how your points and mine hook together. I think what it ultimately comes down to is distinguishing between data and code. More specifically, data can contain code, but code should never contain (foreign) data. So escaping in general is fine, but escaping in this context , where you're building a string of code, is no good. That,…
Doesn't the database server just escape the data in the parametrized query? So if you used the database's escape functions directly wouldn't it be the same thing? I guess if you are arguing that developers are more likely to mess it up than the database server then I see your point.
SELECT * FROM bar_table WHERE x = 123;
{
"querytype": "select",
"fields": ["bar_table.x", "bar_table.y", "bar_table.z"],
"tables": ["bar_table"],
"where_filters": ["x", "=", 123]
}
Now, if you give it a prepared statement:
SELECT * from bar_table WHERE x = ?;
function(arg1){
return {
"querytype": "select",
"fields": ["bar_table.x", "bar_table.y", "bar_table.z"],
"tables": ["bar_table"],
"where_filters": ["x", "=", arg1]
};
}
Of course, the realities of it are more complicated than that for optimization reasons, but that's the basis of it.
Earlier quoted context omitted.
> Occasionally people talk about prepared statements and parameterized queries and such, but usually people just talk about escaping. Occasionally? For many years "preferred prepared statements and use user input, sanitized (via escaping and/or more involved means) or not, only with a very special need that where prepared statements don't do what you need, and then be as restrictive as possible in what you accept" ha…
Lucky you! I've not seen it be so common. Obviously the smart guys who properly understand what's going on are all about parameterized queries, but I still see a ton of other people talking about escaping. To double-check and make sure I'm not just being biased, I did a Google search for "php mysql tutorial" and read through the top five results. Not a single one mentioned parameterized queries . One of the tutorials…
Java, Perl, Ruby, Python, C#, NodeJS and virtually other language or framework strongly encourages the use of placeholders. PHP's community stands alone in stubborn opposition to this despite having facilities to do this.
PHP is also unusually hostile to frameworks and ORM-like database layers even when these would solve a myriad of problems without imposing too greatly.
Honestly, on the whole PHP programmers in general are like hunter gatherers who see no use for anything other than the most basic of tools. There are exceptions, but I figure these people usually graduate to other communities where the best practices they follow have already been fully embraced.
TL;DR: "Because you aren't using our snazzy new product; try it today!" Also: This is primarily because of the most obvious problem: We are still using relational SQL databases. Were we to use NoSQL database systems such as MongoDB or CouchDB, none of these attacks would ever happen Yeah, and motorbikes are safer than cars because the third and fourth wheels never fall off...
Make perfect sense, since there is no SQL in NoSQL its impossible to have a SQL injection, problem solved...
Earlier quoted context omitted.
Doesn't the database server just escape the data in the parametrized query? So if you used the database's escape functions directly wouldn't it be the same thing? I guess if you are arguing that developers are more likely to mess it up than the database server then I see your point.
Not usually. What usually happens is something like this: SELECT * FROM bar_table WHERE x = 123; Is converted into a datastructure like this in the database engine (really simplified): { "querytype": "select", "fields": ["bar_table.x", "bar_table.y", "bar_table.z"], "tables": ["bar_table"], "where_filters": ["x", "=", 123] } Which is then converted into a list of things to do to run that query. Now, if you give it a…
SQL is hard to get rid of injections and here's why I think it is so. How would an ideal injection-free application look? I'd imagine a set of unmutable precompiled SQL statements (the code) each controlled by a set of parameters (the data.) No gluing of statements from strings at runtime and the parameters are obviously passed out-of band. You can't forget to escape user-provided data because in this setup the SQL c…
Binding data to a query after the fact is a reliable way of escaping. Composing a prepared statement is not hard, and creating these at runtime is not a big deal.
Honestly, for most of your daily work you should be using an ORM of some kind where this is already done for you. The only reason you should be writing direct SQL is when you're doing things the ORM doesn't natively support.
Ruby on Rails is currently 100% injection free as far as anyone can tell, and if it isn't there'd be an emergency patch issued right away. There have been situations in the past where this was not the case, but these bugs were quickly addressed after being discovered. Most other frameworks (Django, etc.) are in the same category.
SQL is hard to get rid of injections and here's why I think it is so. How would an ideal injection-free application look? I'd imagine a set of unmutable precompiled SQL statements (the code) each controlled by a set of parameters (the data.) No gluing of statements from strings at runtime and the parameters are obviously passed out-of band. You can't forget to escape user-provided data because in this setup the SQL c…
SQL q = ;Earlier quoted context omitted.
Lucky you! I've not seen it be so common. Obviously the smart guys who properly understand what's going on are all about parameterized queries, but I still see a ton of other people talking about escaping. To double-check and make sure I'm not just being biased, I did a Google search for "php mysql tutorial" and read through the top five results. Not a single one mentioned parameterized queries . One of the tutorials…
The PHP community has an unusually reckless disregard for proper programming practices. Poisonously bad tutorial sites like w3schools are not helping either. Java, Perl, Ruby, Python, C#, NodeJS and virtually other language or framework strongly encourages the use of placeholders. PHP's community stands alone in stubborn opposition to this despite having facilities to do this. PHP is also unusually hostile to framewo…
Earlier quoted context omitted.
The PHP community has an unusually reckless disregard for proper programming practices. Poisonously bad tutorial sites like w3schools are not helping either. Java, Perl, Ruby, Python, C#, NodeJS and virtually other language or framework strongly encourages the use of placeholders. PHP's community stands alone in stubborn opposition to this despite having facilities to do this. PHP is also unusually hostile to framewo…
I completely agree. However, the PHP community is still a huge part of the server-side web community, so they're largely representative even if nobody else follows their lead.
Earlier quoted context omitted.
Make perfect sense, since there is no SQL in NoSQL its impossible to have a SQL injection, problem solved...
In MongoDB you could theoretically have a JavaScript injection, which I'd argue is pretty bad.