Комментарии 160
Функции mysql_* уже давно deprecated в PHP.
Ошибка «Warning: mysql_fetch_array() expects parameter 1 to be resource, boolean given» — не индикация того, что инъекция работает (хотя косвенно инъекция является причиной). Эта ошибка происходит из-за того, что mysql_query завершился неудачно и вернул false, а кое-кто поленился проверить в коде этот результат.
К тому же статья содержит большое количество грамматических ошибок. В общем, мне не понравилось.
Эта ошибка происходит из-за того, что mysql_query завершился неудачно и вернул false, а кое-кто поленился проверить в коде этот результат.
Согласен, т.к. тестируется на скриптах написанных «На коленке» и на локалхосте, поэтому при любой ошибке, даже синтаксиса, выводится данное уведомление. На «Боевых» скриптах, будет нужный вывод ошибок.
$r = mysql_query($q);
while($row = mysql_fetch_row($r)) {
//...
}
А должно быть так:
$r = mysql_query($q);
if ($r) {
while($row = mysql_fetch_row($r)) {
//...
}
} else {
//обработка ошибки
}
Как обрабатывать ошибку, зависит от окружения, но проверка должна быть всегда.
$user = mysql_real_escape_string($_GET['user']);
Вот за такие советы нужно по рукам бить, вы уж простите. PDO на это есть и prepared statements, привыкайте, что ли к цивилизованным методам.
Я лично такое вот делаю
$mdb->mes( $g_id ) или $mdb->query( «SELECT * FROM… WHERE id = '».((int)$g_id)."'" );
Оно по сути тот же mysql_* в мин обертке. Никогда не задумывался, что можно лучше. А я так понимаю можно? Но чем оно лучше?
$mdb->mes( $g_id )
$mdb->query( "SELECT * FROM xxx WHERE id = '".((int)$g_id).";'" );
большая часть пользователей похапе искренне полагает, что эта функция служит не для экранирования спецсимволов в строках, а для защиты от инъекций.
пагубность mysql_ заключается в двух вещах.
Первая чисто теоретическая — РНР-тим забил на эту либу и не хочет ее поддерживать. проблем с этим никаких нет, но теоретически ее могут в какой-то момент объявить deprecated.
Вторая заключается в том, что в коде не должно быть вызовов голого API. А должны быть — как совершенно правильно сделано у вас — вызовы функции- надстройки.
Единственно что, вместо ручной обработки передаваемых данных, лучше использовать автоматическую, с помощью плейсхолдеров:
$mdb->query( «SELECT * FROM table WHERE id =? AND name=?", $id, $name);
Это одновременно и упростит, и обезопасит код
а про быстроту там ниже ерунду написали
Для небольших скриптов достаточно простой фильтрации входящих данных по типу (в большинстве случаев надо просто привести к int, ибо в таких скриптах 80% запросов обычно идёт тупо по primary key) или же mysql_real_escape_string…
большая часть пользователей похапе искренне полагает, что эта функция служит не для экранирования спецсимволов в строках, а для защиты от инъекций.
ну и еще есть проблемы при неправильном использовании её с некоторыми экзотическими кодировками.
А это делается только функцией mysq_set_charset(), про которую большинство разработчиков не подозревает. Так что абсолютное большинство пользуется этой функцией совершенно без малейшей пользы :)
И мы бы давно сидели по уши в инъекциях, если бы эта уязвимость не работала только для ооочень экзотических кодировок.
Почему-то мне кажется, что оно и без этой ф-ции работает верно.
Т.к. у меня в коде есть запрос SET NAMES, но нет mysql_set_charset.
При этом, строки в KOI8-R и UTF-8 экранируются правильно (по-разному).
Если использовать mysql_escape_string (без передачи ресурса параметром), то она «сбоит» — портит строки при экранировании, если кодировка UTF-8.
> alshanetsky addslashes
Нашёл это:
In some cases the escape process can be
abused to execute exploits!
Escaping Shortfall Cont.
// invalid multi-byte sequence with ASCII equiv. of ¿’
$str = 0xBF. 0x27;
// after addslashes() or even mysql_real_escape_string()
// the value becomes [ 0xBF 0x5C ] 0x27
// a valid multi-byte sequence of 縗 followed by ‘.
SQL Injection is once again possible!!!
Native escaping function is only vulnerable if charset
is changed manually via “SET CHARACTER SET” query.
Как я понял проблема заключается в том, что ф-ции экранирования не совсем корректно работают с мультибайтовыми строками. Т.е. например для того же UTF-8 может проявиться уязвимость.
«Если использовать mysql_escape_string (без передачи ресурса параметром), то она «сбоит» — портит строки при экранировании, если кодировка UTF-8.» — Это тоже полная ерунда.
Вы бы хоть попробовали сначала, прежде чем писать.
Умозаключения — это всегда хорошо. Но их обязательно проверять надо :)
При этом пример по ссылке в гугле показывает, что функция как раз сбоит С ПЕРЕДАЧЕЙ параметра. Вы нашли эту статью?
ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.html
Попробуйте выполнить из нее примеры. Это совсем не так сложно. Зато сразу снимет кучу вопросов и неверных догадок :)
Достаточно забыть (или не иметь возможности) выполнить вторую часть заклинания — поставить по краям переменной кавычки — без которой карета, увы, тут же превращается в тыкву…
Главная проблема этой строчки — непонимание её смысла.
Вырежут скоро mysql_* функции из PHP
Пока не появится метка deprecated никуда их не вырежут (и даже с этой меткой не скоро исчезнут). А слухи — плохой аргумент.
сама по себе строка нормальная, в ней ничего ужасного нет.
но если она преподносится в контексте защиты от инъекций, то это, конечно, ужас.
плюс, если если функция посреди кода, а не внутри библиотечного метода — это тоже караул.
Если внимательно присмотреться к ее названию, то слова «защита» или «инъекция» почему-то в нем не встречаются.
Поэтому даже если не «забывать» её писать, что обсуждалось в ветке выше, инъекции после её использования могут быть — только в путь.
'SELECT * FROM `users` WHERE `name` = "{$name}";';
Можете мне привести пример инъекции на этот код, если функция не имеет никакой защиты?
Речь не о каком-то частном примере, а о понимании.
Рекомендую, все-таки, почитать что-нибудь, чтобы не писать ерунды про «встроенные в драйвер mysql защиты от инъекций» :)
Теперь осталось совсем чуть чуть: подумать, для чего на самом деле нужна эта функция, и почему она должна применяться ВНЕ зависимости от каких-либо инъекций.
И какие бывают случаи, когда она применяться не должна.
То, что твои скрипты «прекрасно жили» говорит либо о том, что ты применял не одну только эту функцию для защиты от инъекций, либо о том, они живут не так прекрасно, как ты воображаешь :)
А ПДО, кстати, тоже совсем недостаточна для защиты от инъекций. В более-менее сложных запросах.
Но опять это «ещё» :)
Я настаиваю на том, что функция искейпинга не должна применяться в контексте защиты от инъекций! Если это происходит, то инъекция будет гарантирована, рано или поздно.
Почему? Вы делаете раз за разом категоричные заявления, но не приедите аргументов. Я понимаю про устаревшесть, пдо и все такое, но объясните мне, почему недостаточно эскейпить все входные данные от пользователя и каким образом при правильно настроенных кодировках эта функция может стать причиной дыры в безопасности
Потому что эскейпинг не предназначен для защиты от инъекций. Точка.
Для защиты от инъекций надо применять те инструменты, которые для этого предназначены, а не случайно взятую с потолка функцию, которая может случайно 1 раз сработать.
Самая большая проблема здесь в том, что средний пользователь похапе воображает, будто SQL инъекция — это когда некий злодей Волдеморт водит волшебной палочкой и говорит заклинания. И чтобы от нее защититься, надо тоже поводить своей палочкой туда-сюда. А эскейпинг как раз и является такой палочкой. А если хоть раз в жизни дать себе труд задуматься, что такое инъекция и что делает эскейпинг, то сразу станет понятно что его тупо в одних случаях недостаточно, а в других он неприменим вовсе.
А "эскейпить все входные данные от пользователя" это уже совсем дно. Когда-то в ПХП была такая функция, "волшебные кавычки" называлась. Но уже 10 лет назад её с ужасом и стыдом из языка выпилили. Опять же, надо дать себе труд задуматься — что с ней было не так. Помимо того, что эскейпинг сам по себе не имеет отношения к инъекциям, тут у нас еще одна черная дыра глупости — "входные данные от пользователя". Если спросить среднего похапешника, какие данные входят от пользователя, аакие нет, волосы встанут дыбом. Во всех местах. Так что если доверить этому похапешнику решать, какие данные надо защищать и когда, то проще пароль от базы данных сразу написать на главной странице сайта.
Эта функция должна всегда (за несколькими исключениями) использоваться для того, чтобы обезопасить данные, вставляемые в запрос перед отправкой его в MySQL.То есть вы противоречите официальной документации PHP.
пс. простите за некропостинг, я только недавно заметил, что год топика — 2012-й
По этой ссылке написано, что Данное расширение устарело, начиная с версии PHP 5.5.0, и удалено в PHP 7.0.0.
В актуальной документации этой ереси нет.
Что "есть"? По этой ссылке можно увидеть корректные формулировки, бреда про "обезопасить данные" там нет.
Там написано "можно использовать в SQL выражениях". Может все-таки как-то проаргументируете свои мысли? Ну вот, к примеру, такой неприятный пример, как можно сделать в нем sql-инъекцию?
$in = $_GET['city'];
$escaped = mysqli_real_escape_string($link, $in);
$query = "INSERT into myCity (Name) VALUES ('$escaped')";
mysqli_query($link, $query)Не уходим от темы. Вопрос ко мне был, "можно ли использовать эту функцию для защиты от инъекций". По ссылке выше не написано, что можно. Вообще ни одного слова про инъекцию. Еще вопросы будут?
Давайте я задам вам вопрос иначе. «Почему нельзя использовать mysqli_real_escape_string в качестве защиты от sql-инъекций?» Только пожалуйста, без эмоций, сухие факты, если есть. Если нету — так и скажите.
Но и не написано, что нельзя.
Дружище, это уже совсем за гранью добра и зла и формальной логики. В описании функций strlen, htmlspecialchars, empty, intval, urlencode, sort, header тоже не написано, что их нельзя применять для защиты от инъекций. Cогласно вашей логике получается что можно?
Просто написано, что данные можно вставлять в запрос,
Там нету слова "данные".
Почему нельзя использовать mysqli_real_escape_string в качестве защиты от sql-инъекций?
Потому что эта функция для этого никаким боком не предназначена. По своему прямому назначению ее применять можно. Для защиты от инъекций — нельзя.
Если я, как последний глупец, буду использовать mysqli_real_escape_string для защиты от инъекций — какие проблемы я могу отхватить? Допустим, мой прадедушка пару лет назад сделал сайт про рыбалку, он там использовал эту функцию для защиты от инъекций и я вот хочу оценить риски и понять — нужно ли ему срочно переводить сайт на PDO и плейсхолдеры или можно оставить mysqli_real_escape_string и продолжить делать сайт про охоту? Он у меня просто не очень прогрессивный и ему сложно даются новые технологии. Так расскажите мне риски, пожалуйста, я хочу их оценить
Нельзя потому что нельзя.
Я ничего такого не писал. Не надо перевирать мои слова.
Давайте я вам еще раз попробую объяснить. Не бывает никаких абстрактных "данных", которые можно волшебным образом "обезопасить". Этот бред действительно был когда-то написан в документации, но люди делятся на тех, кто умеет извлекать уроки из ошибок прошлого, и тех кто предпочитает не считать их ошибками.
Волшебной функции для защиты от инъекций вообще в природе не существует. Не существует волшебной палочки, которая защитит любые абстрактные данные от любой абстрактной инъекции. Как только вы избавитесь от этой иллюзии дело сразу пойдет легче.
Я не предлагаю принять на веру. Я предлагаю принять на логику. Я вам привел железобетонный логический аргумент: нигде не написано, кроме устарвешей страницы документации по несуществующей версии пхп, что эта функция должна использоваться для защиты от инъекций. Этого уже должно быть достаточно.
Если в каком-то отдельно взятом случае эта функция случайно помогла, это не значит, что ее предназначение именно в защите от инъекций.
Это ведь просто строки
Не только строки
Как по мне, то использование real_escape_string необходимый в некоторых кейсах элемент защиты от инъекций. Но недостаточный. Видя наличие real_escape_string можно утверждать, что какая-то защита от инъекций есть, но лишь какая-то, не более.
По той причине, что она, в качестве побочного эффекта, защищает от инъекций только строковые литералы. Для всех остальных элементов запроса она бесполезна, и ее использование приведет к инъекции. Именно по этой причине её категорически нельзя использовать для защиты.
Для всех остальных элементов запросаНапример, каких?
Для любых. Если можешь назвать хоть один, то он подойдет. Напиши на бумажке SQL запрос, и выбери любую его часть, которая не строковый литерал. Вот для ее защиты real_escape_string и будет бесполезна на 146%
Мда.
SELECT * FROM news ORDER BY $fieldесли нам требуется сортировка по выбираемому пользователем полю, то real_escape_string не защитит его от слова "никак".
Зададим тебе это в качестве домашнего задания :)
Ты забавный мальчик :)
Если назовешь хоть одну причину, по которой я должен это сделать, то так и быть, я разжую тебе даже это.
Это твоя главная проблема.
И именно поэтому ты поднял топик многолетней давности, ага :)
Логика это явно твоя сильная сторона.
1. По ошибке (увы, не заметил, что он стар)
2. Потому что не знал (и так и не узнал) ответ на вопрос
Мои причины вполне логичны и я их могу назвать. А зачем вы подняли устаревший топик, если до сих пор не можете дать ответ на простой вопрос?
На самом деле я тебе ответил. С превеликим трудом мы уже смогли осилить тот факт, что эскейпинг помогает только строкам (в качестве побочного эффекта), и бесполезен для любых других элементов запроса. Этого уже должно быть достаточно. Но беда в том, что все эти термины для тебя — пустой звук, абстракция.
Чтобы понять ответ на вопрос, надо заранее знать половину ответа. Для тебя же "строки", "инъекция" и "эскейпинг" — это абстрактные понятия, не имеющие физического смысла. Когда-то в далеком детстве ты прочитал сказку, что "инъекция" — это злой Кащей Бессмертный, а "эскейпинг" — это молодцеватый Илья-муромец, который разит супостата прямо в темечко. На таком уровне я действительно не готов объяснять, извини.
Попробуй самостоятельно найти хотя бы один пример инъекции и разобраться как она работает. Понять чем отличается строковый литерал от идентификатора в SQL. Чем конкретно занимается пресловутый искейпинг, и зачем. После того как разговор перейдет для тебя из мифологической в практическую плоскость, можно будет продолжить.
Если же тебе лень это делать то придется принимать на веру, точно также как ты когда-то принял на веру бред про "обезопасить данные".
На самом деле я тебе ответил
Я повторю, возможно переформулировав, вопрос. Максимально кратко, если не доходит:
Приведи пример инъекции.
Все остальное твое самолюбование не имеет никакого смысла. Спекуляции на тему «может быть, а может сам догадаешься» работают только в детском саду.
если нам требуется сортировка по выбираемому пользователем полю
Кстати, я тут нагуглил, что PDO::prepare вообще не позволяет подставить поле, так что все-равно необходимо будет думать об этом независимо от того, используешь ли ты их:
You cannot search with a prepared statement
This fails:
"SELECT * FROM users WHERE :search=:email"
This succeeds:
"SELECT * FROM users WHERE $search=:email"Вот такого рода комментарий, демонстрирующий хоть какое-то шевеление на том конце, является куда более конструктивным способом ведения дискуссии, чем однообразное повторение "дядь, покажи фокус". Я если я тебе покажу инъекцию, она все равно останется на уровне фокуса. А мне интересно чтобы ты понял и сам мог объяснить.
Все верно, PDO::prepare с идентификаторами не работает. Но главное здесь в том что prepare сразу не даст так сделать, а escape_string молча проглотит и ты заложишь первоклассную инъекцию в свой код. Теперь ясно?
Теперь ясно?Нет, не ясно. Если человеку необходимо будет так вставить название поля — ему все-равно придется как-то это сделать (я, правда, не представляю, кто может в качестве названия поля напрямую вставлять ввод пользователя, но это уже детали).
Кстати, на счет фокусов. Я тут прочитал еще раз топик и увидел, что вы начинаете путаться в своих показаниях. Вот тут вы говорите, что она защищает строковые литералы:
По той причине, что она, в качестве побочного эффекта, защищает от инъекций только строковые литералы.
А вот тут, что не защищает:
taliban
Можете мне привести пример инъекции на этот код, если функция не имеет никакой защиты?$name = mysql_real_escape_string($name); 'SELECT * FROM `users` WHERE `name` = "{$name}";';
FanatPHP
Могу, но речь не о них.
// example.com?name=1 OR 1=1
$name = mysql_real_escape_string($_GET['name']);
query("SELECT * FROM `users` WHERE `name` = $name;");Вы это имели ввиду?
Твой прогресс просто потрясает воображение. Ты бы, конечно, мог прийти к этому выводу и раньше, если бы прочитал статью, которую комментируешь — в ней этот пример как раз присутствует. Кстати, если осилишь еще и комментарии к ней, то получишь ответ и на свой предыдущий вопрос.
И снова я вынужден повторять в который раз, real_escape_string не имеет никакого отношения к инъекциям и никогда не должен использоваться для защиты от них.
Нужно всегда соблюдать всего два правила:
— данные пподставляем в запрос только через плейсхолдеры.
— идентификаторы и ключевые слова подставляем только из белого списка, прописанного в нашем коде.
Всё. Больше ничего не нужно, никакой фильтрации.
Можно лишь добавить, что плейсхолдеры могут использоваться либо родные — от БД, либо самодельные.
В последнем случае наш парсер должен знать тип подставляемых данных, и корректно их отформатировать.
Вы бы лучше объяснили незнающим, почему в PHP 10 + «15 apples» даст в результате 25, а 10 + «apples 15» — 10 и т.п…
Поверьте, Вам бы это стоило немного поковырять документацию + исходники, а статья была бы очень даже интересной, на мой взгляд.
Я вот новичок, и мне статья очень понравилась!
Например, я знаю какие символы недопустими в передаваемых параметрах, но как применить эти недопустимые символы в «плохих» целях я не знал. Разве что совсем простые примеры.
Тут мне показали как это можно использовать.
И так понял что в дальнейшем автор планирует показать более сложные примеры.
P.S. например для такого использования union я не додумался. А автор мне показал. Теперь буду знать врага в лицо.
Мне одному кажется что это сжатый и немного измененый пересказ уже существующей статьи датированной 2010 годом? Причем очень много чего в этих статьях схожего.
rdot.org/forum/showthread.php?t=124
Да и по теме. Ни Ваша статья, ни приведенная статья по ссылке не научит правильно обнаруживать и раскручивать SQL иньекции. Хотя, признаюсь, много чего почерпнул когда то из последней статьи.
К примеру пытаться обнаруживать иньекции только по наличию ошибок — бред. В ~80% случаях вывод ошибок отключен, и приходится ориентироваться на поведение самого приложения.
Не верю
(с) Станиславский.
Так как мы не можем повлиять на их количество в первом запросе, то нам нужно подобрать их количество во втором к первому.
Ваша:
Т.к. мы не можем повлиять на их количество в первом запросе, то нам нужно подобрать их количество во втором, чтобы оно было равно первому.
Пример со сто рублями передран и немного переделан. Используется таже таблица news… Продолжать?
Откровенно говоря, оригинал данной статьи я когда то очень долго держал у себя как личную «библию», и очень часто обращался к ней за помощью, именно по ней я научился некоторым фишкам. И тут приходите вы, и пытаетесь выдать чужое за свое…
$_GET['id'] — всегда число, а фильтрация escape для запроса вида
SELECT * FROM news WHERE id=1
Таким образом нам даже и кавычка не нужна для sql-injecton. Достаточно просто положить -1 UNION SELECT 1 в $_GET['id']
>>Если при GROUP BY 4 нет ошибки, а при GROUP BY 6 — ошибка, Значит кол-во полей равно 5
Может быть 4 поля, ибо мы не знаем как оно реагирует на group by 6
' or 1 # считался администратором и пароль при этом не спрашивался. А вообще это даже грустно.
ВНИМАНИЕ! Перед и после него обязательно должны стоять пробелы.
Пробел должен стоять только после —
Отлично, файл у нас записался. Таким образом, Мы можем залить мини-шелл:
sqlinj/index2.php?user=-1' UNION SELECT 1,'<?php eval($_GET[1]) ?>',3,4,5 INTO OUTFILE '1.php' --%20
Такой INTO OUTFILE ничего не даст, так как файл запишется в datadir, не доступный из веба.
Ни слова про привилегии на таблицы/базы? Если у пользовательского скрипта задача только читать, и только из двух таблиц, то ему достаточно соединятся с базой под максимально ограниченными привилениями.
Да и про фильтрацию как-то невнятно… фильтровать желательно не только входящие, но и исходящие данные, причем не только по типу, но и по размеру с диапазоном. Забирать сырое значение из _GET небезопасно по умолчанию, это чревато не только иньекциями. Отдавать шаблонизатору результат неизвестно какого формата тоже опрометчиво.
можете пояснить более подробно?
Отдавать шаблонизатору результат неизвестно какого формата тоже опрометчиво.
На то он и шаблонизатор, чтобы всё что нужно заэкранировать. Шаблонизатор обязан получать сырые данные, если мы хотим сделать разделение логики представления данных и логики получения данных.
тогда sql-injection.jpg
Извините за флуд и формат.
cs303303.userapi.com/v303303091/c49/E10kHhDsomY.jpg
SQL injection для начинающих. Часть 1