4 ms·
It boils down to two things. One is library/tool design typically makes it too easy to make user input be in-band with execution. The other is that most tutoria
by extrapickles 7y ago
It boils down to two things. One is library/tool design typically makes it too easy to make user input be in-band with execution. The other is that most tutorials/guides only show you how to do things in-band.
An example of a tutorial for SQL:
SELECT first_name FROM users WHERE last_name = ‘Smith’
They then have an exercise to hook this query to a text box in the program, where through omission, the programmer is guided to use string concatenation to build the query.
If from the first SQL statement to the last that a programmer saw was parameterized, it would be much harder for them to reach for string concatenation.
Most modern web development frameworks make it very hard to insert un-escaped text into the DOM. You have to go out of your way to introduce a XSS vulnerability in your web application with one, and most of the tutorials and documentation about the framework warn you about using the raw HTML functionality.
Another way to look at it is that the out-of-band way of doing things is typically perceived as either lower in performance, harder to do and/or less elegant (eg: C-style strings vs pascal strings).
I consider anything with user input that is done in-band (eg: escaping is a fix) to be doomed to fail. This is similar in idea to the cryptographic doom principle where decryption before authenticating the message is ultimately doomed to failure.
- gwd 7y ago> If from the first SQL statement to the last that a programmer saw was parameterized, it would be much harder for them to reach for string concatenation. I dunno -- I've been doing C programming for 30-ish years now, but just learned SQL about a year ago. Every man page I looked at, as well as every stackoverflow question, emphasized the importance of using parametrized queries. And IIRC in Python, "only execute a single statement" is enabled by default; if you want to execute multiple statements, you have to use a different call. So even if you somehow manage to forget to parameterize your queries, you'll still be safe from Little Bobby Tables. Do SQL injection attacks still actually happen? How is it possible?
- tsukurimashou 7y agoA lot of websites and applications are built for a purpose they get forgotten, I'm speaking especially people doing it in their free time for fun, or small company projects.
- hobs 7y agoSQL injection attacks still happen, a LOT. Making sure your query only executes a single statement is not enough to prevent sql injection (depending on how you concat the query) - you just have to use the provided context to get/set data you need to escalate your permissions (eg if its SELECT stuff FROM table, you might be able to inject it such that your query replaces stuff and then you can select whatever the querying user has access to.) 2019: For its "State of the Internet" report, Akamai analyzed data gathered from users of its Web application firewall technology between November 2017 and March 2019. The exercise shows that SQL injection (SQLi) now represents nearly two-thirds (65.1%) of all Web application attacks. That's up sharply from the 44% of Web application layer attacks that SQLi represented just two years ago.
- zAy0LfpBZLC8mAC 7y ago> The exercise shows that SQL injection (SQLi) now represents nearly two-thirds (65.1%) of all Web application attacks. Are you sure that you don't actually mean "weird strings sent to web applications" when you write "web application attacks"? Sending a weird string to web applications is not an attack in any particularly relevant sense unless there is an actual vulnerability--other than when akamai wants to sell you snake-oil against all the danger of weird strings.
- bluedino 7y agoMany applications were written 5, 10, or even 25 years ago. They haven't been updated to current standards.
- AmericanChopper 7y ago> The other is that most tutorials/guides only show you how to do things in-band. Learning SQL is completely different from learning how to use SQL in whatever programming language/framework/library you may end up using. Learning how to safely interface with an RDBMS is going to be entirely specific to the stack you’re using for the rest of your application.