Как защититься от подобного рода атак.

DeepVarvar
А-а теперь идею уловил, спасибо... но не думаю что это так страшно.. я например готовые решения как минимум из за этого не использую. Проще написать с нуля свой магазин например один раз, потом уже по мере необходимости его видоизменять и все будут спать спокойно + ничего лишнего и всегда знаешь что где лежит

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

(Отредактировано автором: 25 Августа, 2013 - 02:11:46)

DeepVarvar, ну да, в принципе то, что предложил я с токенами - сложнее проверки реферера, но тогда еще одно предложение - капча, точнее рандомное логическое выражение, например: 3+5= input value

При нажатие "ДА", опять произойдет переадресация на некую страницу, ссылку на которую может прислать злоумышленик, то есть получаем первоначальный вопрос.

Часто бывает необходимость написать например некий портал, где будет много админов, и представь вдруг что ты уволишь кого-то. Так что просто надеяться на то, что кто-то не знает на какую ссылку отправлять какие данные- как минимум глупо.
А если это не админская часть, а сайт - гостевая книга? Там все видно, на какую ссылку какие данные нужно отправлять.
После нажатию на ту же кнопку "Да, я подтверждаю" - происходит та же посылка POST запроса на ссылку.
Т.е. ты, или любой другой человек, может заставить любого пользователя (посетившего твой сайт) послать необходимые POST данные на эту ссылку. Т.е. кто-то зашел на твой сайт, а там скрытая форма, которая отправляет данные на чью-то гостевую книгу.
Так что проверка на стороне сервера необходима в любом случае. Самый простой вариант - это конечно же проверять откуда реффер, но не самый надежный. Второй вариант, это сначала нечто оригинальное сгенерировать - а потом проверять на наличие этого в присылаемых данных. Он сложный и геморный. Третий вариант (тот что я придумал) - проще в реализации, но подходит только для зарегистрированных пользователей. Т.е. при регистрации ты генерируешь рандомный ключ - а потом его проверяешь (присланный ключ должен соответствовать индивидуальному ключу авторизированного пользователя).
(Добавление)
DeepVarvar, все же вернитесь в тему пожалуйста)
Есть вопрос: допустим зашел гость, я для него сгенерировал ключ, записал в БД. Потом мне приходит этот ключ, я его ищу - если нашел, значит все ок.
Также допустим создал кронтаб задачу, которая раз в сутки удаляет из базы все токены, в которых время создания больше чем сутку назад.
Но тут появляется такая проблема: допустим сайт популярный. Злоумышленник может раз в сутки обновлять этот ключ с твоего сайта (просто открыв какую-нить форму отправки), и дальше успешно слать сообщения.
То что, надо еще ключ к IP привязывать?

Чем он не надежен?

-----
Шта? Репозиторий?

Подобные утверждения от незнания.
На самом деле в данном случае этого должно хватить.

Ну можно ещё при каждой попытке модификации чего либо запрашивать пароль ))
Так сказать - параноидальная защита )

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

(Отредактировано автором: 25 Августа, 2013 - 17:57:00)

HTTP_REFFERER самая примитивная защита. Если вы делаете небольшой сайт для себя, то вам этого может и хватит. Учтите, что у некоторых пользователей HTTP_REFFERER может быть октлючен (в частности у тех, кто пользуются всякими анонимайзерами и проксисерверами). И если пользователи имеют возможность размещать контент на вашем сайте (например, на форуме), то вам следует проверять полный адрес, а не только домен.
Использование токенов в ссылках очень распостранённая защита. Во многих фреймворках и CMS это реализовано на уровне ядра. Другой вариант подтверждать все важные действия дополнительной формой, с предупреждением и двумя кнопками (Да/Нет). Это спасет не только от CSRF, но и от невнимательности пользователя. Разумеется формы тоже следует защищать токенами.

Значит ему покажет шиш, а значит эта "примитивная" защита сработает как надо, ибо шел бы лесом тот дядя, который не следует стандартам.
Ну, у меня именно полный адрес предыдущей страницы.
Например при удалении пользака реферер ожидается обязательно вида:

http://domain.tld/admin/users

т.е. предыдущей страницей должен быть список пользаков.

Кто еще хочет сказать о токенах?

-----
Шта? Репозиторий?

Дык, защита должна защищать от хакеров, а не от обычных пользователей.

Если кто-то отключил в браузере реферер - это его собственное действие и он знает об этом.

Никто никогда не думает что каждый анонимайзер/прокся могут перехватывать ваши пароли в пакетах?
Я никогда не пользуюсь такими "сервисами" при посещении важных для меня аккаунтов и админок.

Пусть продолжают пополнять армию зомби, а я при отсутствии валидного реферера в админку не пущу

-----
Шта? Репозиторий?

Хардкод ведь. А если я захочу написать плагин для твоей CMS? Например, дополнительный интерфейс для управления пользователями. Или захочу добавитть для админа контекстную ссылку на удаление в профиль пользователя. Или просто консольный скрипт для пакетного удаления спамеров.

В модульных CMS и фреймворках не используют HTTP_REFFERER. Не возможно учесть все страницы, на которых могут присутствовать административные ссылки. Особенно если эти страницы добавляются модулями и плагинами сторонних разработчиков.

Нет.
Не вижу проблем, пиши свой контроллер и проверяй реферер в нем, или не проверяй, если понадобится.
То же самое.
Снова то же самое. Только CLI точка входа имеет "рутовые" права внутри приложения и поэтому там чутка иначе. Т.е. не надо wget'ом ходить на сайт по крону, а напрямую из php:

-----
Шта? Репозиторий?

Вот в этом и хардкод. Твой контроллер не может быть повторно использован.

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

-----
Шта? Репозиторий?

DeepVarvar, без обид )), но мне кажется что Ch_chov прав.
Например лично знаю людей, которые пользуются vpn-ами аля таких, к примеру даже для того, чтобы как минимум обезопасить себя от такого беспредела (всего лишь пример и просьба на сам контент новости сильно внимания не обращать)
Так что если на большом портале или форуме, при отправке любого сообщения делать проверку на HTTP_REFFERER, то 5% сообщений точно не дойдут.
Дайте ответ пожалуйста на мой вопрос с токенами. Например я в каждую форму генерирую токен который записал в бд. Опять таки если это популярный портал/форум, то злоумышленник сможет без особых проблем обновлять себе эти токены (раз в сутку к примеру), вставлять их в скрытую форму и дальше успешно делать то что делал раньше (только уже с токенами).
И что с этим делать, использовать сессии (что делать не хочется), токен связывать с IP, или давать токену крайне малое время жизни?

(Отредактировано автором: 26 Августа, 2013 - 04:56:30)