News for hackers. Stuff that matters.

A comment on More Memory Safety for Let's Encrypt: Deploying ntpd-rs. Parent comment

Re:More Memory Safety for Let's Encrypt: Deploying ntpd-rs by TeMPOraL on Tuesday June 25, 2024 @01:12AM (#40784727)
> It’s like asking why SQL query forming via string concatenation of user inputs is unsafe.

To be honest, that's a surprisingly deep question, and the answer is something I'm yet to see any developer I worked with understand. For example, did you know that SQL injection and XSS are really the same problem? And so is using template systems[0] like Mustache?

In my experience, very few people appreciate that the issue with "SQL query forming via string concatenation" isn't in the "SQL" part, but in the "string concatenation" part.

--

[0] - https://en.wikipedia.org/wiki/Template_processor

[ Parent | on HN ]
Re:More Memory Safety for Let's Encrypt: Deploying ntpd-rs by cowsandmilk on Tuesday June 25, 2024 @03:15AM (#40785436)
Really, the problem is in combining tainted input strings with string concatenation. If you have certain guarantees on the input strings, concatenation can be safe. That said, I still wouldn’t use it since there are few guarantees that future code wouldn’t introduce tainted strings.
[ Parent | on HN ]
Re:More Memory Safety for Let's Encrypt: Deploying ntpd-rs by codetrotter on Tuesday June 25, 2024 @01:18AM (#40784759)
The problem that causes it is in photo cases that a flat string representation kind of mixes code and data. And therefore escaping (such as not allowing quotes in the user input to terminate quotes in your query, or not allowing html tags to be opened or closed by user input, nor allowing html attributes to be opened or closed by the user input, etc) is needed.
[ Parent | on HN ]
Re:More Memory Safety for Let's Encrypt: Deploying ntpd-rs by IshKebab on Tuesday June 25, 2024 @05:28AM (#40786287)
> In my experience, very few people appreciate that the issue with "SQL query forming via string concatenation" isn't in the "SQL" part, but in the "string concatenation" part.

Really? To me it's pretty obvious that not escaping properly is the issue, and therefore the same issue applies wherever you need escaping. I don't think I've ever heard anyone say that SQL itself was the problem with SQL injection. (Although you certainly could argue that - SQL could be designed in such a way that prepared statements are mandatory and there's simply no syntax for inline values.)

[ Parent | on HN ]