10 рисков для безопасности вашего приложения


Оглавление (нажмите, чтобы открыть):

10 рисков для безопасности вашего приложения

Ниже приводится перечень некоторых известных методов и продуктов для управления рисками информационной безопасности.

Классика жанра

Американский стандарт де-факто

Software Engineering Institute Carnegie Mellon University

Одна из наиболее популярных открытых методологий

Central Computer and Telecommunications Agency (UK), Insight Consulting (Siemens)

Британскийстандартде-факто. ПО уже не поддерживается.

RA2 art of risk

AEXIS Security Consultants совместнос
XiSEC Consultants Ltd

Разработчики ISO 27001 при помощи данного продукта иллюстрируют подход к оценке рисков ИБ, заложенный в стандарте. ПО уже не поддерживается.

Отечественные разработки

Digital Security Office

Наиболее раскрученная отечественная разработка

Институт системного анализа РАН

Концептуальная разработка, применявшаяся в ЦБ РФ

Относительно новые

Microsoft Security Assessment Tool

IT Governance совместносVigilant Software

Новая разработка для оценки рисков по ISO 27001

Высокоуровневое управление риском, соответствием и стратегическое планирование

Citicus ONE vR3.2

Для небольших организаций

Lightwave Security SecureAware v3.7.2

Для средних организаций и для более требовательных организаций

Мощная и дорогая система для управления ИБ

Для крупных и наиболее требовательных организаций

Оперативное управления рисками, связанными с техническими уязвимостями (подход «снизу вверх»)

Secure Win Auditor v2.0

Недорогое средство анализа защищенности и оценки соответствия для небольших Windows-сетей

IT GRC Solution v6.0 и

Мощное и дорогое средство для оперативного управления уязвимостями, рисками и соответствием для крупных организаций

Мощное и дорогое средство для оперативного управления уязвимостями, рисками и соответствием для крупных организаций

Total Protection for Compliance v6.8

Можно рекомендовать только тем, кто строит всю систему защиты корпоративной сети на продуктах McAfee

Skybox 4000 v1.0

Хорошее соотношение цена/возможности

Network Advisor v4.1 & Vulnerability Advisor v4.1

Дорогой, но удобный продукт, особенно в форме эпплайенса

Устаревшие

Callio Secura 17799

Уже не поддерживается. Предназначался для автоматизации всех задач по внедрению СУИБ

Безопасность мобильных банковских приложений

Безопасность мобильных банковских приложений

Безопасность мобильных банковских приложений

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

Основные результаты исследования

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

Так, 35% мобильных банков для iOS и 15% мобильных банков для Android содержат уязвимости, связанные с некорректной работой SSL, а это означает возможность перехвата критичных платежных данных с помощью атаки «человек посередине». 22% приложений для iOS потенциально уязвимы к SQL-инъекции, что создает риск кражи всей информации о платежах с помощью нескольких несложных запросов. 70% приложений для iOS и 20% приложений для Android потенциально уязвимы к XSS — одной из самых популярных атак, позволяющей ввести в заблуждение пользователя мобильного банк-клиента и таким образом, например, украсть его аутентификационные данные. 45% приложений для iOS потенциально уязвимы к ХХЕ-атакам, особенно опасным для устройств, подвергнутым столь популярной в России операции jailbreak. Около 22% приложений для Android неправильно используют механизмы межпроцессного взаимодействия, тем самым фактически позволяя сторонним приложениям обращаться к критичным банковским данным.

Мобильный мир


Популярные мобильные ОС
Почему изучались именно эти операционные системы? ОС Android и iOS наиболее распространены на сегодняшний день и имеют наибольшее количество мобильных банковских приложений в своих магазинах (Google Play и Арр Store соответственно).

ОС Windows Phone достаточно молода и еще не так распространена среди пользователей, но уже сейчас имеет в своем магазине (Windows Store) небольшое количество мобильных банковских приложений. В данное исследование приложения для ОС Windows Phone не включены из-за их малого количества на данный момент (в Windows Store их всего 9). Но с учетом появления Windows Phone 8, содержащей новую модель разработки, позволяющую (благодаря легкому портированию) одновременно разрабатывать приложения для обычной ОС Windows 8 и мобильной, можно ожидать роста популярности разработки под Windows Phone 8.

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

По месту расположения приложения:

  • SIM-приложения — приложение на SIM-карте, написанное в соответствии со стандартом SIM Application Toolkit (STK);
  • Web-приложения — специальная версия Web-сайта;
  • мобильные приложения — приложения, разработанные для определенной мобильной ОС с использованием специализированного API, устанавливаемого в смартфон.

По типу используемой технологии взаимодействия с сервером:

  • сетевые приложения — используют собственный протокол общения поверх TCP/IP, например HTTP;
  • SMS-приложения — приложения на основе SMS (Short Messaging Service).
  • Приложение обменивается с сервером информацией с помощью коротких текстовых сообщений;
  • USSD-приложения — приложения на основе USSD (Unstructured Supplementary Service Data). Сервис основывается на передаче коротких сообщений, схожих с SMS, но имеет ряд отличий;
  • IVR-приложения — приложения, базирующиеся на технологии IVR (Interactive Voice Response). Система основана на заранее записанных голосовых сообщениях и тональном наборе.

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

Типы приложений для мобильного банкинга
К категории «без доступа к счету» относятся такие программы, которые выполняют лишь вспомогательную работу. Эти функции могут присутствовать и в приложениях, у которых есть возможность работать со счетом. Часто мобильное приложение эволюционирует из простого навигационного приложения в приложение с возможностью работы со счетом. Некоторые банки, наоборот, предпочитают разносить эти функции на несколько приложений, что, с нашей точки зрения, правильно: если критичное приложение (производящее платежные операции) не перегружается лишним функционалом, количество векторов атаки, доступных злоумышленнику, уменьшается. В данном исследовании изучались приложения с доступом к счету.

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

Методы оценки безопасности клиентского приложения:

  1. Динамический анализ:
    • отладка запущенного приложения (на эмуляторе или устройстве);
    • фаззинг;
    • анализ сетевого трафика;
    • анализ взаимодействия с файловой системой;
    • анализ памяти приложения.
  2. Статический анализ: анализ исходного кода (если доступен);
    • обратное проектирование (Reverse Engineering);
    • дизассемблирование;
    • декомпиляция;
    • анализ полученного представления на слабые участки кода.

Модели нарушителя
1. Злоумышленник, имеющий физический доступ к устройству клиента. При этом на устройстве не включена блокировка экрана и не используется шифрование.

2. Злоумышленник, не имеющий доступа к устройству, находящийся рядом с жертвой и способный провести атаку типа «человек посередине».

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

Атаки на серверную часть ничем не отличаются от атак на обычные системы ДБО.

Атаки на клиентскую часть возможны при наличии:

  • физического доступа к устройству;
  • вредоносного приложения на устройстве;
  • возможности контролировать канал, например в результате атаки «человек посередине».

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

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

Для атаки через вредоносное приложение необходимо установить вредоносное приложение, используя методы социальной инженерии или через атаку Drive-by-Download.

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

Защита: обновлять ПО на устройстве, использовать программные средства защиты и повышать осведомленность пользователей в вопросах ИБ.

Атаки на канал связи: в ходе классической атаки «человек посередине» перехватываются данные между устройством клиента и сервером. Для этого необходимо находиться в одной сети с жертвой, например в публичной сети Wi-Fi, или использовать поддельные беспроводные точки доступа и поддельные базовые станции. Необходима уязвимость в мобильном приложении некорректная работа с шифрованием передаваемых данных или полное отсутствие шифрования данных. Самый распространенный пример — неправильная работа с SSL. В результате злоумышленник может прослушивать и подменять передаваемые данные, что может в итоге привести к краже денежных средств со счета клиента.

Защита: правильная реализация работы с SSL. Также рекомендуется в мобильном приложении при подключении к серверу доверять только SSL-сертификату банка. Это поможет в случае компрометации корневого центра сертификации.

Стоит также отметить, что jailbreak устройства (iOS) или наличие root-доступа на устройстве (Android) пользователя значительно снижает уровень защищенности устройства и упрощает атаку для злоумышленника.

Выводы

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

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

  1. Осведомлять программистов о вопросах безопасности.
  2. Закладывать безопасность в архитектуру.
  3. Проводить аудит кода.
  4. Проводить анализ защищенности приложения.
  5. Применять параметры компилятора, связанные с безопасностью.
  6. Контролировать распространение приложения в сети Интернет.
  7. Быстро закрывать уязвимости и выпускать обновления.

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

Перед началом исследования предполагалось, что количество специфичных уязвимостей для мобильной платформы будет значительно преобладать над количеством общеизвестных. Но в результате можно увидеть примерно одинаковое количество уязвимостей обоих классов. Это означает наличие возможности проведения хорошо известных атак и на мобильные банковские приложения без знания их специфики. Полученные результаты пересекаются с OWASP Тор 10 Mobile Risks.

У злоумышленников есть множество путей реализации атак. При этом затраты на проведение атаки могут в реальной среде быть весьма низкими по сравнению с возможной выгодой.

Современные средства защиты для мобильных устройств — антивирусы, MDM-решения и т.д. — могут сократить риск, но не решить весь спектр проблем. Безопасность должна внедряться еще на этапе проектирования системы и присутствовать на всех этапах жизненного цикла программы, включая этап разработки и внедрения. Необходимо осуществлять аудит кода, анализ защищенности приложения, тестирование на проникновение.

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

Риски безопасности 2015

Новые политики для снижения рисков

Уже который год подряд наибольшей проблемой для системы безопасности на предприятии является небрежность его сотрудников. Сегодня же ситуация осложняется тем, что сотрудники работают с многочисленными устройствами, да еще и используют коммерческие «облачные» приложения вне офиса. В отчете за 2015 год компании Ponemon Institute сообщается о том, что сегодня 73% респондентов применяют коммерческие «облачные» приложения, 69% используют собственные устройства на работе и 63% сотрудников работают вне офисов, и в частности дома. Но самое примечательное, что, как утверждают 68% опрошенных, ИТ-отделы компаний не поспевают за требованиями сотрудников в отношении большей поддержки мобильных устройств.

В этой ситуации мы можем выделить следующие риски:

1. Основной и, пожалуй, самый большой риск — это небрежные, недоученные сотрудники. Основная причина большинства происшествий в компаниях на сегодня — небрежные сотрудники, которые игнорируют политику безопасности. При этом надо учесть, что увеличивается число персональных устройств, применяемых в корпоративной среде и соединяемых с корпоративной сетью, возрастает степень использования сотрудниками коммерческих «облачных» приложений на рабочем месте, растет численность персонала и т. д.

2. Мобильные устройства становятся мишенью вредоносного программного обеспечения. Представители 71% опрошенных предприятий заявили, что защита конечных мобильных устройств стала гораздо сложнее. 75% респондентов (по сравнению с 68% в прошлом году) полагают, что за последние 12 месяцев мобильные устройства пользователей не раз становились мишенью атак вредоносного программного обеспечения.

3. С учетом растущего риска защита конечных устройств становится все более сложной. Это отметили 68% опрошенных.

