Difference between SQL Injection and Cross Site Scripting

I came across a tweet from a non-Oracle person I follow that should amuse many web developers:

Ordered under what name? #wahckon pic.twitter.com/MftW2r8OK5

— Dan Buzzard (@DanBuzzard) May 1, 2016

One of the replies referred to "little bobby tables", eluding to a classic xkcd comic about SQL injection.

Of course I had to make the correction that this was in fact Cross Site Scripting (XSS), not SQL injection. This post summarises syntactical considerations within APEX, but in the spirit of #entrylevel content I'd like to summarise the conceptual difference. It's a little like flogging a dead horse, but security is everyone's concern so it won't hurt to mention it again!

Both concepts are about information being entered by a user within an application to do something nefarious, but they differ in where this malicious activity ends up happening.

SQL Injection is about information being entered in the browser, such as within a search field, which would impact the query being executed on the database. This could modify the statement to produces results you wouldn't normally have access to see, or even drop a table.

Don't try this on the road (Gizmodo)

Using bind variables instead of building dynamic queries usually mitigates SQL injection, but it doesn't stop bored programmers from finding susceptible examples in the wild.

Cross Site Scripting is also about information being entered in the browser, but instead of the malicious code impacting the database, it affects a user's machine when the information is redisplayed. Someone could enter JavaScript in a text area that when redisplayed as data, the code could actually execute.

It's never hard to find an example of XSS in the news, and it requires a little more proactive coding to minimise flaws.

Oracle APEX does a good job of 'escaping' information displayed in reports by default, so any code gets rendered as it looks, instead of being treated as if it's code. You may have already used the "Escape Special Characters" toggle to allow the use of the apex_item API within a report, but this should normally be used in conjunction with the apex_escape package. Another alternative is to use the HTML Expression attribute to construct your final code for output.

In the end this pizza store wins, since the person's "name" was rendered as entered instead of displaying an alert.

But they lose points for spelling "piza"