Hacker News new | past | comments | ask | show | jobs | submit login

Apologies, I meant string literals.

There's no technical reason the language couldn't make it so that string literals can be identified at runtime.

There are several good ways to put a stop to SQL injection. Better education is one, better APIs is another. There is no reason to just give up on the idea of using SQL queries directly because of injection attacks.




Pop quiz: What is the singular cause of SQL injection, XSS, and stack overflows that causes a security vulnerability?

...

The answer is: Data being treated as an instruction.

Solution: Separate them so that data can never be interpreted as an instruction!

In SQLi, this solution is to use parameterized queries. You send the query in one packet, then the parameters in a second one. SQLi is thus prevented.

(Not that SQLi is the only vulnerability possible.)


I'm not sure what your point is here, because what I'm advocating is precisely to make it easier to use parameterized queries and more difficult not to.


I wasn't being argumentative, I just thought that would be something worthwhile to add for people following along.


Gotcha, sorry. "Pop quiz" always makes me think it's being sarcastic.

So, yes, total agreement there. Parameterized queries are key. I find it crazy that anything else ever existed, let alone still gets used.


Ah, yeah, I hadn't considered the normal usage.

Most people don't realize how much these vulnerabilities have in common, in the abstract, until you frame it like that.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: