Обеспечение безопасности настольных и мобильных Web 2.0-приложений

Чаще всего атакам подвергаются Web-приложения. К этим атакам, направленным на самые распространенные уязвимости, относятся межсайтовый вызов скриптов (cross-site scripting), внедрение SQL (SQL injection), модификация параметров (parameter tampering), подделка cookie-файлов (cookie poisoning) и утечка информации. Традиционные системы защиты периметра, такие как сетевые экраны и системы обнаружения вторжений, не защищают от атак подобного рода, поскольку эти атаки используют уязвимость программ. В данной статье рассматриваются наиболее распространенные уязвимости и возможные контрмеры, а также объясняется значение автоматизированного сканирования системы безопасности в процессе разработки для создания безопасных приложений.

Системы управления доступом, сетевые экраны, системы обнаружения вторжений и системы предотвращения вторжений являются неотъемлемыми составными частями системы безопасности приложений, обеспечивающими защиту периметра. Однако эти механизмы не полностью защищают Web-приложения от атак. Поскольку эти приложения используют Web-технологии, сами принципы взаимодействия Web-пользователей с ними позволяют напрямую атаковать приложения и обходить установленные системы защиты периметра. Злоумышленники знают об этом, и именно поэтому большинство атак - это прямые атаки на Web-приложения.

Чтобы выровнять баланс, разработчики приложений должны изучать стратегии защиты против атак. Также они должны учитывать несколько факторов, являющихся причиной целого ряда атак:

• В своем большинстве разработчики Web-приложений не являются экспертами в области безопасности и могут не знать о многих уязвимостях.
• Многие разработчики не знакомы с передовыми методиками защиты Web-приложений.
• Часто главным приоритетом является функциональность, а вопросы безопасности решаются позже путем модернизации готового приложения.
• Среда, в которой развертываются Web-приложения, меняется с большой скоростью, включая обновления самого кода, а также инфраструктуры. Некоторые из этих изменений не проверяются и не тестируются профессионалами в области безопасности приложений.

Вышеперечисленные факторы диктуют правила, которые следует соблюдать каждому разработчику для написания более качественного кода.

1. Обучайтесь.
2. Ищите готовые решения.
3. Интегрируйте тестирование в план разработки.
4. Выявляйте уязвимости на ранних этапах.

Эта статья призвана повысить уровень информированности разработчиков. В ней рассказывается о наиболее распространенных уязвимостях 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-приложений, в том числе мобильных. Многие организации основное внимание уделяют реализации функциональности. Однако учтите, что устранение уязвимостей в системе безопасности стоит недешево. Поэтому разумно включить анализ и тестирование системы безопасности в состав процесса разработки.

Защита наиболее эффективна, когда она полностью интегрирована в процесс разработки - от проектирования до развертывания.

Этап проектирования

При проектировании необходимо идентифицировать защищаемую информацию, возможные риски и доступные контрмеры. По возможности приглашайте экспертов по системам безопасности для обсуждения и принятия решений на самых ранних этапах. Это снизит вероятность обнаружения уязвимостей на более поздних этапах цикла разработки. Позднее обнаружение приводит к неоптимальным и недешевым решениям по модернизации. Создавайте практические сценарии для тестирования на этапе проектирования. Это поможет организовать интегрированный процесс тестирования по всему циклу разработки. Пошаговое тестирование системы безопасности (например, тестирование возможности несанкционированного доступа) на этапе развертывания помогает организации накопить навыки, обеспечивающие разработку хороших приложений.
 

Этап разработки

Проинформируйте разработчиков о наиболее распространенных уязвимостях и обучите их передовым методикам написания защищенного кода. При проверке кода особое внимание уделите проблемам безопасности, привлекая профессионалов в этой области. Выполните тесты системы безопасности, проанализируйте их и включите в наборы автоматизированных тестов. Запланируйте время на устранение проблем в системе безопасности, обнаруженных при проверке и тестировании кода.
 

Этап развертывания

Тщательно протестируйте готовое приложение на этапе опытной эксплуатации. Данный этап тестирования может включать в себя анализ возможности несанкционированного доступа к приложению, выполняемый группой сторонних разработчиков или автоматизированными средствами сканирования системы безопасности. Критерии для окончательного утверждения обычно диктует практика ИТ-руководства.
 

Этап управления

После развертывания периодически наблюдайте за приложением и его окружением с целью обнаружения атак и уязвимостей, используя средства сканирования, тестирование возможности несанкционированного доступа и аудит файлов журналов. Создайте четкий процесс безопасного изменения среды и применения пакетов исправления ошибок для приложения.
 

Автоматизация тестирования системы безопасности в процессе разработки

На практике автоматизация является ключевым аспектом создания повторяемого и целостного процесса тестирования системы безопасности на протяжении цикла разработки. Продукты IBM Rational AppScan предоставляют средства, которые могут сканировать код, помогая разработчикам обнаружить уязвимости. Автоматизированные средства сканирования можно повторно использовать после разработки для мониторинга развернутых приложений. Это позволит продолжить мониторинг развернутых Web-приложений и обнаружить уязвимости системы безопасности, появившиеся в результате изменений приложения или инфраструктуры.

Семейство продуктов Rational AppScan обеспечивает автоматизацию этой деятельности на этапах разработки и развертывания.

Этап разработки

