Авторизация пользователей через куки (cookie)
Учебник PHP
Практика
Важное
Регулярки
Работа с htaccess
Файлы, папки
Сессии и куки
Работа с БД
Практика по работе с БД в PHP
Перед чтением см. новые уроки раздела «Важное», которые появились выше.
Практика
Движок PHP
Продвинутые БД
Аутентификация
Практика
ООП и MVC
Абстрактные классы и интерфейсы
Трейты
ООП Магия
Практика
Практика: классы как набор методов
Запоминаем пользователя в cookie
Чтобы пользователю не приходилось каждый день вводить пароль (после того, как закончится сессия), принято запоминать то, что он авторизован, в куках (cookie).
Обычно куки устанавливаются на какой-то определенный срок (например, на месяц) или навсегда. Во втором случае пользователь будет авторизован (то есть сможет входить на сайт без ввода пароля) пока не перейдет по ссылке ‘Выйти’ или не зайдет с другого браузера (в нем-то куку мы не устанавливали!).
Как же это правильно реализовать? Принцип такой: нужно записывать случайную строку в куки пользователя и одновременно в базу данных.
Если не запущена, тогда мы смотрим ему в куки и ищем там пометку об авторизации.
При авторизации по логину и паролю мы должны записать случайную строку ему в куки и в базу данных.
Делать это стоит только в том случае, если пользователь поставил галочку ‘запомнить меня’.
Почему? Потому что пользователь может находится не за своим компьютером и поэтому не хочет, чтобы другой человек после него смог авторизоваться под его логином по кукам (то есть не вводя пароля!).
Реализуем работу с куками
Итак, приступим к реализации. Первым делом добавим в таблицу users новое поле cookie:
| id | login (Логин) | password (Соленый пароль) | salt (Соль) | cookie (Куки) |
|---|---|---|---|---|
| 1 | user | 827ccb0eea8a706c4c34a16891f84e7b | sdfLjgyl | |
| 2 | admin | 01cfcd4f6b8770febfb40cb906715822 | sMtrnwpJ |
Для генерации кук мы будем пользоваться функцией generateSalt, которая уже упоминалась раньше при генерации соли.
Модифицируем форму авторизации так, чтобы пользователю была видна галочка (checkbox) ‘Запомнить меня’.
Код для авторизации по логину и паролю (полный код можете посмотреть в том уроке, где мы солили пароль, здесь только часть, которая подвергнется изменению):
Теперь напишем код для авторизации по кукам.
Этот код должен выполняться при каждом заходе пользователя на сайт.
Тогда украденная кука ничего не будет стоить (хакер сможет ей пользоваться ограниченное время), так как она перезапишется настоящим пользователем при его авторизации по паролю.
Добавьте этот код самостоятельно (он есть в предпоследнем примере).
Куки и безопасность
Так как куки очень легко подделать или украсть, то все критические действия со стороны авторизованного пользователя должны требовать введение пароля.
Это может быть удаление аккаунта, редактирование какой-либо важной информации, изменение пароля и другое.
Логаут
Дадим пользователю возможность нажать на кнопку ‘Выйти’ и перестать быть авторизованным.
Если раньше нам нужно было удалить только сессию, то теперь следует удалить также и куки:
Что вам делать дальше:
Приступайте к решению задач по следующей ссылке: задачи к уроку.
Что такое cookie в браузере и почему на многих сайтах предупреждают об их использовании?
Содержание
Содержание
Многие сайты выдают предупреждение об использовании cookie-файлов и запрашивают согласие пользователя. Что это такое, какую информацию несут такие файлы и безопасно ли передавать куки — расскажем подробнее.
Что такое cookie и как это работает
Происхождение термина связывают с другим понятием — magic cookie. Так называли небольшой объем данных, передаваемых между программой и получателем. Как правило, эти данные не имели ценности для получателя до тех пор, пока он не отправит их обратно той же программе.
Самое простое сравнение — номерок в гардеробе. Сам по себе он не имеет практически никакой ценности, но, предъявив номерок в гардеробе, вы можете получить свое пальто обратно. Таким образом, его ценность проявляется только в момент, когда вы обращаетесь в гардероб: именно номерок помогает гардеробщице «распознать» вас в качестве владельца конкретной вещи. Файлы cookie — это своеобразный номерок, который позволяет идентифицировать каждого отдельного пользователя на сайте.
Принцип работы достаточно простой. Когда вы заходите на сайт, сервер отправляет не только данные о странице, но и файл куки. Он записывается непосредственно на ваш компьютер, как правило, в рабочих файлах самого браузера. По мере того, как вы ходите по сайту, файл дополняется различной информацией. Если вы повторно зайдете на этот сайт, браузер отправит серверу cookie, благодаря чему сайт «узнает» вас.
Обычно файл хранится в пользовательских данных (User Data) в папке браузера. Документ не имеет разрешения.
Если говорить о Firefox, то куки представлены набором файлов. Просмотреть содержимое можно через текстовый редактор, однако информация из-за своего формата будет нечитабельной.
Все cookie можно разделить на несколько основных групп:
Последние файлы считаются запрещенными, многие поисковые системы блокируют сайты, которые пытаются подгрузить зомби-cookie к вам на компьютер.
Какая информация хранится в cookie
Насколько хорошо сайты знают вас по информации из куки? Это зависит от конкретного интернет-ресурса.
Данные сессии. В первую очередь, в файле сохраняются логин и пароль, чтобы после каждого обновления страницы пользователям не приходилось вбивать их повторно. Cookie способны собирать информацию о посещенных страницах и времени, проведенном на сайте, а также фиксировать отдельные действия, например, заполнение различных форм.
Настройки профиля. Cookie сохраняют языковые настройки, вашу корзину (даже если вы еще не зарегистрировались на сайте), валюту покупки, геолокацию и так далее. Самый яркий пример — интернет-магазины, которые автоматически подставляют нужную валюту и город доставки, а также сохраняют товары в корзине.
Идентификационные данные. Под этим подразумевают версию браузера или операционной системы, тип устройства, время посещения и не только. Файл куки создается для каждого конкретного браузера, поэтому сайт посчитает одного и того же человека как разных пользователей, если он зайдет на ресурс через разные браузеры.
В большинстве случаев cookie позволяют получить практически полную карту «путешествий» пользователя по сайту. Если же говорить о куки-файлах для отдельных рекламных баннеров, то они могут собрать информацию о вас, даже если вы посещали разные домены, на которых имелись баннеры от одного разработчика.
Безопасность cookie и правовое регулирование
Некоторые пользователи опасаются файлов cookie, поскольку считают их полноценным софтом, способным украсть личную информацию с компьютера. Это заблуждение, поскольку куки не относятся к исполняемым файлам и не производят никаких действий самостоятельно.
Тем не менее, злоумышленники могут использовать cookie, чтобы зайти в ваш личный аккаунт, поскольку в этих данных передается логин и пароль для авторизации. Применяются несколько методов кражи:
Взлом сессии. Хакеры могут перехватить незашифрованный интернет-трафик и извлечь конфиденциальную информацию. Чтобы это предотвратить, необходимо использовать только зашифрованное соединение HTTPS. Однако и это не гарантирует полной безопасности, поскольку отправка самих куки может идти по HTTP. Файлы cookie защищены только в том случае, если атрибут secure находится в значении true.
Например, для Google Chrome есть расширение CookieEditor, которое позволяет посмотреть и редактировать сохраненные куки, в том числе изучить конкретные атрибуты.
Подмена cookie. Возможны атаки на сервер, когда злоумышленник модифицирует куки-файл и получает с этого какую-либо выгоду, например, меньшую сумму заказа. Для предотвращения таких ситуаций сайты передают в куки только уникальный идентификатор сессии, а другая информация хранится на самом сервере, что делает подобную атаку затруднительной.
Межсайтовые cookie. Эти атаки используют уязвимости браузеров и направлены на захват идентификатора вашей сессии. Именно поэтому рекомендуется регулярно обновлять свой браузер.
Кража cookie. Специализированное вредоносное ПО может украсть ваши куки, после чего злоумышленник сможет через них авторизоваться на сайте даже с протоколом HTTPS.
Проблема избыточного сбора информации об интернет-пользователях начала подниматься еще в начале 2000-х. В мае 2018 года Европейский Союз выпустил Общий регламент защиты персональных данных (GDPR). В документе были определены основы работы с cookie:
GDPR предусматривает штрафы до 20 миллионов евро. Самое громкое дело произошло в 2019 году, когда авиакомпанию Vueling оштрафовали на 30 тысяч евро. На сайте компании пользователь не мог отказаться от использования куки. В России действует закон 152-ФЗ «О персональных данных», который контролирует сбор личной информации.
Чтобы избежать штрафов, каждый сайт при использовании cookie должен выдавать пользователям соответствующее уведомление, которое предполагает ответное действие.
Однако здесь может быть несколько подводных камней, которые намеренно или случайно оставляют разработчики сайтов, например:
Как очистить и отключить cookie
Пользователи могут очистить хранящиеся на компьютере куки или полностью запретить их работу. Сделать это можно с помощью стандартных настроек браузера.
Google Chrome
Чтобы стереть cookie, перейдите через главное меню в раздел «История» (Ctrl+H) и в левой части нажмите «Очистить историю». Далее выставьте галочку только для cookie и сверху выберите «За все время». Остается только подтвердить удаление.
Чтобы настроить удаление куки, необходимо в настройках браузера зайти в раздел «Конфиденциальность и безопасность». Выберите пункт «Файлы cookie».
В новом окне вы сможете выбрать, в каких случаях блокировать куки (только для сторонних сайтов или всегда).
Mozilla Firefox
В меню «Журнал» выберите подпункт «Удаление истории». Укажите, за какое время удалить данные, и поставьте галочку напротив «куки».
В разделе «Приватность и защита» вы также можете удалить куки для каждого отдельного сайта. Чтобы полностью отключить куки, в этом же разделе выберите нужный уровень защиты и выставьте блокировку.
Opera
Через иконку в левой части зайдите в блок «История» и выберите «Очистить историю». По аналогии с Chrome укажите период очистки и оставьте галочку только напротив cookie.
Opera также позволяет отключить отправку куки полностью. В разделе «Дополнительно» войдите в «Файлы cookie и прочие данные». В открывшемся меню можно поставить полную блокировку.
Обратите внимание, что полная блокировка куки может привести к некорректной работе сайта, когда вам придется постоянно вводить данные авторизации вручную.
Как обезопасить себя от кражи cookie
Если вы не хотите полностью отключать куки, но при этом беспокоитесь о своей безопасности, то следуйте нескольким рекомендациям:
Когда сайт не предупреждает об использовании cookie, это не означает, что они отключены. Большинство мелких ресурсов просто не утруждаются оповещением посетителей, поэтому проверять этот факт придется вручную.
В домашних условиях куки на компьютере – вполне безопасное и обыденное дело. Они предлагают массу удобств: сохранение логина и пароля, корзины товаров, геолокации и так далее. Все это экономит время. Но при использовании общедоступных точек Wi-Fi от сохранения куки лучше воздержаться, поскольку общественные сети более уязвимы в плане атаки злоумышленников.
Что такое файлы cookies?
Что такое cookies?
Cookies («куки», в переводе с англ. «печенье») — это небольшие текстовые документы, которые с помощью браузера сохраняет на компьютере пользователя веб-сервер (сайт).
В эти файлы можно записать практически любую информацию о посетителе сайта: во сколько и с какого устройства человек заходил на страницу, какими товарами интересовался и так далее.
Об эксперте: Сергей Филатов, старший аналитик в Estée Lauder, автор курсов «Веб-аналитик с нуля до Junior» и «Аналитик мобильных приложений» в онлайн-университете Skillbox.
Для каждого сайта есть свой набор видимых cookie-файлов. Интернет-ресурсы имеют доступ к cookie только тех людей, кто их посетил. То есть у условного магазина одежды нет доступа к файлам зрителей онлайн-кинотеатра.
В cookie-файлы запрещено записывать персональные данные пользователей. Однако они все равно могут содержать в себе ценную информацию, которую злоумышленники порой перехватывают и впоследствии продают на черном рынке.
При посещении любого сайта можно узнать, собирает ли он информацию о вас. Достаточно открыть раздел настроек вашего браузера «Конфиденциальность».
Почему cookies так называются?
Существует много теорий возникновения термина cookie (от англ. «печенье»).
Какие есть виды cookies?
Выделяют временные и постоянные cookie.
Как долго хранятся файлы cookies?
Временные и постоянные cookie находятся в белой зоне. Ими легко управлять, читать и записывать. Их можно удалять. Но помимо белой существуют также серая и темная зоны.
В серую зону попадают сторонние cookie, которые вам записывает не сам сайт, а другой внешний фрагмент кода, например, рекламный баннер. Посещение вами страниц, содержащих этот баннер, позволяет сформировать ваш круг предпочтений. Эта информация о предпочтениях определенной группы пользователей впоследствии продается рекламодателям.
Также существуют cookie из темной зоны, запись которых блокируется: супер-cookie и evercookie.
Описание процедур по очистке cookie-файлов можно найти на страницах служб поддержки браузеров: Mozilla; Opera; Chrome.
Как cookies используются в маркетинге?
В маркетинге существует три типа данных:
Как законодательство регулирует cookies?
За последние несколько лет в рекламной индустрии было много громких скандалов с утечками пользовательской информации — это повлияло на ужесточение законодательства в отношении cookie-файлов.
Недавно принятые законы GDPR в Европе, российский 152-ФЗ «О персональных данных», бразильский LGPD формулируют более строгие требования к записи и обмену куки. В частности, каждый интернет-ресурс обязан уведомлять своих посетителей о том, что собирает эти файлы.
Также наблюдаются шаги по запрету использования постоянных cookie. В других странах, например, в Китае, такие фрагменты информации собираются государством и используются в целях социального скоринга и присвоения оценок благонадежности (на основе посещенных интернет-страниц). Социальный скоринг может повлиять на решение по выдаче кредита или на стоимость страховки.
Как обезопасить себя от кражи cookies?
Среди самых распространенных последствий сбора cookie-файлов может быть:
В основном кражи cookie-файлов происходят по вине владельцев сайтов или же самих пользователей. Чтобы не допустить этого, важно соблюдать несколько правил:
Кроме того, вы можете установить блокировщик рекламы. С ним удобнее серфить в интернете, и ваша личная информация формально остается защищенной. Но блокировщик рекламы — плагин по своей сути, а значит, он также потенциально может собирать информацию по вашим взаимодействиям.
Куки (cookie) файлы что это такое и что с ними делать
Приветствую вас, уважаемый посетитель блога PenserMen.ru. Любой современный человек немало времени проводит в интернете. И многие не раз уже слышали о таком понятии как куки (cookie) файлы. Так что это такое файлы-cookie?
Да и вообще, зачем они нужны и как к ним относиться рядовому пользователю ПК? Есть ли от них польза или вред, стоит ли удалять и как это делать? Давайте разбираться.
Что из себя представляют куки и как они работают
Прежде всего, необходимо уяснить, что это простые текстовые файлы. А не какие-то зловредные программы или вирусы. Нужны они для помощи и пользователю и посещаемому ресурсу.
Например, чтобы идентифицировать Вас при посещении какого то интернет магазина. В случае, если Вы являетесь его постоянным посетителем, облегчить Вам серфинг по нему и совершение покупок.
Не будь файлов куки, у Вас бы никогда не сохранялись товары в корзине. Или же при каждом новом посещении сайта, где требуется аутентификация, Вам бы приходилось заново вводить логин и пароль.
Существуют различные файлы куки:
Первые хранят информацию о Вас пока вы находитесь на этом сайте. И как только Вы его покинете, удаляют её. Вторые хранят более обширную информацию — когда и под каким именем Вы посещали данный интернет-ресурс и какую активность там вели.
Вся эта информация хранится в Вашем браузере, который вы используете на своём компьютере. Если выражаться точнее на Вашем ПК, на диске С. Называется этот файл просто Cookies и не имеет никакого расширения.
Как используются файлы куки и кем
Вредоносные cookie-файлы
Сами по себе файлы куки ни в коей мере не нарушают Вашу безопасность. Но в настоящее время активизировалось использование вредоносных файлов куки. Которые постоянно собирают информацию о Ваших действиях в интернете и посещаемых сайтах.
Таким образом создаётся профиль Ваших интересов. И впоследствии эта информация может быть продана какой-либо рекламной компании. А она уже будет использовать это на своё усмотрение.
Кстати, иногда случается так, что эта информация может быть использована и мошенниками и вымогателями. Особенно если профиль этих интересов носит пикантный характер и открывает для них возможность шантажа.
Что же делать с файлами куки на компьютере
На самом деле сами по себе файлы куки ничего страшного не представляют. А наоборот помогают пользователю при посещении сайтов в интернете. Делают процесс серфинга более удобным и простым.
Это также, как и номерок от Вашей куртки в гардеробе кафе. Удобнее же сидеть там без верхней одежды. Но вот если этот номерок украдут, будет очень неприятно и для Вас возникнут проблемы.
Конечно, можно полностью отключить куки. Но, поверьте от этого больше будет минусов чем плюсов. А некоторые сайты могут вообще перестать работать. Так что это не будет лучшим выходом.
Есть два пути решения этой задачи:
Первый пункт реализуется установкой пароля на компьютер и антивирусной программой. Хорошее решение KasperskyTotal Security.
Второй — инструментами браузера, которым Вы пользуетесь для выхода в интернет.
Удаление куки-файлов в браузере гугл хром
В открывшемся окне поставить галочку у куки и нажать кнопку «Удалить данные»:
После удаления файлов куки на всех сайтах, где Вы вошли в свою учётную запись, будет совершён принудительный выход. И Вам потребуется при повторном посещении заново вводить логин и пароль.
На этом всё. Вот такие они куки (cookie) файлы вкратце.
«Осторожно, печеньки!»: советы начинающим тестировщикам в сфере безопасности
Привет, меня зовут Вика Бегенчева, я 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 в браузере.
Напутствие
Мы рассмотрели лишь несколько уязвимостей из множества существующих. Но это поможет войти в прекрасный мир тестирования безопасности. Чтобы ничего не забыть, мы с железными тестировщиками подготовили чеклист.
Думай, как хакер! Пытайся получить выгоду или навредить. Но только на своём проекте. Следи за новостями безопасности. Смотри реестр уязвимостей, читай статьи, которые пишут фирмы по обеспечению безопасности и мониторь новости про утечки данных. Обязательно пытайся разобраться в сути. И будь на стороне добра!
