This article makes the all too common mistake of confusing input validation with correctly escaping things. The solution to preventing SQL injection, XSS and so on is NOT preventing "harmful" strings from being entered in to an application.
What is the solution? I'm learning about SQL. As far as I understand it, the best thing to do is to bind the parameters using the database's built-in capability to do so...
That's right – parameter binding is the way to go.
There is also an old way which also correctly escapes parameters but is easier to get wrong by forgetting to add it somewhere, which is using your database library's function to escape input before concatenating it into a directly-executed SQL string.
Here are some examples of those methods – in PHP, because it’s the only language I’ve used to build a site without an ORM (which is another option). It’s been a while since I used PHP, but as far as I can tell, with PHP’s built-in library, you would use PDO (PHP Data Objects) for parameter binding. For escaping input for SQL strings, you would use mysql_real_escape_string() (or its relative for your database engine).
You are correct. Note that what you described is not "validating the input checking for harmful SQL code". The latter is a specific case of "enumerating badness", which is a known mistake security wise. Edit: fortunately in the actual list of the errors the advice given is not to check for harmful code, but to whitelist known safe input.
These are hardly the "most dangerous" programming mistakes. Nobody is maimed or killed by SQL injection attacks on a website unless there is physical machinery that is under the direct control of the website. The most dangerous programming mistakes occur in software systems that control powerful physical devices or software systems that provide diagnostic information that guides physical interventions by human beings (i.e. a physician utilizes the information to make treatment decisions) and, unlike the rest of computer security, most of the really dangerous mistakes have to do with computing incorrect results for some edge case rather than a failures related to malicious actors.
Worth re-reading every year, the good stuff is at http://cwe.mitre.org/top25/index.html (but don't read number 25 because it will get you riled up (their advice doesn't go anywhere near far enough))
Like in every article I evalute like this: Open the website, look for title/text/diagrams proportions (here nearly only text and a lot of stuff around the article that doesn't matter for the article at all). Then I try to get the content of the article with reading headlines, bold/italic text and looking at the diagrams (result: only blabla, no errors). Then I downvalue an article that has 2 pages which only serves the website owner, not the reader at all (and I am the reader). Also I evaluate the article on what I find on page one, no content on page one = never click on page two.
To put all together it was really not an article I want to read. Sorry. If you posted the link because you think the content is readable, maybe rework it in an own blog post next time, if the quality of the original is so low. It helps you twice. First readers will appreciate your delivery much more and second, you will get the traffic/fame and not the source page here.
I hope my detailed analysis of why I can't suggest reading this article or giving you the +1 helped.
