Тестирование безопасности — это отдельная область тестирования. О которой я почти ничего не знаю =)) Потому что область сложная. И если юзабилити, в принципе, может проверить даже джуниор, то в тестирование безопасности ему лучше не лезть. Потому что когда безопасность важна — то пропущенный баг стоит миллионы.
Насколько безопасно ваше ПО? Легко ли его взломать? Это очень важный вопрос, если приложение работает с персональными данными или деньгами.
Периодически всплывают сайты из серии «введи свой емейл и мы скажем твой пароль, ведь мы взломали большую базу, аха-ха». Если ваш пароль и правда взломали — значит, злоумышленник обнаружил дыру в безопасности.
Если он найдет дыру в работе банкота, то сможет снять оттуда все деньги при нулевом или минимальном балансе на карточке.
Если он найдет дыру в веб-приложении, то сможет войти под вашим логином-паролем. И если вы сохранили данные карточки, злоумышленник может их считать, купить что-то, или просто вывести деньги. Поэтому банки сейчас ограждаются от покупок добавлением двухфакторной авторизации — вы делаете покупку на сайте и подтверждаете ее кодом из смс.
Способы взлома
Брутфорсинг
Полный перебор (или метод «грубой силы», англ. brute force) — это когда мы пытаемся подобрать данные, перебрав все возможные варианты.
Не секрет, что админский логин в линукс-системе часто идет с логином root. Это по умолчанию, а изменять так лень... Так что логин злоумышленнику известен. Остается подобрать пароль. Метод брутфорсинга — это тупо перепробовать все возможные комбинации. И чем умнее и быстрее становятся компьютеры, тем быстрее они перебирают варианты.
Думаете, что это все фигня и от этого давно есть защита? Пожалуйста, недавняя статья.
В результате выявления уязвимости веб-ресурса ликвидированного Бинбанка персональные данные граждан, направляемые кредитной организации при запросе на выдачу кредита или карты, оказались в открытом доступе, сообщает «Коммерсант».
В понедельник компания DeviceLock сообщила о выявленной утечке данных клиентов-физлиц, подававших заявки на получение кредитной карты Бинбанка «Эlixir», которые не находятся в открытом доступе, однако извлечь их можно методом подбора буквенно-цифровых сочетаний, поясняется в сообщении компании.
По словам основателя DeviceLock Ашота Оганесяна, в настоящее время известно, что уже найдено более 1 тыс. анкет, однако при помощи автоматизированного перебора возможно получить все заявки, а их могут быть десятки или даже сотни тысяч. Также велика вероятность подобных проблем и в других банках, использовавших то же решение для системы безопасности.
Как напомнил вице-президент группы компаний InfoWatch Рустем Хайретдинов, схожая публичная история была в 2015 году с банком «Санкт-Петербург», когда злоумышленники также получили доступ к данным клиентов, после чего банк пересмотрел свой взгляд на безопасность. Руководитель группы исследований безопасности банковских систем Positive Technologies Ярослав Бабин сообщил, что очевидно также отсутствие защиты от атаки перебором.
Если говорить про линукс-сервер, то их пытаются взломать перебором IP-адресов. Ведь для IP-адресов есть какая-то определенная маска , и почти наверняка там будет root логин. А уж если IP известен, рута обязательно попробуют. Хотя бы «ламерским брутфорсом» — перебором типичных комбинаций типа:
- root / root
- root / admin
- …
Ну а что, вполне может сработать, если админ не удосужился поставить нормальный пароль.
Когда я делала обучающие видосики и статьи по линуксу, то нашла облачный сервис, где можно взять в аренду линукс-сервер за 150р в месяц. И решила я для своей странички Test it купить такую машинку. Недорого же, почему бы и нет?
Оплатила сразу на несколько месяцев, создала тестового пользователя и радостно выставила в общий доступ. Потом, как ни зайду под рутом, вижу такого плана сообщения:
root@85.143.174.119's password:
Last failed login: Mon Jul 16 04:24:25 MSK 2018 from 198.98.48.103 on ssh:notty
There were 120 failed login attempts since the last successful login.
Last login: Sun Jul 15 11:33:27 2018 from 37.187.143.213
120 попыток взлома. Вот, казалось бы, зачем? А чтобы навредить. Потому что даже из-под открытого пользователя навредить умудрялись. Поработает сервер пару дней и мне приходит письма от админов «От вас идут попытки взлома, мы погасили машину».
Переустановим с нуля, вроде пытаюсь огородиться, запреты ставлю на потенциально опасные команды (ssh например, чтобы не пытались взломать другие машины), но я ведь не тестировщик безопасности — они все равно путь найдут. И снова мою машину гасят.
Там админы какие-то вялые были, я им объясняю «это для открытого доступа, я сделала то и то, скажите как еще можно защититься», ноль эмоций. Сама думай. В итоге надоело и я перестала оплачивать сервер. Не знаю, может, снова подниму, но уже на другой платформе, где админы помогают, а не все на тебя перевешивают.
В любом случае, если вы где-то засветили IP-адрес, намеренно или нет, ждите атаки на рута, перебирать пароли для него в любом случае будут.
Перехват трафика
Вы отправляете какую-то информацию. Например, вводите в формочку входа свой логин и пароль. Эти данные клиент (браузер) передает серверу. Злоумышленник влезает на пути передачи данных и перехватывает сообщение. Так он получает данные для входа.
И всё, если у вас привязана карточка в приложении, злоумышленник получает к ней доступ. А если приложение открыто отправляет «денежные» данные, то это совсем фейл. Ведь сейчас есть куча платежных систем, которые обеспечивают безопасность. Если вы делаете свой сайт, подключите готовую систему, не делайте самописную на коленке — ее будет слишком легко взломать.
SQL-инъекции
Это когда вы передаете вместо нормального параметра SQL-запрос. Если приложение уязвимо, можно сделать много плохого.
Самая типичная инъекция — ввести в поле одинарную кавычку и за ней какой-то запрос. Вот как на рисунке, только с паролем. Логин админа то обычно стандартный — admin или administrator, а в пароле пишем любой пароль, а потом «ИЛИ 1=1». Пароль не подошел, но 1 = 1, возвращается true → и вот мы уже вошли в систему!
Или вот знаменитая картинка-мем про инъекции:
Давайте переведу:
Ссылки по теме:
Что такое SQL Injection защита — https://wiki.dieg.info/sql_injection
SQL инъекции. Проверка, взлом, защита — https://habr.com/ru/post/130826/
XSS-атаки
Межсайтовый скриптинг — это когда вы внедряете в код страницы вредоносный код.
Например, у вас есть поле ввода — имя в профиле. Разработчик не защитил это поле и позволил вводить все, что угодно.
И вот я могу туда ввести:
Маша <script>alert("Я ТЕБЯ СЛОМАЛ АХАХА")</script>
Что в итоге? Как только я сохраню изменения, то увижу поп-ап с текстом «Я ТЕБЯ СЛОМАЛ АХАХА»
Если мы увидели поп-ап → поле не защищено. И вместо безвредного поп-апа можно внедрить правда плохой скрипт. Который утащит информацию, перенаправит реального пользователя на другой опасный сайт или что-то еще.
Поэтому можете использовать лайт проверку из примера выше с алертом. Если алерт вызвался — бейте тревогу. Ну а как можно навредить такими атаками — изучите в гугле =)
Ссылки по теме:
Уроки по XSS: Урок 1. Основы XSS и поиск уязвимых к XSS сайтов
Что-то более умное
Так как я не умею взламывать, то и научить этому не могу. Про простые атаки знаю, но наверняка есть что-то более сложное и изощренное. Если интересует эта область — идите в тестирование безопасности, копайте и развивайтесь.
Хороший тестировщик безопасности и получает много. Рынок, правда, невелик. По крайней мере, требуются такие люди реже, чем простые тестировщики или автоматизаторы. Но хорошего с руками оторвут.
Истории взлома
Все ваши анализы в открытом доступе
Автор статьи рассказывает, как нашел логи с результатами анализов. Их можно прочитать в машинном виде, а можно получить PNG-файлы в удобном для чтения виде:
Этот автор не в первый раз пишет про уязвимость медицинских данных. Другие его статьи на эту тему:
- утечка персональных данных пациентов и врачей из медицинского онлайн-сервиса DOC+
- уязвимость сервиса «Доктор рядом»
- утечка данных станций скорой медицинской помощи
Мошенники вывели через сервис переводов Mastercard 9 млн рублей из-за ошибки в настройках банкоматов
Операции проводили с 15 по 19 мая 2018 года в банкоматах на железнодорожных вокзалах в Москве. Участники схемы выбирали опцию перевода денег с карт «Сбербанка» на карты «Тинькофф банка», но в последний момент отменяли операцию.
Мошенники выбирали опцию перевода, после чего направлялись запросы в банк отправителя и банк получателя для разрешения на списание и зачисление средств, объясняет эксперт по информационной безопасности банков Николай Пятиизбянцев, изучивший решение суда. Затем на экране банкомата появлялась информация о комиссии и предложение подтвердить перевод.
Ошибка в настройках заключалась в том, что банк — владелец банкомата считал, что операцию все ещё можно отменить, а банк получателя — что перевод уже отозвать нельзя. Мошенники отменяли операцию: сумма восстанавливалась на карте отправителя и одновременно проходил перевод. По правилам Mastercard для операций MoneySend банк получателя может не согласиться с отменой операции.
Комментариев нет:
Отправить комментарий