В большинстве статей по защите от SQL-инъекций почему-то не упоминаются такие вещи как инъекции изнутри, SQL column truncation, ошибки экранирования при работе с многобайтовыми кодировками и фрагментация SQL-инъекций. Слышали ли вы о них? И если да, то как стараетесь избегать подобных опасностей?
Опишу в кратце каждый из них, для тех кто не в курсе. Ну и представлю способы защиты, которые по моему мнению лучше всего к ним подходят.

Инъекции изнутри проводятся при условии, когда введённые пользователем данные записываются в БД с применением экранирования, а потом, при определённом действии, извлекаются оттуда и помещаются ещё в какой-нибудь запрос. Например, пользователь ввёл текст "te'st". При занесении в БД кавычка экранируется - "te\'st" и запись без проблем попадает в таблицу. Дальше, при каком-нибудь действии эта запись извлекается и помещается в какой-нибудь другой запрос. Экранирование в таких случаях часто не проводят т.к. программисты склонны доверять данным пришедшим изнутри приложения. Хотя тот же слэш, который делает кавычку безопасной, пропадает уже при вставке. То есть в БД запись хранится в первозданном виде. Следовательно, в следующий раз попав в запрос, она вызовет ошибку.
Для того чтоб подобных вещей не случалось нужно просто не забывать о постоянном экранировании.

Уязвимости SQL Column Truncation появляются тогда, когда программист при внесении пользовательских данных в БД не проверяет их длину. Суть этих уязвимостей лучше объяснить на примере WordPress. В версии 2.6.1 можно было зарегистрировать второго администратора следующим способом. При регистрации вводилось имя admin[куча_пробелов]x. При этом ник с помощью пробелов делался длиной больше чем вместимость соответствующего поля в БД. Проверка на существования ника в базе конечно же результатов не давала и WP разрешал регистрацию. При попытке вставить в поле логина очень большую запись MySQL обрезал её до необходимой длинны. Плюс убирал пробелы с конца записи. И в базу в итоге попадал логин "admin".
Лечится такое обычной установкой уникального индекса на поля, содержимое которых должно быть уникальным. Ну и конечно-же не нужно забывать про проверку длинны того что ввёл пользователь

Проблемы с экранированием текста в многобайтовых кодировках имеют приблизительно такой смысл. Все мы знаем что у каждого символа есть свой ASCII-код. При оперировании символами машины используют HEX-значения их кодов. При экранировании кавычки, например, к ней добавляется слэш. В HEX-е это выглядит так - 0x5C +0x27 = 0x5C27. Но в некоторых кодировках есть как и символ 0x5С (слэш), так и символы с четырёхзначным HEX-кодом, который содержит в конце 5С. Получается, что подобрав нужный двузначный HEX-код (какой-нибудь символ, пусть даже не печатный), и подставив его перед кавычкой, можно при экранировании слэш превратить в другой символ. Чтоб лучше было понятно приведу такой пример. Допустим в какой-нибудь многобайтовой кодировке есть символ xx5C. Мы посылаем скрипту текст с кавычкой, и перед ней ставим символ с кодом "xx". Получается что между "xx" и "27" вставляется слэш - 5C. Но т.к. в данной кодировке есть символ xx5C, то слэш тут же перестаёт быть собой и надпись xx5C27 становится надписью из 2, а не из 3 как планировалось, символов. Возможно описание немного не понятно, но в сети есть пример такой вот уязвимости в SMF 1.1.4 на примере кодировки BIG5. Найдя его вам наверное станет более ясно что я имею в виду.
Принцип защиты тут прост - не пользоваться функциями типа addslashes, или str_replace("'", "\\'", ...). В PHP для таких вещей есть функция mysql_real_escape_string, которую таким образом не проведёшь. Про функции экранирования в других языках к сожалению не знаю.

Ну и суть фрагментации инъекций выглядит примерно так. Если программист при получении данных, сначала их экранирует, а потом обрезает до нужной длинны, то можно провернуть следующий фокус. Например, вводимый текст должен быть длиною 5 символов. Человек вводит 1111'. После экранирования текст превращается в 1111\', а после урезания до 5 символов - 1111\. Попадая в какой-нибудь запрос последний слэш вызывает нарушение его целостности. Ну и дальше по логике запроса - или это будет просто сбой, или полноценная инъекция.
Чтоб не попадаться на этом стоит просто сначала обрезать данные на сколько это необходимо, а потом уже экранировать.

Кому интересны эти методы нападений можете поискать их подробное описание в сети, там этого хватает. Ну и различные способы защиты там же.