• Rational AppScan Source Edition. Данная программа предоставляет анализ кода методом "белого ящика", помогая разработчикам приложений идентифицировать проблемы на самых ранних стадиях разработки. Также она предоставляет разработчикам информацию о возможных уязвимостях и советы по их устранению.
• Rational AppScan Tester Edition. Для отделов обеспечения качества данная программа является инструментом автоматизации и интеграции тестирования системы безопасности в процесс обеспечения качества. Тестировщики могут добавить ее в свои среды тестирования, чтобы интегрировать тестирование системы безопасности в процесс тестирования функциональности и производительности.
• Rational AppScan Build Edition. Эта версия поддерживает интеграцию сканирования системы безопасности в процессе компоновки. Она интегрируется с системами управления компоновками (например, Rational Build Forge), а также направляет разработчикам отчеты посредством ПО по управлению дефектами (например, Rational Clear Quest).

Этап развертывания

• Rational AppScan Standard Edition. Это приложение помогает тестировщикам системы безопасности, выполняя тестирование развернутого приложения методом "черного ящика". Тестировщик указывает URL существующего приложения (желательно опытного экземпляра), а программа исследует приложение и сканирует на известные уязвимости. В результате создается список расставленных согласно приоритетам уязвимостей вместе с подробной информацией по каждой из них и возможными мерами по устранению. Поддерживается создание специализированных отчетов, направляемых группам разработки и управления.
• Rational AppScan Enterprise Edition. Это многопользовательское Web-приложение, предназначенное для централизованного сканирования приложений по всему предприятию. Аналогично Rational AppScan Standard Edition, оно сканирует существующие приложения и генерирует отчеты со списками уязвимостей и задачами по их устранению. Приложение позволяет назначать ответственных за устранение проблем.

Ссылки на дополнительную информацию по продуктам семейства Rational AppScan приведены в разделе Ресурсы; там же размещена ссылка на руководство IBM Red guide, в котором описывается автоматизация и интеграция обеспечения безопасности в процесс разработки при помощи продуктов семейства Rational AppScan.

Уникальные проблемы доступа к Web-приложениям с мобильных устройств

Многие риски для приложений и устройств являются продолжением уязвимостей настольных приложений. Рассмотрение современной практики идентификации и управления доступом выходит за рамки данной статьи, но обычно руководство Web-приложениями охватывает следующие области:

• Сканирование приложений на известные уязвимости.
• Управление доступом.
• Идентификация и аутентификация пользователей.
• Идентификация конечных точек и управление ими.
• Вредоносное ПО.

В документе IBM® Redbooks® (см. раздел Ресурсы) приведена дополнительная информация о том, как семейство продуктов IBM способствует интеграции системы безопасности. Дополнительную информацию о семействе продуктов IBM Tivoli можно найти на Web-странице IBM Web Application Security Solutions.

Мобильные устройства представляют собой дополнительный источник проблем, поскольку по своей природе являются персонализированными и переносимыми. Мобильные устройства легко потерять. Смартфон, выскользнувший из кармана в такси или самолете - весьма распространенный сценарий. Кроме того, по причине своего маленького размера смартфоны являются объектами краж. Поэтому к Web-приложениям, доступным с мобильных устройств, должны применяться дополнительные меры безопасности.

Такими дополнительными мерами корпоративного руководства при развертывании мобильных устройств могут быть:

• Многофакторная аутентификация. Скомбинируйте два метода аутентификации, например, пароль и считыватель отпечатков пальцев (если он есть в устройстве).
• Детализированное управление доступом. Пользователи должен иметь доступ только к тем ресурсам, которые нужны им для работы, но не больше. Любой механизм управления доступом должен быть как можно более детализированным.
• Ограничение доступа. Предоставляйте доступ к интранет-ресурсам из Интернета с использование виртуальных частных сетей (VPN).
• Шифрование данных. Согласуйте возможности устройства с требованиями к конфиденциальным данным.
• Управление. Если разрешен доступ к конфиденциальной информации, для украденных и (или) потерянных телефонов желательно предусмотреть безопасное стирание такой информации.

Заключение

У Web 2.0-приложений, предназначенных для настольных и мобильных устройств, есть много общих проблем безопасности и, следовательно, много одинаковых способов их решения. Разработчики должны знать о наиболее распространенных уязвимостях и бороться с ними на протяжении всего цикла разработки. Для обеспечения безопасности приложения также необходимо постоянное автоматическое сканирование на наличие уязвимостей в процессе разработки и развертывания. Мобильные устройства имеют свой собственный уникальный набор проблем, поскольку по своей природе являются персонализированными и переносимыми. Заранее, еще до развертывания мобильных решений, продумайте защиту данных при краже или потере устройства.

Ресурсы

• Оригинал статьи: Web 2.0 desktop and mobile application security design (EN).
• Просмотрите страницу developerWorks AppScan и страницу линейки продуктов AppScan, чтобы подобрать наиболее подходящие для вас редакции.
• Поработайте с Web-сайтом Altoro Mutual, демонстрирующим возможности программы Rational® AppScan Standard Edition по сканированию приложений на наличие уязвимостей.
• Совершенствование системы безопасности цикла разработки Web-приложений (EN).
• Использование IBM Rational AppScan (EN), формат PDF (IBM® Redguide®, 2009 год).
• Архитектура решений IBM по системе безопасности для сетей, серверов и конечных точек (EN), формат PDF (IBM Redbooks, февраль 2011 года).
• IBM Rational AppScan: межсайтовые скрипты (EN). Амит Клайн (Amit Klein) (developerWorks, март 2008 года).
• Web-страница IBM Web Application Security Solutions.
• Просмотрите следующие страницы Web-сайта Open Web Application Security Project (OWASP):
• Проект Top 10 содержит список наиболее распространенных уязвимостей, используемых злоумышленниками в настоящее время.
• Страница Web-сайта OWASP по межсайтовым скриптам (XSS).
• Страница Web-сайта OWASP по внедрению SQL-кода.
• Страница Web-сайта OWASP по утечке информации.
• Страница Web-сайта OWASP по модификации Web-параметров.
• Страница Web-сайта OWASP для непроверенных уязвимостей.