Почему codeigniter2 не хранит csrf_hash более безопасным способом, таким как сессия?

Question

Почему сгенерированный токен защиты CSRF не сохраняется и не используется через SESSION, как предложено здесь ? В настоящее время в CI2 механизм защиты CSRF (в классе безопасности) таков:

1. Генерируйте уникальное значение для токена CSRF в функции _csrf_set_hash ():

$this->csrf_hash = md5(uniqid(rand(), TRUE));

2.Введите этот токен в скрытое поле формы (с помощью помощника form_open)

3. Пользователь отправляет форму, а сервер получает токен через POST. CI выполняет проверку токена в функции "_sanitize_globals ()" в классе Input:

$this->security->csrf_verify();

4.Функция "csrf_verify" класса Security, которая только что проверяет, установлена ​​в POST ['token'] и POST ['token'] равна COOKIE ['token'];

public function csrf_verify(){

// If no POST data exists we will set the CSRF cookie
if (count($_POST) == 0)
{
    return $this->csrf_set_cookie();
}

// Do the tokens exist in both the _POST and _COOKIE arrays?
if ( ! isset($_POST[$this->_csrf_token_name]) OR
         ! isset($_COOKIE[$this->_csrf_cookie_name]))
{
    $this->csrf_show_error();
}

// Do the tokens match?

if ($_POST[$this->_csrf_token_name] != $_COOKIE[$this->_csrf_cookie_name])
{
    $this->csrf_show_error();
}

// We kill this since we're done and we don't want to
// polute the _POST array
unset($_POST[$this->_csrf_token_name]);

// Nothing should last forever
unset($_COOKIE[$this->_csrf_cookie_name]);
$this->_csrf_set_hash();
$this->csrf_set_cookie();

log_message('debug', "CSRF token verified ");

return $this;
}

Почему бы не хранить токен в сеансе? ИМХО, просто проверка не является пустой POST ['token'] и равна COOKIE ['token'], потому что оба могут быть отправлены злым сайтом.

Answer 1

Есть несколько причин.

Во-первых, хранение токена в файле cookie небезопасно. Anti-CSRF не предназначен для предотвращения автоматической публикации контента, он предназначен для предотвращения подделки запроса в качестве аутентифицированного пользователя (через iframe или простую ссылку). Пока сам токен не догадается, этого достаточно.

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

Answer 2

Потому что CSRF означает «Подделка межсайтовых запросов».Примером такой атаки может быть, если вы знаете, что кто-то установил WordPress на http://somedomain.com/wordpress.Вы можете заставить их щелкнуть по новой ссылке, которая действительно сделает что-то плохое на их панели управления WordPress.CSRF был разработан, чтобы предотвратить это, проверяя, что выполненное действие было предназначено пользователем, выполняющим действие.

Даже если кто-то знал, как подделать и файл cookie, и поле скрытой формы, чтобы соответствовать, нет никакого способа сделатьэтот межсайтовый, и в любом случае нет подделки, чтобы предотвратить.

Answer 3

В CodeIgniter они нигде не используют нативные сессии PHP в коде.

Приведенный вами пример показан с использованием нативных сессий PHP.

При использовании класса CodeIgniter Session есть возможность либо сохранять данные с помощью файлов cookie, либо сохранять их в базе данных. [ссылка: http://codeigniter.com/user_guide/libraries/sessions.html]

При проверке данных csrf не имеет смысла каждый раз проверять базу данных, было бы правдоподобно сохранять их в файлах cookie.

Я думаю, что в целом это безопасно, но в этом методе есть несколько уязвимых мест. Возможно, шифрование с помощью ключа на стороне сервера может помочь повысить безопасность ...

РЕДАКТИРОВАТЬ:

https://code.djangoproject.com/wiki/CsrfProtection#Sessionindependentnonce

Согласно статье говорится, что CSRF Protection с независимым от сеанса одноразовым номером (используется CodeIgniter) имеет уязвимость для CSRF + MITM Attack ( Man-in-the-Middle ):

Злоумышленник может установить файл cookie CSRF с помощью Set-Cookie, а затем предоставить соответствующий токен в данных формы POST. Так как сайт не завязывается куки-файлы сеанса к куки-файлам CSRF, он не может определить что токен CSRF + cookie являются подлинными (хеширование и т. д. одного из они не будут работать, так как злоумышленник может просто получить действительную пару из сайт и использовать эту пару в атаке).

Практически, функция csrf_verify () только проверяет, является ли cookie и входной POST равно, что оба могут быть созданы с помощью простого JavaScript. Вам следует дважды подумать об этом, если вы серьезно относитесь к безопасности.

Источник: Как работает эта атака «Человек посередине»?