4. Участились атаки вредоносного программного обеспечения на корпоративные сети. Более 80% респондентов утверждают, что выросло число атак, особенно целенаправленных высокотехнологичных атак и комплексов скрытого проникновения.

5. Определенные приложения увеличивают риски для ИТ-систем предприятия:

  • Adobe Acrobat, Flash Player, Reader — 62%;
  • Java Oracle JRE — 54%;
  • сторонние приложения, основанные на «облачных» технологиях.


6. Самый большой риск несет использование мобильных устройств. С умными телефонами сопряжен самый большой риск. Это отметили 80% респондентов. При этом 69% выделяют риски, связанные с уязвимыми местами сторонних приложений, 42% — с мобильными удаленными сотрудниками. Одновременно отмечается рост числа неоправданно беспечных сотрудников.

Вместе с тем, по данным отчета Cisco 2014 Annual Security Report, еще две современные тенденции способствуют усилиям злоумышленников. Во?первых, это широкое распространение мобильных платформ, а во?вторых, рост использования мобильных приложений. Особенно важно, что многие пользователи устанавливают мобильные приложения, совершенно не задумываясь о безопасности. Мало того, тенденция применения собственных устройств сотрудников только усложняет все меры защиты. Ведь очень нелегко управлять всем этим «зоопарком» оборудования, особенно в условиях ограниченного бюджета.

Мобильность предполагает возникновение новых путей к данным, которые в свою очередь открывают все новые угрозы. Беспроводные каналы создают вероятность «прослушки» и получения доступа к данным. Соответственно мобильность порождает для организаций целый ряд проблем, связанных с безопасностью, включая угрозы потери интеллектуальной собственности и уязвимых данных, особенно если устройство сотрудника утеряно или украдено и при этом не было защищено.

7. Беспечность сотрудников. Согласно исследованию за 2014 год, проведенному «Лабораторией Касперского» совместно с B2B International, сотрудники российских компаний, использующие для работы смартфоны, стали менее оперативно сообщать о потере своих устройств. Лишь немногим больше половины служащих, а именно 56%, заявляют об этом в день пропажи — для сравнения, в 2013 году этот показатель составлял почти 70%.

Примечательно, что почти в четыре раза выросла доля тех, кто уведомляет отдел безопасности своей компании только через 3-5 дней после утраты смартфона: в 2014 году так поступили 11% опрошенных. При этом очевидна закономерность: чем меньше организация, тем спокойнее ее сотрудники относятся к инциденту. В очень маленьких компаниях о пропаже оперативно сообщают 44% работников, а в крупных корпорациях — 63%.

В том же опросе отмечается, что в 35% российских компаний мобильные устройства используются для передачи конфиденциальных данных — с большой долей вероятности часть этих данных остается на смартфонах. И хотя представители более половины организаций уверены, что передача такой информации с мобильных устройств менее безопасна по сравнению с рабочими станциями, прогрессирующая безответственность их сотрудников говорит о недостаточных просветительских мерах внутри компаний.

Ситуация на сегодня

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

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

Jailbreaking (или джейлбрейк, от англ. jailbreak — «побег из тюрьмы») iPhone/iPod Touch/iPad/ — официально не поддерживаемая корпорацией Apple операция, которая позволяет получить доступ к файловой системе устройств iPhone, iPod или iPad. Это позволяет расширить функциональность аппарата, например сделать возможными поддержку тем оформления и установку приложений из независимых источников (не из магазина App Store). Джейлбрейк открывает полный доступ к файловой системе iPhone, iPod или iPad. При этом лицензионное соглашение нарушается, и владелец устройства Apple лишается права на техническую поддержку и гарантийные обязательства.

Наверняка в вашей компании есть сотрудники, которые требуют для себя самых современных технологий. При этом они могут быть достаточно опытными и умеют самостоятельно настраивать свои устройства, получая полный доступ к ним на уровне системы.

Jailbreaking снимает ограничения, наложенные производителем оборудования. При этом очень часто устраняются ограничения, разработанные для повышения безопасности, а между тем владелец получает полномочия на уровне администратора устройства. Он вправе установить и запустить приложения, которые могли быть потенциально опасными. Не стоит забывать, что jailbreaking привносит как преимущества, так и риски. Начнем с положительного влияния.

• Компенсация неудобств, связанных с политикой Apple, таких как:

  • отсутствие ряда стандартных для коммуникаторов функций (например доступа к файловой системе со стороны пользователя) или других приложений;
  • отсутствие возможности воспроизведения контента с внешнего диска (USB-накопителя, карты памяти) без необходимости избыточного копирования на устройство;
  • отсутствие возможности создания «черного списка» абонентов (до iOS 7);
  • невозможность установить свой файл в качестве мелодии звонка;
  • привязка к App Store;
  • невозможность использования сторонних источников приложений;
  • негибкие возможности настройки интерфейса.

Теперь перечислим риски.

• Программное обеспечение, доступное в магазине Cydia, в отличие от App Store, не проверяется на надежность и безопасность и может нанести ущерб данным на устройстве или стать причиной их кражи.

• Не стоит забывать о том, что вредоносные программы, выполняемые на аппаратах с jailbreaking, также будут выполняться с правами администратора. К чему это приведет, надеюсь, пояснять не нужно.

Рутинг (англ. rooting) — процесс получения прав суперпользователя root на устройствах под управлением операционной системы Android. Основными целями рутинга являются снятие ограничений производителя либо оператора связи, управление системными приложениями и возможность запуска приложений, требующих прав администратора. Устройство, прошедшее процесс рутинга, называют рутованным. Аналогичный процесс для устройств на базе Apple iOS называется jailbreak, а для устройств на базе Windows Phone — HardSPL.

Все приложения Android исполняются в изолированной среде и обычно не имеют доступа к другим компонентам платформы и их данным. Разделы, содержащие системные файлы, монтируются в режиме «только для чтения». Эти ограничения призваны защитить систему от вредоносных программ и потенциально опасной модификации системных настроек, а также предотвратить незаконное копирование платных приложений.

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

Преимущества:

  • Ограничение интернет-трафика в мобильных сетях и соответственно экономия средств.
  • Блокирование рекламы, а значит, снижение трафика и экономия.
  • Контроль действий приложений, например блокирование звонков и отправки SMS на платные номера для вредоносных программ.
  • Установка системных приложений, которым необходимы права root, например драйверы и эмуляторы.
  • Замена и удаление стандартных программ.
  • Перенос данных и создание резервных копий приложений.

Недостатки:

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

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

Уязвимое программное обеспечение. Нередко сотрудники могут использовать корпоративные данные на своем устройстве, но вместе с тем не в состоянии обновить на нем программное обеспечение. Как правило, процесс обновления программного обеспечения представляет большую проблему для пользователей мобильных устройств. Если Apple и Microsoft регулярно предоставляют обновления программного обеспечения своим пользователям (как iPhone, iPad, так и Windows Phone), то пользователям Android можно посочувствовать. Обновление устройств под управлением Android от Google гораздо больше зависит от поставщика услуг и производителя оборудования, и иногда в них остаются известные уязвимости, доступные атакующим в течение длительного времени.

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

Точки доступа. Некоторые устройства сотрудников (например, под управлением Windows Phone 8.1) настроены таким образом, чтобы идентифицировать и попытаться соединиться с любой открытой точкой доступа для получения данных из Интернета. В то время как большинство компаний предоставляет безопасные точки доступа гостям, открывая беспроводные точки в некоторых отелях и других местах, владельцы таких устройств могут подвергнуться опасности атак «человек посередине» и других, которые позволяют злоумышленнику наблюдать за их действиями. Чтобы снизить уровень таких угроз, организации должны использовать в своих интересах технологию VPN при получении доступа к корпоративным ресурсам.

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

Бесплатные рекламные и шпионские программы. Бесплатные мобильные приложения собирают много данных о владельце устройства, чтобы продавать данные рекламным сетям. Мобильное приложение считается бесплатным программным обеспечением с размещенной в нем рекламой или шпионским программным обеспечением в случае, если оно собирает данные, не запрашивая разрешения владельца. Некоторые приложения устанавливают управляемые поисковые системы на устройство, чтобы отправлять пользователя на сайты рекламодателей.

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

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

Хотя многие владельцы смартфонов знают, что приложения иногда делятся приватной информацией с «третьей стороной», мало кто догадывается, насколько интенсивно происходит такой обмен. Устанавливая то или иное приложение, пользователи редко обращают внимание на то, какое приложение и куда требует доступ. Вспомним нашумевшую в свое время игру Angry Birds. А знаете ли вы, что эта игра весьма активно использовала данные о вашем местонахождении? Даже в то время, когда вы не использовали ее. А теперь вопрос: зачем? Более того, установить эту игру без предоставления доступа к данным геолокации было просто невозможно.

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

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

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

В исследуемой группе две дюжины пользователей Android, видевших, какие приложения и как часто получали доступ к данным, могли изменить соответствующие настройки для обеспечения конфиденциальности. В частности, за 14 дней десять приложений совместно задействовали данные геолокации 5398 раз. Такие данные используются для того, чтобы соответствующие приложения могли «угадать» желания владельца устройства, например показать целевую рекламу или ответить на вопрос, какой будет погода на следующий день.

Большинство владельцев смартфонов ничего не знают о поведении приложений. Однако, если такая информация у них появляется, они действуют достаточно быстро, изменяя настройки конфиденциальности. Так, после того как в ходе исследования люди узнавали, насколько часто используются их данные геолокации, большинство (58%) предприняло шаги для улучшения защиты конфиденциальности, изменив настройки приложений. В ходе эксперимента пользователи пересматривали полномочия приложений 69 раз и заблокировали 122 дополнительных полномочия в 47 приложениях.

К сожалению, программное обеспечение AppOps, предназначенное для отслеживания полномочий приложений, не работает на версиях Android выше 4.3, в то время как в iPhone предусмотрен «менеджер конфиденциальности».

«Облачные» хранилища. Dropbox, iCloud, OneDrive и другие «облачные» хранилища, предлагаемые пользователям мобильных платформ, могут использоваться для хищения данных. Сотрудники могут задействовать эти «облачные» хранилища, чтобы копировать туда конфиденциальные данные, если организации не в состоянии запретить их копирование или не используют механизм, ограничивающий использование мобильных «облачных» хранилищ.

Вредоносные программы Android. В последнее время наблюдается взрывоопасный рост вредоносов для мобильных устройств под управлением Android. Это обусловлено не только тем, что таких устройств используется больше всего, но и внушающим опасения увеличением числа уязвимостей в устройствах под управлением данной операционной системы.

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

Таким образом, в дальнейшем мы с вами будем наблюдать рост мобильных угроз, и компаниям стоит задуматься о необходимости скорейшего создания систем защиты от них.

Поделитесь материалом с коллегами и друзьями

Статьи

Общий обзор классификаций угроз безопасности: OWASP, CWE, CAPEC, WASC


Содержание:

Мировой опыт

