что такое веб уязвимость
Популярные уязвимости сайтов: чем опасны и как их избежать
Для любого, кто управляет веб-сайтом, на первом месте должен стоять вопрос безопасности. Критические угрозы и уязвимости могут сильно ударить как по репутации, так и по кошельку. Вместе со специалистами команды безопасности REG.RU Артёмом Мышенковым и Георгием Шутяевым рассказываем о популярных уязвимостях и способах их устранения.
В этом материале мы выделим пять популярных типов уязвимостей, с которыми может столкнуться любой веб-сайт, и поделимся способами, которые сами применяем для поиска «дыр» в безопасности, проверки сайта на уязвимости и защиты от атак.
IDOR: простая и очень опасная уязвимость
IDOR (Insecure Direct Object Reference, небезопасные прямые ссылки на объекты) — уязвимость, которая позволяет получить несанкционированный доступ к веб-страницам или файлам. Самый распространенный случай IDOR — когда злоумышленник перебирает предсказуемый идентификатор и получает доступ к чужим данным.
Лучше рассмотреть на примере. Допустим, вы зарегистрировались на сайте крупного интернет-магазина. Заполняя свои контактные данные, вы видите в строке браузера похожую ссылку:
onlinestore.ru/user/details/edit?id=39082330
Здесь главную роль играет ваш личный идентификатор (id=39082330). Эксперимента ради вы решили заменить последнюю цифру, и вдруг — попали на страницу с чужими контактными данными, которые можете редактировать.
Таким образом, просто перебирая id в URL, вы можете читать и изменять контактную информацию всех зарегистрированных пользователей. Проблема заключается в том, что при запросах к сайту он не проверяет принадлежность данных конкретному посетителю.
К чему может привести
— Разглашение конфиденциальной информации. Получив доступ к аккаунтам пользователей, злоумышленники увидят их личные данные.
— Обход аутентификации: можно получить доступ сразу к сотням или тысячам учётных записей с этой уязвимостью.
— Изменение данных: редактируя вашу контактную информацию, злоумышленник может использовать её в своих целях. Например, направить все ваши заказы в интернет-магазине к себе домой.
— Захват учётной записи. В некоторых случаях таким способом можно увести аккаунты пользователей, похитить деньги с их баланса и наделать много других неприятностей.
Как защититься
Всегда стоит помнить, что данные, поступающие в HTTP-запросе, являются недоверенными. Если ваш сайт должен отображать определённые страницы в зависимости от каких-то значений из входящих запросов, то такие запросы нужно обязательно валидировать. А именно:
— проверять, есть ли права на указанную страницу или действие;
— проверять принадлежность аккаунта или услуги авторизованному пользователю;
— использовать идентификаторы, которые невозможно предугадать или перебрать;
— использовать подпись идентификатора.
XSS: плохой сценарий
XSS — Cross Site Scripting (межсайтовое выполнение сценариев). Строго говоря, XSS — не уязвимость, а атака. Но условимся, что под XSS мы понимаем уязвимости, позволяющие проводить атаку XSS.
Когда происходит XSS-атака, в веб-страницу встраивается вредоносный код. И как только посетитель сайта откроет эту страницу, начнёт выполняться какой-либо неприятный сценарий. Чаще всего под вредоносным кодом подразумевается внедрение html-тегов или скриптов на JavaScript.
XSS бывают нескольких разновидностей:
1. Хранимые (stored). Код, который позволяет проводить атаку, постоянно находится на сервере и выполняется автоматически.
2. Отражённые (reflected). В этом случае вредоносного кода нет на самом сайте, но он содержится в заранее созданной злоумышленником веб-ссылке. Обрабатывая этот «плохой» кусок кода, сайт может ненамеренно запустить в браузере пользователя скрипт, который перехватит данные или выполнит другую «полезную нагрузку», если имеется ввиду сама нагрузка XSS.
3. DOM-based. Вариант отражённых, когда вредоносный код не отправляется на сервер, а выполняется сразу в браузере.
К чему может привести
— Перехват сессии пользователя (файлы cookies).
— Подмена страницы (например, формы ввода логина/пароля), чтобы похитить конфиденциальные данные.
— Внедрение скриптов на сайты с высокой посещаемостью (с целью рекламы, накрутки просмотров, DDoS-атак и прочего).
— Внедрение вредоносных программ на внешне безопасных сайтах.
Как защититься
— Выполняйте кодирование данных, вводимых пользователем, при выводе их на страницу.
— Если какие-то данные нельзя закодировать, защитите их дополнительной валидацией.
— Обеспечьте безопасную обработку данных, причём не только на стороне сервера, но и на стороне клиента.
SQL-инъекции
SQL-инъекция — это атака, направленная на сайт или веб-приложение, в ходе которой пользователь может обходным путём получить информацию из базы данных с помощью SQL-запросов. В случае успешной атаки пользовательские данные интерпретируются как часть SQL-кода запроса, и таким образом изменяется его логика. Как и прочие атаки, SQL-инъекция эксплуатирует уязвимости и недоработки в коде, и нужно проводить анализ сайта, чтобы найти «слабые» места.
Попробуем пояснить, что такое SQL-инъекция, на простом примере.
Как известно, большинство сайтов и веб-приложений состоят из трёх компонентов: бэкенд (код, который выполняется на сервере), фронтенд (код, который выполняется на стороне клиента, например в браузере) и база данных. Базы данных обычно состоят из множества таблиц. Скажем, если вы владеете интернет-магазином, у вас должно быть как минимум две таблицы: характеристики товаров и информация о зарегистрированных покупателях. Чтобы получать из базы информацию, например, о конкретном товаре, используется язык SQL-запросов.
Представим, что вы пришли в отдел бытовой техники (базу данных). У вас собой есть список покупок, где написано: «Один чайник за 1000 рублей». Вы даёте список продавцу, прося его принести то, что в нём указано (SQL-запрос).
В ответ на вашу просьбу продавец принесёт вам чайник — переходя к реальной жизни, отправив запрос, вы получите информацию из базы данных.
SQL-инъекция возникает, когда злоумышленник может изменить запрос к базе данных.
В примере выше SQL-инъекция бы возникла, если бы кто-то посторонний исправил ваш список покупок, например дописал в конец: «Чайник за 1000 рублей или смартфон за 30 000 рублей». Получив от вас такой запрос, продавец, видя, что смартфоны лежат гораздо ближе, чем чайники, дал бы вам смартфон — то есть то, что нужно злоумышленнику.
SQL-инъекция возможна при отсутствии фильтраций входящих параметров — хакеры могут менять их, чтобы получать нужные им данные. Уязвимыми местами в этом случае служат поля пользовательского ввода и URL-адреса, взаимодействующие с базой данных.
К чему может привести
— Утечка конфиденциальных данных (паролей, данных банковских карт и прочего).
— Внедрение вредоносного контента в уязвимые поля.
— Изменение базы данных.
— Доступ к операциям администрирования.
Как защититься
— При составлении запросов используйте плейсхолдеры (параметризированные запросы).
— Настройте белый список полей ввода.
— Отделите базу данных от логики веб-приложения.
— Используйте экранирование запросов.
Обход директорий
Обход директорий (Path traversal или Directory traversal) заключается в том, что хакер получает доступ к директориям или файлам на сервере с помощью манипуляций переменных, ссылающиеся на эти файлы. Например, для скачивания файла с сервера указывается его имя:
www.site.ru/download?file=file.pdf
С помощью символа, обозначающего директории (../), можно получить доступ к другим файлам, просто добавив его в строку:
www.site.ru/download?file=../../../etc/passwd
Если имя файла никак не валидируется, то злоумышленник сможет увидеть все файлы системы. И это очень опасно, так как важная информация (файлы конфигурации, логи и прочее) находится в заранее известных местах. Кроме того, можно читать исходный код приложения.
Уязвимость становится ещё опаснее, если помимо чтения файлов есть ещё и возможность загружать их в произвольные директории.
К чему может привести
— Несанкционированный доступ и изменение системных файлов, а также исходного кода сайта или веб-приложения.
— Удалённое выполнение вредоносного кода
— Подмена страниц сайта.
Как защититься
— Старайтесь не использовать вызовы файловой системы при пользовательском вводе.
— Если же без вызовов файловой системы не обойтись, проверяйте вводимые пользователем данные перед их обработкой. После проверки входных данных используйте API файловой системы платформы для канонизации пути. Следует убедиться, что канонизированный путь начинается с ожидаемого базового каталога.
Уязвимости при загрузке файлов
На многих сайтах пользователи могут подгружать разные файлы: например менять свою фотографию профиля или прикреплять изображения к комментариям. Если на вашем сайте доступна загрузка файлов пользователями, то нужно тщательно подойти к вопросу безопасности.
Тип файла обычно проверяется по заголовку, но такая проверка опасна, так как заголовок можно подменить. Проверки на стороне клиента тоже иногда можно обойти. И даже использование чёрного/белого списка расширений может быть неэффективным, поскольку иногда вредоносный код встраивается прямо в файл с «правильным» расширением.
К чему может привести
Злоумышленник подгрузит на сайт вредоносные скрипты, сможет «сломать» его или извлечь какие-либо данные.
Как защититься
Исчерпывающие рекомендации о том, как обезопасить загрузку файлов, есть на StackOverflow. Чек-лист посвящен PHP, однако некоторые пункты будут актуальны и для других языков:
1. запретить выполнение файлов в директории, куда они сохраняются;
2. переименовывать пользовательские файлы так, чтобы пользователь не мог повлиять на них;
3. заново сохранять картинки с помощью библиотек по редактированию изображений, чтобы удалить лишние meta-данные и возможный внедрённый в них вредоносный код.
Итак, мы рассмотрели несколько популярных уязвимостей и рассказали, как их избежать. Пишите в комментариях, хотите ли вы больше узнать о веб-безопасности и какие темы были бы наиболее интересны. Мы всегда готовы поделиться полезным опытом.
Также рекомендуем ознакомиться со статьями про безопасность сайта в нашей Базе знаний.
Спидран по 13 уязвимостям на сайтах. Основные понятия, и средства защиты
Недавно по работе собирал своего рода лекцию по веб-безопасности, ознакомился с известным рейтингом уявзимостей OWASP 2013 года, но с удивлением обнаружил, что корректной инфы на русском языке крайне мало, или её практически нет.
Это, собственно, и стало поводом написать такую статью, в которой тезисно будут описаны основные уязвимости, причины, примеры и решения.
Некоторые из предоставленных в списке уязвимостей уже расписаны и не раз — известный факт, но без них список был бы неполным. Поэтому сразу дам небольшое содержание поста:
1. SQL Injection
2. Некорректная аутентификация и управление сессией
По умолчанию, индентификатор созданной сессии сохраняется в cookie браузера, за исключением случаев когда cookie в браузере откючены. В таком случае, они будут автоматом подставляться в каждый URL самим сервером
Как видите, ID передаётся в открытом виде, в то время как с куками он скрыт в заголовке HTTP-запроса.
Для этого предусмотрели настройку запрета на передачу сессии через URL:
Использование шифрования
Если на вашем сайта должна храниться/передаваться конфиденциальная информация (деньги, номера кошельков, состояние здоровья), то стоит использовать зашифрованные протоколы с сертификатом SSL.
При этом стоит при установке cookie выставлять шестой параметр secure = 1.
Собственно, из URL’а украть ID сессии несложно, и немногим труднее это сделать с куками.
Способы защиты:
Тем не менее, есть и недостатки — взломщик и пользователь могут сидеть за фаерволом с одного и того же IP, или же у юзера попросту может происходить динамическая смена IP прямо во время сессии.
Использование SSL означает, что все передаваемые данные, в т. ч. и куки будут зашифрованы, это делает прямой угон кук невозможным. Минус — куки по-прежнему можно угнать физически, поэтому остальные методы защиты тоже требуются.
Про завершение сессий — время их жизни следует выставлять минимальное, и всегда иметь кнопку выхода из аккаунта на сайте.
Вывод — данная уязвимость вторая по распространённости среди веб-сервисов, и используя все вышеперечисленные методы борьбы можно достаточно эффективно уберечь клиентов от подобного взлома. Ведь хакеру достаточно иметь ID сессии, и ему больше не понадобится ни пароля, ни имени пользователя, чтобы предстать в его образе.
3. XSS
Исчерпывающая и замечательная статья: habrahabr.ru/post/149152
… но от себя хотелось бы добавить кое-что.
HTTP заголовки:
X-Content-Type-Options: nosniff
Блокирует загрузку неподтверждённых атрибутом скриптов. (type=«text/javascript», type=«text/css»)
X-Frame-Options: DENY
Запрещает встраивать данную страницу в iframe
Strict-Transport-Security: max-age=expireTime Запрет на загрузку чего-либо по незашифрованному протоколу (HTTP)
Комментарий BeLove:
Этот заголовок сообщает браузеру, что с ресурсом надо работать только по HTTPS, т.е. отправляется при первом редиректе с HTTP на HTTPS (чтобы исключить mitm по HTTP. Естестственно, не защищает, если посещение ресурса происходит впервые для браузера).
Важное замечание, касающееся этой и предыдущей темы — httpOnly cookie.
Это стандарт был введён давно, но многими забывается или игнорируется. Делает он следующее: делает куки недоступными иными средствами, кроме HTTP. Его установка означает, что их нельзя будет получить средствами JavaScript.
httpOnly это седьмой параметр функции setcookie() в PHP.
4. Небезопасные прямые ссылки на объекты
Данная уязвимость проявляется, когда разработчик указывает прямую ссылку на внутренний объект, например такой как файл, каталог или запись в базе данных, как параметр в URL. Это позволяет атакующему за счёт манипуляций с этим параметром получить несанкционированный доступ к системе.
Нельзя просто забывать проверить, тот ли юзер стоит перед нами, или нет.
Сюда же относится простая защита на количество неправильных попыток ввода пароля.
5. Небезопасная конфигурация
А что это за папка, которая лежит у нас в корне третий месяц?
6. Утечка чувствительных данных
Как правило, данная уязвимость уже вытекает как следствие взлома сайта, в ходе которого были похищены данные, которые оказались легко читаемыми.
Пример #2: Простой сайт, не использующий SSL на всех своих страницах. Достаточно, чтобы сертификат где-то один раз порушился, чтобы злоумышленник смог стырить ID сессии, отслеживая трафик данных.
Пример #3: Хранить в БД незасоленные пароли.
Рекомендуется не автокомплитить такую информацию, и не кешировать страницы с ней.
7. Отсутствие контроля доступа к функциональному уровню
Заголовок подразумевает разграниченный доступ к определённым функциям приложения.
8. Подделка межсайтовых запросов (CSRF)
Один из самых малозаметных для разработчиков типов уязвимостей. В одиночку, как правило, несёт не много вреда, чаще всего урон от него можно почувствовать в связке с другими уязвимостями (XSS, невалидированные редиректы)
На самом деле, это мой любимый метод взлома сайта, и заслуживает целой статьи с подробностями, но какой же это тогда спидран?
Приведу ссылку на замечательное описание дыры на securitylab.ru
9. Использование компонентов с известными уязвимостями
10. Невалидированные редиректы
Профилактика
11. Кликджекинг
Из названия — «угон кликов». Над страницей сайт злоумышленника лежит прозрачный iframe, с помощью пресловутой социальной инженерии хакер заставляет пользователя сделать несколько определённых действий. Юзеру кажется, что он нажимает кнопки/формы на одном сайте, на самом деле всё подстроено так, что все действия выполняются на странице внутри iframe. Такое достигается путём создания одинаковых координат кнопок/форм на атакующем сайте и сайте-жертве.
Особенность в том, что пользователь сам не знает, что он вводит данные «не туда». Чтобы предотвратить такое, следует пользоваться тегом X-Frame-Options: DENY (см. выше), и простая каптча или повторный ввод пароля.
12. Фишинг
Популярный метод вытянуть логин/пароль из жертвы. Как правило, по особым базам данных жертв производится E-Mail рассылка, где пользователя от лица настоящего сайта побуждают к действию перейти на сайт.
К примеру, вместо yandex.ru это окажется yandx.ru, uandex.ru, yandex.nk.me и проч.
Внешне он выглядит точно так же, как наш сайт, на котором юзер разлогинен. Опять же, какими-либо средствами соц. инженерии злоумышленник просит жертву залогиниться, (на своём сайте), и просто-напросто получает логин/ пароль. Как правило, после ввода выдаётся что-то вроде сообщения об ошибке авторизации, и больше ничего не происходит.
От фишинга сейчас защищены даже браузеры, и большое количество антивирусов, но проблема остаётся актуальной. Во избежание «рутания» аккаунта ваших пользователей, просите их вводить пароль при особо важных операциях (перевод денег), или просите подтвердить аккаунт при помощи SMS.
13. PHP Include
Уже, пожалуй, маловстречаемый способ захвата сайта.
Заключается в неправильной логике работы приложения, позволяющая подключить любой файл на сервере (при неправильной конфигурации, опять же).
В адресной строке видим запрос:
site.com/index.php?p=contacts.php
Уже всё яснее ясного, да? Как правило, внутри кроется примерно следующее:
Дальше ваша фантазия может играть сколько угодно:
Во избежание многих из этих ошибок, помните, что GET — только для получения данных, для всего остальное есть Master POST.
Большинство рекомендаций взято отсюда, переведено и дополнено мной.
OWASP TOP-10: практический взгляд на безопасность веб-приложений
Хабр, привет! Мы — Иван Притула и Дмитрий Агапитов, занимаемся разработкой решений, которые делают жизнь людей проще и комфортнее. Сегодня мы хотим представить один из наших новых сервисов – это платежный агрегатор SimplePay. Все что мы делаем продиктовано мучительной невозможностью мириться с несовершенством в целом, и несовершенством конкретных программных решений в частности. Именно в погоне за совершенством и рождаются наши продукты. Стараемся мы изо всех сил, а уж насколько мы близки, судить не нам.
Чтобы Всем было интереснее, мы не будем рекламировать свой сервис (ну если только чуть-чуть). Вместо этого, мы подготовили первую серию публикаций, которая будет посвящена такой увлекательной и крайне актуальной теме, как безопасность Web-приложений. Мы постараемся раскрыть опасности, сопутствующие любому действующему интернет-проекту и простым языком донести всю важность ответственного подхода к рутинным, казалось бы, мелочам в вопросах безопасности данных. Надеемся наши статьи будут не бесполезны для Вас. Уверены, так Вы узнаете нас гораздо лучше.
SimplePay — это современный высокотехнологичный агрегатор платежей. Компания создана в 2014г., зарегистрирована в г. Москве и ведет свою деятельность в соответствии с законодательством Российской Федерации. Наша основная задача, это обеспечение простой, удобной возможности организации приема платежей на интернет-сайтах компаний, вне зависимости от сферы деятельности, масштаба бизнеса и наличия подготовленного технического персонала.
Мы предлагаем следующие услуги:
Безопасность веб-приложений
Современный мир несет в себе тысячи угроз и потенциальных опасностей буквально на каждом шагу и в каждый момент времени. Всемирная сеть, ставшая неотъемлемой частью нашей жизни, не является исключением.
Киберпреступность сейчас развита как никогда – ведь почти каждая компания имеет свой сайт в интернете, а злоумышленник в сети может легко оставаться абсолютно анонимным.
При этом все компании, имеющие сайт в интернете, делятся на три типа:
Акцент на возможности практического применения сделан не случайно. Мы считаем, что недостаточно знать теорию для понимания истинного масштаба угрозы – ведь уязвимости, которые выглядят не очень страшно в теории, зачастую могут нести катастрофические для бизнеса последствия.
Количество угроз растет пропорционально росту бизнеса, однако как показала многолетняя практика, 99% атак происходят через десяток стандартных ошибок валидации входящих данных, либо обнаруженные уязвимости в установленных компонентах программного обеспечения сторонних производителей, либо банально, по халатности системных администраторов, использующих настройки и пароли, установленные по-умолчанию.
Классификацией векторов атак и уязвимостей занимается сообщество OWASP (Open Web Application Security Project). Это международная некоммерческая организация, сосредоточенная на анализе и улучшении безопасности программного обеспечения.
OWASP создал список из 10-и самых опасных векторов атак на Web-приложения, этот список получил название OWASP TOP-10 и в нем сосредоточены самые опасные уязвимости, которые могут стоить некоторым людям больших денег, или подрыва деловой репутации, вплоть до потери бизнеса.
В этой вводной статье мы пробежимся по списку OWASP TOP-10, а далее в рамках серии наших статей «Теория и практика защиты Web-приложений» подробно рассмотрим каждый из перечисленных векторов атак, методы практической эксплуатации, степень опасности на примерах реального бизнеса, а также методы практической защиты Web-приложений и Web-сервисов.
Мы постараемся вести изложение максимально доступно, с целью донести информацию не только и не столько до технических специалистов, но также до собственников и управляющих бизнеса, которые, порой, пребывают в счастливом неведении, пока их не сломали злоумышленники, и занимаются онлайн-бизнесом, не ведая о серьезнейшей опасности, нависшей над ними.
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)
Данный вид уязвимости является также следствием недостаточной проверки пользовательских данных. Суть ее заключается в том, что при выводе каких-либо конфиденциальных данных, например личных сообщений или учетных карточек клиентов, для доступа к объекту используется идентификатор, который передается в открытом виде в адресной строке браузера, И не реализована проверка прав доступа к объектам. Например, есть страница, которая отображает личное сообщение и она имеет адрес вида:
Перебирая число после «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 в общем виде, постарались рассказать о них максимально простым языком, а также показать на простых практических примерах, какие риски несут для вашего бизнеса те или иные векторы атак.
В первую очередь эта статья была рассчитана на собственников интернет-проектов и молодых разработчиков. В дальнейших статьях мы осветим более подробно каждый из упомянутых векторов атак, уже с развернутыми техническими подробностями и наглядными примерами, и конечно же, способами защиты.
Если Вы – собственник бизнеса, мы надеемся, что ваше понимание рисков, связанных с IT-безопасностью стало более полным, а следующие статьи могут стать отличным пособием для ваших IT-специалистов.