6 ms·
Compile Time Prevention of SQL-Injections in Rust
- alexandernst 8y agoIs it me or the person that wrote that post has no idea what SQL inject actually is?
- empath75 8y agoI don’t understand at all what the difference is between the two functions.
- deleted 8y ago[deleted]
- borntyping 8y agoThe 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).
- empath75 8y agoSo what to you do if you need to make a sql call based on user input?
- gnud 8y agoUse parameters, of course. Using SQL parameters for untrusted input is the only sane way to avoid SQL injections.
- EugeneOZ 8y agojust 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.
- C4K3 8y agoto_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.)
- EugeneOZ 8y agolol, so you call your SQL just with constants? "username" in his example just for one user forever? Still a bullshit.
- C4K3 8y agoNo, only the SQL statement has to be 'static. It's not bullshit.
- EugeneOZ 8y agoCan you provide real-world example please?
- Khoth 8y agoFrom TFA: let _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.
- EugeneOZ 8y agoand 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.
- derkha 8y agoYou 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.
- kazinator 8y agoThe 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.
- kpmah 8y agoLooks correct to me. What issue do you have with it? They're saying injection attacks come from dynamically building strings, so if you prevent that you stop the vulnerabilities.
- alexandernst 8y agoSQL 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.
- charriu 8y agoThis prevents dynamically created queries using lifetimes. It does not search for ' characters.
- swirepe 8y agoYup. But it does it at compile time for basically no work.
- CiPHPerCoder 8y agoNo it doesn't. The argument isn't "block ' characters to stop SQL injection" it's "force the developer to use prepared statements and no dynamically constructed queries".
- coldtea 8y agoFirst, no, it prevents much more attacks. 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.
- microsuck 8y agoAm I just too dumb or is it really impossible for this code to exchange the username?
- deleted 8y ago[deleted]
- microsuck 8y agoHow is this going to prevent a sql injection?
- deleted 8y ago[deleted]
- Eridrus 8y agoThis is a pretty natural thing to want, but is not actually usable in real world settings. 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?
- deleted 8y ago[deleted]
- gnud 8y agoYou could try to create some sort of SQL-builder API where each fragment must be static, and each fragment contains its own placeholders. Then you can use conditionals and loops to decide which fragments are included.
- pc86 8y agoOr you can just use runtime SQL injection prevention methods?
- coldtea 8y agoOr just have an employee carefully monitor user input manually, and have them propagate it to the backend with a delay. That is, sure, it's not like Rust takes the option to check for injection at runtime.
- jcelerier 8y agoWhy "just" ? It's incredibly more costly than having the injections being prevented at compile-time.
- chopin 8y agoI 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
- bluejekyll 8y agoYou 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).
- icebraining 8y agoYeah, 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.
- kbsletten 8y agoThat 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.
- yoklov 8y agoThis is doable in rust too.
- olavk 8y agoIs 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.
- kuschku 8y agoThat’s the point. You should never use string interpolation with strings defined at runtime for SQL. Always build your queries out of strings defined at compile time and use them as prepared statements with parameters.
- pjmlp 8y agoThat is the theory, sadly it doesn't work everywhere on the SQL statement. So we always end up with a mix of prepared statements and string manipulation.
- C4K3 8y agoIt works by only allowing statically defined strings to be used for SQL /statements/, it still works for dynamic input. https://en.wikipedia.org/wiki/Prepared_statement https://en.wikipedia.org/wiki/Prepared_statement The ? is a placeholder for dynamic values, the user input is bound to it.
- Tuna-Fish 8y agoThis 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. [1]: https://doc.rust-lang.org/std/string/struct.String.html#method.into_boxed_str https://doc.rust-lang.org/std/string/struct.String.html#meth... [2]: https://doc.rust-lang.org/std/boxed/struct.Box.html#method.leak https://doc.rust-lang.org/std/boxed/struct.Box.html#method.l...
- michaelmior 8y agoGood 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.
- Paul-ish 8y agoThis 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.
- deleted 8y ago[deleted]
- kibwen 8y agoIt'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).