The second function only accepts strings defined at compile time, meaning it can't be called with strings created at runtime (i.e. any string containing user input).
just add "to_owned()" and problem solved. This function doesn't protect nothing, it's a bullshit. I love Rust, but author is far from the theme he is trying to describe. And theme is dangerous enough.
to_owned() converts to a String, not to a &'static str. Those are not the same. You can't create a &'static str dynamically (though you can mutate one using unsafe.)
and I already told that this example has no meaning, it's just a bullshit - nobody will use it in real app. You want to fetch from db info about the only one user, who's name is a constant? Yeah, all apps do it every day.
You can convert a `String` into a `&'static str` using only safe stdlib functions via `Box::leak(s.into())`. This uses `unsafe` internally, of course... but so does almost any code.
The idea seems to be that if a variable has a certain kind of Rust lifetime, then it contains only trusted data associated with the program itself, rather than some untrusted input.
Problem is, that is too limiting to satisfy the functional use cases in a lot of code that constructs SQL queries by substituting values into templates, where some of the pieces are necessarily dependent on inputs from logged-in users and such.
SQL Inject is not only a ' character. SQL Inject could be a blind query, subselect attack, time attack and so on and so on. This completely fails to prevent pretty much anything except the very naive and silly attacks.
The argument isn't "block ' characters to stop SQL injection" it's "force the developer to use prepared statements and no dynamically constructed queries".
Second, the naive and silly attacks are the default definition of SQL injection -- and the most commonly found holes, so even if it just prevented those that would be still a huge help. Nothing statically ensures that at runtime except the programmer's due diligence.
I think the appeal of sql builder apis is that they make it much harder to shoot yourself in the foot. If your queries are strings you can use placeholder syntax to avoid injection but all there is nothing stopping you (or a junior dev) from writing something stupid like "and name ='" + username + "'". If queries are represented with a separate datatype then it is much harder to put unsanitized user input strings inside them.
In many cases that may be true, but not in the case of the parent comment you're responding to. The parent identifies a scenario where you have a faceted search functionality that generates conditions in the where clause of the query dynamically).
So? What prevents those conditions to be generated as a number of SQL fragments that are statically checked for injection?
What would be checked by Rust is the actual fitness of the fragments, not if your building them in a loop from pre-made WHERE, AND etc clauses + placeholders.
As a non-webdev who only have a surface-level understanding of SQL: is that a thing people do regularly? Like, you literally append a bunch of strings together dynamically every request to construct queries?
I'd imagine it would depend entirely on the type of search you're trying to do.
If you know all the possible ANDs and ORs beforehand, you could pass in flags to select which ones to use. That would also mean you could prepare queries ahead of time, and not need to compile them every time you run them.
I don't think there would be many situations where you wouldn't know what possible filters you could have at compile time, and in such a situation I'd question whether there was a better way to implement what I was trying to do.
I think the main problem (don't know whether this is possible in Rust which I am not familiar with) is that untrusted input is passed around as strings at all (Java, which I am familiar with, does this). I'd prefer:
- Getting untrusted input as a separate type
- Having only a controlled way to put instances of this type into an SQL query
You pretty much just nailed exactly what this post is demonstrating about Rust. The lifetime associated with the different types indicates the provenance of the variables.
Basically, the 'static lifetime guarantees that the query string was built at compile time. And then it allows the parameters to be from user input. To Rust, these are effectively different types due to the restrictions on the function definition, which restricts the first parameter to 'static, and the list of SQL parameters can come from anywhere (static or dynamic runtime).
Yeah, but using "built at compile time" as a synonym for "safe" is pretty crude. A runtime string composed of the concatenation of two compiled strings is still safe, yet not allowed here.
That seems easy enough to fix, no? Change the API to allow a runtime generated list of compile-time strings, et viola. Though, I doubt that's as safe as you might imagine. Imagine a return oriented programming-like technique using static SQL strings. Difficult, for sure, but not impossible.
Is this serious? It seems to prevent SQL injection by only allowing statically defined strings to be interpolated. So basically not allowing any kind of dynamic or user input.
This doesn't actually work. It is possible to produce objects with 'static lifetime references at runtime.
What &'static means is that whatever the reference is pointing at will never be modified or go out of scope. One way to provide this is to put it in the read-only part of the executable, which is what literals do. Another is to use into_boxed_str() [1] and Box::leak() [2] to leak the string and thus make sure it will never be modified or freed. Neither function is unsafe, while Box::leak() is still only in nightly.
Good clarification. Although it's at least likely to stop you from using user input accidentally. I think it's unlikely that someone would use either of the options above when constructing a string involving user input without knowing what they're doing.
This does seem to be the case. Here is an example I was able to create:
use std::io::stdin;
fn main() {
let mut s = String::new();
stdin().read_line(&mut s).expect("Did not enter a correct string");
let sql_example = format!("SELECT * FROM users WHERE username={}", s);
let x = Box::new(sql_example);
let static_ref: &'static str = Box::leak(x);
println!("{}", static_ref)
}
Note the type on our variable "static_ref". It is a static str, meaning it could be an argument to the code in the blog post. No "unsafe" blocks either.
When I run it
Input: ' OR '1'='1
Output: SELECT * FROM users WHERE username=' OR '1'='1
The technique might be still useful if it was only allowed in debug builds to reduce boilerplate during debugging in a system that tried to use types to solve the issue.
It's a neat little hack, though it seems a bit restrictive. I was expecting a blog post about how, by using ownership, it should be possible to create an API that both requires untrusted data to be escaped and prevents double-escaping (though you could probably achieve pretty much the same in any statically-typed language).
56 comments
[ 5.0 ms ] story [ 126 ms ] threadlet _rows = sql_query("SELECT * FROM users WHERE username=?", &[username]);
The statement is static, but the [username] part is not, it's just a variable that can have whatever username you want.
Problem is, that is too limiting to satisfy the functional use cases in a lot of code that constructs SQL queries by substituting values into templates, where some of the pieces are necessarily dependent on inputs from logged-in users and such.
They're saying injection attacks come from dynamically building strings, so if you prevent that you stop the vulnerabilities.
The argument isn't "block ' characters to stop SQL injection" it's "force the developer to use prepared statements and no dynamically constructed queries".
Second, the naive and silly attacks are the default definition of SQL injection -- and the most commonly found holes, so even if it just prevented those that would be still a huge help. Nothing statically ensures that at runtime except the programmer's due diligence.
If your SQL has to be computed at compile time, how do you implement any sort of search where you will have a variable number of ANDS & ORs?
Then you can use conditionals and loops to decide which fragments are included.
That is, sure, it's not like Rust takes the option to check for injection at runtime.
It's not your SQL (e.g. whole query) that needs to be computed at compile time, but the proper escaping of placeholder parameters.
So, the answer is: trivially.
What would be checked by Rust is the actual fitness of the fragments, not if your building them in a loop from pre-made WHERE, AND etc clauses + placeholders.
where = "1=1";
if (cond) { where += " and foo ='bar'"; }
...
If you know all the possible ANDs and ORs beforehand, you could pass in flags to select which ones to use. That would also mean you could prepare queries ahead of time, and not need to compile them every time you run them.
I don't think there would be many situations where you wouldn't know what possible filters you could have at compile time, and in such a situation I'd question whether there was a better way to implement what I was trying to do.
- Getting untrusted input as a separate type
- Having only a controlled way to put instances of this type into an SQL query
Basically, the 'static lifetime guarantees that the query string was built at compile time. And then it allows the parameters to be from user input. To Rust, these are effectively different types due to the restrictions on the function definition, which restricts the first parameter to 'static, and the list of SQL parameters can come from anywhere (static or dynamic runtime).
Always build your queries out of strings defined at compile time and use them as prepared statements with parameters.
So we always end up with a mix of prepared statements and string manipulation.
https://en.wikipedia.org/wiki/Prepared_statement
The ? is a placeholder for dynamic values, the user input is bound to it.
What &'static means is that whatever the reference is pointing at will never be modified or go out of scope. One way to provide this is to put it in the read-only part of the executable, which is what literals do. Another is to use into_boxed_str() [1] and Box::leak() [2] to leak the string and thus make sure it will never be modified or freed. Neither function is unsafe, while Box::leak() is still only in nightly.
[1]: https://doc.rust-lang.org/std/string/struct.String.html#meth... [2]: https://doc.rust-lang.org/std/boxed/struct.Box.html#method.l...
When I run it
The technique might be still useful if it was only allowed in debug builds to reduce boilerplate during debugging in a system that tried to use types to solve the issue.