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

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

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

В то время как умы кибербезопасников и новостные заголовки оккупированы ранзомварью, на ее долю в 2017 году приходилось лишь 2% серьезных инцидентов, тогда как более 70% — это веб-приложения.

Все типы веб-сайтов, начиная от одностраничников и заканчивая многофункциональными веб-приложениями, уязвимы для кибератак. Атаки на веб-приложения более злободневны, чем ранзомварь! Веб-приложения — это «мягкое подбрюшье- предприятия, щель в доспехах, которой киберзлоумышленники не преминут воспользоваться для своих махинаций. Уязвимости распространенных веб-компонентов, небезопасные привычки кодирования и бум автоматических эксплойтов, превратили CMS. e-commerce и другие вебплатформы в богатые охотничьи угодья для хакеров . Атаки на CMS Joomla составили в 2017 году 25% от всех веб-атак. за ними следуют WordPress (10%) и Magento (7%). Кстати, если у вас есть свой проект на упомянутых CMS или иных вариантах — вы наверняка задумывались о росте и привлечении целевой аудитории, и в этом вам наверняка сможет помочь продвижение seo. Остается пожелать успехов вашим проектам и удачного продвижения. Возвращаясь к главной теме, хотелось бы напомнить что начиная с 1991 года браузеры непрерывно эволюциони­руют, обрастая все новыми и новыми веб-технологиями. Последний существенный шаг в этой эволюции — внедрение стандарта HTML5. Обновление веб- стандартов влечет за собой также и обновление букета проблем с безопасностью HTML5, позволяющий веб-страницам имитировать обычный настольный софт, не исключение Возможности для взлома браузеров и клиентской части веб-приложений, работающих по стандарту HTML5 практически безграничны. Потому что HTML5 — это что-то вроде небольшой операционной системы, запущенной в вашем браузере.

1. Все началось в 1991 году, когда были предложены самая первая версия НТТР-протокола, самая первая версия HTML-стандарта и самая первая версия браузера. HTTP и HTML тогда были статичными. Взаимодействие с пользователем было минимальным. Веб-программирование сводилось к тому, чтобы писать CGI-скрипты. Одно из самых больших ограничений протокола HTTP на тот момент заключалось в том, что у него не было переменных состояния, и поэтому пользователи, посещая веб-сайты, заходили на них каждый раз как в первый раз. Для устранения этого недостатка были придуманы cookie-файлы. С момента появления cookie-файлов браузеры попали в поле зрения киберзлоумыш­ленников, поскольку в браузерах теперь появились конфиденциальные данные.

2. По мере того как интернет развивался, от HTML стали ожидать большей динамичности. В качестве ответа на эту потребность в набор веб-технологий браузера были добавлены JavaScript и DOM. Эти нововведения значительно расширили поверхность возможных кибератак. Чуть позже стали появляться первые языки вебпрограммирования (ASP. РНР и Perl), которые расширили поверхность возможных кибератак еще сильнее. С внедрением этих технологий вопросы целостности и конфиденциальности трафика приобрели особую актуальность. Появились первые вариации MiTM-атак. В качестве решения был предложен SSL-протокол, но как показывает практика, с ним никто так и не научился обращаться.

3. JavaScript и CSS стали применяться в веб-приложениях повсеместно HTML-спецификация обросла новыми технологиями: усовершенствованный DOM расширенная модель событий, новые тэги и атрибуты. Причем все эти технологии также были встроены и в JavaScript. Так что JS тоже стал более функциональным, и закономерно более уязвимым. Перечисленные технологии стали причиной появления таких векторов атак, как XSS и CSRF. Эволюция браузерных технологий практически пересекла точку невозврата, где поверхность атаки на браузеры расширилась настолько, что манипуляции киберзлоумышленников вышли из-под контроля киберзащитников.

4. Требования к браузеру продолжали расти, и на клиентской стороне веб-приложений появились плагины (такие, как flash), расширения и другие им подобные «толстые» компоненты В то же время спецификации JavaScript и DOM претерпели очередное обновление, чтобы идти в ногу с этими новыми улучшениями. «Толстые» улучшения породили новые векторы атак. Стали широко использоваться наборы эксплойтов, ориентированных на JavaScript.

5. Разработчики и пользователи нуждались в еще более «толстых» функциональных решениях. В качестве ответа на эти нужды появилась технология Ajax, которая ознаменовала начало технологии Web 2.0. DOM продолжал эволюционировать. Разработчики веб-приложений начали пользоваться XMLHttpRequest-обьектами и мощными DOM-инструментами — на клиентской стороне, в браузере. Данный этап эволюции стал поворотным. С этих пор пла­гины (вроде flash и им подобным) стали выходить из моды, уступая место встроенной в сами браузеры функциональности. В результате, веб-приложения стали сильнее полагаться на DOM Соответственно, и кибератаки на DOM стремительно возросли. Появилось множество обязательных требований для так называемого безопасного кодирования, специфичных для клиентской части веб-приложений.

