Как и зачем взламывают web-приложения — оконачание

Как и зачем взламывают web-приложения

Как и зачем взламывают web-приложения — оконачание.

Эксплуатация уязвимой криптографии. По странному стечению обстоятельств у мобильных приложений гораздо больше проблем с криптографией, чем у традиционных настольных веб-приложений. Уязвимыми криптографическими реализациями грешат 87% приложении Android и 80% приложений iOS. Большинство корпоративных системных администраторов не имеют инструментов для отслеживания таких подключений, и поэтому их веб-сайты становятся уязвимы для бэкдор-атак.

Кибератакам подвержены абсолютно все типы вебсайтов и веб-приложений начиная с одностраничников и заканчивая увесистыми многофункциональными вебприложениями В 2016 году около 40% от всех киберинцидентов пришлось на веб-приложения. В отчете Verizon о киберинцидентах за 2017 год указано, что почти 60% киберинцидентов затрагивают веб-приложения.

Уязвимости есть не только в веб-приложениях, но и в инструментах разработчика

Новый код для веб-приложений разрабатывается и выпускается быстрее, чем когда-либо, с применением экстремально быстрых методик разработки и повторно используемых блоков. Теперь уже не написанное с нуля, современное веб-приложение (как для ПК, так и для мобильного устройства) собирается из взаимосвязанных API-интерфейсов, компонентов с открытым исходным кодом и облачных компонентов, таких как контейнеры и микросервисы/веб-сервисы.

Больше 80% веб-приложений, написанных на РНР, Classic ASP или ColdFusion, подвержены как минимум одной критической уязвимости из ТОП-10 OWASP. Уязвимости в приложениях, написанных на скриптовых языках, встречаются гораздо чаще чем в приложениях написанных на NET или Java. Фактически 64% приложений на Classic ASP. 62% на ColdFusion и 56% на РНР имеют по крайней мере одну уязвимость SQL-иньекции. Для сравнения: у NET эта цифра составляет 29%, а у Java — 21%. Данное обстоятельство вызывает серьезную тревогу, особенно в свете того, что большое количество веб-приложений сидят на CMS под управлением РНР В том числе WordPress и Drupal.

Создать веб-приложение, в котором не будет ни одного дефекта, практически невозможно. Но даже если теоретически предположить, что кому-то из разработчиков это удалось — злоумышленникам никто не помешает эксплуатировать уязвимости бэкенд-движка, под управлением которого это веб-приложение работает, и таким образом менять поведение веб-приложения на свое усмотрение. В 2017 году на конференции Black Hat были представлены критические уязвимости в пяти наиболее распространенных языках вебпрограммирования:

Python. Содержит недокументированные методы и локальные переменные окружения, которые могут использоваться для выполнения команд операционной системы.

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

Node.js. Встроенные сообщения об ошибках Node. js для функции require могут эксплуатироваться киберзлоумышленником для определения наличия на машине файла с заданным именем и для считывания первой строки этого файла.

JRuby. CneunanncTaMU было обнаружено. что Java-версия Ruby позволяет осуществлять удаленное выполнение кода способом, непредусмотренным базовой спецификацией языка.

РНР. Специфически построенный РНР-код позволяет осуществлять несанкционированное удаленное выполнение команд операционной системы. Скриптовые движки постоянно развиваются и усложняются. Вместе с новыми возможностями приходят и новые уязвимости, потому что для реализации этих новых возможностей уже существующая функциональность скриптового движка используется новым, незапланированным до этого способом. Так, например, в обсуждаются новые интересные особенности JavaScript, с появлением которых в JS-движке также появились и новые критические уязвимости, которым подвержены самые разнообразные современные скриптовые движки. В том числе те. которые реализованы в Adobe Flash. Chrome. Microsoft Edge и Safari.

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

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

«Серебряная пуля»

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

Так как же все-таки обеспечить безопасность?

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

Все вышеперечисленное не имеет особого значения. То, что имеет по-настоящему важное значение, лежит за пределами технологий: наглядность и подотчетность. Веб-ресурсы и организации, которые безопаснее своих сверстников: 1) имеют четкое представление об эффективности своего жизненного цикла разработки ПО; 2) у них также есть четкие метрики для корпоративной кибербезопасности; метрики, которые прозрачно показывают, как поддерживать кибербезопасность на протяжении этого жизненного цикла; 3) и в этих организациях также действует культура подотчетности, в том числе в терминах «когда» и «если». Поэтому они могут наглядно измерять производительность. Почему это работает? Потому что все измеренное приобретает тенденцию улучшаться Когда все проблемы наглядно измерены, решение найти намного проще http://u.to/LKNQ

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *