Моя реализация в тот момент не требовала никаких JS движков. Мне просто захотелось чтобы это работало из под браузера в виде плагина. Изначально у меня была реализация без браузера, без интрепретаторов JS, на чистом PHP, который разбирал скрипты сам в автоматическом режиме. Давайте не будем с вами спорить на тему что было бы если бы ваш скрипт вдруг изменился бы. Факт автоматического распознавания на тот момент был? Да. Что еще вы пытаетесь мне и остальным доказать?
Что за едкое замечание насчет моей крутизны? Не забывайтесь пожалуйста. Конкретно у меня нет никакой личной неприязни, и, попрошу заметить, это не «желание доказать личную крутизну», а намек на то что ваши слова безосновательны. И да, я видел реализацию с классификацией изображения, и я не верю в «100 миллионов» картинок, так как предложенные мне картинки переодически повторялись (о как?).
И да, я искренне считаю что кроме вас некому ставить минус за то сообщение мне в карму, но я вам заранее прощаю, даже если это не вы, так как зная вас, вам нужно давать как можно меньше поводов для спора.
Я не ошибусь если скажу что вы автор этой капчи, да?
Опять ради той же справедливости прошу заметить, что для распознавания данной капчи мне браузер был абсолютно не нужен. Все распознавание проводилось не в браузере а в отдельном скрипте. Не надо вводить остальных пользователей в заблуждение. Да и разве не Вы не мне в комментариях в моем блоге писали все с точностью наоборот что боты уже стали совсем умными и используют браузеры? Что-то вы, уважаемый, путаетесь в показаниях)
Да и откуда я знаю какие используются у вас там защиты. К чему это вы сказали? Зачем эта реклама тут? Заметьте я не призываю отказываться от вашей капчи, и не говорю что она плоха или хороша. Я лишь рассказываю что она была взломанна, пусть даже не полностью и всего лишь одна из ее реализаций… Но могу с вами поспорить что если мне понадобится я точно также смогу взломать реализацию по классификации изображений.
И еще замечен минус от вас мне в карму… Это я так понимаю личная неприязнь?)
Ну и вы не сочтите за рекламку, но мною уже был продемонстрирован рабочий пример взлома этой капчи с очень высоким процентом распознавания (практически под 90-95%). Пример работал в виде плагина для браузера, который автоматически собирал эту капчу, это очень удобно для пользователей, не отрицаю =)
Справедливости ради, могу сказать, что разработчики буквально через пару дней что то пофиксили, и пример перестал работать. Но сейчас любому спамеру ничего не мешает повторить мой результат.
UPDATE `table` SET `name`=CONCAT('Проект ', @i := @i+1) WHERE `type` = 1 ORDER BY `id`;
А насчет цикла, я где то в интернете натыкался на организацию цикла с помощью Benchmark, правда он не подойдет для запросов типа UPDATE. А то, что вы называете циклом в вашей статье, как то слабо на него похоже, это всего лишь обычный способ использовать переменные.
Идея неплоха, такая капча хорошо отобъет обычных ботов, да и китайцев тоже. Будучи музыкантом, мне было бы намного приятнее разгадывать такую капчу, чем тупо вводить цифры с картинки.
Единственный ее минус, на мой взгляд, — ее очень легко научиться програмно распознавать. Распознавать нотный стан очень легко после того как поймешь принцип его «построения». Я даже когда то хотел написать конвертер своих картинок с нотными листами в формат gtp (кто не знает программа для редактирования гитарных табулатур), но тогда я уперся в отсутствие описания данного формата.
А так — да, профильная капча на сайте выглядит намного приятнее, да и заодно это хороший способ снизить количество «левых» людей.
Во время Великой Отечественной войны, как известно, у нас уделяли значительное внимание организации партизанского движения. Почти каждый отряд в тылу врага имел радиостанцию, а также то или иное сообщение с «большой землёй». Имевшиеся у партизан шифры были крайне нестойкими — немецкие дешифровщики «раскалывали» их достаточно быстро. А это, как известно, выливается в боевые поражения и потери.
Партизаны оказались хитры и изобретательны и в этой области тоже. Приём был предельно прост. В исходном тексте сообщения делалось большое количество грамматических ошибок, например, писали: «прошсли тры эшшелона з тнками». При верной расшифровке для русского человека всё было понятно. Но криптоаналитики противника перед подобным приёмом оказались бессильны: перебирая возможные варианты, они встречали невозможное для русского языка сочетание «тнк» и отбрасывали данный вариант как заведомо неверный.
Этот, казалось бы, доморощенный приём, на самом деле, очень эффективен и часто применяется даже сейчас. В исходный текст сообщения подставляются случайные последовательности символов, чтобы сбить с толку криптоаналитические программы, работающие методом перебора или изменить статистические закономерности шифрограммы, которые также могут дать полезную информацию противнику.
Ну конечно, уже что-то доказывать смысла нет. Странный вы человек. Возьмите, да добавьте в статью ссылки на используемые материалы. Не стройте из себя гения который сам всему научился и все знает, вот и вся проблема.
Так как мы не можем повлиять на их количество в первом запросе, то нам нужно подобрать их количество во втором к первому.
Ваша:
Т.к. мы не можем повлиять на их количество в первом запросе, то нам нужно подобрать их количество во втором, чтобы оно было равно первому.
Пример со сто рублями передран и немного переделан. Используется таже таблица news… Продолжать?
Откровенно говоря, оригинал данной статьи я когда то очень долго держал у себя как личную «библию», и очень часто обращался к ней за помощью, именно по ней я научился некоторым фишкам. И тут приходите вы, и пытаетесь выдать чужое за свое…
Мне одному кажется что это сжатый и немного измененый пересказ уже существующей статьи датированной 2010 годом? Причем очень много чего в этих статьях схожего. rdot.org/forum/showthread.php?t=124
Да и по теме. Ни Ваша статья, ни приведенная статья по ссылке не научит правильно обнаруживать и раскручивать SQL иньекции. Хотя, признаюсь, много чего почерпнул когда то из последней статьи.
К примеру пытаться обнаруживать иньекции только по наличию ошибок — бред. В ~80% случаях вывод ошибок отключен, и приходится ориентироваться на поведение самого приложения.
С вами сложно спорить. Я вам об одном, вы мне о другом.
Я, повторюсь, использовать соль в алгоритме — это тоже своего рода сокрытие алгоритма генерации конечного хеша. Вы также считаете это security through obscurity?
Заметьте, никто не задается целью сделать невозможным брут хеша. С помощью соли и неизвестного алгоритма, разработчики пытаются максимально усложнить этот процесс. И при этом, пока и то и другое остается тайной для злоумышленника — этот процесс в конечном счете является бессмысленным.
Вы путаете понятия, security through obscurity — это нечто другое.
Я бы не стал утверждать так категорично что второй вариант плох. В данном случае неизвестный алгоритм это такая же соль для злоумышленника только немного в другом виде. Или наличие соли вы тоже считаете security through obscurity?
Я думаю человек выше имел ввиду, что существует вероятность того, что для каждого пароля существуют коллизии.
И, к сожалению, есть вероятность того, что для вашего супер длинного пароля в минимум 30 символов найдется коллизия, которая будет намного короче (например в 1 байт), и будет случайно найденна при брутофорсе.
А насчет длинны, то все банальнее. Чем длиннее хеш — тем меньше вероятность того, что такая коллизия существует или будет случайно найденна при брутофорсе.
Попрошу заметить, при неправильном подходе добавление соли — не панацея. У злоумышленника всего лишь отпадет возможность атаки по словарю и радужным таблицам (и то не всегда, есть онлайн сервисы которые справляются даже с хешами с короткой солью).
Добавление соли к паролю при генерировании хеша призванно увеличить длинну пароля прозрачно для конечного пользователя. Скажем у пользователя пароль в 6 символов (хеш от него легко сбрутить), добавляем соль длиной еще, к примеру, в 10 символов, и получаем общий 16-и символьный пароль, который на данный момент сбрутить в разумные сроки практически невозможно.
Но неправильный подход к реализации губит эту идею на корню. В большинстве (по-крайней мере в 90% изученных мною) веб-приложений хеш и соль хранятся в БД. И если злоумышленнику удалось получить каким-то образом хеши, то ему не составит труда получить оттуда и соль. А далее атака сводится к обычному брутофорсу недостающих симолов, т.е. исходного пароля пользователя.
Правильный подход к использованию соли заключается в следующем. Вы должны не допустить того чтобы злоумышленник смог получить и соль и хеш одновременно. Один из вариантов практической реализации — в БД хранится хеш, в конфиге приложения общая соль для всех хешей. Еще вариант — соль для каждого хеша генерируется от некоторых данных пользователя (например по логину), так чтобы алгоритм генерации остался для злоумышленника неизвестен.
О! Я теперь знаю что делать если вдруг мою систему заразит «Яндекс.Бар»)
Моя реализация в тот момент не требовала никаких JS движков. Мне просто захотелось чтобы это работало из под браузера в виде плагина. Изначально у меня была реализация без браузера, без интрепретаторов JS, на чистом PHP, который разбирал скрипты сам в автоматическом режиме. Давайте не будем с вами спорить на тему что было бы если бы ваш скрипт вдруг изменился бы. Факт автоматического распознавания на тот момент был? Да. Что еще вы пытаетесь мне и остальным доказать?
Что за едкое замечание насчет моей крутизны? Не забывайтесь пожалуйста. Конкретно у меня нет никакой личной неприязни, и, попрошу заметить, это не «желание доказать личную крутизну», а намек на то что ваши слова безосновательны. И да, я видел реализацию с классификацией изображения, и я не верю в «100 миллионов» картинок, так как предложенные мне картинки переодически повторялись (о как?).
И да, я искренне считаю что кроме вас некому ставить минус за то сообщение мне в карму, но я вам заранее прощаю, даже если это не вы, так как зная вас, вам нужно давать как можно меньше поводов для спора.
Опять ради той же справедливости прошу заметить, что для распознавания данной капчи мне браузер был абсолютно не нужен. Все распознавание проводилось не в браузере а в отдельном скрипте. Не надо вводить остальных пользователей в заблуждение. Да и разве не Вы не мне в комментариях в моем блоге писали все с точностью наоборот что боты уже стали совсем умными и используют браузеры? Что-то вы, уважаемый, путаетесь в показаниях)
Да и откуда я знаю какие используются у вас там защиты. К чему это вы сказали? Зачем эта реклама тут? Заметьте я не призываю отказываться от вашей капчи, и не говорю что она плоха или хороша. Я лишь рассказываю что она была взломанна, пусть даже не полностью и всего лишь одна из ее реализаций… Но могу с вами поспорить что если мне понадобится я точно также смогу взломать реализацию по классификации изображений.
И еще замечен минус от вас мне в карму… Это я так понимаю личная неприязнь?)
Справедливости ради, могу сказать, что разработчики буквально через пару дней что то пофиксили, и пример перестал работать. Но сейчас любому спамеру ничего не мешает повторить мой результат.
А насчет цикла, я где то в интернете натыкался на организацию цикла с помощью Benchmark, правда он не подойдет для запросов типа UPDATE. А то, что вы называете циклом в вашей статье, как то слабо на него похоже, это всего лишь обычный способ использовать переменные.
Единственный ее минус, на мой взгляд, — ее очень легко научиться програмно распознавать. Распознавать нотный стан очень легко после того как поймешь принцип его «построения». Я даже когда то хотел написать конвертер своих картинок с нотными листами в формат gtp (кто не знает программа для редактирования гитарных табулатур), но тогда я уперся в отсутствие описания данного формата.
А так — да, профильная капча на сайте выглядит намного приятнее, да и заодно это хороший способ снизить количество «левых» людей.
Очень малая толика файлов, на мой взгляд, содержит описание.
Грамотно и емко сказанно. Отчаянно плюсую!
Ну конечно, уже что-то доказывать смысла нет.Странный вы человек. Возьмите, да добавьте в статью ссылки на используемые материалы. Не стройте из себя гения который сам всему научился и все знает, вот и вся проблема.Ваша:
Пример со сто рублями передран и немного переделан. Используется таже таблица news… Продолжать?
Откровенно говоря, оригинал данной статьи я когда то очень долго держал у себя как личную «библию», и очень часто обращался к ней за помощью, именно по ней я научился некоторым фишкам. И тут приходите вы, и пытаетесь выдать чужое за свое…
Не верю
(с) Станиславский.
Мне одному кажется что это сжатый и немного измененый пересказ уже существующей статьи датированной 2010 годом? Причем очень много чего в этих статьях схожего.
rdot.org/forum/showthread.php?t=124
Да и по теме. Ни Ваша статья, ни приведенная статья по ссылке не научит правильно обнаруживать и раскручивать SQL иньекции. Хотя, признаюсь, много чего почерпнул когда то из последней статьи.
К примеру пытаться обнаруживать иньекции только по наличию ошибок — бред. В ~80% случаях вывод ошибок отключен, и приходится ориентироваться на поведение самого приложения.
Я, повторюсь, использовать соль в алгоритме — это тоже своего рода сокрытие алгоритма генерации конечного хеша. Вы также считаете это security through obscurity?
Заметьте, никто не задается целью сделать невозможным брут хеша. С помощью соли и неизвестного алгоритма, разработчики пытаются максимально усложнить этот процесс. И при этом, пока и то и другое остается тайной для злоумышленника — этот процесс в конечном счете является бессмысленным.
Я бы не стал утверждать так категорично что второй вариант плох. В данном случае неизвестный алгоритм это такая же соль для злоумышленника только немного в другом виде. Или наличие соли вы тоже считаете security through obscurity?
И, к сожалению, есть вероятность того, что для вашего супер длинного пароля в минимум 30 символов найдется коллизия, которая будет намного короче (например в 1 байт), и будет случайно найденна при брутофорсе.
А насчет длинны, то все банальнее. Чем длиннее хеш — тем меньше вероятность того, что такая коллизия существует или будет случайно найденна при брутофорсе.
Добавление соли к паролю при генерировании хеша призванно увеличить длинну пароля прозрачно для конечного пользователя. Скажем у пользователя пароль в 6 символов (хеш от него легко сбрутить), добавляем соль длиной еще, к примеру, в 10 символов, и получаем общий 16-и символьный пароль, который на данный момент сбрутить в разумные сроки практически невозможно.
Но неправильный подход к реализации губит эту идею на корню. В большинстве (по-крайней мере в 90% изученных мною) веб-приложений хеш и соль хранятся в БД. И если злоумышленнику удалось получить каким-то образом хеши, то ему не составит труда получить оттуда и соль. А далее атака сводится к обычному брутофорсу недостающих симолов, т.е. исходного пароля пользователя.
Правильный подход к использованию соли заключается в следующем. Вы должны не допустить того чтобы злоумышленник смог получить и соль и хеш одновременно. Один из вариантов практической реализации — в БД хранится хеш, в конфиге приложения общая соль для всех хешей. Еще вариант — соль для каждого хеша генерируется от некоторых данных пользователя (например по логину), так чтобы алгоритм генерации остался для злоумышленника неизвестен.