comments (not for humans)
"As you saw from your implementation, writing your own security routines isn't always a good idea", Mr. X said looking me straight in the eyes.

I had to admit he was right. If I had already made one easy mistake, there were bound to be others I couldn't easily think of.

"Instead of reinventing the wheel for each project", he continued, "we should rather look at what is made available to us by the frameworks we are using or if there are any external modules that fits our project"
"Ok", I replied, "Anything in mind for the SQL-injection part?"
"Yes. SQL-injection is quite easy to mitigate by allowing the framework to do the output escaping for you. Most frameworks support some sort of parametrized queries."
"But I thought those were invented to support prepared statements", I objected
"You may be right, but they also have an added security benefit. Let's look at some code", he said and moved over to my laptop.

He opened a browser window, and pointed it to http://java.sun.com/docs/books/tutorial/jdbc/basics/prepared.html. He scrolled a bit down, and showed me the following code:
PreparedStatement updateSales =
con.prepareStatement("UPDATE COFFEES SET SALES = ? WHERE COF_NAME LIKE ? ");
updateSales.setInt(1, 75);
updateSales.setString(2, "Colombian");
updateSales.executeUpdate();

"Now as you can see", he said, "we are replacing the inputs with question marks, and in the two next lines we are telling the framework the data to input and the corresponding data types. This allows the framework to handle the escaping for us"
"So by using prepared statements or parametrized queries we avoid SQL-injection?"
"Well, not really. There are still ways developers can abuse this to reintroduce SQL-injection vulnerabilities. Consider the following"

He copied the code into a text editor, and changed it slightly:
PreparedStatement updateSales =
con.prepareStatement("UPDATE COFFEES SET SALES = ? WHERE COF_NAME LIKE \""
+ coffeeName + "\"");
updateSales.setInt(1, 75);
updateSales.executeUpdate();

"We are still using the PreparedStatement class, but we are abusing it by concatenating the SQL-statement with input. The application is once again vulnerable."

Continue to part 8...

Go back to: Part 1, Part 2, Part 3, Part 4, Part 5, Part 6
Thomas Ferris Nicolaisen

Nice!

Very readable and understandable stuff! I really like the story-teller/dialogue style. Keep it up :)
Erlend

Re: Nice!

Thanks! Appreciated
Some1

Spelling correction - TYPO

"I had to admin he was right"
Shouldn't it be "I had to *admit*"
What's this article about ?
Erlend

Re: Spelling correction - TYPO

Thanks, fixed now. It's a series of articles trying to explain web security as a story. Heavily influenced by Robert C. Martin's similars series regarding code and code quality. There is a link and reference to it in the first part http://erlend.oftedal.no/blog/?blogid=79
Comments closed for this post