Безопасность WEB это целое отдельное направление в общей теме обеспечения ИБ. Оно и понятно, ресурсы сети сегодня почти безграничны. Всемирная паутина стала платформой для бизнеса, развлечений, общения, коммуникаций, поиска и передачи информации. Соответствующей реакцией на это стал и рост уязвимостей, угроз безопасности. Проект OWASP, речь о котором пойдет в данной статье, составил рейтинг ТОП 10 самых опасных атак на Web-ресурсы.
Сегодня наиболее авторитетно классификацией векторов атак и уязвимостей в Web-сфере занимается сообщество OWASP (Open Web Application Security Project). Это коротко, то это международная некоммерческая организация, сосредоточенная на анализе и улучшении безопасности программного обеспечения. Сообщество OWASP включает в себя корпорации, образовательные организации и частных лиц со всего мира. Сообщество работает над созданием статей, учебных пособий, документации, инструментов и технологий, находящихся в свободном доступе.
Но, нам интересна практическая сторона дела.
Так OWASP знаменит тем, что создал список из 10-и самых опасных векторов атак на Web-приложения, этот список получил название OWASP TOP-10 и в нем сосредоточены самые опасные уязвимости, которые могут стоить некоторым людям больших денег, или подрыва деловой репутации, вплоть до потери бизнеса.
В этой вводной статье мы бегло пробежимся по списку OWASP TOP-10. Мы постараемся вести изложение максимально доступно, с целью донести информацию не только и не столько до технических специалистов, но также до собственников и управляющих бизнеса, которые, порой, пребывают в счастливом неведении, пока их не сломали злоумышленники, и занимаются онлайн-бизнесом, не ведая о серьезнейшей опасности, нависшей над ними.
Ну что же, давайте, начнем.
На сайте OWASP каждая из уязвимостей разбирается весьма подробно.
Рейтинг отражает не только распространенность, но и опасность угрозы. Первая версия Топ-10 вышла в 2003 году, следующие — в 2004, 2007 и 2010гг.
Список OWASP Топ-10 основан на восьми базах данных от семи компаний, включая четыре консалтинговые фирмы и трех вендоров SaaS. Общая база содержит более 500 000 уязвимостей в сотнях организаций и тысячах приложений.
Вот типовый набор OWASP Топ-10
- A1 Внедрение кода
- A2 Некорректная аутентификация и управление сессией
- A3 Межсайтовый скриптинг (XSS)
- A4 Небезопасные прямые ссылки на объекты
- A5 Небезопасная конфигурация
- A6 Утечка чувствительных данных
- A7 Отсутствие контроля доступа к функциональному уровню
- A8 Подделка межсайтовых запросов (CSRF)
- A9 Использование компонентов с известными уязвимостями
- A10 Невалидированные редиректы
Попробуем разобраться более подробно.
1. Инъекции — Injections
Все данные, как правило, хранятся в специальных базах, обращения к которым строятся в виде запросов, чаще всего написанных на специальном языке запросов SQL (Structured Query Language – структурированный язык запросов).
Приложения используют SQL-запросы для того, чтобы получать, добавлять, изменять или удалять данные, например при редактировании пользователем своих личных данных или заполнении анкеты на сайте. При недостаточной проверке данных от пользователя, злоумышленник может внедрить в форму Web-интерфейса приложения специальный код, содержащий кусок SQL-запроса.
Такой вид атаки называется инъекция, в данном случае самый распространённый — SQL-инъекция. Это опаснейшая уязвимость, позволяющая злоумышленнику получить доступ к базе данных и возможность читать/изменять/удалять информацию, которая для него не предназначена.
Например, изменить вместе с именем и фамилией баланс своего счета, посмотреть баланс чужого счета, или же, похитить конфиденциальные личные данные.
Эта уязвимость является следствием недостаточной проверки данных, поступающих от пользователя. Это позволяет злоумышленнику «подсунуть», например, в веб-формы, специально подготовленные запросы, которые «обманут» приложение и позволят прочитать или записать нелегитимные данные.
В целом эта разновидность атак имеет общее название «Ошибки валидации», к ней относятся далеко не только SQL-инъекции и мы будем упоминать этот вектор еще не раз.
2. Недочеты системы аутентификации и хранения сессий (Broken Authentication and Session Management)
Для того, чтобы отличать одного пользователя от другого, web-приложение использует так называемые сессионные куки. После того, как Вы ввели логин и пароль и приложение вас авторизовало, в хранилище браузера сохраняется специальный идентификатор, который браузер в дальнейшем предъявляет серверу при каждом запросе страницы вашего web-приложения. Именно так web-приложение понимает, что Вы это именно Вы.
В случае, если ваш идентификатор украдет злоумышленник, а в системе не были реализованы проверки, скажем IP-адреса сессии, или проверки наличия более одного соединения в одной сессии, злоумышленник сможет получить доступ в систему с правами вашего аккаунта. А если это интернет-банк или кабинет платежной системы, о последствиях такого несанкционированного доступа Вы можете легко догадаться сами.
3. Межсайтовый скриптинг – XSS (Cross Site Scripting)
Межсайтовый скриптинг – еще одна ошибка валидации пользовательских данных, которая позволяет передать JavaScript код на исполнение в браузер пользователя. Атаки такого рода часто также называют HTML-инъекциями, ведь механизм их внедрения очень схож с SQL-инъекциями, но в отличие от последних, внедряемый код исполняется в браузере пользователя. Чем это чревато?
Во-первых, злоумышленник может украсть вашу сессионную cookie, последствия чего были описаны во втором пункте, буквально парой абзацев выше. Нужно отметить, что далеко не все серверы приложений уязвимы к данному типу атак, об этом мы отдельно поговорим в пункте под номером 5.
Во-вторых, могут быть украдены данные, вводимые в формы на зараженной странице. А это могут быть конфиденциальные персональные данные, или, что еще хуже, данные кредитной карты вместе с CVC-кодом.
В третьих, через JavaScript можно изменять данные, расположенные на странице, например, там могут быть реквизиты для банковского перевода, которые злоумышленник с удовольствием подделает и заменит подставными.
4. Небезопасные прямые ссылки на объекты (Insecure Direct Object References)
Данный вид уязвимости является также следствием недостаточной проверки пользовательских данных. Суть ее заключается в том, что при выводе каких-либо конфиденциальных данных, например личных сообщений или учетных карточек клиентов, для доступа к объекту используется идентификатор, который передается в открытом виде в адресной строке браузера, И не реализована проверка прав доступа к объектам. Например, есть страница, которая отображает личное сообщение и она имеет адрес вида:
mysite.ru/read_message.jsp?id=123654
Перебирая число после "id=" можно будет читать чужие личные сообщения. Эксплуатация данной уязвимости очень проста и не требует вообще никаких специальных навыков – достаточно лишь перебирать число в адресной строке браузера и наслаждаться результатом. Как ни парадоксально, но этой детской болезни, порой были подвержены достаточно крупные европейские платежные системы.
5. Небезопасная конфигурация (Security Misconfiguration)
Безопасность Web-приложения требует наличия безопасной конфигурации всех компонентов инфраструктуры: компонентов приложения (таких как фреймворки – frameworks), веб-сервера, сервера баз данных и самой платформы. Настройки компонентов сервера по-умолчанию зачастую небезопасны и открывают возможности к атакам. Например, кража сессионной cookie через JavaScript при XSS-атаке становится возможна благодаря выключенной по-умолчанию настройке cookie_http only.
При правильной настройке сервера и включенной опции cookie_httponly, получить сессионную cookie через JavaScript невозможно, но зачастую эта простая и важная настройка отсутствовала в таких критично важных местах, как личные кабинеты платежных систем.
Еще один пример детской уязвимости – использование настроек по-умолчанию в серверах баз данных, таких как Redis, Memcached и других – закрытая служба может быть доступна на публичном IP-адресе сервера, и/или использовались пароли, установленные производителем по-умолчанию. Это позволяет злоумышленнику запросто читать и изменять данные, в числе которых, нередко бывают и сессионные cookies (чем это чревато – мы уже знаем) и выводимые пользователям в браузер данные (что позволяет еще и XSS-атаку применить).
Кроме того, программное обеспечение должно быть в актуальном состоянии: уязвимости находят каждый день в самых различных программных компонентах – операционной системе, web-серверах, серверах баз данных, почтовых серверах и т.д. И даже если ваше приложение правильно написано и тщательно проверяет все входящие данные, и вообще, хорошо защищено, это не означает что в один прекрасный момент не найдется уязвимость в вашей ОС или Web-сервере.
6. Незащищенность критичных данных (Sensitive Data Exposure)
Многие веб-приложения не защищают конфиденциальные данные, такие как кредитные карты и учетные данные для аутентификации. Злоумышленники могут украсть или модифицировать такие слабо защищенные данные для использования в своих корыстных целях.
Самый простой пример – передача данных по протоколу HTTP. Дело в том, что данные передаваемые по протоколу HTTP никак не шифруются, а при прохождении данных от компьютера пользователя до Web-сервера, данные пройдут достаточно много различных узлов: маршрутизатор офиса или домашний роутер, маршрутизатор провайдера, маршрутизатор на канале, маршрутизатор в дата-центре хостинг-провайдера сервера и так далее. На каждом из этих узлов может затаиться зловред, так называемый сниффер, программа, которая считывает весь трафик и передает злоумышленнику. А последний просматривает полученные данные на предмет персональных данных и данных кредитных карт.
Такие данные должны передаваться исключительно по протоколу HTTPS, о чем должна гласить соответствующая надпись в адресной строке браузера:
Еще одна задача SSL-сертификата (а именно так называется специальный ключ, при помощи которого осуществляется проверка подлинности и шифрование в HTTPS) – подтвердить, что он выдан именно для данного сайта. В случае, если сертификат просрочен или подделан, Вы увидите следующую картину:
Другой пример – отсутствие шифрования критичных данных, таких как пароли или номера кредитных карт. В случае, если данные зашифрованы, то даже в случае получения несанкционированного доступа на сервер, злоумышленник не сможет украсть критичные данные. К паролям, в частности, должна применяться необратимая хеш-функция – расшифровать шифрограмму при этом не возможно и проверка пароля происходит путем формирования шифрограммы введенного пароля и сравнения ее с имеющейся в базе.
7. Отсутствие функций контроля доступа (Missing Function Level Access Control)
Суть уязвимости, как следует из названия, заключается в отсутствии проверки наличия надлежащего доступа к запрашиваемому объекту.
Большинство веб-приложений проверяют права доступа, прежде чем отобразить данные в пользовательском интерфейсе. Тем не менее, приложения должны выполнять те же проверки контроля доступа на сервере при запросе любой функции. Ведь есть еще множество вспомогательных служебных запросов, которые, зачастую отправляются в фоновом режиме асинхронно, при помощи технологии AJAX.
Если параметры запроса не достаточно тщательно проверяются, злоумышленники смогут подделать запрос для доступа к данным без надлежащего разрешения.
Частный, и пожалуй, самый распространенный случай данной уязвимости мы уже рассмотрели в 4 пункте нашей статьи – отсутствие проверки пользователя в личных сообщениях.
8. Межсайтовая подделка запроса (Cross-Site Request Forgery, CSRF/XSRF)
Вектор атаки CSRF, также известный как XSRF, позволяет злоумышленнику выполнять от имени жертвы действия на сервере, где не реализованы дополнительные проверки.
Например, в некоторой платежной системе для перевода средств на другой аккаунт, есть страница вида:
demobank.com/transfer_money.jsp?transfer_amount=1000&transfer_account=123456789
где transfer_amount – сумма для перевода и transfer_account – номер аккаунта, куда должны быть переведены средства.
Если жертва заходит на сайт, созданный злоумышленником, от её лица тайно отправляется запрос на вышеуказанную страницу платежной системы. Как результат – деньги уйдут на счет злоумышленника, после чего, вероятно, будут оперативно обменяны на Bitcoin или переведены в другую безвозвратную платежную систему, и получить их назад уже не получится.
Предполагается, что жертва должна была предварительно пройти аутентификацию в платежной системе и должна быть открыта активная сессия (скажем, страница платежной системы открыта в другой вкладке браузера).
Решается проблема достаточно просто и об этом мы расскажем в отдельной статье, посвященной CSRF.
9. Использование компонентов с известными уязвимостями (Using Components with Known Vulnerabilities)
Зачастую web-приложения написаны с использованием специальных библиотек или «фреймворков» (англ – framework), которые поставляются сторонними компаниями. В большинстве случаев эти компоненты имеют открытый исходный код, а это означает, что они есть не только у вас, но и у миллионов людей во всем мире, которые штудируют их исходный код, в том числе, и на предмет уязвимостей. И нужно отметить, что делают они это отнюдь не безуспешно.
Также уязвимости ищут (и находят) в более низкоуровневых компонентах системы, таких как сервер базы данных, web-сервер, и наконец, компоненты операционной системы вплоть до ее ядра.
Очень важно использовать последние версии компонентов и следить за появляющимися известными уязвимостями на сайтах типа securityfocus.com.
10. Непроверенные переадресации и пересылки (Unvalidated Redirects and Forwards)
Web-приложения зачастую переадресуют пользователя с одной страницы на другую. В процессе могут использоваться ненадлежащим образом проверяемые параметры с указанием страницы конечного назначения переадресации.
Без соответствующих проверок, атакующий может использовать такие страницы для переадресации жертвы на подложный сайт, который, к примеру, может иметь очень схожий или неотличимый интерфейс, но украдет ваши данные кредитной карты или другие критичные конфиденциальные данные.
Этот вид уязвимостей, также как и многие другие перечисленные выше, является разновидностью ошибок проверки входящих данных (input validation).
И так, мы рассмотрели основные виды уязвимостей из OWASP TOP-10 в общем виде, постарались рассказать о них максимально простым языком, а также показать на простых практических примерах, какие угрозы и риски реально вас могут обеспокоить.
Всем удачи, и надежной защиты ваших данных!
Комментариев нет:
Отправить комментарий
Вы можете добавить свой комментарий...
Примечание. Отправлять комментарии могут только участники этого блога.