кэш и куки в чем разница
Кэш vs куки
Что такое кэш (cache) и куки (Cookie), а также чем они различаются, должен знать любой тестировщик программного обеспечения. К тому же, этот вопрос нередко задают на собеседованиях, особенно когда речь идет о малоопытных соискателях, претендующих на позицию Junior/Trainee. Об этом — наша статья.
Кэш представляет собой промежуточный буфер памяти и место на жестком диске персонального компьютера, где хранится информация о ранее посещенных веб-страницах, включая изображения и прочие данные.
Представьте, что вы впервые зашли на какой-нибудь сайт. Вы просматриваете разные страницы, при этом вся информация (графическая, текстовая, мультимедийная) загружается на сайт с соответствующего сервера. Когда кэширование подключено, данные с посещенных вами страниц сохраняются на жестком диске в специально отведенной для этого папке. Ниже можно посмотреть, где хранится кэш браузера Google Chrome:
Когда вы посещаете этот сайт второй и последующие разы, ваш веб-браузер проверяет содержимое сайта, а потом выполняет загрузку лишь новой информации. Остальная же информация берется для отображения именно из вашего кэша. Для чего? Во-первых, для повышения скорости загрузки сайта, во-вторых, для снижения нагрузки на интернет-соединение, ведь доступ к данным в кэше осуществляется быстрее.
Надо ли чистить кэш?
Безусловно, да. Делать это следует периодически по следующим причинам: 1. Кэш занимает место на жестком диске, а свободного пространства, как известно, много не бывает. Если долго не чистить кэш, это скажется на скорости работы вашего ПК. 2. Кэш важно чистить в целях безопасности. Недоброжелатели могут попытаться взломать ваш компьютер через кэш. 3. Кэш надо чистить в целях поддержки актуальности данных. Считается, что если кэш не чистить от слова совсем, есть вероятность пропустить обновления на сайтах, которые вы посещаете. 4. Кэш важно чистить для обеспечения корректной работы приложений и онлайн-сервисов. Это важный момент для тестировщика. Когда возникают проблемы на стороне пользователя, не забудьте, прежде всего, почистить кэш браузера.
Куки тоже хранятся на персональном компьютере пользователя и представляют собой данные (как правило, их небольшой фрагмент). Вот, где хранятся куки браузера Хром:
Этот фрагмент отправляется на ваш компьютер веб-сервером при первом посещении веб-сайта. Согласно международным правилам, вы должны дать согласие на прием куки, впрочем, скорее всего, вы делали это неоднократно, вот, как это может выглядеть:
Главное отличие куки от кэша заключается в том, что каждый раз, когда вы повторно заходите на конкретный сайт, с которого вам был когда-то отправлен конкретный куки, веб-клиент (обычно, это ваш веб-браузер) пересылает этот фрагмент данных web-серверу в составе HTTP-запроса.
Как правило, применение куки упрощает следующие процедуры: • аутентификацию пользователя; • хранение персональных настроек и предпочтений; • отслеживание состояния сеанса доступа; • ведение статистики и т. д.
Вот несколько примеров использования куки на практике: 1. Авторизация на сайте. Как известно большинство сайтов имеют авторизацию (ввод пароля, логина, телефона, почты и т. п.). Cookie могут применяться сервером для опознания ранее аутентифицированных пользователей. 2. Корзина в интернет-магазинах. Если не использовать куки, при выборе товара и переходе на новую страницу товар может исчезнуть. 3. Настройки. К примеру, вы выставили нужные настройки региона, языка и т. д. Без куки они могут сброситься и вернуться в статус значений по умолчанию.
Надеемся, теперь вы понимаете разницу между кэшом и куки.
Как почистить кэш и куки?
То есть надо будет выбрать адрес сайта под строкой Cookie, нажать правую кнопку мыши, а потом «Clear».
Теперь кэш. Есть разные способы его очистки, но мы продолжим использовать «Инструменты разработчика». Переходим на интересующий веб-сайт, нажимаем F12, потом опять Application. Далее выбираем Clear storage и скроллим вниз. Смотрим, чтобы стояла галочка напротив Cashe storage и нажимаем кнопку Clear site Data. Обратите внимание, что тут же можно почистить сразу и куки, да и не только их.
Напоследок, дадим еще несколько советов начинающим тестировщикам: — в режиме «Инкогнито» все данные тянутся напрямую с сервера, кэш не используется! — нажав Ctrl+F5 в обычном режиме браузера, вы также «потянете» все данные не из кэша браузера, а напрямую с сервера.
Что такое кеш и cookie, как влияет на браузер?
Для неопытных пользователей термины cash и cookies звучат почти, как эльфийский язык. В статьях по оптимизации работы компьютера советуют периодически делать очистку кеша. Слово “куки” встречается на каждом сайте, где есть формы для заполнения. С 2017 году все ресурсы, использующие эту функцию, обязаны уведомлять пользователей о ее наличии. Мошенники могут получить доступ к данным на компьютере с помощью вирусов, поэтому необходимо своевременно удалять лишнюю информацию.
Что такое КЕШ и cookies
Cash — это место на HDD и SSD, где хранятся временные данные. К ним относятся текст, видео, фото и другие компоненты сайтов. Функция нужна для ускорения серфинга в сети. Компьютеру не приходится скачивать страницу каждый раз заново. Системе достаточно загрузить информацию из созданных ранее резервных копий. Папка с данными, как правило, находится на диске C. Общий вес файлов зависит от активности пользователя. Если на браузере открывается всего пара сайтов в месяц, папка не занимает больше 100 мегабайт. Однако при постоянном серфинге в интернете ее размеры могут увеличиться до нескольких гигабайт.
В cookies попадает вся информация, которую пользователь вписывает в формы отправки на сайтах: логины, email, пароли, ФИО, номера телефонов, адреса, индексы и другие данные, которые могут потребоваться для регистрации. Функция куки экономит время владельцев компьютеров: им не потребуется повторно вводить информацию. Когда в браузере открывается форма с полями, которые были заполнены ранее, система сама предлагает подходящие варианты.
Зачем чистить cash и куки
Первая причина для очистки файлов — защита личной информации от взлома. Когда на компьютер пропадают боты и трояны, они начинают анализ данных, которые сохранены в системе. Папки с кэшем и cookies отправляются владельцу вредоносного софта. Так он за секунду получает доступ ко всем личным данным. Поэтому периодическая очистка временных файлов — лучшая защита от вреда, который могут причинить мошенники.
Вторая причина для систематического сброса данных менее серьезна. Когда сайт обновляет контент, он может неправильно отображаться у пользователей из сохраненных кэшем копий. Чтобы увидеть актуальную страницу, владельцу ПК придется несколько раз ее открыть. Такая же проблема может возникнуть в онлайн играх и приложениях, которые записывают данные для ускорения загрузки.
Временные файлы сохраняют почти все программы. К ним относятся даже Microsoft Word и приложения социальных сетей.
Как удалить временные данные
Есть несколько способов избавиться от кэша и файлов cookies. Чаще используют только 3 метода:
Чтобы выбрать способ, нужно понять, каким должен быть итоговый результат. Если пользователь хочет сохранить данные всех программ, а очистка нужна только для обновления контента на странице в интернете, можно ограничиться очисткой кэша браузеров. Когда на основном диске C заканчивается место, требуется полная оптимизация системы с удалением временных файлов.
Как избавиться от cash в браузере
Порядок действий зависит от используемой программы. Почти во всех инструментах серфинга по интернету удаление кэша осуществляется через настройки. Например, чтобы найти нужный раздел в Google Chrome, необходимо:
Порядок действий работает почти для всех браузеров, однако комбинация кнопок для автоматического запуска функции очистки может отличаться.
Удаление всех временных файлов с ПК
Если необходимо за один раз очистить данные нескольких программ, проще это сделать через параметры Windows. Нужно открыть меню с помощью кнопки “Пуск” и нажать на иконку в виде гайки. В строке поиска открывшегося окна ввести запрос “Хранилище”. Система покажет, сколько информации хранится на каждом разделе жесткого диска. Далее порядок действий зависит от сортировки данных на конкретном компьютере. Если пользователь ничего не менял в настройках, кэш сохраняется на диске C. Нужно выбрать из списка этот раздел, чтобы система начала автоматическое сканирование информации, хранящейся на нем.
В полученных результатах выбрать пункт “Временные файлы“. Для запуска очистики убрать все лишние галочки. Они должны стоять только на разделах: “Временные файлы”, “Временные файлы интернета” и “Кэш построителя текстуры Direct X”. Чтобы запустить очистку, нажать на кнопку “Удалить файлы”.
Сторонние утилиты
Скачав дополнительный софт, пользователь может настроить автоматическую очистку кэша и файлов cookies. Для этих целей подходит программа CCleaner. Она способна оптимизировать систему, оповещать о давно неиспользуемых приложениях, очищать остаточные файлы удаленных программ. В ее функции входит и периодическая очистка кэша и файлов cookies. Изначально это дополнение не активировано, но его можно включить, выбрав соответствующий пункт в настройках.
Сохранение временных данных способно облегчить жизнь пользователям. Однако, когда их скапливается слишком много, они заметно затрудняют работу компьютера. Недостаток встроенной памяти сказывается на скорости обработки процессов и возможности устанавливать новые программы. Чтобы кэш и cookies не доставляли неудобств, достаточно их вовремя удалять. Справиться с этим способен любой пользователь, даже если он только начал осваивать работу с ПК.
Что такое кэш и куки браузера. Назначение файлов кэш (cache) и куки (cookie)
Думаю, каждый пользователь сети Интернет хоть раз в жизни слышал такие таинственные слова, как кэш (cache) и куки (cookie) браузера. А также, что их надо чистить. Но почему, зачем их нужно удалять? Каково вообще их предназначение? Давайте выяснять.
Что такое кэш браузера
Для начала разберемся, что такое кэш браузера и каково его назначение? Путешествуя по просторам всемирной паутины, загружая и просматривая веб-страницы, вы возможно и не подозреваете, что ваш браузер автоматически сохраняет определенные данные на жесткий диск вашего компьютера. В этот список входят элементы дизайна сайтов, изображения и картинки, видеофайлы, которые вы просмотрели в интернете, прослушанная музыка и т.д. Совершается это затем, чтобы при следующем обращении к странице, она загрузилась быстрее, благодаря тому, что часть информации загружается не с сервера, а непосредственно с вашего жесткого диска!
Чем это чревато? Конечно, учитывая все, описанное выше, можно сделать вывод, что кэш значительно облегчает пользователям жизнь, делая серфинг в сети наиболее быстрым и комфортабельным, но с другой стороны…
Полагаю, уже этих причин хватает, чтобы периодически чистить кэш своего браузера, тем более что с этой процедурой справиться любой, даже неопытный пользователь. Однако следует иметь в виду: после удаления файлов кэша, интернет-страницы будут загружаться немного медленнее. Это происходит из-за того, что все эти страницы будут грузиться прямо с веб-сервера, а кэш-файлы будут создаваться заново.
Что такое файлы cookie браузера
Cookie – тоже временные файлы, хранящиеся на жестком диске компьютера пользователя. Куки служат для хранения персональных данных пользователя: данные авторизации (логины и пароли), ваши настройки на определенных сайтах и т.д. В момент захода на страницу, браузер отсылает эти данные на сервер, благодаря чему мы, например, сразу попадаем на личную страничку в социальной сети без необходимости постоянно вводить логин и пароль.
Очищать куки-файлы, как и кэш, следует, когда страницы отображаются некорректно.
Когда чистить кэш и куки
Если страницы отображаются неверно, сначала стоит попробовать воспользоваться режимом «инкогнито» (или приватным), чтобы убедится в том, что очистка временных файлов действительно необходима. В данном режиме cache и cookie не используются. Это поможет вам понять, вызвана ли проблема с отображением именно временными файлами. Если проблема не разрешилась и в приватном режиме, следует сначала очистить кэш (хотя файлы кэша в любом случае лучше чистить время от времени). Если все описанные меры также не принесли положительного результата, то удаляйте куки. Но помните: при удалении файлов cookie удаляются и ваши персональные настройки на сайтах и другие личные сведения, а в некоторых браузерах – все сохраненные комбинации логинов и паролей. Поэтому будьте внимательны! Если в браузере в окне выбора параметров удаления нет отдельной графы про пароли, то ваши данные авторизации тоже будут удалены.
Оцените статью. Вам не сложно, а автору приятно
Кэш, куки и сессия браузера: применение в сфере тестирования ПО
С понятиями кэш, куки и сессия в браузере должен ознакомится каждый QA-инженер, который предоставляет услуги по тестированию веб-продуктов.
Очень часто, при «столкновении» с данными терминами, возникает много вопросов.
Чтобы максимально раскрыть каждое из данных понятий, узнать их области применения и алгоритм использования (исходя из применяемого браузера), рассмотрим каждое более детально.
Сookies (куки) – определенное количество информации, создающееся сервером после того, как пользователь посетил страницу, и которое остается на ПК пользователя как отдельный текстовый документ.
В основном, куки хранят идентификационную информацию, данные о пользователе, о характеристиках и настройках, которые были выбраны в процессе взаимодействия со страницей, а также другие подобные данные, относящиеся к служебным.
Если куки поддерживаются браузером, то при каждом следующем запросе весь объем информации транспортируется от пользователя на сервер. Какая польза для сайта от этих данных?
Как правило, идентификационная информация используется сервером, чтобы:
Если рассматривать куки с технической точки зрения, то это текстовые документы небольших размеров. Максимальный объем куки-файла – 4096 байт.
Что находится в документе куки:
Сессия
Веб-сервера имеют одну важную особенность, которая кроется в том, что они не могут распознавать откуда каждый раз поступают запросы (с одного и того же браузера или с разных).
Это происходит потому, что HTTP протокол «не разрешает» прослеживать ход этих состояний и, соответственно, поддерживать беспрерывную связь с посетителем.
Каждый запрос проходит обработку отдельно, без малейшей связи с прошедшими.
Данную проблему позволяет решить сессия браузера (сеанс) – механизм отслеживания запросов от одного браузера, способный сберечь некоторые переменные в процессе переходов между страницами веб-продукта.
Со стартом сессии, на сервере создается документ, где находятся данные о клиенте, его манипуляциях и событиях, произошедших в пределах одной сессии. Это может быть просматривание сайта, действия с составляющими деталями страниц, произведение транзакций и прочее.
Пока сеанс длится, новый начаться не может.
Предыдущая сессия закончится только в том случае, когда будет реализовано одно из условий (зависит от настроек):
Всем прекрасно известно, что для высокого качества работы в интернете, сайт должен быстро загружаться.
Увеличенное время ожидания отклика страницы может привести к тому, что посетитель просто закроет ее и перейдет на другую, более оптимизированную. Поэтому, в интересах разработчика, не допускать подобного.
Вся сложность ситуации в том, что сервер, при каждом обновлении страницы, транспортирует браузеру достаточно большой объем информации. Естественно, это негативно влияет на скорость работы сайта. Для решения этой проблемы и оптимизации веб-программ, создали кэш.
Например, ваша сеть интернет работает медленнее, нежели компьютер. С помощью кэша, браузер локально сохраняет определенную часть данных на ПК клиента.
Как результат, в повторной загрузке идентичной информации нет необходимости, требуемые данные просто грузятся из памяти ПК без подключения к сети.
Естественно, загрузка страницы, при таком раскладе, происходит значительно быстрее.
Что, в основном, хранится в кэше? Обычно страницы одного сайта имеют однотипный дизайн, в следствие этому, есть элементы сайта, которые дублируются на разных страницах.
Чтобы при каждом переходе не передавать одинаковый снимок, он локально загружается в файлы кэша и при обновлениях уже грузится с жесткого диска пользователя, а не через сервер.
Кроме логотипов, кэшироваться могут текстовые сообщения, видео-файлы, звук.
Кэш браузера ограничен в размере. Его максимальный объем настраивается. Когда хранилище кэша заполнено, то те данные, которые дольше всего не были в использовании, удаляются, тем самым освобождая пространство новым частям.
После того, как мы разграничили термины «сессия», «кэш» и «куки», перейдем к непосредственному процессу их применения.
В целом, обычному пользователю вполне хватить умений включить или выключить, отредактировать или удалить куки, произвести очистку кэша и суметь обнаружить данные документы на своем ПК.
Как выполнить очистку кэша на компьютере?
В первую очередь, нужно учитывать, какой браузер используется для работы.
Важно помнить, что кэш одного и того же веб-продукта, у разных браузеров, находится в различных файлах директории C:\Users\Admin\AppData\Local\.
Если такую папку вы не можете найти на своем ПК, следует просто в параметрах активировать демонстрацию скрытых файлов.
Каждый браузер в этой директории формирует свою файловую папку, где и находится кэш.
Представим наиболее распространенные браузеры:
Обнулить всю информацию из сайта, очистить кэш и куки можно непосредственно в браузере.
Для этого создана специальная функция, активацию которую можно выполнить в настройках.
Алгоритм у каждого из браузеров отличается, поэтому, рассмотрим подробнее процесс очистки кэша в них:
Также, существует еще один способ почистить кэш браузера, не используя его настройки. Это горячие клавиши: Ctrl+Shift+Del – для большого количества браузеров и –⌥(Option)+⌘(Command)+E для Safari на Mac.
Как найти куки на разных браузерах?
К примеру, чтобы обнаружить куки в Chrome, следует выполнить такой алгоритм действий:
Если говорить об Internet Explorer 11, то там путь выполнения немного другой: «Меню браузера» — «Свойства браузера» — «Конфиденциальность» — Сайты/Дополнительно. Здесь возможна работа с файлами куки для выбранных веб-сайтов.
Для просмотра значения сохраненных настроек определенного сайта, необходимо прибегнуть к средствам разработчика (клавиша F12). В пункте «Сеть» поданы списки запросов, а в «Файлы куки» — их данные.
Создание веб-продукта – очень динамичный процесс. Иногда, редактирование сайта осуществляется по несколько раз за день.
Любому тестировщику нельзя забывать о том, что перед выполнением непосредственной проверки продукта необходимо произвести очистку кэша.
Если не выполнить данное условие, большая вероятность того, что страница будет грузится из кэша и внедренных обновлений просто не будет видно.
Процедура сеанса подразумевает собой идентификацию браузера и обработку запросов в течение одного сеанса.
При этом, используются переменные из прошлых запросов. В основном, все данные о сессии находятся на сервере и скрыты от пользователя.
Когда QA-инженер знает сроки окончания сессии и может предвидеть поведение сайта при ее завершении, он легко напишет несколько сценариев для тестирования.
Очень часто, чтобы сайт работал корректно, нужно включить куки. При таком раскладе, проверку работы продукта можно осуществлять двумя способами: с включенными и отключенными куки.
Третий вариант проверки – редактирование куки вручную, с использованием как валидной, так и невалидной информации.
В файлах куки хранятся конфиденциальные данные пользователя для авторизации.
Применив определенный инструментарий для изменения этих данных, тестировщик может узнать, можно ли открыть доступ к аккаунту другого посетителя, отредактировав куки. Такой вид деятельности относят к тестированию безопасности.
При первом знакомстве с кэшем, сессий браузера и куки, все это кажется сложным и запутанным, но изучив терминологию и опробовав полученные знания в практической деятельности, убеждаешься, что здесь нет ничего тяжелого.
«Осторожно, печеньки!»: советы начинающим тестировщикам в сфере безопасности
Привет, меня зовут Вика Бегенчева, я QA-инженер в Redmadrobot. Я расскажу, как злоумышленники крадут наши данные, и что можно сделать, чтобы от этого защититься.
Термин «тестирование безопасности» звучит довольно серьёзно. Многие боятся погружаться в эту тему, думая, что их ждут непроходимые дебри из непонятных слов, сложной литературы и загадочных аббревиатур. Я разберу основы тестирования безопасности и вы убедитесь, что на самом деле это просто и интересно.
Статья написана для начинающих тестировщиков безопасности и тех, кому непонятно, что за «фрукты» эти хакеры и чем они там занимаются. Мы рассмотрим примеры самых частых уязвимостей и постараемся разобраться, как грамотно проверить проект на слабые места и сформировать у себя образ мышления, который в дальнейшем станет вашим верным помощником в тестировании.
Что хранят cookie
Допустим, мы зашли на сайт интернет-магазина ошейников для собак и выбрали французский язык (почему бы и нет). Добавили в корзину пару шлеек и поводок. Что будет, если мы закроем вкладку и зайдём на сайт снова? Всё останется прежним: интерфейс на французском и три товара в корзине. Магия? Нет, cookie.
Cookie — один из инструментов, который формирует так называемый фингерпринт каждого пользователя в сети. Его можно сравнить с «отпечатком пальца», по которому можно узнать, что за человек покупает ошейник для собаки.
На вашем устройстве есть текстовый файл, в котором содержится различная информация о пользователе для каждого сайта — cookie. Она хранится для разных целей, в том числе и для удобства пользования сайтом. Cookie бывают временные (cookie-сессии) и постоянные. Давайте взглянем на них поближе.
Открываем панель разработчика в Chrome и переходим на рандомную статью на «Хабре». Во вкладке Network находим первый запрос, и в хедерах видим как проставляются cookie:
«Хабр» в Chrome
И в респонсе (ответе) видим cookie:
Set-Cookie: fl=ru; expires=Fri, 25-Feb-2022 08:33:31 GMT; Max-Age=31536000; path=/
Тут уже работает логика и Google (если очень нужно): cookie типа fl=ru (параметр, вероятно, отвечающий за язык) или те, которые хранят товары в корзине — постоянные cookie. Они не меняются, если пользователь их не трогает. Нас же интересуют временные или сессионные cookie. Они хранят информацию, которая помогает сайту понять, что это всё тот же пользователь в текущей сессии.
Например, при авторизации на сайте, в файл cookie проставляется условный session_id — уникальный идентификатор сессии на данный момент времени, к которому привязаны текущий браузер и пользователь.
Когда мы совершаем действия, доступные только этому пользователю, мы отправляем в хедер запроса (заголовок запроса, в него передаётся способ общения с сервером) и данные, которые локально сохранили в cookie, чтоб подтвердить, что это мы, а не условный программист из Финляндии. Временные cookie имеют срок годности и стираются в конце сессии, или становятся неактуальными с течением времени.
Как понять, что ваши данные в опасности
Если хакеру удастся угнать cookie пользователя, то он сможет действовать от его лица или же просто получит конфиденциальную информацию юзера. Как узнать, всё ли впорядке?
Во-первых, нужно проверить, не хранятся ли пароли от сайтов в cookie. Удивительно, но в 2021 году до сих пор существуют сайты, которые это делают. Информация о сессиях должна иметь ограничения — быть временной или заменяться с каждой новой сессией.
Во-вторых, нужно проверить, чтобы все конфиденциальные cookie были с флагом httpOnly и secure.
Cookie с флагом “secure” передаются на сервер только по протоколу HTTPS. Как правило, в этом случае есть сертификат SSL или TLS. Cookie с флагом “httpOnly” защищены от манипуляции JavaScript через документ, где хранятся cookie.
Открываем в Chrome «инструменты разработчика» и переходим во вкладку Application.
Проверяем, не хранятся ли пароли в LocalStorage в этом же разделе «инструментов разработчика».
Теперь рассмотрим сценарии кражи пользовательских данных и как от них защититься.
HTTP и HTTPS
Гуляя по сайтам мы до сих пор встречаем предупреждения браузеров о «незащищённом соединении». Иногда строгий браузер вообще не пускает нас на сайт, потому что не хочет нести за него ответственность. А чего он боится?
А боится он протокола HTTP — он древний и небезопасный. Все современные сайты общаются по протоколу HTTPS и вот их браузер любит. Разница между HTTP и HTTPS всего в одной букве, но эта буква означает много — «Secure». Безопасность передачи данных — главный приоритет современных браузеров.
Сайты, которые общаются с сервером по протоколу HTTPS, используют сертификат TLS (его предшественник — SSL). Такой сертификат может защищать как один домен, так и группу поддоменов.
Вернёмся в магазин — мы решили всё-таки купить ошейник своей собаке. Переходим в корзину, вводим данные банковской карты для оплаты, нажимаем на большую кнопку «Оплатить» и наши данные улетают на сервер для обработки запроса. Допустим, злоумышленники решили перехватить данные нашей банковской карты в момент отправки запроса.
Если сайт общается по протоколу HTTPS, то между магазином и сервером построен безопасный «мост». SSL-сертификат позволяет шифровать данные нашей карты и преобразует их в нечитаемый набор символов.
На этом моменте все хакеры мира грустят, потому что они знают, что расшифровать данные может только сервер. На нём есть ключ дешифратор, который поможет понять, какие данные мы ввели на сайте и правильно их обработать.
Чтобы защититься от кражи данных, убедитесь:
Что сайт общается через HTTPS, а не через HTTP.
Есть редирект с http:// на https:// — злоумышленник может разместить ссылку с http://, тогда данные можно будет угнать. Редирект насильно переводит пользователя на https:// ради его же блага. И все счастливы.
Brute force атаки
Допустим, в нашем любимом магазине ошейников для питомцев есть админка. Владелец сайта решил оставить ссылку админки по адресу “https:// […].com/admin”. Злоумышленник переходит по этому адресу и его ждёт страница входа в панель администратора. Допустим, наш хакер вводит логин «admin», а пароль подбирает с помощью скрипта, который сам будет перебирать пароли.
Если логин верный, то узнать пароль дело нескольких часов. Запустил скрипт на ночь, лёг спать, а утром уже есть доступ к панели администратора. Такой перебор и есть brute force атака.
Защититься от взлома можно несколькими способами (про авторизацию/аутентификацию и oauth2 мы поговорим ниже). Но, если речь идёт о brute force атаке, то простейшая защита тут — установка лимита на попытки ввода пароля.
Лимиты устанавливают в зависимости от специфики продукта и решения проектной команды:
ограниченное число попыток в единицу времени;
ограниченное число попыток с последующей блокировкой функционала (например, с восстановлением доступа через почту когда попытки закончились);
установление тайм-аута после n попыток ввода.
Естественно, это не избавит от всех проблем, но сильно усложнит жизнь злоумышленнику.
Токены и сессии
Давайте представим, что мы захотели вступить в тайный клуб любителей настольных игр. Туда просто так не попасть. Сначала нужно доказать, что мы подходим на роль члена клуба — любим настолки.
Итак, в клубе знают наше имя и фамилию, мы доказали, что любим игры, и теперь нам выдадут специальный пропуск, по которому мы сможем проходить в здание закрытого клуба. Теперь не нужно каждый раз доказывать, что мы — это мы. У нас есть волшебный ключ-пропуск, который открывает двери тайного клуба.
А что будет, если наш пропуск-ключ украдут? По нему просто войдут в здание и узнают все секреты закрытого клуба. Токены сессии — это ключи к ресурсам нашего сайта. Когда мы логинимся на сайте, мы отправляем запрос на авторизацию/аутентификацию пользователя. На сервере проверяются его права и генерируется токен.
Access-token определяет права пользователя и доступность ресурсов для него. Выглядит он как длинный набор символов. Можно сказать, что токен — тот самый пропуск, который нам выдали в нашем тайном клубе.
При каждом следующем обращении к ресурсам теперь нам не нужно вводить логин и пароль, чтоб доказать, что мы имеем право на доступ. Просто в каждым запросе на ограниченный ресурс отправляем наш пропуск — access-token.
Хорошей и частой практикой является использование время жизни токена. После логина и формирования access-токена, фиксируется время жизни – дата, до которой токен считается действительным. Это как абонемент на месяц в тайный клуб.
На разных ресурсах, требования ко времени жизни токена разные. На одном сайте токен живёт год, а на другом — всего лишь час. После того как срок действия токена истечёт, система попросит пользователя снова авторизоваться. Чтобы не вводить всё время логин и пароль после истечения access-токена, придумали refresh-токен.
У refresh-токена только одна цель — обновлять access-токен. Это работает так:
отправляем запрос на закрытый ресурс с истекшим аксесс-токеном;
сервер возвращает ошибку о «протухшем» токене;
клиент видит эту ошибку и сразу формирует запрос на обновление аксесс-токена;
в хедеры этого запроса проставляется значение рефреш-токена;
сервер сверяет рефреш-токен с базой данных, формирует новый аксесс-токен и отправляет его обратно на клиент;
клиент автоматически повторяет запрос на закрытый ресурс уже с новым аксесс-токеном.
Готово! А пользователи сайта даже ничего не увидели и не поняли. Как этим пользуются хакеры?
Access- и refresh-токены – это токены сессии. Если злоумышленнику удастся перехватить их, то он докажет, что он — это мы, просто подставив в запрос. Он получит доступ к нашим ресурсам и сможет совершать действия от нашего имени.
Чтобы защититься, нужно:
проверить, что токены сессии не хранятся в файлах Cookie или LocalStorage;
убедиться, что все запросы с токенами передаются по зашифрованному HTTPS;
проверить, что нет доступа к ресурсу без предъявления токена — отправить запрос без токена;
проверить, что нет доступа с чужим токеном, а также проверить запросы с несуществующим токеном;
проверить запросы с истекшим токеном;
поменять в базе данных вручную время жизни токена (продлить/просрочить);
удалить access-token токен из базы данных и отправить запрос.
Авторизация и аутентификация
Чтобы обеспечить безопасность системе и разрешить взаимодействовать с ней разным ролям пользователей (админы, модераторы и т.д.), важно понимать различия между авторизацией и аутентификацией.
Аутентификация — это проверка на соответствие заявленного имени пользователя (паспорта) с идентификатором в системе (Лаврентий Куашников). Авторизация — это предоставление нам прав в соответствии с нашей ролью в системе (отдельная комната для спикера).
Вернёмся к примеру с админкой нашего магазина ошейников. Снова переходим по адресу админки и нас ждёт страница с вводом логина и пароля. Логин — это идентификатор пользователя в системе. Пароль — это доказательство пользователя, что он — это он (ведь только он может знать пароль).
Когда в запросе мы отправляем эти данные, сервер проверяет их на соответствие — это аутентификация. Если аутентификация прошла успешно, то сервер смотрит в базе данных на нашу роль в системе и какие возможности у нас есть — это авторизация.
В разных сервисах авторизация и аутентификация могут проходить как одновременно, так и по отдельности. В первом случае при входе в админку у нас проверяется сразу как пароль, так и разрешение на переход в панель управления сайтом. Во втором случае авторизация проходит тогда, когда уже аутентифицированный пользователь пытается что-то изменить в системе.
А ещё наш сервер умный, и он знает, как реагировать на ошибки авторизации/аутентификации. У него есть два кода ошибок:
401 — если логин/пароль не совпадают или если для доступа к ресурсу нужна аутентификация;
403 — когда сервер понял, что за юзер к нему ломится, но отказывает ему в доступе.
Если хакер доказал, что он — это мы, то система примет его с распростертыми объятиями. Злоумышленник получит доступ к информации и действиям, доступным только нам.
Самый простой способ помочь хакеру пройти авторизацию в системе — передать логин и пароль в запросе в незашифрованном виде. Ну и хранить информацию в cookie, конечно. Но мы не хотим помогать хакерам. Так что делать?
Есть ряд проверок, которые снижают вероятность взлома:
проверьте, что пароли авторизации не хранятся в cookie. Токены – хранятся только в httpOnly куках;
все запросы, где используется авторизация, передаются по зашифрованному соединению https.
Также проверьте пользовательский доступ к ресурсам с кэшем страницы:
Авторизуйтесь в системе.
Откройте ту же страницу в соседней вкладке, при этом пользователь должен быть авторизован.
Разлогиньтесь из второй вкладки.
Вернитесь на первую вкладку (кэш сайта покажет, что вы ещё в системе).
Попробуйте перейти на страницу с ограниченным доступом из первой вкладки, например, в личный кабинет.
Доступ должен быть запрещён. То же самое проделайте при условии, что вы не просто вышли во второй вкладке, а зашли под другой учётной записью.
Проверьте также время жизни токенов в системе. Можно попросить разработчика поменять время жизни на 3 минуты, вместо 7 дней. Также можно попросить поменять время сервера. Но время жизни токена в любом случае должно быть ограничено.
Отправьте запрос без хедеров авторизации.
Отправьте запрос с чужими значениями параметров авторизации.
Проверьте запрос с истекшим токеном или с тем же токеном после логаута (после логаута токен должен стать недействительным).
Проверьте, чтобы логин/пароль не передавались в параметрах запроса. Пример, как не нужно передавать логин/пароль в параметрах http запроса: “http://site.ru/page.php?login=testqa&password=12345678”.
Так же в некоторых системах с повышенными требованиями к безопасности можно применять дополнительные опциональные проверки. Первое, что мы можем сделать, так это можно проверить авторизацию при смене пароля:
Авторизуйтесь в системе в одном браузере.
Авторизуйтесь в системе в другом браузере (или во вкладке «инкогнито»).
Смените пароль в системе через первый браузер.
Проверьте доступ к ресурсам на втором браузере.
Тут мы проверяем, достаточно ли системе только сохранённых данных в cookie. При смене пароля все токены должны быть недействительными.
Второе: можно проверить наличие и работоспособность функции «Выход со всех устройств». При этом запросе мы говорим серверу, что аннулируем все действительные токены, кроме текущего.
Третье: проверьте наличие постоянного тайм-аута сессии (Session-Timeout), они бывают нескольких видов. Наличие постоянного тайм-аута запрещает доступ к ресурсу через n минут после авторизации. Наличие динамического тайм-аута запрещает доступ к ресурсу через n минут после последнего запроса. Другими словами, динамический тай-маут закрывает доступ из-за вашего бездействия в системе.
И напоследок, не забудьте проверить, доступна ли двухфакторная аутентификация на сайте.
Двухфакторная аутентификация
Если в вашей входной двери есть замок только одного типа, то грабителю нужна только одна отмычка (отмычка одного типа). Если же у вас есть ещё и дополнительная защита (цепочка, навесной замок, собака), то грабителю будет сложнее вас ограбить. Скорее всего он передумает.
Так работает и двухфакторная аутентификация. У нас есть основной замок — логин и пароль. И у нас есть второй тип защиты — чаще всего это код, приходящий по SMS, электронной почте или отображаемый в программе двухфакторной аутентификации (например, в Google Authenticator).
Ещё неплохой практикой является использование на сайте протокола oAuth2. Простыми словами, oAuth2 — это когда мы авторизуемся в одном сервисе с помощью другого. Например, когда регистрируемся/логинимся на сайте с помощью Gmail.
Схема примера работы oAuth2
SQL-инъекции кода
Давайте немного углубимся через ещё одну аналогию. Допустим, мы работаем официантом в элитном ресторане. Гости периодически просят изменить состав блюд. Официант отмечает, какие изменения внести в меню.
Недобросовестный официант анализирует и понимает, что на кухне не раздумывая выполняют любой запрос. Поэтому можно внести свои собственные изменения в заказ и повара безоговорочно приготовят блюдо. И он пишет на очередном рецепте:
«ДОБАВИТЬ перец И УБРАТЬ сахар».
Вот и всё. Пранк удался. Но мы на стороне добра, так что вместо того, чтобы заменять заказ, мы проверим, как на кухне умеют фильтровать изменения. Как этим пользуются хакеры? SQL injection — это намеренное внесение в базу данных извне. В нашем примере, кухня — это база данных. SQL-запросы — заказы от официантов.
Схема заражения
Если у базы данных нет фильтрации запросов, то злоумышленник может манипулировать данными: получать данные пользователей (в том числе логин и пароль), размещать файлы, заменять значения. Как же злоумышленник может отправлять такие запросы? Это можно сделать через параметры HTTP, добавив в адресной строке параметры:
“http://some.site.ru/test/index.php?name=1′ UNION SELECT 1,2,3,4,5 —+ &password=1234”
Не углубляясь в то, как мы можем сами попробовать хакнуть свою базу данных, разберёмся в причинах уязвимости и посмотрим, как можно защититься.
Во-первых, в запросе должно быть экранирование спецсимволов — игнорирование исполняемым кодом спецсимволов, которые используются в синтаксисе языка программирования. Если один из спецсимволов пропал, то сервер воспринимает его, как часть команды — уязвимость есть.
Во-вторых, проверяем, чтобы при намерено кривом запросе не выводились ошибки, через которые можно сделать выводы о составе базы данных. Например, ошибка “Unknown column ‘4’ in ‘order clause’” говорит о том, что данные из таблицы выбираются по трём колонкам или меньше.
Сегодня существует множество фреймворков и библиотек, которые предоставляют защиту от SQL-инъекций. Например, библиотека node-mysql для node.js.
XSS расшифровывается как “Cross-Site Scripting”. Эта уязвимость входит в список OWASP TOP-10. Её смысл в том, что злоумышленник принудительно внедряет JavaScript-код через инпут на сайте: в поле ввода «пушит» код, который сохраняется на странице. Впредь он будет исполняться каждый раз при вызове страницы. Это происходит потому, что на сайте отсутствует экранирование спец символов.
У хакера много вариантов воспользоваться этой уязвимостью: от отображения алерта (всплывающего окна) с рекламой до кражи cookie и редиректа на сайт-зеркало.
Не забывайте, что проверять наличие уязвимостей на чужом сайте по законодательству РФ (и многих других стран) запрещено. Это воспринимается, как попытка намеренного причинение вреда сайту. И что тогда делать?
После этого вводим в инпуты строку:
Это универсальная проверка сразу на несколько кейсов. Если часть символов исчезла (например, в поле поиска) или не записалась в БД (если это поле имени пользователя при регистрации, например), то уязвимость есть. Все символы не должны восприниматься, как часть исполняемого поля. Если часть символов исчезла (например, в поле поиска) или не записалась в БД (если это поле имени пользователя при регистрации, например), то уязвимость есть. Все символы не должны восприниматься, как часть исполняемого поля.
В конце вводим скрипт или спецсимволы в окно фронтенда — вставляем прям в код сайта через dev tools в браузере.
Напутствие
Мы рассмотрели лишь несколько уязвимостей из множества существующих. Но это поможет войти в прекрасный мир тестирования безопасности. Чтобы ничего не забыть, мы с железными тестировщиками подготовили чеклист.
Думай, как хакер! Пытайся получить выгоду или навредить. Но только на своём проекте. Следи за новостями безопасности. Смотри реестр уязвимостей, читай статьи, которые пишут фирмы по обеспечению безопасности и мониторь новости про утечки данных. Обязательно пытайся разобраться в сути. И будь на стороне добра!