В то время как умы кибербезопасников и новостные заголовки оккупированы ранзомварью, на ее долю в 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*);» —
Продолжение следует. Понравилась статья — поделитесь с друзьями и близкими, и конечно что же оставляйте ссылку на своих страничках, а мы продолжим радовать вас интересным и познавательным контентом !
Добавить комментарий