UPDATE. По результатам обсуждений в систему защиты внесены изменения — откорректировал описание в топике. Особенно большое спасибо benone, Wizard, onthefly за активное обсуждение проблемы.

Раньше в движке для обеспечения защиты от несанкционированных действий использовалась проверка переменной $_SERVER['HTTP_REFERER']. Но иногда это создавало дополнительные проблемы, поэтому было решено ввести новый механизм защиты (готов к использованию начиная с ревизии #551).

Защита данных, полученных через GET-запрос.

Проблема: Некоторые действия выполняются, после перехода пользователя по ссылке, например, удаление топиков. При этом, естественно, проверяется авторизация пользователя. Но, злоумышленник, может подгрузить вам эту страницу на другом сайте в невидимом фрейме и вы удалите топик сами того, не подозревая.

Основная идея решения такова:

1) Завершая свою работу, модуль Security генерирует уникальный 32-х символьный ключ, зависящий от идентификатора сессии (считается, что идентификатор сессии стянуть практически невозможно).
2) В шаблонах, ссылки подобного рода генерируются с добавлением параметра ?security_ls_key=…
3) При переходе по такой «критической» ссылке, Security сравнивает security-key из ссылки с рассчитанным значением для данного идентификатора сессии.

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

Защита данных переданных POST запросом.

При отправке POST-запросов из форм на сервер также отправляется security-key, который валидируется методом, описанным выше.

Все ajax запросы были переведены в режим явной отправки переменных в POST, а в обработчиках соответственно добавлена проверка isPost().

P.S. На всякий случай старый метод ValidateReferal() сохранен, т.е. при желании можно переключиться в старый режим проверки.