CSRF защита

Защита от CSRF атак вполне легко обеспечивается формальным подходом, впрочем как и для SQL injection, в отличие от XSS атак. Для обеспечения защиты от XSS можно лишь наметить для себя приоритетное использование инструкции шаблонизатора {{ }} (вывод переменной с экранированием) и использовать "фильтры входа". Но так как в шаблонах часто бывает нужно выводить переменные и без экранирования, то этот подход, не является достаточно хорошим формальным решением для обеспечения XSS защиты. Не зря XSS стоит на третьем месте ключевых уязвимостей веб-приложений согласно OWASP 2013. Хорошее дело - иметь собственный сканер, работающий аналогично сканерам взломщиков, который первым найдет XSS уязвимости и сообщит разработчику.

Итак для обеспечения CSRF защиты:

1. разработчик четко помнит, что нельзя использовать запросы GET и HEAD для изменений данных на сервере веб-приложения. То есть, в терминах CRUD, GET и HEAD можно использовать только лишь для действий типа `list` и `show` (READ), и нельзя для `create`, `update`, `delete`. Тогда для этих запросов CSRF защита просто не требуется;

2. код coresky всегда проверяет CSRF токен, полученный в запросах POST и сохраненный в сессии для каждого посетителя сайта. При несоответствии скрипт прекращает выполнение, срабатывает Exception. При использовании класса `Form` или CSN-AJAX механизма добавление токенов и их проверка происходит автоматически в ядре coresky кода. Так что коду приложений, чаще всего не требуется совсем заботиться о CSRF защите. Если требуется отключить CSRF проверку для некоторых URL, необходимо переписать хук по умолчанию `WING::h_load()` в файл `main/app/hook.php`, в который поместить проверку этих URL:

001 002 003 004

<?php if (!in_array(PAGE, ['api', 'gate'] && 'POST' == $sky->method) {     # делать CSRF проверку всегда кроме URL 'api' и 'gate' }

Начнем сначала

Вообще-то все современные браузеры, при крос-доменных запросах не посылают куки на сервер, даже если они существуют для домена и время их жизни не истекло, но вместо куки посылают заголовок `Origin`, в котором указан домен с которого выполняется крос-доменный запрос. Так что CSRF защита уже обеспечена этим механизмом: отсутствием куки. Заголовок `Origin` не может быть сфальсифицирован программным путем из javascript, таким образом CSRF защиту можно обеспечить еще и простым кодом:

001 002 003 004

<?php if ('POST' == $sky->method && $sky->origin && $sky->origin != $site_domain) {     throw new Error('Origin not allowed'); }

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

Как указано выше, coresky код прозрачно выполняет CSRF защиту с помощью токенов, но для форм, построенных вручную, без класса `Form`, необходимо добавить, перед закрывающим тегом </form> вызов функции hidden() без параметров. Эта функция возвращает HTML input элемент с токеном:

<input type="hidden" value="{{scrf_token_value}}" name="_csrf" />

В шаблонах Jet, эквивалентно, нужно использовать @csrf().

CSRF токены приватны, нужно стараться, чтобы их значения не стали доступны кому либо, кроме посетителей сайта, для которых они предназначены. Утечка токена, позволит осуществлять CSRF атаку, чтобы этого не произошло, веб-приложения должны иметь защиту от всех (большинства) видов известных атак.