Статья про нетипичную эксплуатацию SQL инъекции и про трюк в sqlmap. А еще — про Counter Strike

[vanxant]

Админам: ну и соль, конечно, неплохо бы поменять с дефолтного значения.
Мало ли, сколько там ещё дырок.

[Fedcomp]

нужно чтобы разрабатываемые скрипты сами меняли соль на случайную при установке.

[cher11]

Скажите, пожалуйста, для чего в запросе используется «admin_pass = 0x61»? Очень интересна тема инъекций, понятно, почему запрос пройдет, понятно, что UNION выберет записи из таблицы с администраторами. Но зачем пароль должен быть равен строчной латинской «a»? (смотрел по таблице ASCII)

[tyderh]

Это суть слепой инъекции. Благодаря оптимизациям в выражении

admin_pass = 0x61 or sleep(1)

второе условие даже не исполняется, если верно первое, поскольку результат в таком случае уже определен. По очевидным причинам мы можем узнать, выполнилось ли второе условие.
Далее sqlmap перебирает все символы алфавита и узнает тем самым первую букву пароля. Можно продолжать со второй.

[stan_jeremy]

Если точнее то time-based слепой инъекции.

[zenn]

Из забавного — не получится ничего сделать если соль и/или алгоритм для подписи будут неизвестны атакующему.

Это смотря для чего она используется эта подпись, к сожалению вы не показали это в статье. Если это валидация «голоса» — то строка так или иначе должна быть передана клиенту (возможно в другом виде) где и может быть поймана.

[BeLove]

Я указал в статье явным образом, что подпись (hash) используется при голосовании пользователем.
Передавать хэш, да, надо, но не соль. А не зная соль и алгоритм подписи sqli провести не получится, так как не получится вычислить хэш для запросов. Шансы восстановить соль+алгоритм подстановки, зная только хэш, довольно минимальны.

[zenn]

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

[BeLove]

yadi.sk/d/OR6OSOvVCedhZ качал отсюда

[zenn]

Ну и в чем проблема с этим «хэшем»? Он отображается прямо на странице пользователю и далее передается в js функцию rating() 3-им параметром, после отправляется в $.post {} вместе с остальными хедерами.
/servers.php (~156-162)

<a href='javascript://' onClick=\"rating({$r['server_id']}, 'up', '".md5("m0n3ng1ne.s4lt:P{]we{$r['server_id']}@._)%;")."');\" class='voteup' id='{$r['server_id']}'></a>
<a href='javascript://' onClick=\"rating({$r['server_id']}, 'down', '".md5("m0n3ng1ne.s4lt:P{]we{$r['server_id']}@._)%;")."');\" class='votedown' id='{$r['server_id']}'></a>

Открываем нужную страницу, дергаем hash и его же подставляем к выше описанному вами методу как параметр 'hash' (post) и ненужно там ничего генерировать, никакие соли нам не важны.

[BeLove]

Хах, тогда да, я не смотрел дальше, думал они всё же сразу его подставляют на серверной стороне, а не на клиентской :) Это, конечно, доставляет.

[zenn]

Просто хэш он на то и хэш — если идет где то его проверка и она как-либо связана с клиентскими данными то и на стороне клиента должна быть какая-либо строка, которая позволит в дальнейшем сгенерировать данную хэш-сумму (ведь функция — необратима). Здесь он роль «хэша» не исполняет вовсе — т.к. по сути это строка отданная клиенту и в дальнейшем проверенная на подлинность.

[BeLove]

Про хэш да, но не про соль+алгоритм. На сторону клиента можно было отдать уже хэш, без соли, генерируя его на серверной стороне.
В данном случае вообще этот хэш — «пустышка», ни от чего не защищает (как кроме от sqli, если бы соль не отдавалась клиенту).

[zenn]

И что бы вы тогда проверяли? )) Как не крути — вам придется передать клиенту данные, на основе которых вы после и будете проверять корректность запроса. Зная алгоритм проверки запроса(или нет) — как не извращайтесь, эти данные легко подделать(даже получив данные как легитимный клиент приложения).

[BeLove]

reCaptcha + уникальность IP в 24 часа.

[zenn]

Все верно, тест Тьюринга здесь необходим, но отношения к «хешу» он не имеет. И да, для recaptcha есть уйма сервисов по разгадыванию за символичный бакс на тысячу, а с ip могут возникнуть в дальнейшем и проблемы, связанные с увеличением кол-ва пользователей сети (v4 провайдеры смело выдают 1 на всю подсеть) и переходом(в перспективном будущем) к ipv6 ;)

[BeLove]

Так я и пишу, что хэш — не нужен. Максимум, сделать какую-нибудь зависимость от IP адреса клиента, чтобы добавить накрутчику один запрос.
Про рекаптчу в курсе, но когда говорим о средствах защиты мы должны сопоставлять стоимость атаки и профит от неё. В данном случае атакующему проще купить легальный «VIP» статус, который зарезервирует за ним топ в списке серверов.

[rework]

Сохранять хэш в сессии, не нужно клиенту передавать данные.

[zenn]

А чем будет отличаться сохраненный «хеш» в $_SESSION от к примеру параметра «1» — ведь эти данные остаются на стороне сервера…

[BeLove]

upd: соль не передается клиенту, так что приведенный код ничего не дает.
Нам нужна оригинальная соль, чтобы подписывать свои запросы. Мы не можем открыть страницу с сервером с параметром инъекции, выдаст 404.

[NickyX3]

У авторов скрипта непонимание того, зачем нужна mysql_real_escape_string и что делать с параметрами вообще.
Во-первых, если они использовали mysql_real_escape_string — то думали что id таки строка — тогда наличие кавычек в запросе обязательно.
Во-вторых, если же кавычки отсутствуют, то скорее всего подразумевалось что $id всеже число, причем целое. Тогда и mysql_real_escape_string не нужна — достаточно было сделать intval($_POST['id']) приведя тем самым $id к определенному типу (и отрезать большинство инъекций).

Статья — еще один довод тем, кто еще не проверяет входящие параметры и не приводит типы к ожидаемым

[zencd]

Шел XXI век, а ССЗБ всё составляли и составляли строки sql-
запросов вручную…

[Alexsey]

После просмотра исходников я бы сказал скорее так — Шел XXI век, а ССЗБ до сих пор не использовали фреймворки и MVC подход для таких достаточно крупных скриптов.

[NickyX3]

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