Прежде всего необходимо пояснить важное отличие реестра или перечня от классификации. К классификации предъявляются достаточно строгие требования:

  • классы не должны пересекаться;
  • объединение всех классов должно быть полным, т. е. покрывать все классифицируемые объекты;
  • процедура классификации должна быть понятной, повторяемой и непротиворечивой, то есть вне зависимости от того, кто пытается вычислить класс объекта, результат всегда будет один и тот же;
  • классификация должна быть полезной: к примеру, легко разбить множество объектов на две группы по какому-либо признаку, что формально будет являться классификацией, однако такой подход вряд ли будет востребован;
  • наконец, классификация должна стать принятой в сообществе; данный критерий является следствием предыдущих – без выполнения какого-либо из перечисленных выше пунктов у классификации мало шансов быть адаптированной специалистами.

В данной статье будут рассматриваться следующие перечни и классификации:

  • OWASP – перечень наиболее опасных рисков информационной безопасности для веб-приложений по мнению экспертного сообщества;
  • CWE – классификация уязвимостей и недостатков программного обеспечения (не обязательно в веб-приложениях);
  • CAPEC – классификация шаблонов компьютерных атак;
  • WASC – классификация угроз безопасности веб-приложений.

OWASP Top 10

OWASP (Open Web Application Security Project) – это некоммерческая организация, целью которой является повышение осведомленности всех специалистов отрасли информационной безопасности в вопросах разработки, эксплуатации и защиты веб-приложений. OWASP Top 10 является одним из наиболее известных проектов организации. OWASP Top 10 — это рейтинг из десяти наиболее опасных рисков информационной безопасности для веб-приложений, составленный сообществом экспертов отрасли. Для каждого пункта рейтинга риск посчитан экспертами на основе методики OWASP Risk Rating Methodology и включает оценку по следующим критериям: распространенности соответствующих уязвимостей в приложениях (Weakness Prevalence), сложности их обнаружения (Weakness Detectability) и эксплуатации (Exploitability), а также критичности последствий их эксплуатации (Technical Impacts). По понятным причинам в расчетах критичности рисков не учитываются бизнес-последствия от их реализации. Там, где это возможно, названия рисков в рейтинге соотносятся с названиями соответствующих уязвимостей в классификации CWE (Common Weakness Enumeration). Следует отметить, что в отличие от классификаций, проект OWASP Top 10 не претендует на охват всех имеющихся рисков, а лишь представляет самые актуальные из них на момент выпуска рейтинга.

Первая версия рейтинга OWASP Top 10 появилась в 2004 году, и с тех пор документ обновляется каждые три-четыре года. Обновленные версии публиковались в 2007, 2010, 2013 и 2020 годах.

Последняя версия рейтинга, опубликованная в 2020 году, содержит следующие риски:

  • A1 – Внедрение кода (Injection).
  • A2 – Некорректная аутентификация (Broken Authentication).
  • A3 – Утечка чувствительных данных (Sensitive Data Exposure).
  • A4 – Внедрение внешних XML-сущностей (XXE – XML External Entities).
  • A5 – Нарушение контроля доступа (Broken Access Control).
  • A6 – Небезопасная конфигурация (Security Misconfiguration).
  • A7 – Межсайтовый скриптинг (XSS – Cross-Site Scripting).
  • A8 – Небезопасная десериализация (Insecure Deserialization).
  • A9 – Использование компонентов с известными уязвимостями (Using Components with Known Vulnerabilities).
  • A10 – Отсутствие журналирования и мониторинга (Insufficient Logging & Monitoring).

На схеме отражены отличия текущей версии от предыдущей:

Для каждого пункта в OWASP Top 10 представлена общая информация, описание, рекомендации по предотвращению, примеры соответствующих атак и полезные ссылки.

Рейтинг OWASP Top 10 составляется на основе данных, предоставляемых сообществом экспертов отрасли информационной безопасности. В 2020 году рейтинг был обновлен на основе данных, собранных из отчетов 23 компаний, специализирующихся в сфере безопасности веб-приложений, в которых было проанализировано свыше 114 тысяч веб-приложений. В предоставленных данных присутствовали результаты как автоматического, так и ручного анализа, однако автоматический преобладал. При этом данные по 68% от общего числа приложений были предоставлены компанией Veracode, занимающейся автоматическим анализом (статическим и динамическим).

Для оценки рисков использовались две группы факторов: факторы, влияющие на возможности атакующего по обнаружению и эксплуатации уязвимостей, а также факторы, влияющие на критичность последствий эксплуатации уязвимостей. В первую группу входят распространенность (prevalence), сложность обнаружения (detectability) и простота эксплуатации (ease of exploit). Ко второй группе относятся последствия эксплуатации уязвимости (technical impact). Некоторые важные факторы, например, такие как последствия эксплуатации уязвимости для бизнеса (business impact), модели злоумышленников, технические особенности невозможно проанализировать для всех веб-приложений в целом без учета специфики конкретного веб-приложения, поэтому они не рассматривались. Вероятностные характеристики выявлялись на основе предоставленных данных, а возможные последствия оценивались сообществом экспертов. Каждый фактор для конкретной уязвимости получал оценку от 1 до 3, и для получения общей оценки риска среднее арифметическое первой группы факторов умножалось на среднее арифметической второй группы факторов.

Надо отметить, что данный подход к формированию рейтинга и тот факт, что OWASP – компания некоммерческая, все-таки не исключают возможность вмешательства коммерческих интересов. Например, выход в свет OWASP Top 10 2020 RC (предварительная версия рейтинга 2020 года) сопровождался волной возмущения по поводу нового пункта A7 – Недостаточная защита от атак (Insufficient Attack Protection). Спорный пункт был предложен компанией Contrast Security. Один из руководителей этой компании был активным участником проекта OWASP Top 10, что, вероятно, сыграло основную роль в появлении этого «риска» в рейтинге. Даже не дожидаясь выхода окончательной версии рейтинга, Contrast Security начала ссылаться на пункт A7 у себя на сайте, рекламируя свою программу для защиты веб-приложений. В итоговом рейтинге этот пункт был исключен.

OWASP Top 10 используется в Microsoft, PCI DSS (Payment Card Industry Data Security Standard), MITRE (некоммерческая организация, занимающаяся разработками и исследованиями в области системной инженерии при поддержке органов государственной власти США) и множестве других организаций, связанных с безопасностью веб-приложений. Некоторые позиционируют OWASP Top 10 как «лучшую практику защиты веб-приложений», однако такая позиция не совсем верна. Во-первых, рейтинг не покрывает все возможные уязвимости и поэтому не является достаточным источником для полной защиты веб-приложения. Даже в самом документе OWASP, описывающем Top 10, есть призыв: «Не останавливайтесь на 10». Во-вторых, нужно помнить про его ограничения и недостатки: довольно большой период между обновлениями, неуточненная предметная область (для тех приложений, которые используют только новые фреймворки, большая часть рейтинга может быть неактуальна), неполные исходные данные (в основном — полученные компаниями на основе автоматических тестирований).

В настоящее время упоминание OWASP Top 10 часто является скорее маркетинговым ходом, чем реальной гарантией качественной защиты веб-приложений. С другой стороны, этот рейтинг хорош для отсылок благодаря своей широкой известности, может использоваться как стартовая точка и для привлечения внимания к обеспечению безопасности веб-приложений.

С 2011 года OWASP выпускает рейтинг Top 10 Mobile Risks, который обновлялся в 2014 и 2020 годах. В него входят следующие риски:

  • M1 – Обход ограничений безопасности платформы (Improper Platform Usage).
  • M2 – Небезопасное хранение данных (Insecure Data Storage).
  • M3 – Небезопасная передача данных (Insecure Communication).
  • M4 – Небезопасная аутентификация (Insecure Authentication).
  • M5 – Слабая криптостойкость (Insufficient Cryptography).
  • M6 – Небезопасная авторизация (Insecure Authorization).
  • M7 – Низкое качество кода в клиентской части приложения (Poor Code Quality).
  • M8 – Модификация кода (Code Tampering).
  • M9 – Анализ исходного кода (Reverse Engineering).
  • M10 – Скрытый функционал (Extraneous Functionality).

Некоторые формулировки в этом списке вызывают недоумение своей неконкретностью. Например, M8 и M9. Почти любое мобильное приложение может быть с тем или иным успехом подвергнуто анализу исходного хода (reverse engineering); почти любое мобильное приложение запускается в окружении, которое автор приложения не контролирует, и поэтому потенциально подвержено модификации кода (code tampering). Эти пункты сложно соотнести с конкретными уязвимостями, а как риски они теряют свою ценность, не будучи проанализированы для конкретного приложения с его спецификой и бизнес-логикой.

Несколько лет назад на стадии разработки находился еще один проект — OWASP Cloud Top 10 Security Risks, однако последняя активность в рамках этого проекта наблюдалась в 2012 году, и в настоящее время он переведен в статус неактивных проектов.

Классификация недостатков CWE

CWE (Common Weakness Enumeration) — общий перечень уязвимостей и недостатков безопасности программного обеспечения (ПО), представляет собой иерархический словарь, предназначенный для разработчиков и специалистов по обеспечению безопасности ПО. CWE поддерживается MITRE по заказу Министерства внутренней безопасности США и развивается при широкой поддержке сообщества экспертов. По словам разработчиков, CWE — это общий язык для описания недостатков безопасности ПО, который необходим для стандартизации методик оценки программных продуктов с точки зрения информационной безопасности.

Ошибки в программном обеспечении, которые могут быть непосредственно использованы злоумышленником для реализации угроз безопасности называют уязвимостями. Ошибки, которые могут привести к возникновению уязвимостей – недостатками безопасности. Примером, иллюстрирующим разницу между этими двумя понятиями, является уязвимость – СVE-2010-2245 (внедрение внешних XML-сущностей в веб-сервисе Apache версии ниже 1.1.1) и недостаток безопасности СWE-611 (неверное ограничение XML-ссылок на внешние объекты), послуживший причиной этой уязвимости. Главное отличие принципов, на которых строятся классификации недостатков от принципов классификации уязвимостей, состоит в том, что особенно важно сохранить связь между недостатками, ведь ошибки ведут к новым ошибкам, например, ошибки проектирования ведут к ошибкам в реализации. Такая связь в CWE воплощена через разные уровни абстракций и обширные иерархические представления, которые будут рассмотрены ниже.

Первая версия CWE 0.1 вышла в 2005 году и стала результатом продолжения работы MITRE над CVE. В настоящее время актуальна версия 3.0. В обновлении перечня участвует большое количество компаний и научных организаций. Обновление происходит посредством широкого обсуждения на официальном форуме и через почтовую рассылку. Важной особенностью CWE является строгая структурированность. Любое изменение – результат объемной работы сообщества, поэтому перечень обновляется относительно редко.

Для классификации недостатков используется многоуровневая структура, которая описывает древовидное устройство CWE: конечные недостатки объединяются в типы, типы – в категории, категории – в представления. Каждое представление – особый способ классификации записей CWE, предназначенный для упрощения решения конкретной задачи. В последней версии три основных представления:

  1. Концепции разработки – в этом представлении CWE недостатки безопасности классифицируются с использованием принципов и понятий, которые часто встречаются при разработке ПО; представление предназначено в первую очередь для разработчиков и специалистов по оценке качества ПО.
  2. Концепции архитектуры – для анализа качества архитектурных решений на этапе проектирования.
  3. Концепции исследований – представление, предназначенное для упрощения академических исследований. Отличается от первых двух высоким уровнем абстракций. Основное внимание в этом представлении уделено формальным понятиям поведения программного обеспечения, конкретные же примеры по возможности опускаются.

