Размещение идентификатора сеанса: скрытое поле формы или HTTPOnly cookie
Каковы преимущества и недостатки размещения идентификатора сеанса в скрытой форме ввода по сравнению с cookie?
Правильно ли помещать CSRF-тег в скрытое поле ввода формы и идентификатор сеанса в файле cookie httpOnly? Что является более безопасным?
2 ответа
Я не думаю, что один по своей природе менее безопасен, чем другой. Безопасность обычно строится слоями. Утверждая, что выбор A может быть более безопасным, чем выбор B, когда оба варианта играют на одной и той же вертикали, вы утверждаете, что безопасность на этом заканчивается. Это абсолютно ложно и необоснованно на практике.
Передавая идентификаторы сессий в основном в форме скрытых входных данных, вы фактически создаете больше проблем, чем решаете сами. Кроме того, я не согласен с утверждением, что это в любом случае делает вас по сути защищенным от CSRF.
Когда вы думаете о том, для какой цели служит сеанс (сохранение состояния между сервером и клиентом по протоколу без сохранения состояния), на самом деле не имеет смысла говорить, что я передам все свои идентификаторы сеанса через скрытые поля ввода. Потому что, например, не каждый запрос к вашему серверу включает использование формы. С другой стороны, состояние теряется в тот момент, когда пользователь обновляет страницу или закрывает свой браузер. Это не прагматично.
Правильно размещать токены CSRF в скрытых входах. Также не неправильно отправлять их клиенту через заголовки HTTP. Маркер CSRF сам по себе недостаточен для предотвращения атаки. Также необходимо, чтобы сервер понимал, как распознать, что этот ток, который предположительно был сгенерирован уникально для этого клиента, не используется повторно и не привязан к другому сеансу тем же пользователем.
Поскольку обычно атака CSRF основана на предпосылке, что вы не можете отличить реального пользователя от злонамеренного подделки, идея состоит в том, чтобы усложнить работу фальсификатора путем регенерации токена для каждого запроса. В сочетании с требованием " использовать только один раз", и на самом деле больше не имеет значения, что сеанс захвачен. Поэтому вам не следует пытаться решить эту проблему на неправильном уровне, предполагая, что вы можете каким-то образом решить обе проблемы, полагаясь на передачу идентификаторов сеансов в скрытых входах и убеждая себя в том, что это более безопасно, чем хранение идентификатора сеанса в печенье. Это не так. Должны быть дополнительные уровни безопасности, чтобы защитить ваши сеансы от перехвата сеансов или атак с фиксацией сеансов, таких как использование файлов cook ie только SSL, HSTS и восстановление идентификаторов сеансов (при удалении старых файлов сеансов) при запросах на повторную аутентификацию. Кроме того, принудительная повторная аутентификация для неидемпотентных действий на уровне пользователя.
Но, пожалуйста, не думайте, что скрытый ввод делает вас более защищенными от CSRF, фиксации сеанса или любой из этих атак. Это не так!
Если вы поместите идентификатор сеанса в скрытое поле формы, это станет намного более безопасным, однако это может затруднить взаимодействие с пользователем.
Причина в том, что это по сути защитит вас от CSRF, потому что любые междоменные запросы, сделанные на ваш сайт, будут означать, что браузер не будет автоматически включать идентификатор сеанса, который делает возможными атаки CSRF. Он также нейтрализует атаки, связанные с фиксацией сеанса, поскольку нет cookie для отравления. Кроме того, любой Логин CSRF также мертв в воде.
Чтобы реализовать это, у вас должно быть любое действие на вашем сайте, включая навигацию, которое будет выполняться методом POST. Метод GET был бы неподходящим, потому что он выставлял бы идентификатор сеанса в истории браузера, в любых журналах прокси или сервера по умолчанию, а также мог быть пропущен через referer заголовок.
Например,
<form method="post" action="/executeAction">
<input type="hidden" name="sessionId" value="12345678901234567890" />
<input type="hidden" name="action" value="navigateToAccountStatus" />
</form>
Обратите внимание, что это предотвратит использование кнопки "Назад" без повторной отправки пользователем формы (что может быть опасно, если действие не было безопасным). Чтобы избежать этого, вы можете обновить идентификатор сеанса после обработки каждого действия.
Другая причина в том, что это защитит ваш сайт от таких атак, как POODLE. Поскольку для "Человека в середине" не существует файлов "cookie", чтобы перебирать один байт за раз, атака POODLE была бы бесплодной.
Обратите внимание, что этот подход сложнее реализовать, и не многие веб-фреймворки поддерживают его по умолчанию.
Правильно ли поместить CSRF-тег в скрытое поле формы и идентификатор сессии в файле cookie httpOnly?
Да, такой подход используется большинством сайтов. Он "достаточно безопасен" для большинства целей - только системы с очень высокой степенью безопасности, такие как онлайн-банкинг, должны принимать формальный подход.