Описание
Чаще всего атакам подвергаются Web-приложения. К этим атакам, направленным на самые распространенные уязвимости, относятся межсайтовый вызов скриптов (cross-site scripting), внедрение SQL (SQL injection), модификация параметров (parameter tampering), подделка cookie-файлов (cookie poisoning) и утечка информации. Традиционные системы защиты периметра, такие как сетевые экраны и системы обнаружения вторжений, не защищают от атак подобного рода, поскольку эти атаки используют уязвимость программ. В данной статье рассматриваются наиболее распространенные уязвимости и возможные контрмеры, а также объясняется значение автоматизированного сканирования системы безопасности в процессе разработки для создания безопасных приложений.
истемы управления доступом, сетевые экраны, системы обнаружения вторжений и системы предотвращения вторжений являются неотъемлемыми составными частями системы безопасности приложений, обеспечивающими защиту периметра. Однако эти механизмы не полностью защищают Web-приложения от атак. Поскольку эти приложения используют Web-технологии, сами принципы взаимодействия Web-пользователей с ними позволяют напрямую атаковать приложения и обходить установленные системы защиты периметра. Злоумышленники знают об этом, и именно поэтому большинство атак – это прямые атаки на Web-приложения.
Чтобы выровнять баланс, разработчики приложений должны изучать стратегии защиты против атак. Также они должны учитывать несколько факторов, являющихся причиной целого ряда атак:
- В своем большинстве разработчики Web-приложений не являются экспертами в области безопасности и могут не знать о многих уязвимостях.
- Многие разработчики не знакомы с передовыми методиками защиты Web-приложений.
- Часто главным приоритетом является функциональность, а вопросы безопасности решаются позже путем модернизации готового приложения.
- Среда, в которой развертываются Web-приложения, меняется с большой скоростью, включая обновления самого кода, а также инфраструктуры. Некоторые из этих изменений не проверяются и не тестируются профессионалами в области безопасности приложений.
Вышеперечисленные факторы диктуют правила, которые следует соблюдать каждому разработчику для написания более качественного кода.
- Обучайтесь.
- Ищите готовые решения.
- Интегрируйте тестирование в план разработки.
- Выявляйте уязвимости на ранних этапах.
Эта статья призвана повысить уровень информированности разработчиков. В ней рассказывается о наиболее распространенных уязвимостях Web-приложений, использующих технологию Web 2.0. Также приводится краткая информация о проблемах безопасности, свойственных мобильным устройствам.
Распространенные Web-уязвимости
Мобильные Web-приложения во многом подвержены тем же уязвимостям, которые присущи настольным Web-приложениям. Более подробная информация об уязвимостях и контрмерах приведена в проекте Top 10 Project на Web-сайте Open Web Application Security Project (OWASP), ссылку на который можно найти в разделе Ресурсы.
В следующих подразделах рассматривается несколько основных уязвимостей, о которых должны знать разработчики.
Межсайтовый вызов скриптов
При этой распространенной атаке вредоносный код внедряется в аутентичный Web-сайт. Если в HTML-код отображаемой страницы можно вставить входные данные HTTP-запроса, сайт открыт для таких атак.
Например, сервис принимает параметр image для извлечения из файловой системы изображения и его обработки:
http://somedomain/myImageProcessor?image=myimage.jpg
Злоумышленник может исследовать это приложение, вставляя JavaScript-код в параметр image. Цель – обнаружить неправильную обработку ошибок. Если получится сгенерировать сообщение об ошибке, содержащее вредоносный скрипт, злоумышленник может использовать это в своих интересах:
http://somedomain/myImageProcessor?image=myimage.jpg(script)..вредоносный код ..(/script)
Если сообщение об ошибке возвращает содержимое параметра image без фильтрации, выполняется код, заключенный в теги (script). Скрипт потенциально может получить доступ к локальным cookie-файлам атакуемой Web-страницы или даже изменить содержимое отображаемой страницы. Эту уязвимость можно использовать для рассылки инфицированных ссылок по электронной почте или включения их в злонамеренные Web-страницы.
Эта концепция показана на Web-сайте Altoro Mutual, который демонстрирует возможности программы IBM® Rational® AppScan® Standard Edition по сканированию приложений на наличие уязвимостей
Рисунок 1. Демонстрационный Web-сайт Altoro Mutual AppScan
На рисунке 2 показано, что элемент поиска "pineapples" отображается в результатах поиска независимо от того, найден он или нет.
Рисунок 2. В результатах поиска всегда отображается элемент поиска
Это говорит о том, что приложение восприимчиво к атакам посредством выполнения межсайтовых скриптов. На рисунке 3 показан результат поиска выражения (script)alert('attack')(/script). Код сценария возвращается в результатах поиска и выполняется, после чего отображается окно с предупреждением.
Рисунок 3. Ввод JavaScript-кода в качестве выражения поиска приводит к выполнению этого кода
Контрмеры
Для предотвращения выполнения межсайтовых скриптов (XSS):
- Не отображайте пользователям непроверенные входные данные.
- Удаляйте вредоносный код из входных и выходных данных путем, например, фильтрации или использования белого списка (определяя допустимые данные и запрещая все остальные).
- Кодируйте выходные данные для предотвращения выполнения браузером.
В случае с Altoro Mutual простым решением мог бы стать запрет на возврат элемента поиска.
Более подробное обсуждение межсайтовых скриптов и защиты от них приведено в статье developerWorks® IBM Rational AppScan: подробно о межсайтовых скриптах, а также на странице Cross-site Scripting сайта OWASP
Внедрение SQL
Эта атака тоже связана с использованием уязвимостей в запросах и направлена на вставку SQL-выражений в поля Web-приложения, предназначенные для ввода данных. Возможность вставлять запросы в поля ввода позволяет злоумышленнику обойти механизмы аутентификации Web-сайта и получить доступ к базе данных. Эта атака, наряду с выполнением межсайтовых скриптов, является одной из самых распространенных.
Приведенный ниже пример демонстрирует плохо сконструированную процедуру входа, в которую внедряется SQL: Web-приложение запрашивает имя пользователя и пароль, для чего используется следующее SQL-выражение:
String query = "SELECT * FROM users WHERE user ='"username+"' AND password ='"passwd"'";
Переменные username и password никак не очищаются, и им присваиваются значения, введенные пользователем в приложении. Это позволяет злоумышленнику в качестве username ввести, например, следующее:
anything' OR 1=1 --
Пароль может быть любым. В данном случае предположим, что это * (звездочка).
После подстановки этих данных в переменные username и password сформированный запрос будет выглядеть следующим образом:
SELECT * FROM users WHERE username ='anything' OR 1=1 -- AND password ='*'
Это выражение преобразовывает пароль в комментарий и вставляет условие 1=1, которое всегда истинно. Злоумышленник будет определен как разрешенный пользователь, хотя он не предоставил никаких данных, подтверждающих его полномочия.
Эта атака демонстрируется Web-приложением Altoro Mutual (см. рисунок 4). Перейдите на страницу входа, введите в качестве имени пользователя anything' OR 1=1 --, и любой введенный в качестве пароля символ предоставит вам административный доступ к приложению (рисунок 5). Эта учетная запись может управлять учетными записями других пользователей.
Рисунок 4. Попытка входа с произвольным паролем и фрагментом SQL-кода в качестве имени пользователя
Рисунок 5. После выполнения атаки с использованием внедрения SQL злоумышленник входит в систему как администратор
Аналогично атаке с применением межсайтовых скриптов, данная атака является следствием плохой (или отсутствующей) очистки и проверки вводимой информации.
Контрмеры
Для предотвращения этой атаки:
- Не доверяйте данным, вводимым пользователем.
- Выполняйте их очистку - например, посредством фильтрации или использования белого списка.
В случае Altoro Mutual возможным решением является фильтрация всех поступающих из полей Username и Password символов, отличных от цифр и букв.
Подробная информация о внедрении SQL и возможных мерах противодействия приведена на странице SQL Injection сайта OWASP
Утечка информации
Настойчивый злоумышленник может исследовать приложение, пытаясь обнаружить уязвимости. Это можно сделать разными способами:
- Вручную исследовать приложение для поиска скрытых каталогов.
- Систематически вызывать исключительные ситуации и просматривать подробную информацию о них.
- Сканировать HTML в поисках комментариев, раскрывающих детали инфраструктуры и поведения приложения.
- Систематически вводить разные имена пользователей для поиска существующих учетных записей.
Приложение Altoro Mutual допускает утечку существующих в системе имен пользователей. Например (см. рисунок 6), ввод неправильного имени и пароля пользователя приводит к появлению следующего сообщения об ошибке "Login Failed: We're sorry, but this user name was not found in our system. Please try again" (Во входе отказано: к сожалению данный пользователь не найден в системе. Попробуйте еще раз).
Рисунок 6. Приложение явно указывает, что такого пользователя нет
Далее злоумышленник вводит имя jsmith, и Web-приложение Altoro Mutual выдает следующее сообщение: "Login Failed: Your password appears to be invalid. Please re-enter your password carefully" (Во входе отказано: ваш пароль неверен. Введите пароль повторно). Из этой информации злоумышленник узнает о существовании учетной записи jsmith. Следовательно, он может сконцентрироваться на взломе пароля и попытаться угадать его, выполняя так называемую атаку методом "грубой силы" (brute force attack).
Рисунок 7. Приложение Altoro Mutual сообщает о существовании пользователя jsmith
Данную ситуацию можно исправить, выводя стандартное сообщение, не указывающее конкретно, что произошло, например: "Login failed: User name or password invalid. Please re-enter your credentials carefully" (Во входе отказано: имя пользователя или пароль введены неверно. Попробуйте еще раз).
Контрмеры
Утечку информации необходимо рассматривать в контексте приложения, и лучшей защитой является компетентность разработчика. Существуют различные меры по смягчению последствий утечки информации, которые следует рассмотреть разработчикам.
- Удаляйте из HTML-кода все комментарии, сообщающие что-либо о приложении.
- Не отображайте в браузере конкретные исключительные ситуации. Если ведется журнал исключительных ситуаций, сохраняйте их на сервере и отображайте обобщенную ошибку.
- Не раскрывайте информацию о том, на каком этапе аутентификация завершилась неудачно.
- Кроме того, настройте Web-сервер и сервер приложений на предотвращение произвольной навигации по Web-сайту и приложению.
Этот список никоим образом не претендует на полноту. Необходимо учитывать специфику приложения и рабочей среды.
Дополнительная информация об утечке информации приведена на странице Information Leakage сайта OWASP.
Модификация параметров
Эта атака нацелена на управление параметрами, передаваемыми в приложение. Рассмотрим плохо написанное приложение, позволяющее клиенту устанавливать стоимость покупаемого товара. Такое приложение может отправлять следующий запрос:
http://somedomain/myStore?item=1234&price=$200
Если бизнес-логика не выполняет двойную проверку на стороне сервера, злоумышленник может изменить стоимость, чтобы получить товар по меньшей цене. В данном случае разрешение установки цены со стороны клиента является явной ошибкой.
Контрмеры
- Для исправления этой конкретной ситуации можно изменить код, чтобы получать цену из базы данных на стороне сервера, предотвращая манипуляцию ценой.
- Защита от такой атаки включает в себя проверку параметров и тщательный анализ логики приложения.
Дополнительная информация о модификации параметров и возможных контрмерах приведена на странице Web Parameter Tampering сайта OWASP
Подделка cookie
Cookie представляет собой информацию, хранящуюся в виде пар ключ/значение в текстовом файле или в памяти и отправляемую сервером в браузер. Содержимое cookie используется создавшим его Web-приложением. Подделка cookie – это изменение его содержимого после выполнения Web-приложения. Эта атака аналогична модификации параметров.
Контрмеры
- Контрмеры против подделки cookie включают в себя проверку параметров и тщательный анализ логики и кода приложения.
- Также могут применяться продвинутые механизмы защиты.
- Общепринятым подходом является использование цифровых подписей, гарантирующих отсутствие изменений хранилища текстовых файлов.
- Еще одной контрмерой является защита cookie путем шифрования при передаче для снижения риска изменения и перехвата.
Подделка cookie обсуждается на странице OWASP, посвященной уязвимостям из-за ввода непроверенных данных
Заключение
У Web 2.0-приложений, предназначенных для настольных и мобильных устройств, есть много общих проблем безопасности и, следовательно, много одинаковых способов их решения. Разработчики должны знать о наиболее распространенных уязвимостях и бороться с ними на протяжении всего цикла разработки. Для обеспечения безопасности приложения также необходимо постоянное автоматическое сканирование на наличие уязвимостей в процессе разработки и развертывания. Мобильные устройства имеют свой собственный уникальный набор проблем, поскольку по своей природе являются персонализированными и переносимыми. Заранее, еще до развертывания мобильных решений, продумайте защиту данных при краже или потере устройства.