6. Наконец, в нашей жизни появился HTML5 с его мощными спецификациями Web Fonts, WebGL, Storage, WebSQL, Web Workers и т.п. Появились такие технологические наборы, как Flex и Silverlight. Все эти технологии не просто пришли к нам. чтобы остаться неизменными. Они продолжают непрерывно эволюционировать, чтобы удовлетворять постоянно возрастающие потребности RIA (rich internet application; обогащенное интернет-приложение). С появлением HTML5 и сопутствующих веб-технологий клиентская сторона веб-приложений «растолстела еще сильнее. Браузеры превратились в маленькие операционные системы. Благодаря всем этим технологиям клиентская часть веб-приложений теперь может полноценно работать даже в автономном режиме. Причем не только на персональных компьютерах, но и на мобильных устройствах. Что само собой, расширяет поверхность возможных кибератак еще сильнее.

Итак, веб-технологии, приближаясь к своему 30-летнему юбилею, претерпели значительную эволюцию. Оглядываясь назад можно вспомнить, что все начиналось с CGI-скриптов, а теперь мы живем в эпоху облаков и RIA, HTML5, DOM L4 и XHR L2 — современные спецификации, реализованные в браузере, которые позволяют веб-приложениям быть удивительно эффективными, производительными и гибкими. Таким образом, в эпоху Web 2.0. современниками которой мы все являемся, браузерная часть веб-приложений — это смесь технологий HTML5, DOM L4 и XHR L2, которые обеспечивают высокую интерактивность, и на сегодняшний день являются стандартом де-факто при разработке мобильного и настольного веб-софта.

Но есть у высокой интерактивности Web 2 0 и оборотная сторона много клиентского кода, выполняемого ни на сервере, а в браузере: FLEX CLI или JavaScript. Более того, ингредиенты этого клиентского кода зачастую подгружаются сразу из нескольких внешних источников и перед выполнением замешиваются прямо в браузере. Поэтому неудивительно, что киберзлоумышленники сегодня могут совершать самые разнообразные атаки на веб-приложения, с гарантированно летальным исходом.

Технологии HTML5 глазами взломщика

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

Кроме того, поверхность атак быстро расширяется благодаря включению такой функциональности, как аудио/видео-тэги, API для механизма Drag&Drop. CSS-прозрачность, локальное хранилище WebWorkers, DOM-селекторы, мышиная жестикуляция, встроенная поддержка JSON, управление межсайтовым доступом, автономный просмотр и т.д.

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

— передача значений параметров непосредственно в DOM без промежуточного НТТР-запроса к серверной части веб-приложения;

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

AV3. По идее веб-приложение может взаимодействовать только со своим локальным хранилищем. Поэтому предполагается, что «выбраться из песочницы и получить доступ к хранилищу чужого сайта (к его cookies, например) не получится. Однако на самом деле такая возможность существует. Посредством DNS-спуфинга и XSS- атаки, например. От DNS-спуфинга до некоторой степени можно защититься при помощи SSL: чтобы доступ к DNS был возможен только при наличии сертификата (но SSL тоже не панацея).

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

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

— когда веб-приложение уже скомпрометировано XSS-атакой у киберзлоумышленника есть полный доступ к его локальной БД, как на чтение, так и на запись.

— все те методики проведения SQL-иньекций, которые актуальны для удаленных баз данных, применимы также и здесь. Наиболее опасные из инъекций — асинхронные инъекции.

AV5. XHR и WebSockets открывают перед киберзлоумышленником множество вариантов злодейства. Вот несколько примеров того, что злодей может делать:

— Вызывать в JavaScript функции от имени произвольных доменов.

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

— Создавать канал связи со своим злонамеренным удаленным сервером после того, как браузер был ском­прометирован.

— Перенаправлять сетевой трафик.

AV6. В эпоху HTML5 веб-приложения опираются в своей работе на самые разнообразные потоковые структуры данных (JSON, XML, AMF и т.п.) и пользуются механизмом межсайтового разделения контента. Киберзлоу­мышленник посредством своего злонамеренного сайта может побудить браузер своей жертвы (на клиентской стороне) создать один из таких потоков и использовать этот поток в качестве точки входа для CSRF-атаки на подсистему межсайтового разделения контента (на серверной стороне).

AV8. При возникновении событий вроде Drag&Drop браузер отправляет запрос к серверной части веб-приложе- ния, чтобы оно прислало программный код для обработки этого события. Киберзлоумышленник при желании может перехватывать такие события и подсовывать браузеру свой собственный обработчик события. Например, чтобы подменить обработчик для Drag&Drop. киберзлоумышленник может сделать инъекцию через setData. Для этого надо установить draggable в true и поставить обработчик на событие ondragstart:

<div draggable — «true» ondragstart- -J

«event.dataTransfer.setData(’text/plaxn, J code injection*);» —

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

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

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