SQL injection isn't the only situation in which hackers can elevate data to a command level in order to execute an attack. Web applications, for example, have to constantly guard against what can happen when end-user input is collected then redisplayed for other users (typically after it's been saved to a database).
Here's a simple example of how exploits against web applications can function: Suppose that a blog engine allows visitors to comment on posts. This blogging engine stores user comments in a database and then redisplays them to subsequent visitors. A comment such as "nice post!</body></html>" would wreak havoc with the display of the site because the user input has been elevated to the command level and has been empowered to prematurely signal the end of the HTML document through the use of HTML tags.
However, when it comes to exploiting web applications, hackers typically aren't looking to merely deface layouts. Instead, they're looking for an opportunity to use any input mechanism (such as form fields, the query string, cookies, user-agent strings, or the referrer) to inject markup and behavior into a vulnerable site, which they can then use to exploit the browsers of other visitors. So, for example, rather than injecting something tame like "</html>", a hacker might try something like "<img src=http://evilsite.com/x.gif />", which would instruct a user's browser to "reach across" to another website. Moreover, if hackers are able to force browsers to reach across to other websites and load scripts, they succeeded in creating what is known as a cross-site scripting, or XSS, attack.
Commonly, XSS attacks are categorized as either being first-order (or direct) or second-order (or persisted) attacks. In first-order attacks, hackers try to lure users to click a link that uses direct input (commonly from the query string) to facilitate an attack. In second-order attacks, hackers try to successfully save input (e.g., input in the form of comments) in a database.
Because second-order XSS attacks involve a database, they're commonly confused with SQL injection attacks. But other than the fact that SQL injection and second-order XSS attacks involve the use of databases and occur when developers let hackers elevate input to the command level, these two attack vectors are quite different. For example, SQL injection attacks focus solely on attempting to gain control of databases and the data within them (although if hackers gain sufficient control, they can execute second-order XSS attacks as a "bonus"), whereas XSS attacks focus on exploiting web browsers and their owners.
Trying to scrub, or filter out, malicious input represents an ineffective solution for XSS attacks. Instead, you need to make sure that end-user input is never allowed to be blindly parroted back as markup. In other words, to defeat XSS attacks, user-supplied input needs to be encoded to ensure that it's treated as data instead of markup.
