SQL Injection после удаления всех одиночных кавычек и тире символов

Может ли кто-нибудь показать пример оператора sql, когда SQL Injection произошел даже после того, как все "одиночные кавычки" и "штриховые символы" были удалены из пользовательского ввода?

SELECT MyRecord   FROM MyTable   
WHERE MyEmail='[email protected]' AND MyPassword='foo'

(Здесь не задействованы никакие INT).

Кажется, что все говорят "да, я могу это сделать"... но когда они нажаты для e-x-a-m-p-l-e... никогда не показывались.

(Вы можете использовать любую версию, новую или старую, любого SQL-движка: SQL Server, MySql, SqlLite, PostgreSQL, Oracle и многие другие.)

ОТВЕТЫ

Ответ 1

Как вы "лишили пользователя ввода"? Если вы просто удалили все вхождения кавычек, то это действительно не справедливо для susan.o'[email protected], который не сможет использовать ваш сайт.

Если вы избежите каждой цитаты с другой цитатой которая также может вызвать проблемы. Если вы прошли через \'; DROP TABLE users; -- (по крайней мере, в MySQL \' является альтернативой экранированию кавычек), то экранирование одной кавычки приведет к атаке SQL-инъекции, которая приведет к потере таблицы пользователей:

SELECT MyRecord FROM MyTable
WHERE MyEmail='\''; DROP TABLE MyTable; --' AND MyPassword='foo'

единственным реальным безопасным способом дезинфекции ваших входов является Параметрирование:

SELECT MyRecord FROM MyTable
WHERE MyEmail=? AND MyPassword=?

а затем добавьте значения параметров, используя выбранный вами язык, например, в java, где ps - PreparedStatement:

ps.setString(1, "[email protected]");
ps.setString(2, "foo");
ps.executeQuery();

Ответ 2

Проблема заключается не в том, что вы не можете создать систему санитарии, которая может избежать инъекции SQL; ты можешь. Проблема в том, что вы не можете создать реалистичную систему санитарии, которая гарантирует отсутствие инъекции SQL и может использоваться в любой, но самой тривиальной ситуации.

Приведенный вами пример - один из тех тривиальных случаев, которые никогда не могли быть использованы в реальном продукте. Реальный продукт должен поддерживать как одиночные кавычки, так и дефисы в именах пользователей и, вероятно, должен позволять обе (по крайней мере, дефисы) в поле пароля. Ваша система не позволяет:

  • Пользователи с апострофами в своих именах, например О'Рейли.

  • Пользователи с дефисными именами (Jean-Pierre) или последними (Fortesque-Smythe).

  • Пользователи, чьи домены адресов электронной почты включают дефисы.

  • Пароли, в которых пользователи следуют общей рекомендации по выбору знаков пунктуации и хотят использовать дефис или апостроф.

Итак, ваша санитация довольно безопасна для SQL-инъекций. Но так будет система, которая допускала бы только верхнюю букву "A".

Ответ 3

Возможно, вам стоит попробовать эту строку: [email protected]%BF%27 OR true; /* см. эту ссылку для объяснения