2010-01-18 3 views
3

Sql Инъекция возможна, если параметры передаются через GET. Но возможно ли это также через POST. Если да, может ли https предотвратить это?Возможно ли внедрение SQL с помощью POST?

+0

См. Вопрос SO http://stackoverflow.com/questions/1716979/are-sql-injection-attacks-only-a-threat-on-a-page-that-has-a-form, который охватывает «POST против GET "часть этого вопроса. – mjv

ответ

19

Да, это возможно с $_POST, а также с $_GET, $_COOKIE и $_REQUEST. HTTPS не будет защищать вас вообще. Вы должны использовать некоторые функции для защиты вас, например mysql_real_escape_string или использовать prepared statements.

Все сообщения из веб-браузера должны обрабатываться как «ненадежные». Другие методы, которым вы не можете доверять, - Ajax, file uploads и JavaScript form validations (среди прочих). Все эти данные поступают непосредственно из веб-браузера и не должны быть доверены, прежде чем вы отфильтровываете их или проверяете данные.

Единственное, чем вы можете доверять: $_SESSION, при условии, что вы ТОЛЬКО ставите проверенные данные в свои $_SESSION переменных.

+0

* giggles * ... так что PHP нуждался в функции * real * string escape, потому что оригинала не хватило? И они не стеснялись называть его именно так? :-) – Joey

+0

@johannes: Не знаю, почему здесь находится «настоящая» часть, но mysql скорее всего потребует определенных символов, которые могут быть или не могут быть покрыты в других управляющих функциях. Поэтому наличие специальной версии mysql имеет смысл. Опять же, не знаю, что делает «настоящая» часть в названии, хотя ...возможно, кто-то с удовольствием: p – Svish

+2

На самом деле разница в том, что настоящая строка escape учитывает набор символов текущего соединения с базой данных, в то время как исходная escape-строка даже не требует подключения к использованию (менее безопасна) –

7
  1. Да, вы можете вводить SQL через POST. Любой может изменить то, что получает отправку в POST-запросах (найдите аддон для firefox под названием «hackbar»
  2. Ни один https не поможет в этом, потому что он ничего не может сделать против атак на уровне веб-приложений, средние атаки и нюхают.
+2

Вам не нужны модные инструменты взлома - написание ваших собственной страницы html с vi/notepad может быть достаточно. – symcbean

+0

Хакбар позволяет подделывать референта и легко добавлять/манипулировать куки. Мне нравится показывать это в качестве примера, потому что это иллюстрирует, что клиенту никогда не следует доверять. +1 для простоты, хотя –

0

HTTPS не может защитить вас здесь. Фильтр вам вход (ы)

+0

дезинфицировать всю сторону сервера ввода пользователя ... вы не можете доверять любому коду на стороне клиента ... и вы можете переписать любой заголовок, например, user-agent или referrer, чтобы они не записывались непосредственно в db. . –

4

Вы должны избежать всех пользователей представленных данных, независимо от метода.

2

нет, ISN» t разница между этими двумя методами.

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

+0

Если вам необходимо пройти Sql Query через POST или GET, что может быть самой безопасной? Если я зашифрую запрос и отправлю тогда ...? – RKh

+0

Никогда не нужно передавать необработанный запрос в браузер под контролем пользователя, которому не доверяют полностью (доверяют, чтобы не пытаться сломать вещи ** и **, которым доверяли, чтобы не повредить вещи случайно). Если вы считаете, что есть необходимость, вы просто не думали о достойном решении (что обычно связано с разбивкой данных в запросе на части, которые являются стандартными (которые вы держите на стороне сервера) и части, которые являются введенными пользователем данными (которые вы проверяете, когда они отправляются обратно вам, чтобы убедиться, что они в безопасности). – Quentin

+0

Если я передаю зашифрованную строку, то? – RKh

2

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

Самый простой способ, который я нашел в PHP для этого, - использовать Codesense's mysqli wrapper. Это аккуратный, маленький, класс, который удаляет большую часть проблем, связанных с необработанными подготовленными операциями, был более чем достаточно прочным, где я его использовал.

Использование этого подготовленного SQL только немного сложнее, чем прямой SQL, поэтому на самом деле нет оправдания для нет.

Смежные вопросы