Секреты безопасных веб приложений на JavaScript. Гайд для новичков.

[D2]

Авторство: hackeryaroslav​

Источник: xss.is​

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

С JavaScript, который взял свыше 99% веб-сайтов в мире под свою опеку, тут как-то так – это как звезда программирования, особенно для веб-приложений. Язык этот дает огромное количество инструментов и фреймворков, что позволяет разработчикам на любом уровне создавать крутые веб-сайты, не особо заморачиваясь с финансами. Ну а помимо всех этих возможностей, у JavaScript есть и свой "но". Его репутация как мишени для хакеров весьма известна, в основном из-за встроенных слабостей.

Поскольку JavaScript тесно взаимодействует с объектной моделью документа веб-сайта (DOM), злоумышленники тут как на подбор используют уязвимости безопасности DOM. Они это делают, чтобы засадить вредоносные скрипты на веб-сервер, которые потом выполняются в браузере пользователя. С этими хитроумными скриптами злоумышленники могут взять под контроль учетные записи пользователей, подпортить веб-системы или вообще поворошить данными пользователя/системы.

Что такое уязвимости JavaScript? Мы вот о них поговорим. Межсайтовый скриптинг ( всем известный XSS) – это такая дыра в безопасности, которая позволяет злоумышленникам вкрадывать свои подлые скрипты на веб-страницы. И это может случиться, когда пользователь просто посещает такую страницу. Атаки XSS обычно запутаны, потому что они могут произойти там, где приложение принимает ввод от пользователя. Я также писал статьи детального разбора. Поэтому здесь пробигусь по нему кратко. Если пользовательский ввод не проверен на подлинность, браузер не осилит отличить хороший скрипт от плохого и автоматически его выполнит. А вот и попался – доступ к важным данным приложения, кукисам (печеньки, куки) и другим личным штукам у пользователя в кармане.

XSS-атаки делятся на три типа:

1. Хранимый/постоянный XSS – зловредный скрипт хранится на сервере и подсовывается жертвам вместе с их запрошенной инфой.
2. Отраженный XSS – вредоносный скрипт отражается от сервера сразу же в ответ на запрос пользователя, который включает в себя введенные им данные. Вредоносную нагрузку могут доставить через всякие там подставные ссылки в письмах и на других веб-сайтах. И браузер, доверчивый как он есть, думает, что это все ок и выполняет этот скрипт.
3. DOM-основанный XSS – тут вредный скрипт попадает в браузер пользователя через изменение DOM-среды.

А еще у JavaScript есть свои встроенные уязвимости. Вот несколько из них:

1. Непреднамеренное выполнение скриптов – если не кодировать JavaScript и HTML-код, то они становятся открытыми для всех, и хакеры это используют, чтобы засунуть туда свой контент. Результат – каждая клиентская машина, подключенная к веб-странице, выполнит эти скрипты.
2. Уязвимости исходного кода – возникают, когда разработчики игнорируют правила безопасного кодирования. JavaScript зависит от разных библиотек и фреймворков с открытым исходным кодом, и они могут привнести в систему несколько дырок безопасности. И если использовать небезопасные пакеты до их проверки, то это может создать неприятности с безопасностью, позволяя злоумышленникам внедрять и запускать вредоносные скрипты.
3. Раскрытие сессионных данных – приложения, написанные на JavaScript, которые выдают токены сессии, такие как куки и идентификаторы сеансов пользователей, ставят под угрозу конфиденциальность данных. Если эти сессионные данные сочетаются с другими доступными данными, злоумышленники могут получить доступ к ним. А еще некоторые веб-приложения кэшируют данные сессии, что создает соблазн для атакующих захватить сессии через компрометированные прокси и шлюзы.

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

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

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

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

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

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

Пользовательская валидация и защита от CSRF

CSRF Токены

Так вот, обычно сервер создает своего рода "печать" (токен), связанную с текущей сессией пользователя. Когда пользователь посылает запрос, этот токен включается как своего рода валидационный билет. Потом сервер сравнивает этот токен в запросе с сохраненным у себя. Если они не совпадают, сервер просто отвергает запрос. Это затрудняет хакерам создать поддельный HTTP-запрос, который сервер примет. А еще токены CSRF генерируются так, чтобы быть непредсказуемыми, используя временные метки и псевдослучайные числа. Это добавляет еще слой безопасности, делая сложным анализ токенов хакерами.

Техники предотвращения уязвимостей JavaScript

Очистка данных пользователя

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

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

Политики безопасности контента (CSP)

Чтобы предотвратить уязвимости, связанные с источниками JavaScript, мы используем политики безопасности контента. CSP добавляет дополнительный слой защиты, указывая, какие источники данных могут взаимодействовать с веб-приложением. Эти директивы указываются в заголовках ответов HTTP, определяя разрешенные источники для веб-активов. Браузер, зная эти директивы, ограничит выполнение контента только из разрешенных источников.

Например:

• default-src: директива по умолчанию для большинства других директив.
• script-src: белый список источников для сценариев.
• style-src: определяет источники для стилевых таблиц CSS.
• connect-src: разрешенные источники для прямых соединений.
• object-src: управляет источниками плагинов.
• img-src: указывает источники изображений.
• font-src: определяет источники для загрузки шрифтов.

Кодирование/экранирование пользовательского ввода

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

Проверка целостности субресурсов

Важно проверять целостность внешних сценариев перед их загрузкой с серверов хостов для выполнения. Современные браузеры поддерживают SRI (Subresource Integrity), проверяя внешние сценарии с использованием криптографических хэшей. Значение хэша генерируется и добавляется к HTML-коду, обеспечивая проверку действительности внешних файлов JavaScript.

Лучшие практики предотвращения атак JavaScript

Некоторые советы, чтобы избежать уязвимостей JavaScript:

• Избегайте использования функции eval().
• Не передавайте токены CSRF через сессии, используйте их скрытыми полями или в заголовках AJAX.

Заключение: Взлеты и Падения JavaScript в Мире Программирования

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

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

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

Так что, несмотря на все вызовы и трудности, JavaScript продолжает быть королем веб-программирования. И пусть JavaScript продолжает вдохновлять нас на новые творческие высоты! Happy coding, друзья!