this post was submitted on 03 Sep 2024
57 points (100.0% liked)
Cybersecurity
5664 readers
108 users here now
c/cybersecurity is a community centered on the cybersecurity and information security profession. You can come here to discuss news, post something interesting, or just chat with others.
THE RULES
Instance Rules
- Be respectful. Everyone should feel welcome here.
- No bigotry - including racism, sexism, ableism, homophobia, transphobia, or xenophobia.
- No Ads / Spamming.
- No pornography.
Community Rules
- Idk, keep it semi-professional?
- Nothing illegal. We're all ethical here.
- Rules will be added/redefined as necessary.
If you ask someone to hack your "friends" socials you're just going to get banned so don't do that.
Learn about hacking
Other security-related communities !databreaches@lemmy.zip !netsec@lemmy.world !cybersecurity@lemmy.capebreton.social !securitynews@infosec.pub !netsec@links.hackliberty.org !cybersecurity@infosec.pub !pulse_of_truth@infosec.pub
Notable mention to !cybersecuritymemes@lemmy.world
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
The beautiful thing about string injection vulnerabilities is that they will never ever stop happening. It's just too easy to sprintf untrusted input.
๐ญ prepare your queries!!!!
You know, the reason this happens is that you can ask your database to execute a string type, but languages usually don't distinguish between a static string and a dynamically constructed string.
Not to proselytize, but this is a place where rust's lifetime annotations can shine. The DB interface should take a
&'static str( and a variable number of parameters to insert) so it can be certain that no untrusted user input has already been injected into the query string. Assuming all static data is trusted, the sql injection vulnerabilities just went poof.Sadly, it looks like rusqlite's
execute()takes a non-staticstr. I wonder why.