На схеме ниже приведен граф связей CWE-611 (XXE) в разных представлениях. Полные графы для всех представлений, можно увидеть на официальном сайте проекта (http://cwe.mitre.org/data/pdfs.html).

Кроме основных представлений поддерживается большое количество вспомогательных, например «Разработка на С++» или «Недостатки разработки мобильных приложений». Поскольку CWE претендует на то, чтобы быть наиболее общим перечнем недостатков безопасности, большое внимание при разработке словаря обращается на сопоставление записей CWE с записями других классификаций, перечней, рейтингов. Результатом этого сопоставления являются представления внешних отображений, например, SANS Top 25, OWASP Top 10, Seven Pernicious Kingdoms и т. д. Эти представления переносят структуру других рейтингов и классификаций на CWE для того, чтобы упростить их сравнение и работу с ними.

Запись о недостатке строго структурирована и содержит в себе следующую информацию:

  • Название.
  • Описание.
  • Другие названия.
  • Описание поведения.
  • Описание и вероятность возможной эксплуатации.
  • Описание возможных последствий эксплуатации.
  • Способы предотвращения.
  • Информация о связях с другими элементами CWE.
  • Источники.
  • Примеры кода для языков/архитектур.
  • Ссылки на актуальные CVE.

Таблица 1. Пример описания недостатка безопасности.

Продукт/Метод Разработчик Сайт Комментарий
CWE 445 Double free (повторное освобождение памяти)
Описание ПО вызывает free() дважды на одном адресе памяти, что потенциально может привести к непредсказуемому изменению структур, управляющих памятью.
Вероятность эксплуатации От низкой до средней.
Общие последствия Контроль доступа: двойное освобождение памяти может привести к условию write-what-where, позволяя злоумышленнику выполнить произвольный код.
Способы предотвращения Архитектура и дизайн: рекомендуется выбрать язык, обеспечивающий автоматическое управление памятью.
Способы предотвращения Архитектура и дизайн: рекомендуется выбрать язык, обеспечивающий автоматическое управление памятью.

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

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

Примеры Пример кода на языке С++:

char* ptr = (char*)malloc (SIZE);
.
if (abrt) <
free(ptr);

>
.
free(ptr);

Ссылки на актуальные CVE CVE-2002-0059
CVE-2003-0545
CVE-2003-1048
CVE-2004-0642
CVE-2004-0772
CVE-2005-1689
Информация о связях с другими элементами CWE Предшествующие:

CWE-666, СWE-675 в представлении CWE-1000
CWE-339 в представлении CWE-699
CWE-398 в представлении CWE-700
CWE-633 в представлении CWE-631
CWE-742 в представлении CWE-734

CWE-364, CWE- 416, CWE-123

Подверженные платформы C/C++
Источники PLOVER — DFREE — Double-Free Vulnerability7 Pernicious Kingdoms — Double Free
CLASP — Doubly freeing memory
CERT C Secure Coding — MEM00-C — Allocate and free memory in the same module, at the same level of abstraction
CERT C Secure Coding — MEM01-C — Store a new value in pointers immediately after free()
CERT C Secure Coding — MEM31-C — Free dynamically allocated memory exactly once
CERT C Secure Coding — MEM00-C — Allocate and free memory in the same module, at the same level of abstraction CERT C Secure Coding — MEM01-C — Store a new value in pointers immediately after free()
CERT C Secure Coding — MEM31-C — Free dynamically allocated memory exactly once

CWE используется многими инструментами статического анализа, оценки качества и безопасности программ, большая часть из таких инструментов зарегистрирована в MITRE как CWE-совместимые. Любой продукт перечисленных классов можно зарегистрировать как CWE-совместимый, для чего необходимо обеспечить соответствие первым четырем (из шести) требований CWE:

  1. Возможность поиска и группировки срабатываний средства по идентификаторам CWE.
  2. Срабатывания средства включают или позволяют получить соответствующие им элементы CWE.
  3. Срабатывания средства однозначно отображаются на элементы CWE.
  4. В документации средства и в описании срабатываний используются описания из CWE.
  5. В документации средства и в описании срабатываний явным образом перечислены идентификаторы из CWE.
  6. Результаты тестирования размещены на сайте CWE.

Если продукт соответствует всем шести требованиям он считается CWE-совместимым.

Классификация шаблонов компьютерных атак CAPEC


В ходе развития CWE, появилась еще одна классификация, схожая с CWE по структуре – CAPEC (Common Attack Pattern Enumeration and Classification). Объектом систематизации в ней являются шаблоны атак, то есть, описания общих элементов и методов, используемых при атаках на уязвимые компоненты. Расширение перечня происходит аналогично CWE через обсуждение на официальном форуме и почтовую рассылку.

В CAPEC используется сходный с CWE иерархический подход. Разработано два основных представления (механизмы атак и объекты атак) и несколько вспомогательных. В представлении «механизмы атак» шаблоны иерархически упорядочены в соответствии с механизмами, которые часто используются при эксплуатации уязвимостей. Категории, например «внедрение непредвиденных элементов», в этом представлении отражают различные методы, используемые для атаки на систему, но не отображают целей и последствий. В представлении «объекты атак» категории содержат описание компонентов, на которые производится атака, например «передача данных».

На схеме ниже приведен граф связей CAPEC-112 в разных представлениях.

Запись о шаблоне атак в CAPEC включает описание механизмов эксплуатации уязвимости, возможные последствия и методы противодействия. Кроме того, запись ссылается на используемые в шаблоне уязвимости в CVE и на приводящие к ним недостатки из CWE.

Таблица 2. Пример описания шаблона атаки.

CAPEC-34 HTTP Response Splitting
Название Разделение HTTP-ответов.
Критичность Высокая.
Описание Разделение HTTP-ответов приводит к тому, что уязвимый веб-сервер отвечает на вредоносный запрос, отправляя клиенту HTTP-ответ таким образом, что он интерпретируется в браузере как два отдельных ответа вместо одного. Это возможно, когда контролируемый пользователем ввод используется в составе заголовков ответов. Злоумышленник может заставить жертву интерпретировать введенный Заголовок как ответ на второй фиктивный запрос, в результате чего созданное содержимое будет отображаться клиентом и, возможно, кэшироваться на промежуточных прокси-серверах или самом клиенте. Чтобы добиться разделения HTTP-ответа на уязвимом веб-сервере, злоумышленник:

  1. Находит такие данные для ввода, которые приводят к произвольному внедрению HTTP-заголовка.
  2. Производит вредоносный ввод, состоящий из данных, необходимых для того, чтобы завершить исходный ответ (например, \r\n\r\n) и начать второй ответ с заголовками, контролируемыми злоумышленником.
  3. Вынуждает жертву отправить на уязвимый сервер два HTTP-запроса. Первый запрос состоит из вредоносного ввода, который будет использоваться как часть заголовков HTTP-ответов, а второй является фиктивным запросом, чтобы жертва интерпретировала вторую часть разделенного ответа как принадлежащую второму HTTP-запросу.
Необходимые предпосылки атаки Пользователь может контролировать входные данные, которые могут использоваться как часть HTTP-заголовка.

Возможность злоумышленника внедрять произвольные строки в HTTP-заголовок.

Недостаточные проверки входных данных.

Вероятность эксплуатации Средняя.
Метод атаки Внедрение, манипуляция протоколом.
Примеры сценария Уязвимость CVE-2006-0207.
Компетенции злоумышленника Высокие, злоумышленник должен иметь глубокое понимание протокола HTTP.
Необходимые злоумышленнику ресурсы Нет.
Признаки атаки Единственный признак – несколько ответов на один запрос в логах, однако это сложно заметить без анализатора журнала.
Способ предотвращения Чтобы избежать разделения HTTP-ответов, приложение не должно доверять вводу пользователя при формировании выходного потока ответов (заголовков или тела).

Разделение ответов происходит за счет внедрения последовательностей CR-LF и дополнительных заголовков. Все данные, поступающие от пользователя и используемые в качестве части заголовков HTTP-ответов, должны подвергаться строгой проверке (валидации).

Цель и последствия Исполнение несанкционированного кода или команд.

Вытекающие последствия – повышение привилегий.

Описание контекста Атаки разделения HTTP-ответа происходят там, где сценарий сервера внедряет управляемые пользователем данные в заголовки HTTP-ответа. Обычно это происходит, когда скрипт встраивает такие данные в URL-адрес перенаправления в ответ перенаправления (код статуса HTTP 3хх), или когда сценарий включает такие данные в cookie ответа.
Вектор атаки Управляемый пользователем ввод, который является частью выходных заголовков HTTP-ответов.
Атакующая строка Закодированный HTTP-заголовок и данные, разделенные соответствующими последовательностями CR-LF. Вводимые данные должны состоять из корректных HTTP-заголовков, а также скрипта (обычно JavaScript), который будет включен в текст HTML.
Зона активации Вызовы API в приложении, которые формируют выходные заголовки HTTP-ответов.
Связанные недостатки CWE-113, CWE-74, CWE-697, CWE-707, CWE-713.

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

Классификация угроз WASC Threat Classification

Рассматривая классификации угроз безопасности, нельзя не упомянуть проект WASC Threat Classification. WASC (The Web Application Security Consortium) — это некоммерческая организация, которая ранее активно занималась разработкой и продвижением стандартов безопасности приложений. В настоящий момент организация не проявляет активности. Некоторые члены WASC участвовали также и в разработке проектов OWASP.

В WASC Threat Classification (далее – TC) описываются недостатки и классы атак, которые могут привести к компрометации веб-приложения, его данных или пользователей. Первая версия классификации появилась в 2004 году, вторая — в 2010-м, и на данный момент она остается последней. Атаки и недостатки в проекте сформированы в два представления: первое — это обычное перечисление, а второе — это распределение по трем фазам разработки (проектирование, реализация, внедрение). Всего в перечнях описано 34 типа атаки и 15 типов недостатков. Для каждой сущности приводится описание, примеры и полезные ссылки.

Классификация разрабатывалась большой группой экспертов по веб-безопасности на добровольной основе: в разработке второй версии приняло участие более 50 экспертов. Обсуждение содержания проекта, все предложения и замечания обсуждались посредством почтовой рассылки. Так, каждый раздел составлялся и обсуждался неделями, обеспечивая итоговый консенсус среди участников проекта. Неясно как с методической точки зрения участниками обеспечивалась полнота и непротиворечивость разрабатываемой классификации, кроме как умозрительное экспертное согласие с разработанными документами. Архив email-переписки доступен на сайте по адресу http://lists.webappsec.org/mailman/listinfo/wasc-threat_lists.webappsec.org.

Интересная деталь: в материалах второй версии WASC TC упоминалось, что авторы предполагают отдохнуть несколько месяцев и продолжить работать над проектом в том же 2010 году. На сайте проекта даже существует раздел с планами на будущее, где среди прочего есть недостающие пункты, которые предлагается добавить в классификацию. К сожалению, по необнародованным причинам раздел после этого не обновлялся, а следующая версия классификации так и не вышла. Таким образом, данный проект не рассматривается как завершенный самими авторами.

В первую очередь WASC TC предлагается использовать как справочное руководство. Ссылки на эту классификацию встречаются в книгах, презентациях, отчетах, описаниях уязвимостей и т. п. Проект можно использовать в процессе оценки безопасности веб-приложения как контрольный список или план тестирования, а также как систему для сбора метрик обнаруживаемых в приложении недостатков и уязвимостей. Однако стоит учитывать, что область безопасности веб-приложений активно развивается, а WASC Threat Classification не обновлялся с 2010 года.

При сравнении WASC TC с CWE и CAPEC, другими известными перечнями недостатков и атак, можно отметить несколько основных отличий. Во-первых, CWE/CAPEC — это более общие и фундаментальные проекты, которые больше подходят для академических целей и формализации, в то время как WASC TC удобнее и проще для «повседневного» использования. Во-вторых, CWE/CAPEC охватывают не только веб-приложения. Наконец, эти проекты продолжают развиваться и обновляться, а WASC TC так и остался незавершенным.

Авторы:
Николай Калинин, разработчик систем безопасности, ООО «СолидСофт»,
Валерия Шерварлы, разработчик систем безопасности, ООО «СолидСофт»,
Андрей Петухов, м.н.с. кафедры информационной безопасности ВМК МГУ.

10 рисков для безопасности вашего приложения

Поехали!

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

    Вылетели из расписания и не успели выпустить приложение вовремя.

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

Решили добавить новые функции, но потеряли задачу и забыли это сделать.

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

Подвела третья сторона.

Не смогли вовремя подготовить нужные материалы: фотографии, тексты, переводы. Срок затянулся ещё больше.

Когда приложение все-таки выпустили, выяснилось, что оно плохо работает из-за багов.

Сделали приложение, а оно не прошло модерацию в сторах.

  • Государство подкинуло сюрприз на законодательном уровне.
  • Ситуация. Разработчики заложили на работу с важной функцией две недели. А производитель мобильных устройств критически обновил операционную систему. Важную функцию пришлось разрабатывать месяц. Или на согласование закладывали один день, а уходит не меньше недели.

    Как подстраховаться. Следите за ходом каждого этапа проекта, честно оценивайте сроки согласования.

    Если у приложения сложная логика, то график работы сложно рассчитать с большой точностью. Грамотные менеджеры сами будут регулярно рассказывать вам о ходе разработки, показывать промежуточные результаты. Если этого не происходит — уточняйте, всё ли идет по графику. Чем скорее узнаете о задержках, тем скорее сможете принять меры: сдвигать дедлайн или сокращать объем работ, чтобы успеть в срок.

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

    Ситуация. Сделали макет — экран приложения, который появляется после того, как покупатель оформил заказ. Впопыхах написали «Какой-то текст». Разработчики приняли это как задачу. Заказчик неприятно удивился, пришлось снова согласовывать подробности и переделывать.

    Как подстраховаться. Как написано на бумаге, так и будет реализовано. Поэтому установите правило: никаких общих формулировок. Уточняйте всё, что кажется непонятным или неточным.


    С разработчиками вы подпишете договор на разработку. Специалисты будут писать техническую документацию:

    • подробное техническое задание с указанием версий операционных систем;
    • дизайн экранов и карта переходов;
    • требования к API, полная документация с описанием рисков и возможных ошибок.

    Если вы в эти документах чего-то не понимаете — не пускайте на самотек. Требуйте понятных формулировок и внятной структуры. Через год после релиза приложения техническая документация будет единственным надежным источником сведений об этом проекте.

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

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

    Ситуация. В студии разработки уволился проджект-менеджер: назначили нового человека, и он решил продолжать работу не так, как раньше. Или ТЗ не было актуализировано. Или вы решили избавиться от какой-то функции, поменять уже согласованный дизайн.

    Как подстраховаться. Договоритесь сразу: согласовывать все изменения. Важные моменты сразу вносить в договор. Если изменения на договор не влияют, достаточно описать их в электронном письме. Так ни одно принятое решение не потеряется.

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

    Как подстраховаться. Убедитесь, что в договоре на разработку прописано, кто владеет готовым продуктом разработки. Оформите на себя или свою компанию доменное имя приложения и учетные записи в App Store и Google Play. Выделите место на серверах компании или в облачных папках для рабочих материалов по проекту.

    Безопасность банковских приложений: самые популярные уязвимости и атаки

    Поставщики

    Популярное

    Пластиковые карты, IT

    Регулирование, IT

    IT, О разном, Рынок

    О разном, IT

    Финансовые организации – одна из главных целей киберпреступников: исследования Positive Technologies показывают, что банки традиционно входят в топ-5 наиболее популярных целей, а одним из ключевых мотивов для киберпреступника остается финансовая выгода. Поэтому банкам приходится уделять серьезное внимание информационной безопасности и защите своей инфраструктуры. С какими уязвимостями сталкиваются банки и их клиенты? И как защититься?

    Популярность банковских приложений – мобильного и онлайн-банкинга – постоянно растет. Одна из причин – появление цифровых альтернатив, что позволяет клиентам банков не тратить время на походы в отделение. Согласно статистике , до 40% клиентов американских банков не были в отделениях по полгода и более. Кроме того, среди общего числа клиентов финансовых организаций растет число молодых пользователей, так называемых миллениалов. К примеру, в США 47% из них используют мобильный банк, в сравнении с 23% людей старшего поколения (бэби-бумеров).

    Во всем мире именно пользователи 18−34 лет становятся самой активной группой клиентов. Эти люди озабочены вопросами удобства и надежности используемых продуктов больше, чем их родители. По данным исследования компании Kasasa, 82% пользователей до 34 лет не боятся смены банка, 83% из них сделают это, если конкуренты предложат им более выгодные условия обслуживания (например, кешбэк), а для 65% пользователей удобство мобильного приложения – критически важный фактор при выборе банка.

    Россия идет в ногу с мировыми трендами – доля пользователей интернет- и мобильного банкинга в РФ выросла до 45,1%. Развитие технологий приводит к сокращению присутствия банков в офлайне – количество действующих подразделений в 2015 году сократилось на 11,2%, в 2020-м — на 8,7%, в 2020-м — еще на 3,4%.

    Безопасность онлайн-банкинга в цифрах

    Интернет становится все более важным каналом взаимодействия банков и их клиентов, поэтому финансовые организации уделяют все большее внимание безопасности. Хакерам все сложнее успешно атаковать банковскую инфраструктуру. По данным опубликованного FinCert отчета , с января по август 2020 года целевые атаки принесли киберпреступникам всего 76,5 млн рублей. Годом ранее доход киберпреступников составил 1,08 млрд рублей. И это несмотря на рост общего числа атак (22 за восемь месяцев 2020 года против 20 в прошлом году).

    Ущерб от действий хакеров снижается из-за успешного противодействия их работе со стороны служб безопасности финансовых компаний и правоохранительных органов. Согласно данным исследования Positive Technologies , несмотря на рост общего числа уязвимостей в системах дистанционного банковского обслуживания российских банков (с 6 в 2020 году до 7 в 2020-м), количество уязвимостей высокого уровня риска падает несколько лет подряд (в 2015 году такие недостатки безопасности содержались в 90% систем, в 2020 – лишь в 56%). Становятся безопаснее и мобильные приложения. Уровень защищенности 8% таких систем в ходе исследования был оценен как приемлемый. В 2020 году 93% мобильных банков имели низкий уровень защиты.

    Внедрить код и перехватить данные

    Это две самые распространенные уязвимости банковских систем. Они позволяют злоумышленникам совершать атаки на пользователей финансовых приложений и перехватывать введенные ими данные. Для этого они внедряют в веб-страницу сайта банка вредоносный код, который подменяет или ворует вводимые на этой странице данные.

    Такие недостатки безопасности встречаются даже на сайтах и приложениях крупных банков. Например, в сентябре 2020 года издание The Register сообщало о том, что исследователь обнаружил возможность межсайтового выполнения сценариев (XSS) на сайтах британской Lloyds Group, объединяющей банки Lloyds, Halifaxи Bank of Scotland. Ошибка позволяла хакерам перехватывать и модифицировать данные, введенные пользователем в контактную форму на веб-страницах. В итоге могла быть похищена важная информация, включая логины и пароли для доступа к онлайн-банку.

    Пользователям трудно самостоятельно защититься от таких атак без специализированных инструментов (вроде плагинов для браузеров). Поэтому банкам приходится самостоятельно осуществлять аудит своих сайтов на предмет наличия XSS.

    Пароль перестал быть надежным

    Еще одна распространенная уязвимость: несмотря на то, что ее доля с годами снижается, в 2020 году эта проблема встречалась в четверти онлайн-банков . В большинстве подверженных уязвимости системах не была реализована защита от подбора одноразового пароля при использовании двухфакторной аутентификации. Если в системе не реализовано ограничение попыток ввода или время жизни одноразового пароля, то ничто не мешает злоумышленникам подобрать его и получить доступ к счету пользователя.

    Кроме того, киберпреступники могут использовать уязвимости сигнальных сетей SS7 для перехвата SMS с кодами для авторизации от банка – жертвами подобной атаки в 2020 году стали жертвы одного германского банка. В том же году Национальный институт стандартов и технологий (NIST) раскритиковал использование SMS как инструмента обеспечения безопасности. Финансовым компаниям стоит задуматься об использовании более надежных способов реализации двухакторной аутентификации (например, с помощью специализированных приложений).

    Письма с сюрпризом

    Успешные кибератаки, приводящие к краже денежных средств, могут быть осуществлены и без использования конкретных уязвимостей. Одним из наиболее эффективных способов проникновения в корпоративную инфраструктуру финансовых организаций остается фишинговая рассылка электронных писем на адреса сотрудников банка. Письма могут отправляться как на рабочие адреса, так и на личные. Такой метод использовали группировки Cobalt , Lazarus , Metel , GCMAN .

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

    Использование для подключения к серверам банка незащищенного WiFi-соединения также может приводить к проблемам. В такой ситуации злоумышленникам очень просто перехватить трафик, содержащий учетные данные. Известны случаи, когда хакерам удавалось обмануть мобильные приложения банков и отправить им поддельные сертификаты безопасности для установления соединения. В частности, исследователи обнаружили возможность проведения таких атак на приложения банков HSBC, Nat West, Bank of America.

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

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

    Риски информационной безопасности WEB-приложений

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

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

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

    инициация, согласно бизнес-процессам компании;
    установка;
    эксплуатация;
    выведение из эксплуатации.

    Информационная система и её составляющие

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

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

    Действия: оценка технического задания функционала системы и её фактических составляющих.

    Управление рисками

    Управление рисками включает в себя два вида деятельности, которые чередуются циклически:

    регламентную оценку рисков;
    выбор эффективных и экономичных защитных средств (нейтрализация рисков).

    По отношению к выявленным рискам возможны следующие действия:

    ликвидация риска (например, за счет устранения уязвимости);
    уменьшение риска (например, за счет использования дополнительных защитных средств или действий);
    принятие риска (и выработка плана действия в соответствующих условиях).


    Управление рисками можно подразделить на следующие этапы:

    инвентаризация анализируемых объектов;
    выбор методики оценки рисков;
    идентификация активов;
    анализ угроз и их последствий;
    определение уязвимостей в защите;
    оценка рисков;
    выбор защитных мер;
    реализация и проверка выбранных мер;
    оценка остаточного риска.

    Для определения основных рисков можно следовать следующей цепочке: источник угрозы > фактор (уязвимость) > угроза (действие) > последствия (атака).
    Источник угрозы — это потенциальные антропогенные, техногенные или стихийные носители угрозы безопасности.
    Угроза (действие) — это возможная опасность (потенциальная или реально существующая) совершения какого-либо деяния (действия или бездействия), направленного против объекта защиты (информационных ресурсов), наносящего ущерб собственнику, владельцу или пользователю, проявляющегося в опасности искажения и потери информации.
    Фактор (уязвимость) — это присущие объекту информатизации причины, приводящие к нарушению безопасности информации на конкретном объекте и обусловленные недостатками процесса функционирования объекта информатизации, свойствами архитектуры автоматизированной системы, протоколами обмена и интерфейсами, применяемыми программным обеспечением и аппаратной платформой, условиями эксплуатации.
    Последствия (атака) — это возможные последствия реализации угрозы (возможные действия) при взаимодействии источника угрозы через имеющиеся факторы (уязвимости).

    Действия: внедрение политики информационной безопасности компании.

    Источник угрозы

    Антропогенными источниками угроз безопасности информации выступают субъекты, действия которых могут быть квалифицированы как умышленные или случайные преступления. Методы противодействия напрямую зависят от организаторов защиты информации.

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

    Внешние источники могут быть случайными или преднамеренными и иметь разный уровень квалификации. К ним относятся:

    криминальные структуры;
    потенциальные преступники и хакеры;
    недобросовестные партнеры;
    технический персонал поставщиков телематических услуг;
    представители надзорных организаций и аварийных служб;
    представители силовых структур.

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

    основной персонал (пользователи, программисты, разработчики);
    представители службы защиты информации.

    Действия: составление вероятностной шкалы источников угроз.

    Анализ угроз

    Основным источником угроз информационной безопасности веб-приложения являются внешние нарушители.

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

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

    В контексте веб-приложения они могут быть разделены на следующие этапы:

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

    Действия: составление регламента работ по идентификации уязвимостей, патч-менеджмента.

    Идентификация технических уязвимостей

    Идентификация технических уязвимостей производится для внешнего и внутреннего периметра корпоративной сети. Внешний периметр – это совокупность всех точек входа в сеть. К внутреннему периметру относятся хосты и приложения, доступные изнутри.

    Традиционно используются два основных метода тестирования:

    тестирование по методу «черного ящика»;
    тестирование по методу «белого ящика».

    Тестирование по методу «черного ящика» предполагает отсутствие у тестирующей стороны каких-либо знаний о конфигурации и внутренней структуре объекта испытаний. При этом против объекта испытаний реализуются все известные типы атак и проверяется устойчивость системы защиты в отношении этих атак. Используемые методы тестирования эмитируют действия потенциальных злоумышленников, пытающихся взломать систему защиты.

    Метод «белого ящика» предполагает составление программы тестирования на основании знаний о структуре и конфигурации объекта испытаний. В ходе тестирования проверяется наличие и работоспособность механизмов безопасности, соответствие состава и конфигурации системы защиты требованиям безопасности. Выводы о наличии уязвимостей делаются на основании анализа конфигурации используемых средств защиты и системного ПО, а затем проверяются на практике.

    Также, существует метод тестирования под названием «серый ящик», который комбинирует вышеописанные методы, когда известна частичная информация об объекте тестирования.

    Отдельным пунктом исследования стоит возможность инфраструктуры работать на пиковых нагрузках и противостоять большому объему «мусорного трафика», генерируемого злоумышленниками или вредоносными программами.

    Для исследования времени отклика системы на высоких или пиковых нагрузках производится «стресс-тестирование», при котором создаваемая на систему нагрузка превышает нормальные сценарии её использования. Основная цель нагрузочного тестирования заключается в том, чтобы, создав определённую ожидаемую в системе нагрузку (например, посредством виртуальных пользователей) наблюдать за показателями производительности системы.

    Действия: аудит информационной безопасности, в том числе и регламентный (например, согласно требованиям PCI DSS).

    Обработка рисков

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

    Использование этого метода может привести к рассмотрению одного, двух или трех рисков для одного актива, в зависимости от конкретной рассматриваемой комбинации угроза/уязвимость.

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

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

    Действия: compliance management, консолидация и контроль соответствия требованиям ИТ и ИБ политик.

    Нейтрализация и контрмеры

    Нейтрализация рисков включает определение приоритетов, оценку и реализацию контрмер, уменьшающих риски и рекомендованных по результатам оценки рисков.

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

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

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

    В качестве мер обеспечения могут быть внедрены следующие решения (как по отдельности, так и в совокупности), подготовленными штатными специалистами и/или с помощью аутсорсинга информационной безопасности:

    Системы защиты от атак на прикладном уровне (WAF);
    Системы управления инцидентами и событиями ИБ (SIEM);
    Системы управления соответствием требованиям ИБ (Compliance Management);
    Системы управления идентификационными данными и доступом (IAM);
    Системы однократной и многофакторной аутентификации в корпоративных сетях;
    Системы защиты от утечки конфиденциальной информации (DLP);
    Системы управления доступом к информации (IRM);
    Инфраструктуры открытых ключей (PKI);
    Решения по сетевой безопасности;
    Системы антивирусной защиты;
    Системы защиты электронной почты от спама, вирусов и других угроз;
    Системы контентной фильтрации web-трафика;
    Системы контроля доступа к периферийным устройствам и приложениям;
    Системы контроля целостности программных сред;
    Системы криптографической защиты при хранении информации.

    Действия: внедрение технических мер для обеспечения информационной безопасности; внедрение административных мер; повышение уровня осведомленности персонала

    BlackBerry в России

    Если вы попытаетесь искать приложения для обеспечения безопасности и конфиденциальности в Google Play, то вы увидите множество списков приложений для защиты от вирусов и вредоносных программ. Но, к сожалению, это очень узкий взгляд на проблему. Есть множество приложений, которые могут сделать использование смартфона более безопасным. Большинство из них достаточно просты в использовании и не требуют значительных ресурсов вашего устройства. Конечно, для бизнес-использования, вам лучше изучить пакет приложений BlackBerry, но для вот лучшие пользовательские приложения для обеспечения безопасности, доступные на Android.

    Android Device Manager

    Android Device Manager — это сервис, который помогает защитить ваш смартфон от кражи или потери. Это приложение должно быть установлено на каждом устройстве Android (если у него есть магазин Google Play). Вы можете в любой момент получить доступ к своему аккаунту, перейдя в Настройки аккаунта Google в меню настроек вашего устройства. После активации сервиса (это производится по умолчанию) вы можете зайти на веб-сайт и управлять вашим устройством. Возможности включают поиск и удаление данных с устройства. Вы даже можете включить громкий сигнал, чтобы его найти. Услуга полностью бесплатна. Это одно из обязательных приложений для безопасности.

    Подробней о том, как найти ваш смартфон на базе Android используя Android Device Manager — в нашей статье: Как найти ваш BlackBerry PRIV используя Удаленное управление Android?

    Applock

    Цена: бесплатно / донейт по желанию


    Applock — одно из наиболее полезных приложений для обеспечения безопасности. Оно работает, блокируя различные приложения. После установки приложения вам нужно будет ввести код для доступа к настройкам приложения. Это обязательное приложение для семей с детьми. Кроме того, это хороший способ удержать любопытного друга от изучения информации в вашем телефоне. Applock даже удержит злоумышленников, на некоторое время, если телефон попадет к ним в руки. Однако это не лучшее решение. Грамотный специалист сможет обойти эту блокировку, потратив достаточно времени. Это приложение бесплатно и содержит рекламу. Вы можете сделать донейт, и удалить рекламу. Вы также можете просто отключить рекламу и использовать бесплатную версию этого приложения.

    DuckDuckGo

    DuckDuckGo один из самых безопасных сервисов для поиска. Это поисковая система, похожая на Google, Bing или Yahoo, однако его основное преимущество в том, что он не отслеживает историю поиска. Это означает, что вам не потребуется беспокоиться о том, что кто-то будет наблюдать за тем, что вы ищете. Приложение работает достаточно хорошо. У него есть настройки поиска и встроенный браузер. Формально, это не приложение для безопасности, но тем не менее, оно отлично подойдет для тех, кто хочет получить больше конфиденциальности.

    Браузер Ghostery

    Ghostery — один из лучших браузеров. Приложение покажет вам трекеры и рекламные сети, которыми пользуется каждый веб-сайт и предоставит возможность отключить их. Его функции похожи на DuckDuckGo, но доступны для каждого веб-сайта, а не только для поиска. В большинстве сценариев браузер работает очень хорошо, но это не самый быстрый браузер. Это одно из лучших приложений для тех, кто хочет путешествовать в интернете и сохранять конфиденциальность.

    GlassWire

    GlassWire — это новое приложение для обеспечения безопасности, которое позволяет вам видеть, какие приложения расходуют ваши данные. Вы получите живой график, который в режиме реального времени показывает, сколько данных потребляют ваши приложения. Кроме того, вы получите оповещения, которые позволят вам узнать, когда новое приложение загружает данные. Это отличный способ узнать, сколько данных использует каждое из ваших приложений. Это также отличный способ увидеть какие-то странные действия, которые могут происходить в фоновом режиме. Это приложение, по своему назначению напоминает предустановленное на смартфоны BlackBerry на базе Android приложение DTEK, однако GlassWire предоставляет информацию не только о доступе к вашим данным, но и о объемах переданной информации.

    LastPass

    Цена: бесплатно / $ 12 в год

    LastPass — одно из лучших приложений для управления паролями. Он позволяет хранить пароли сайтов, PIN-коды и другую важную информацию для быстрого доступа. Это намного безопаснее, чем просто записывать эту информацию. Вы также можете использовать LastPass Authenticator для дополнительной безопасности. LastPass — это мощное и кроссплатформенное приложение. Бесплатная версия имеет достаточно много возможностей, а полная версия добавляет некоторые функции, параметры синхронизации с другими устройствами и многое другое. Это одно из обязательных приложений для безопасности.

    Reslio Sync

    Resilio Sync — это ваше собственное облачное хранилище. Версия Resilio Sync для компьютера превращает ваш обычный бытовой компьютер в сервер для хранения данных, а приложение может использоваться для доступа к файлам. Функционал приложения похож на Google Диск или Dropbox, за исключением того, что вы знаете, где хранятся ваши файлы. Это отлично подходит для важных данных и тех, кто не доверяет онлайновому облачному хранилищу, но все же хочет иметь возможность им пользоваться. Приложение очень легко в настройке, даже для новичков, а также совершенно бесплатно. Это одно из самых недооцененных приложений для безопасности.

    Signal Private Messenger, Telegram или WhatsApp

    На Android существует множество приложений, поддерживающих защищенный обмен сообщениями. Signal Private Messenger, Telegram или WhatsApp — станут отличным выбором. Каждый и этих мессенджеров поддерживает сквозное шифрование сообщения, видеовызовы, групповые сообщения и общий доступ к файлам. Они немного отличаются набором функций, но на ваш выбор скорее всего повлияет то, каким из этих приложений пользуются ваши друзья и собеседники. Они все бесплатны, так что по крайней мере вам не придется беспокоиться об этом.

    Мы бы советовали вам опробовать Signal Private Messenger, который использует систему поиска контактов с помощью номера телефона, а если у ваших друзей нет Signal Private Messenger, то они просто будут получать от вас обычные SMS. Приложение можно считать одним из самых безопасных, ведь каждое сообщение, входящее или исходящее, имеет свой код шифрования, который не раскрывается до самого получения, предотвращая любые попытки перехвата. Для того, чтобы полностью обезопасить себя, приложение должно быть установлено у обоих собеседников, но Signal Private Messenger также очень хорошо работает и как автономное приложение для SMS.

    Проект Tor (три приложения)

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

    На данный момент проект Tor предоставляет доступ к Orfox — браузеру Tor на Android (который все еще в бета версии), и Orbot — прокси-приложению, которое позволяет другим приложениям использовать технологию Tor, чтобы оставаться анонимным. Браузер все еще находится в разработке, и анонимность не может быть гарантирована, но Orbot определенно заслуживает внимания.

    В проект также недавно вошло приложение Ooniprobe, которое позволяет вам определить, блокирует ли ваш интернет-провайдер соединение с некоторыми сайтами. Это превосходные приложения для безопасности для тех, кто немного более продвинут.

    TunnelBear VPN

    Цена: бесплатно / $ 7.99 в месяц / $ 49.99 в год

    Список приложений безопасности не будет полным без сервисов VPN, и мы выбрали TunnelBear. Его простота использования и доступность делают его отличным выбором для новичков, поскольку мы предполагаем, что эксперты, вероятно, найдут более элегантное VPN-решение. TunnelBear позволяет вам использовать VPN в различных странах, и эффективно скрывать ваш IP-адрес от используемых сайтов. VPN также позволяет использовать общественный WiFi с большей безопасностью. Бесплатная версия предоставляет 500 Мб бесплатного трафика каждый месяц. Вы также можете получить неограниченное количество данных за 6,99 долл. США в месяц или 49,99 долл. США в год. Это, конечно, один из многих VPN сервисов, и в ближайшее время мы расскажем вам о других вариантах!

    BlackBerry Privacy Shade

    Цена: бесплатно

    Недавно BlackBerry выпустила приложение для обеспечения конфиденциальности BlackBerry Privacy Shade. Это Android приложение имеет очень простую концепцию, но чрезвычайно практично. Оно функционирует именно так, как предполагает его название и позволяет управлять тем, какой контент отображается на экране вашего смартфона.

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

    BlackBerry Privacy Shade позволяет вам скрывать все, что отображается на вашем экране, показывая выбранную информацию в небольшом окне, чтобы обеспечить приватность при использовании устройства в людных местах.

    Чтобы обеспечить быстрый доступ к приложению, BlackBerry добавила его в быстрые настройки в Android Nougat, а если вы используете устройство BlackBerry с дополнительной программируемой клавишей, вы можете назначить запуск BlackBerry Privacy Shade с ее помощью. Если вы хотите опробовать Privacy Shade, то приложение уже доступно в Google Play.

    Если вы выбрали один из смартфонов BlackBerry на базе Android — BlackBerry PRIV, DTEK50 или DTEK60, то кроме пакета приложений BlackBerry Hub+ для повышения производительности, на них предустановлены приложения BlackBerry для безопасности пользователя: DTEK для мониторинга активности приложений и Менеджер паролей BlackBerry:

    Не пропустите наши обзоры лучших приложений для смартфонов BlackBerry на базе Android:

    Проверьте ваши приложения на уязвимости из списка OWASP Top 10 за 2013 год.

    Ознакомительная версия AppScan Standard

    IBM Security AppScan – это передовой пакет инструментов, предназначенный для проверки приложений на защищенность и помогающий управлять процессом обнаружения уязвимостей на протяжении всего жизненного цикла разработки ПО. IBM Security AppScan автоматизирует оценку степени уязвимости приложений, а также сканирует и проверяет их на наличие известных уязвимостей, присущих Web-приложениям, включая внедрение SQL-кода, межсайтовый скриптинг, переполнение буфера и сканирование уязвимостей в flash/flex-приложениях и сервисах Web 2.0.

    AppScan полностью охватывает все уязвимости из списка OWASP Top 10 за 2013 год. Кроме того, наше решение поддерживает протокол Transport Layer Security (TLS) версии 1.2 и совместимо со стандартами Federal Information Publication Standard (FIPS) 140-2 и National Institute of Standards and Technology (NIST) Special Publication (SP) 800-131a.

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

    Бизнес также поспособствовал бурному развитию Web-приложений. Помимо того, что Web-приложения предоставляют новые коммерческие возможности, разрабатывать их гораздо дешевле и быстрее, чем обычные настольные приложения. Web-приложения проще и в развертывании: все, что нужно для их использования – это иметь совместимый Web-браузер. Любые требования к операционной системе (Windows®, Mac, Linux® и т. д.) и аппаратному обеспечению (например, наличие свободного дискового пространства) остались в прошлом.

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

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

    Защита Web-приложений

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

    Защита сетевого уровня (хостинга) Web-приложений является проторенной дорожкой и представляет собой ряд несложных действий, которые необходимо выполнить. Однако сетевой экран не обеспечивает защиты самих Web-приложений. Ахиллесовой пятой в защите онлайновой информации является уровень приложений. Уязвимости приложений, возникшие вследствие ошибок в коде и использования слабых приемов программирования, постоянно эксплуатируются хакерами и послужили причиной ряда крупнейших утечек данных, произошедших в недавнем прошлом. В марте 2008 года была похищена информация о 134 миллионах кредитных карт процессинговой компании Heartland Payment Systems; причиной послужила уязвимость Web-приложения, которую хакеры использовали для внедрения SQL-кода и установки вредоносного ПО. В 2012 году компания Yahoo! несколько раз пострадала от утечек данных, причиной которых послужило использование уязвимостей в Web-приложениях; в результате внедрения SQL-кода и межсайтового скриптинга были украдены пароли более чем от 450 тысяч учетных записей пользователей.

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

    Плохой код – основная причина большинства брешей в Web-приложениях

    Основной причиной большинства брешей в Web-приложениях является написанный разработчиками программный код. Разработчики могут допускать ошибки при написании кода или не осознавать всю важность использования приемов безопасного программирования – все это приводит к появлению уязвимостей в приложениях. Рассмотрим для примера код, удаляющий из поля ввода символы, которые не должны приниматься и обрабатываться приложением. Это довольно простой прием программирования, но если о нем забыть, то злоумышленник может использовать поле ввода для выполнения SQL-запроса, в результате которого он сможет получить все данные о пользователях, включая их имена, электронные адреса и даже номера кредитных карт. Такие уязвимости являются источником легкой добычи для киберпреступников, поскольку похищенную информацию можно быстро продать на нелегальных онлайн-рынках. Все Web-приложения необходимо проверять на наличие уязвимостей прикладного уровня, а разработчиков необходимо обучать оценивать риски и писать безопасный код.

    Список OWASP Top 10 – лучшая практика защиты Web-приложений

    Проект Open Web Application Security Project (см. раздел Ресурсы) – это Open Source-сообщество, сформированное в 2001 году и занимающееся разработкой бесплатных руководств по защите приложений. Сообщество OWASP ведет постоянно актуализируемый список OWASP Top 10, в котором перечислены наиболее опасные уязвимости в системе безопасности Web-приложений. Список OWASP Top 10 является лучшей практикой устранения уязвимостей Web-приложений; на него ссылаются такие солидные организации и нормы безопасности, как PCI DSS, FTC, MITRE, а также большинство организаций, занимающихся тестированием Web-приложений на предмет уязвимостей.

    Список OWASP Top 10 за 2013 год

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

    1. Внедрение кода

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


    Пример простой атаки с внедрением SQL-кода

    В следующем примере мы будем использовать Web-сайт, разработанный IBM специально для тестирования Web-приложений на предмет уязвимостей. Компания Altoro Mutual является вымышленной, но продемонстрированная атака является вполне реальной (см. рисунок 1).

    Тестовое Web-приложение позволяет пользователям выводить списки транзакций, совершенных за определенный период времени. Значение, вводимое в поле ввода даты, не обрабатывается фильтрами, поэтому приложение уязвимо для внедрения SQL-кода. Ввод следующего значения позволяет выполнить команду, возвращающую содержимое базы данных, включая имена и пароли пользователей: 1/1/2010 union select userid,null, username+’ ‘+password,null from users— .

    Рисунок 1. Web-приложение, возвращающее данные после отправки запроса

    Первая часть значения, введенного в поле ввода, является датой – это именно то, чего ожидает приложение. Этот прием гарантирует, что приложение обработает данные, содержащие дату, вместе с оставшейся частью введенной команды. За датой следует оператор «union», означающий начало SQL-команды. По существу, он говорит «Вот вам ожидаемая дата, а еще. «. Методом проб и ошибок злоумышленник может вычислить название таблицы, содержащей данные об учетных записях пользователей (она называется users ), и количество полей в ней. После этого атакующий использует эту информацию для составления SQL-команды select , возвращающей данные из таблицы users . Полученная информация, содержащая имена и пароли учетных записей пользователей, отображается на Web-странице в форме для вывода списка транзакций.

    Это самый простой пример внедрения SQL-кода. В реальном мире атаки этого типа намного изысканнее, а хакеры используют специализированные инструменты, помогающие автоматизировать атаки.

    2. Некорректная аутентификация и управление сеансами

    Вторая наиболее опасная уязвимость в списке OWASP связана с методами аутентификации и защиты пользовательских сеансов в Web-приложении. Существует множество типов этой уязвимости, одним из которых является несанкционированное использование сеанса.

    Несанкционированное использование сеанса

    Злоумышленник может попытаться украсть (несанкционированно использовать) Web-сеанс пользователя, узнав его секретный идентификатор. Зная секретный идентификатор сеанса, атакующий может представиться Web-серверу аутентифицированным пользователем и скомпрометировать его учетную запись. Если приложение недостаточно хорошо защищает идентификаторы сеансов (например, отображает идентификаторы внутри URL-адреса вместо использования cookie-файлов), то злоумышленнику очень просто получить идентификатор сеанса, обманув пользователя.

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

    Рисунок 2. Пример сценария для получения идентификатора сеанса, хранящегося в cookie-файле

    Для улучшения системы аутентификации и управления сеансами в приложениях можно использовать современные платформы для разработки ПО, а также приемы написания безопасного кода. В частности, можно применять привязку исходного IP-адреса к идентификатору пользовательского сеанса и обязательную повторную аутентификацию при изменении важных параметров учетной записи (например, пароля или адреса электронной почты). Именно эти действия пытаются выполнять злоумышленники сразу же после взлома Web-сеанса. В этих случаях такой простой прием программирования, как повторная аутентификация, уничтожает несанкционированный сеанс и снижает риск.

    Другим простым приемом программирования, который нельзя оставлять без внимания, является уничтожение сеанса по истечении заданного времени простоя. Например, если пользователь не работает с Web-сайтом в течение пяти минут, приложение разрывает сеанс, заставляя пользователя (или любого злоумышленника) выполнять повторную аутентификацию для продолжения работы. Этот простой прием также снижает риск несанкционированного использования сеанса; его используют в большинстве онлайновых банковских Web-приложений.

    3. Межсайтовый скриптинг

    Межсайтовый скриптинг (cross-site scripting, XSS) – это еще одна разновидность атаки на Web-приложения, сохраняющая популярность уже много лет. Если Web-приложение содержит XSS-уязвимость, то злоумышленник может внедрить на Web-страницу вредоносный сценарий, выполняющийся при загрузке страницы пользователем.

    Пример XSS-атаки

    Web-приложение из следующего примера позволяет пользователям заходить на Web-страницу и размещать отзывы на продукты компании. Поле для ввода комментария подвержено XSS-атакам. Ниже показан пример комментария ( This is a great product >), внедряющий в Web-страницу XSS-сценарий, который пытается узнать идентификатор сеанса пользователя.

    Рисунок 3. Пример комментария, внедряющего XSS-сценарий в Web-страницу

    Уязвимое Web-приложение обрабатывает комментарий вместе с XSS-сценарием. Начиная с этого момента пользователи, зашедшие на страницу отзывов, видят комментарий «This is a great product», но не видят сценария, который тем не менее выполняется в их Web-браузерах и отправляет информацию из cookie-файлов (включая идентификатор сеанса) на Web-сайт злоумышленника. В этом примере Web-сайт злоумышленника называется «evilsite». Получив необходимый идентификатор сеанса, злоумышленник компрометирует учетную запись жертвы. Такие сценарии чрезвычайно опасны, поскольку с их помощью хакеры могут похищать за один прием тысячи учетных записей.

    В наши дни большинство современных браузеров содержит защиту от XSS-атак – например, Internet Explorer по умолчанию запускается в режиме защиты, предотвращающем выполнение XSS-сценариев. Тем не менее XSS-атаки до сих пор довольно популярны и распространены, поэтому подобные уязвимости никогда не должны присутствовать в Web-приложениях.

    4. Небезопасные прямые ссылки на объекты

    Брешь, обусловленная наличием небезопасных прямых ссылок на объекты, может привести к тому, что авторизованный пользователь Web-приложения может получить неавторизованный доступ к привилегированным функциям и данным. Если в коде приложения неграмотно или неправильно реализованы методы работы с информационными объектами (например, с файлами, каталогами или ключами баз данных), то пользователи, не обладающие требуемыми привилегиями, могут обойти средства защиты, реализованные в приложении. Используя эту уязвимость, пользователи могут изменять значения параметров таким образом, чтобы непосредственно обращаться к объектам, доступ к которым им запрещен.

    Чтобы защититься от этого, разработчики могут внедрить средства контроля доступа ко всем доступным пользователям объектам.

    5. Небезопасная конфигурация

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

    Рисунок 4. Сообщения об ошибках раскрывают хакерам все секреты

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

    6. Утечка уязвимых данных

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

    7. Отсутствия контроля доступа к функциональному уровню

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

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

    8. Подделка межсайтовых запросов (CSRF)

    Подделка межсайтовых запросов (cross-site request forgery, CSRF) основана на том, что аутентифицированного пользователя Web-приложения обманным путем заставляют запустить вредоносный сценарий, который выполняет действия от имени законного пользователя. Например, на компьютере пользователя может скрытно выполняться CSRF-сценарий, отправляющий Web-приложению запрос на изменение пароля, а после успешной авторизации пользователя Web-приложение исполняет этот запрос.

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

    9. Использование компонентов с известными уязвимостями

    Любой сторонний компонент Web-приложения – будь то двоичный или исходный код, коммерческое или Open Source-приложение – должен проверяться на отсутствие уязвимостей.

    Практически каждое Web-приложение использует Open Source-компоненты, например, библиотеку OpenSSL, обеспечивающую TLS/SSH-шифрование Web-сайтов (HTTPS). В апреле 2014 года в нескольких версиях этой библиотеки была обнаружена критическая уязвимость CVE-2014-0160, известная как Heartbleed.

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

    10. Непроверенные перенаправления и переходы

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

    За дополнительной информацией о списке OWASP Top 10 (2013) обратитесь к разделу Ресурсы.

    Как избежать лишних затрат при минимизации уязвимостей в Web-приложении

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

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

    Передовой инструмент для поиска уязвимостей в Web-приложениях – IBM Rational AppScan – позволяет разработчикам и тестировщикам Web-приложений сделать процесс поиска уязвимостей частью внутреннего цикла разработки ПО, включающего в себя поиск всех уязвимостей из списка OWASP Top 10 (см. раздел Ресурсы). AppScan – это мощный инструмент, который разработчики могут настраивать под свои нужды. А поскольку разработчики знают о своих приложениях намного больше любых сторонних производителей средств испытаний на проникновение, AppScan позволяет им выполнять более глубокое тестирование Web-приложений.

    Обучение разработчиков

    AppScan выдает краткую информацию обо всех уязвимостях, которые он обнаруживает в Web-приложениях, включая подробную информацию о методе тестирования, в ходе которого была обнаружена уязвимость (такую информацию нечасто можно встретить в отчетах испытаний на проникновение). AppScan оказывается особенно полезным тогда, когда необходимо объяснить причину возникновения уязвимости разработчикам и научить их правильно писать код с помощью простых текстовых и видеоматериалов и даже фрагментов кода, которые они могут использовать для устранения своих ошибок. Такие уровень поддержки разработчиков и объем предоставляемой информации не только помогают разработчиком лучше понять всю важность защиты Web-приложений, но и учат их писать правильный код, снижая вероятность появления уязвимостей в Web-приложениях в будущем.

    Гарантия защищенности Web-приложений


    В AppScan реализованы широкие возможности создания стандартизированных отчетов самых различных типов, которые можно использовать в качестве гарантий и доказательств того, что в процессе разработки Web-приложение было должным образом защищено. Отчет Delta Analysis служит подтверждением того, что приложение содержит все исправления, закрывающие уязвимости, а отчеты на базе стандартов OWASP Top 10 и PCI DSS демонстрируют защищенность Web-приложений аудиторам и заказчикам.

    Заключение

    Недооценка важности защиты Web-приложений – это мина с часовым механизмом. Одна-единственная уязвимость в Web-приложении может привести к глобальной утечке данных, которая может разрушить до основания даже самую большую компанию, вызвав негативные отзывы в средствах массовой информации по всему миру, серьезные финансовые санкции и потерю общественного доверия. Сегодня защита Web-приложений с использованием общепринятых стандартов и методов, таких как OWASP Top 10, а также использование инструментов поиска уязвимостей, таких как IBM Rational AppScan, являются необходимой практикой.

    Ресурсы для скачивания

    Похожие темы

    • Оригинал статьи: Scan your app to find and fix OWASP Top 10 2013 vulnerabilities (EN).
    • В библиотеке OpenSSL была обнаружена критическая уязвимость CVE-2014-0160 (EN), известная как Heartbleed.
    • Получите дополнительную информацию и указания по работе с последним списком OWASP Top 10 (EN).
    • Проект Open Web Application Security Project (OWASP) (EN) – это основанное в 2011 году Open Source-сообщество, занимающееся разработкой бесплатных руководств по защите приложений.
    • Используйте для тестирования уязвимостей демонстрационное Web-приложение от IBM.
    • Подделка межсайтовых запросов (CSRF) (EN) может заставить конечного пользователя выполнять нежелательные действия в Web-приложении, в котором он аутентифицирован.
    • Присоединяйтесь к сообществу Security On developerWorks (EN) и знакомьтесь с руководствами, статьями, видеофайлами и демонстрационными материалами, которые можно найти в библиотеке сообщества.
    • Познакомьтесь с блогом Security On developerWorks (EN), в котором вы найдете информацию о различных руководствах, статьях и демонстрационных видеоматериалах.
    • Подпишитесь на еженедельный информационный бюллетень Security On developerWorks (EN), чтобы быть в курсе последних новостей.
    • Следите за материалами блога @dwsecurity (EN) в Твиттере и получайте обновления раздела Security портала developerWorks в реальном времени.
    • Узнайте больше о IBM Rational AppScan (EN) – передовом инструменте для поиска уязвимости в Web-приложениях.
    • Используйте в вашем следующем open source проекте ознакомительные версии программного обеспечения IBM (EN), которые можно загрузить с сайта или заказать на DVD.

    Комментарии

    Войдите или зарегистрируйтесь для того чтобы оставлять комментарии или подписаться на них.

    10 рисков для безопасности вашего приложения

    Ниже приводится перечень некоторых известных методов и продуктов для управления рисками информационной безопасности.

    Классика жанра

    Американский стандарт де-факто

    Software Engineering Institute Carnegie Mellon University

    Одна из наиболее популярных открытых методологий

    Central Computer and Telecommunications Agency (UK), Insight Consulting (Siemens)

    Британскийстандартде-факто. ПО уже не поддерживается.

    RA2 art of risk

    AEXIS Security Consultants совместнос
    XiSEC Consultants Ltd

    Разработчики ISO 27001 при помощи данного продукта иллюстрируют подход к оценке рисков ИБ, заложенный в стандарте. ПО уже не поддерживается.

    Отечественные разработки

    Digital Security Office

    Наиболее раскрученная отечественная разработка

    Институт системного анализа РАН

    Концептуальная разработка, применявшаяся в ЦБ РФ

    Относительно новые

    Microsoft Security Assessment Tool

    IT Governance совместносVigilant Software

    Новая разработка для оценки рисков по ISO 27001

    Высокоуровневое управление риском, соответствием и стратегическое планирование

    Citicus ONE vR3.2

    Для небольших организаций

    Lightwave Security SecureAware v3.7.2

    Для средних организаций и для более требовательных организаций

    Мощная и дорогая система для управления ИБ

    Для крупных и наиболее требовательных организаций

    Оперативное управления рисками, связанными с техническими уязвимостями (подход «снизу вверх»)

    Secure Win Auditor v2.0

    Недорогое средство анализа защищенности и оценки соответствия для небольших Windows-сетей

    IT GRC Solution v6.0 и

    Мощное и дорогое средство для оперативного управления уязвимостями, рисками и соответствием для крупных организаций

    Мощное и дорогое средство для оперативного управления уязвимостями, рисками и соответствием для крупных организаций

    Total Protection for Compliance v6.8

    Можно рекомендовать только тем, кто строит всю систему защиты корпоративной сети на продуктах McAfee

    Skybox 4000 v1.0

    Хорошее соотношение цена/возможности

    Network Advisor v4.1 & Vulnerability Advisor v4.1

    Дорогой, но удобный продукт, особенно в форме эпплайенса

    Устаревшие

    Callio Secura 17799

    Уже не поддерживается. Предназначался для автоматизации всех задач по внедрению СУИБ

    Мастер Йода рекомендует:  Все для изучения Java, примеры разработки
    Добавить комментарий
    Продукт/Метод Разработчик Сайт Комментарий