Comments 24
Админам: ну и соль, конечно, неплохо бы поменять с дефолтного значения.
Мало ли, сколько там ещё дырок.
Мало ли, сколько там ещё дырок.
Скажите, пожалуйста, для чего в запросе используется «admin_pass = 0x61»? Очень интересна тема инъекций, понятно, почему запрос пройдет, понятно, что UNION выберет записи из таблицы с администраторами. Но зачем пароль должен быть равен строчной латинской «a»? (смотрел по таблице ASCII)
Это суть слепой инъекции. Благодаря оптимизациям в выражении
второе условие даже не исполняется, если верно первое, поскольку результат в таком случае уже определен. По очевидным причинам мы можем узнать, выполнилось ли второе условие.
Далее sqlmap перебирает все символы алфавита и узнает тем самым первую букву пароля. Можно продолжать со второй.
admin_pass = 0x61 or sleep(1)второе условие даже не исполняется, если верно первое, поскольку результат в таком случае уже определен. По очевидным причинам мы можем узнать, выполнилось ли второе условие.
Далее sqlmap перебирает все символы алфавита и узнает тем самым первую букву пароля. Можно продолжать со второй.
Из забавного — не получится ничего сделать если соль и/или алгоритм для подписи будут неизвестны атакующему.
Это смотря для чего она используется эта подпись, к сожалению вы не показали это в статье. Если это валидация «голоса» — то строка так или иначе должна быть передана клиенту (возможно в другом виде) где и может быть поймана.
Я указал в статье явным образом, что подпись (hash) используется при голосовании пользователем.
Передавать хэш, да, надо, но не соль. А не зная соль и алгоритм подписи sqli провести не получится, так как не получится вычислить хэш для запросов. Шансы восстановить соль+алгоритм подстановки, зная только хэш, довольно минимальны.
Передавать хэш, да, надо, но не соль. А не зная соль и алгоритм подписи sqli провести не получится, так как не получится вычислить хэш для запросов. Шансы восстановить соль+алгоритм подстановки, зная только хэш, довольно минимальны.
Дайте пожалуйста в п.м. ссылочку на архив с исходными кодами, хотелось бы взглянуть.
yadi.sk/d/OR6OSOvVCedhZ качал отсюда
Ну и в чем проблема с этим «хэшем»? Он отображается прямо на странице пользователю и далее передается в js функцию rating() 3-им параметром, после отправляется в $.post {} вместе с остальными хедерами.
Открываем нужную страницу, дергаем hash и его же подставляем к выше описанному вами методу как параметр 'hash' (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) и ненужно там ничего генерировать, никакие соли нам не важны.
Хах, тогда да, я не смотрел дальше, думал они всё же сразу его подставляют на серверной стороне, а не на клиентской :) Это, конечно, доставляет.
Просто хэш он на то и хэш — если идет где то его проверка и она как-либо связана с клиентскими данными то и на стороне клиента должна быть какая-либо строка, которая позволит в дальнейшем сгенерировать данную хэш-сумму (ведь функция — необратима). Здесь он роль «хэша» не исполняет вовсе — т.к. по сути это строка отданная клиенту и в дальнейшем проверенная на подлинность.
Про хэш да, но не про соль+алгоритм. На сторону клиента можно было отдать уже хэш, без соли, генерируя его на серверной стороне.
В данном случае вообще этот хэш — «пустышка», ни от чего не защищает (как кроме от sqli, если бы соль не отдавалась клиенту).
В данном случае вообще этот хэш — «пустышка», ни от чего не защищает (как кроме от sqli, если бы соль не отдавалась клиенту).
И что бы вы тогда проверяли? )) Как не крути — вам придется передать клиенту данные, на основе которых вы после и будете проверять корректность запроса. Зная алгоритм проверки запроса(или нет) — как не извращайтесь, эти данные легко подделать(даже получив данные как легитимный клиент приложения).
reCaptcha + уникальность IP в 24 часа.
Все верно, тест Тьюринга здесь необходим, но отношения к «хешу» он не имеет. И да, для recaptcha есть уйма сервисов по разгадыванию за символичный бакс на тысячу, а с ip могут возникнуть в дальнейшем и проблемы, связанные с увеличением кол-ва пользователей сети (v4 провайдеры смело выдают 1 на всю подсеть) и переходом(в перспективном будущем) к ipv6 ;)
Так я и пишу, что хэш — не нужен. Максимум, сделать какую-нибудь зависимость от IP адреса клиента, чтобы добавить накрутчику один запрос.
Про рекаптчу в курсе, но когда говорим о средствах защиты мы должны сопоставлять стоимость атаки и профит от неё. В данном случае атакующему проще купить легальный «VIP» статус, который зарезервирует за ним топ в списке серверов.
Про рекаптчу в курсе, но когда говорим о средствах защиты мы должны сопоставлять стоимость атаки и профит от неё. В данном случае атакующему проще купить легальный «VIP» статус, который зарезервирует за ним топ в списке серверов.
Сохранять хэш в сессии, не нужно клиенту передавать данные.
upd: соль не передается клиенту, так что приведенный код ничего не дает.
Нам нужна оригинальная соль, чтобы подписывать свои запросы. Мы не можем открыть страницу с сервером с параметром инъекции, выдаст 404.
Нам нужна оригинальная соль, чтобы подписывать свои запросы. Мы не можем открыть страницу с сервером с параметром инъекции, выдаст 404.
У авторов скрипта непонимание того, зачем нужна mysql_real_escape_string и что делать с параметрами вообще.
Во-первых, если они использовали mysql_real_escape_string — то думали что id таки строка — тогда наличие кавычек в запросе обязательно.
Во-вторых, если же кавычки отсутствуют, то скорее всего подразумевалось что $id всеже число, причем целое. Тогда и mysql_real_escape_string не нужна — достаточно было сделать intval($_POST['id']) приведя тем самым $id к определенному типу (и отрезать большинство инъекций).
Статья — еще один довод тем, кто еще не проверяет входящие параметры и не приводит типы к ожидаемым
Во-первых, если они использовали mysql_real_escape_string — то думали что id таки строка — тогда наличие кавычек в запросе обязательно.
Во-вторых, если же кавычки отсутствуют, то скорее всего подразумевалось что $id всеже число, причем целое. Тогда и mysql_real_escape_string не нужна — достаточно было сделать intval($_POST['id']) приведя тем самым $id к определенному типу (и отрезать большинство инъекций).
Статья — еще один довод тем, кто еще не проверяет входящие параметры и не приводит типы к ожидаемым
Шел XXI век, а ССЗБ всё составляли и составляли строки sql-
запросов вручную…
запросов вручную…
Sign up to leave a comment.
Статья про нетипичную эксплуатацию SQL инъекции и про трюк в sqlmap. А еще — про Counter Strike