In simple terms, it is any code that can get onto and run on a server that is not supposed to, making a SQL Injection a subcategory of an SSI Injection.
Proper sanitization of incoming submissions is required to remove this sort of code, for example examining hidden fields the server has placed on a web page which have returned with different contents than what was placed in them originally, or data returned to the server from a result set it provided, which was not originally in the result set provided.
“In simple terms, it is any code that can get onto and run on a server that is not supposed to, making a SQL Injection a subcategory of an SSI Injection.”
No, server side include injection is not in the same category as SQL injection. The two use completely different functionality to attack a given script/site/application. Code that can get onto and run on servers it doesn’t belong is called either a virus, a rootkit or a crack. SSI injection can lead to one of these, but SQL injection will most likely not.
For a user to attack a site using SSI injection given the rudimentary definition at the link provided, they have to have permissions to write a web accessible file to the server. This is so they can write the code, then browse to it with a web browser to see the results. However, historically more common, a developer will use an unsafe command in an SSI command which a user then uses to attack the site, something like running an exec using form input. I say historically because there aren’t that many sites out there using SSI. *Most* sites now run on PHP or ASP, both of which are capable of far more than simple SSI in a far more secure manner.
On the other hand, SQL injection can be performed against any site or application which connects to a database. SQL injection is where a user enters unexpected values into a request field on a form which then exploits the database in some manner – such as returning data it’s not supposed to or wiping out essential data. However, the only way a user can perform this type of attack against you is if you directly use the user input in your query without sanitizing it. In any case where the possible exploit comes from user input, Mistoffeles is right, make sure you sanitize it.
In cases where a user has write permissions to a web accessible directory, your best bet is to jail them in that directory. If you can’t do this for whatever reason, remove the SSI exec privelege from the web server.