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

Постараюсь очень лаконично и быстро обрисовать ситуацию с хэшами.

Сразу определю какую задачу применения хешей буду рассматривать — аутентификация пользователей. Не токены восстановления паролей, не аутентификация запросов, не что-то еще. Это также не статья про защиту канала передачи данных, так что комментарии по challenge-response и SSL неуместны!

Хочу поделиться одной особенностью при установке значений COOKIE, которую очень часто забывают веб-разработчики.
В моей практике исследования веб-приложений на уязвимости, за 2009-2011 года, данная ошибка встретилась в 87% веб-приложений, написанных на PHP.
Чтобы как-то уменьшить данный показатель, решил написать этот текст.

Речь пойдет даже не о httpOnly флаге, хотя его использование не менее важно и обязательно к применению.

    Сложность программного обеспечения растет – программы становятся более динамическими, и их поведение возможно оценить только в процессе выполнения. Производить оценку безопасности (поиск уязвимостей, недокументированных возможностей и т.д.) таких приложений значительно сложнее. Использовать только статические подходы анализа становится невозможным, так как из-за динамически генерируемого кода мы даже не можем гарантировать полное покрытие кода при анализе. На помощь приходят динамические методы анализа.

    Есть такая замечательная технология, как динамическая бинарная инструментация (Dynamic Binary Instrumentation, DBI), которая заключается во вставке в бинарный исполняющийся код анализирующих (в общем случае) процедур. Основная прелесть данного подхода заключается в том, что нет необходимости в исходном коде анализируемого приложения – работа происходит непосредственно с бинарным файлом.