pureacetone 25 апр 2022 в 08:16

Самодостаточная капча без бутстрапа и БД

4 мин

4.8K

Информационная безопасность*Веб-разработка*

Комментарии 15

andreymal 25 апр 2022 в 10:54

проверочный токен заносится в специальный кеш

Это уже не "Zero Storage", можно в том же самом кеше просто хранить ответ на капчу и не выпендриваться (собственно, именно так я на всех своих сайтах и делаю)

pureacetone 25 апр 2022 в 11:41

Можете в деталях описать как вы храните капчи, чтобы разница стала очевидной?

andreymal 25 апр 2022 в 12:03

Ничего особенного, просто кладу в Redis (можно и memcached по вкусу) строку с ответом, ключ — рандомный токен, по таймауту редис автоматически удаляет старые капчи

127.0.0.1:6379> keys *captcha_sol_*
 1) "captcha_sol_ZTcabneMEqKgjCq4"
 2) "captcha_sol_7y6sGkqsg7J5mCb8"
 3) "captcha_sol_w2LUY3wNkWHj3BVj"
127.0.0.1:6379> get captcha_sol_ZTcabneMEqKgjCq4
"YB2PB"

pureacetone 25 апр 2022 в 13:35

Похожая механика, согласен. Остается оправдаться, что в моем случае пару минут хранятся только те токены, на которые пришел корректный ответ. Таким образом запрос тысячи капч не увеличит объем потребляемой памяти ни на йоту под хранение сгенерированной информации. Хранятся только использованные токены, чтобы не счесть их валидными дважды.

andreymal 25 апр 2022 в 13:58

Залил миллион ключей в Redis — он скушал 147 МБ оперативки. Наверное, каждый сам для себя решит, какой вариант лучше (ваш вариант тоже имеет свои плюсы), но я предполагаю, что большинству проектов не понадобится хранить миллион капч одновременно и такое потребление памяти можно считать незначительным

pureacetone 25 апр 2022 в 14:45

Спасибо за дискуссию по сути темы

Revertis 25 апр 2022 в 18:08

большинству проектов не понадобится хранить миллион капч одновременно

Но ведь это потенциальная уязвимость DoS, которую могут даже скрипт-кидди использовать. Просто в цикле, во много потоков, будут запрашивать у вас капчи сутками.

andreymal 25 апр 2022 в 18:34

Во-первых, Капитан Очевидность сообщает, что нужно ставить рейт-лимиты по айпишникам (и это касается вообще любых действий клиентов, не только капчи).

Во-вторых, в такой ситуации сервак помрёт от перегрузки намного раньше, чем от нехватки памяти (и это относится к любым реализациям капчи, да и вообще к реализациям какой угодно CPU-bound задачи).

select26 27 апр 2022 в 09:45

Идея толковая.

Но в моем случае я часто получаю DoS'ы по 1-2MRPM. И в моем случае подход автора топика оправдан - экономия памяти будет очень существенная.

Хотя, при таких объемах можно наступить на CPU limit - вычисления то на каждый ВЫДАННЫЙ токен, не на проверенный.

Буду тестировать.

Спасибо всем за хорошую идею и дискуссию!

mixsture 25 апр 2022 в 15:31

Имхо, стойкость капчи низкая. Волна искажения во всех картинках к статье — константная => исключить ее легко. Эллипс с контрастом динамический, но я на вскидку не вижу больших сложностей в его вычислении, даже если использовать только 1 из его цветов (а основной цвет эллипса всегда противоположен основному преобладающему цвету картинки).
После исключения этих 2 факторов останутся лишь точки и линии, которые очень тонкие и врятли сильно будут мешать OCR. Но даже если и будут, у них сильно маленькая толщина относительно букв, поэтому я бы применил какой-нибудь контурный механизм из openCV, посчитал их площадь и выкинул 1% самых маленьких объектов по площади, заменив их окружающим фоном — точки выкинет. Линии тоже относительно легко линейной регрессией вычислить.
Так что, сугубо имхо, но содержимое этой капчи довольно легко восстанавливается до первоначального текста.

pureacetone 25 апр 2022 в 16:03

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