In school, one of the things they tried to drill into us was the separation of the UI (view), models, and controllers, as well as the idea of using stored procedures. Now I know why they tried to ram things like this into our minds.
One app I had the opportunity to work on was written in Visual Basic. The app being written in Visual Basic wasn't the worst. There's been some decent things created using Visual Basic, even if it is the runt of the programming language litter. This app, in particular, though, had some nasty surprises. One of these surprises was discovered by a "Mr. O'Conner".
At one point in the app, it had a text box that took in an individuals name. When I first started digging into the code, I was horrified to see an SQL statement directly behind the button click event for the button that was next to the text box. It was literally taking the contents of the text box, at face value, and inserting them directly into an insert query. This worked fine until someone had a single quote in their name. Like Mr. O'Conner.
For those not familiar with an SQL injection attack, the idea goes something like this: if inputs aren't properly sanitized, it is possible to enter a piece of text that terminates the existing SQL query, and starts another - whatever other sort of query (or update/delete statement) you want. So Mr. O'Conner, with a single quote in his name, was suddenly breaking the app. The previous developer put in the "fix" of converting the single quote to a backtick.
This is not the proper way to fix something like that. The proper fix would be to use a stored procedure, and sanitize any inputs going into the app. But, like I said, in this case "Mr. O'Conner" was switched over to be "Mr. O`Conner".
The moral of the story:
- Never put SQL statements directly behind button clicks.
- Use stored procedures.
- Sanitize your inputs properly (and don't trust them in the first place!).
- If your name is Mr. O'Conner, you may want to consider a career in software testing.
Top comments (0)