ANTICHAT — форум по информационной безопасности, OSINT и технологиям

можно написать плоент

Лучше уже метод золотого сечения. По теории быстрее будет, если память меня не подводит.

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

Метод интересный, но есть одна загвозка, а именно возможное наличие соли.

__________________

огромную базу хешей надо иметь. Первый угаданный символ хеша сокращает перебор в 2^4=16 раз, следующий еще в 16 и т.д., т.е. получается если угаданы N символов хеша, то перебор паролей сокращается в (16)^n раз, что очень неплохо...

Теоретически, это тяжело сделать, я имею ввиду, не каждый хеш таким образом подобрать можно, но еще надо учитывать человеческий фактор, что на практике поможет получить результат

А вобще конечно оригинальный способ, но слишком много условий должно выполняться для этого, незнаю, мож я не обращал внимания на такие вещи, когда просто все знаки фильтруются (ну понятно о чем я), обычно или вобще нет никакой филитрации в order by или значения для sql запроса берутся с помощью конструкции switch...case, при первом варианте обычно есть возможность провести скуль инъекцию, при втором нет, а твой метод для промежуточных вариантов, когда кодеры сами себя обхитрили, непонятно для чего, хотя могу и ошибаться

__________________
Карфаген должен быть разрушен...

Боян, еще старая тема, об этом не где не писалось но логически догадаться не сложно

Так же в моем случаем можно было
- Подбирать названия колонок
- Использывать посимвольный перебор через Benchmark в на 4.1 >
- Узнать AND в Как для различный иньекций...
- Так же можно узнать юзера, если база запушенна под непривелегерованным юзером, если даже отколючен вывод ошибок добавляем /**/from/**/mysql.user/*и далее нам пишет доступ в users такомоту юзера запрещен.

То что привел автор не имеет не какого различия, так как админские пассы редко бывают легкими.

p.s.
Такие баги очень часты, в различных системах статистик, а так же партнерках ведущих подробную статистику.

1. согласен с diehard - нужна большая база хэшей.
2. идею можно приспособить и для group by в инъекциях. когда есть траблы с выводом ошибок.

Хорошие отзывы, я рад . Хотел бы добавить, что методика не отработана, нужно подумать что она еще может дать. Хорошее замечание сделал +toxa+, если есть соль, то все это дело не прокатит.
Вообще суть сводится к тому что в условиях хорошей фильтрации в запросе вида
SELECT ...... FROM users ORDER BY $order мы можем поставить в переменной $order поле пароля. т.е. при условии что на $order стоит фильтр который не дает провести полноценный иньект, мы все равно можем получить нужную инфу.
2 [ cash ] согласен с тем что логически догадаться не сложно, просто я нигде не видел описания....., по поводу админ пассов тоже верно, но эта же проблема не снимается когда мы получили полный хеш при стандартной скуле, и в моем случае не было возможности
или я просто не сумел это дело найти.