Что такое куки логгер
Каждому сайту доступны cookie-файлы, и хакеры ими пользуются. Новый способ взлома аккаунтов
В 2020 году киберпреступники научились взламывать аккаунты жертв по-новому — с помощью cookie-файлов — либо точечно подбирают жертву, либо используют эти данные для самого взлома. Проблема в том, что доступ к ним имеет почти каждый веб-сайт. Как управлять cookie-файлами и обезопасить себя от взлома — в материале Лайфа.
Что такое cookie? Благодаря им сайты знают о нас всё
Cookie — это небольшие текстовые документы, хранящиеся на компьютере пользователя. В них записывается практически любая информация о посетителе сайта: во сколько и с какого устройства он зашёл на страницу, какими товарами интересовался, какие поисковые запросы он вбивал, и так далее.
Почти каждый сайт запрашивает разрешение на их использование при первом посещении. Основное их назначение — экономия времени и для пользователя, и для ресурса. Юзер может один раз ввести логин и пароль, в следующие разы они будут добавлены автоматически, достаточно будет лишь кликнуть на «Войти». Условному интернет-магазину это позволяет предлагать товары более точно. Если последние просмотренные посетителем товары — обогреватели Xiaomi, то на главной странице появятся преимущественно эти приборы от конкретного бренда.
Причём cookie-файлы хранятся надёжно. Пароли зашифрованы, и в случае взлома сайта хакеры не получат данные пользователей в открытом виде. «Куки» напрямую не отображают пароли, а вместо этого они содержат хеш, который хранит ваш пароль. Когда пароль был хеширован, он был зашифрован таким образом, чтобы прочитать его мог только тот веб-сайт, с которого он был записан в «куки». Каждый сайт использует уникальный алгоритм шифрования для кодирования хеша и его раскодирования, — говорит руководитель департамента системных решений Group-IB Станислав Фесенко.
Также на основе cookie настраиваются показы рекламы в Интернете. Таргетированные баннеры работают на основе истории браузера, это тоже файлы cookie.
Какими бывают cookie?
Технологии. Главное по теме
Пользователям iPhone рассказали, как избавиться от рутинных операций с гаджетом
Самолётик символизирует свободу. Дуров рассказал о новом методе побега из WhatsApp в Telegram
Россияне стали массово интересоваться 3D-печатью. Не пугает даже высокая стоимость принтеров
Они делятся на два типа:
1. Временные. Это данные о просмотренных страницах, записи форм заказов и другая информация, позволяющая клиентам упростить пользование сайтом. Удаляются после ухода посетителя с ресурса.
2. Постоянные. Не удаляются после окончания взаимодействия с сайтом. Отображают историю посещений сайта. Это логин и пароль, если пользователь их кеширует после регистрации. История браузера и просмотренных страниц на сайте.
Их время хранения зависит от того, в какой зоне находятся эти файлы. Их три: белая, серая и тёмная.
Как используют cookie мошенники?
Прежде всего они помогают точнее выбрать жертву. Главным трендом развития мошенничества в Интернете аналитики Group-IB считают персонализацию и таргетирование атак. Жертва выбирается на основе анализа файлов cookie.
В России возросли случаи кибератак. Названы 3 самые популярные площадки, где водятся хакеры
Впрочем, для взлома могут использоваться и они непосредственно. В cookie-файлы запрещено записывать персональные данные пользователей. То есть идентифицировать жертву напрямую с их помощью нельзя. Пароли здесь также не получить. При этом они упрощают процесс взлома, так как хранят данные для входа в аккаунт.
— Установив файлы cookie с хешированными паролями в свой веб-браузер, киберпреступник может немедленно получить доступ к аккаунту на этом сайте, при этом ему не понадобится вводить регистрационные данные жертвы. Если злоумышленник сможет получить доступ к вашему компьютеру или вашей сети, то с большой долей вероятности он завладеет и «куки». Например, с помощью расширения для браузера Firefox под названием Firesheep, — рассказал руководитель департамента системных решений Group-IB Станислав Фесенко.
Когда веб-сайты «запоминают» пользователя, они сохраняют в файлах cookie уникальный ID сеанса, который позволяет идентифицировать человека. Злоумышленники могут обмануть веб-сайты, получив такой ID: «представиться» жертвой и взять под контроль её аккаунт. Один из вероятных сценариев, как злоумышленники могут реализовать такую схему, — заражение устройства вирусом.
В прошлом году Лаборатория Касперского обнаружила два вируса для Android, которые как раз сохраняли файлы cookie, записанные браузерами для смартфонов и приложениями популярных социальных сетей, в частности Facebook. Они позволяют злоумышленникам незаметно получать контроль над аккаунтом жертвы в социальной сети и распространять контент от её имени. Например, запускать масштабные спам- и фишинговые рассылки и атаки. Попав на устройство, троян получал root-права и передавал cookie-файлы браузера и установленного приложения соцсети на сервер злоумышленников.
Есть и более совершенные вирусы. Зачастую иметь только ID сессии недостаточно для того, чтобы взять под контроль чужой аккаунт. У ряда веб-сайтов есть меры безопасности, позволяющие предотвратить подозрительные попытки входа. Именно для таких случаев был предназначен второй троян. Он мог запустить прокси-сервер на телефоне и предоставить злоумышленникам доступ в Интернет с устройства жертвы, чтобы обойти меры безопасности и таким образом войти в аккаунт.
Как законодательство регулирует cookie?
За последние несколько лет в индустрии технологий было множество громких скандалов с утечками пользовательской информации. Это повлияло на ужесточение законодательства в отношении cookie-файлов.
В Европе недавно приняли закон GDPR, а в России 152-ФЗ «О персональных данных». По ним каждый интернет-ресурс обязан уведомлять своих посетителей о том, что собирает эти файлы. Как правило, в баннере сообщается лишь о факте использования некоторых cookie-файлов, подробнее взаимодействие с ними описывается в разделе «Пользовательское соглашение».
Чем опасны отслеживающие cookies если вам и вправду нечего скрывать
В последнем подкасте Habr Weekly #21 обсуждалась тема отслеживающих cookies и вопрос их нежелательности. Бытуют мнения о сомнительности вреда таких куков если скрывать и вправду нечего. Такая позиция определенно не выдерживает критики.
На наш взгляд главный риск таких отслеживающих cookies для пользователей, кому и вправду нечего скрывать, кроется в возможности индивидуальной манипуляции их сознанием.
Это может быть выгодно как целым государствам, так и отдельным хозяйствующим субъектам.
Демократия и государственность
Самые серьезные риски, считаю, может нести прямое или косвенное воздействие на политические взгляды в обществе и, как следствие, влияние на демократические процессы в государстве. Об этом свидетельствуют регулярные сообщения, связанные с возможными вмешательствами государств в избирательный процесс других стран путем размещения политической рекламы в Интернете.
К тому же, подмешивая «правильную» (грамотно таргетированную по интересам) рекламу о событиях в мире, государстве и обществе можно планомерно доводить человека до нужного состояния. Искали сегодня билет на концерт любимой группы, — завтра можете увидеть рекламу о поддержке группой той или иной политсилы.
Купи Слона!
Ровно как и в политической рекламе, ваше сознание и восприятие вещей могут изменяться в пользу любых коммерческих продуктов.
Таргетированная реклама по интересам может быть не всегда добросовестной, или отражающей реальную действительность. Поискали как-то информацию о соблюдении GDPR для своего бизнеса — получите рекламу услуг и продуктов с шокирующей информацией о гигантских штрафах. И никто не будет говорить о реальной, не столь устрашающей, статистике таких санкций. Ничего личного, просто коммерция.
Дорогая, я могу все объяснить
А это пример из личного опыта, после которого взял за привычку использовать браузер в режиме инкогнито. Типичный случай человека, которому нечего, как казалось, скрывать перед женой.
Как вы наверняка догадались, речь о… подарке для любимой. Будьте предельно осторожны при поиске сюрпризов для своей второй половинки, если пользуетесь с ней общим девайсом. Ситуация, что в рекламе она увидит результаты ваших предыдущих поисков очевидна. Cюрпризу тут не быть, а в худшем случае придется объяснять, что подарок был для нее.
Что делать с отслеживающими cookies
Пользователям можно рекомендовать использовать режим инкогнито браузеров, который делает любые cookies сессионными, т.е. сохраняет их только до закрытия браузера. При этом после окончания работы нужно не забывать закрывать браузер. Не лишним будет нажимать на кнопки отказа от cookies на сайтах, где разрешение на их использование запрашивается.
Владельцам сайтов, не желающим способствовать маркетинговой слежке пользователей, рекомендуется придерживаться принципов и требований Европейского GDPR. В частности, можно установить баннер согласия cookies, который будет блокировать их установку до получения разрешения. В случае отказа пользователя отслеживающие куки установлены не будут.
Roblox Cookie Logger: How to Cookie Log on Roblox (2021)
Assuming Roblox is your child’s first experience with digital socializing, then they will probably start out as players not creators and as time elapse, they might graduate into designing there own games and even become the perfect script kiddie out there.
As an online entertainment platform for play, Roblox allows users to create games for the public. There are literally millions of games published on the platform and some of them vary from roaming a kingdom as medieval knight to delivering pizzas.
Albeit popular with young people, players of all ages can use Roblox. The site is completely free per se but with a little bit of dosh spent on its virtual currency called Robux, you can easily get yourself a nice pair for your character.
At the very least, Roblox Cookie Logger is basically a script file that collects the cookies on your computer. They are mostly used to steal a user’s login details for the site and by so doing enables them to hack into your account without permission.
In this article, we’re going to walk you through on how to make a JavaScript Cookie Logger and then we will go further to guide you on how to Cookie Log on Roblox like a Pro. So if you are already itching to try it out, then read on.
How to Make a JavaScript Cookie Logger
To begin with, head over to Discord and Log in to your account. From here, click on the Add a Server button (I.e the plus (+) icon on the left side of the screen).
A pop-up will appear asking if you want to create a server. Simply click on “Create My Own“.
On the next pop-up, you’ll be asked if your server is for a few friends or a larger community. Select “For me and my Friends”
Now enter a memorable” Server Name” when asked and once that is done, click on the “Create” button
Now it’s time to create a channel where you want the cookies to be logged. So to get this one going, click on the plus (+) icon beside text channel or the server name you just created. A drop-down should appear, select the “Create Channel” option.
From here, you’ll get a pop-up. Simply select “Text Channel” under Channel Type and then input the Channel Name. Once everything is done, click on the “Create Channel” button.
Now it’s time to get the webhook URL. So go ahead and click the plus (+) sign beside your Channel Name. From here, select “Edit Channel”
On the next page, click on “Integrations” followed by the “Create Webhook” button.
Now click on the button that says “Copy Webhook URL”
Then head over to any of the following Roblox JavaScript Cookie Logger
In there, paste the “Discord Webhook” URL you copied earlier into the appropriate box and then enter a “Prompt” in the second box or leave it blank.
With everything done, click on the “Create” button and then copy the JavaScript generated.
Now navigate to a profile in Roblox. From here, paste the JavaScript into the address bar and then remove the (×) sign in front of it.
Once done, click Enter on your keyboard and the prompt screen will pop-up. Simpy type any word or number into the box and hit the “Ok” button.
Do note that you can easily hack into someone’s Roblox account using the appropriate JavaScript. Rather than typing any random word or number, we suggest you jump into our previous article which detailed how to hack Roblox accounts and you’d be accessing someone’s Roblox account in no time.
How to Cookie Log on Roblox
Now let’s cookie log on Roblox. So to get this one going, you’ll need to download the browser extension “EditThisCookie“. You can install it directly from Chrome web store.
Once done, the cookie icon should appear beside your Chrome search bar. Now head back to your Discord Server and copy all the codes found within the Cookie box.
Click on it to reveal a drop down. Now under “Value“, delete all the codes found in there and paste/replace them with the cookie codes you copied from your Discord Server.
Once that’s done, click the green check button and then refresh the page and you’ll be good to go.
Wrapping Up
«Осторожно, печеньки!»: советы начинающим тестировщикам в сфере безопасности
Привет, меня зовут Вика Бегенчева, я 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 в браузере.
Напутствие
Мы рассмотрели лишь несколько уязвимостей из множества существующих. Но это поможет войти в прекрасный мир тестирования безопасности. Чтобы ничего не забыть, мы с железными тестировщиками подготовили чеклист.
Думай, как хакер! Пытайся получить выгоду или навредить. Но только на своём проекте. Следи за новостями безопасности. Смотри реестр уязвимостей, читай статьи, которые пишут фирмы по обеспечению безопасности и мониторь новости про утечки данных. Обязательно пытайся разобраться в сути. И будь на стороне добра!