Прослушать статью

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

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

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

Что мне нужно знать о JavaScript?

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

В прошлом приложения JavaScript выполнялись на стороне клиента. С появлением Node.js, Angular.js, Vue.js и подобных фреймворков для веб-разработки JavaScript стал одним из основных элементов серверной веб-разработки. Какие бы уязвимости ни были в JavaScript, они могут повлиять как на клиент, так и на сервер, и крайне важно обеспечить безопасность обоих концов.

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

10 главных уязвимостей безопасности JavaScript

Проект Open Worldwide Application Security Project (OWASP) ежегодно публикует 10 основных рисков безопасности веб-приложений. Хотя не все из них связаны с JavaScript, многих повторяющихся проблем, с которыми мы сталкиваемся каждый год, можно было бы избежать, отдав приоритет безопасности JavaScript. Давайте рассмотрим некоторые распространенные уязвимости JavaScript, многие из которых есть и продолжают появляться в списке.

1. Межсайтовый скриптинг (XSS)

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

Межсайтовый скриптинг существует в трех формах; постоянные, отражающие и основанные на DOM.

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

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

На основе DOM: эта атака использует преимущества «объектной модели документа». При атаке XSS на основе DOM сервер никогда не затрагивается; все происходит в браузере жертвы (аналогично рефлексивному XSS). Атака возможна, если приложение записывает данные в DOM без надлежащей очистки.

Все эти атаки можно предотвратить

  • Надлежащая очистка пользовательского ввода (например, не считывание пользовательского ввода как кода)
  • Использование выходной кодировки (преобразование специальных символов в альтернативные, например, преобразование символа ‹ в строку)
  • Использование политики безопасности контента

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

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

Это отличается от отраженной атаки XSS. Атака CSRF использует аутентификацию жертвы на целевом веб-сайте. Запрос сделан в другом месте (через вредоносную ссылку), но уязвимый веб-сайт считает, что запрос был сделан внутри (на его собственном сайте). Отсюда подделка межсайтовых запросов.

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

3. Небезопасные прямые ссылки на объекты (IDOR)

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

Например, если банк использовал такие URL-адреса, как «www.bank.com/account?id=1234567», где «1234567» — фактический номер счета, злоумышленник может заменить этот номер в URL-адресе на любой случайный банковский счет. Если приложение не выполняет надлежащие проверки, злоумышленник может получить доступ к информации, которой в противном случае он не должен был бы иметь.

То же самое относится к любому типу внутренних ссылок на объекты, таким как имена файлов или профили пользователей.

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

4. Неправильные настройки безопасности

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

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

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

5. Разоблачение конфиденциальных данных

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

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

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

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

6. Сломанная аутентификация

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

  • Разрешение слабых паролей, которые можно легко угадать или подобрать методом грубой силы
  • Фиксация сеанса — когда злоумышленник устанавливает идентификатор сеанса пользователя перед входом в систему.
  • Перехват сеанса — когда веб-приложение неправильно проверяет идентификаторы сеанса или использует предсказуемые идентификаторы; злоумышленник может украсть или «захватить» сеанс легитимного пользователя, используя тот же идентификатор
  • Если в приложении нет политики, ограничивающей попытки входа в систему (количество неудачных попыток на учетную запись пользователя или на IP-адрес), злоумышленники могут попытаться взломать вход

7. Недостаточное ведение журнала и мониторинг

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

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

8. Небезопасная десериализация

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

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

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

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

Существует несколько инструментов для сканирования и аудита ваших приложений на наличие таких уязвимостей.

10. Подделка запросов на стороне сервера (SSRF)

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

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

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

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

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

Рекомендации по безопасности JavaScript

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

Проверка ввода и очистка

Удалите или измените символы и элементы, которые могут нанести вред, например символы, используемые в сценариях: < ! -- etc.

Убедитесь, что ввод соответствует ожидаемому формату. Это может защитить от атак XSS, IDOR и SSRF.

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

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

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

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

Токены CSRF и атрибут файла cookie SameSite

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

Надежный контроль доступа

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

Безопасное хранилище паролей и многофакторная аутентификация

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

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

Шифрование данных в состоянии покоя и в пути

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

Регулярные аудиты безопасности и управление зависимостями

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

Встраивание безопасности в дизайн приложений

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

Документация и просмотр журнала

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

Заключение

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

Полный курс веб-тестирования на проникновение и Bug Bounty

Часто задаваемые вопросы

Какие наиболее распространенные уязвимости JavaScript?

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

Подвержен ли JavaScript уязвимости log4j?

Является ли JavaScript уязвимым для XSS?

Какие распространенные ошибки в JavaScript?

Узнайте ВЗЛОМ И ЭТИЧЕСКИЙ ВЗЛОМ ОТ А ДО Я

КАТЕГОРИИ

КодингВзлом

  • Кассандра Ли
  • Кассандра — писатель, художник, музыкант и технолог, которая устанавливает связи между дисциплинами: кибербезопасностью, письмом/журналистикой, искусством/дизайном, музыкой, математикой, технологиями, образованием, психологией и многим другим. Она открыто выступает за девочек и женщин в STEM с 2010-х годов, написав для Huffington Post, Международной математической олимпиады 2016 года и Дня Ады Лавлейс, и для нее большая честь присоединиться к StationX. Вы можете найти Cassandra в LinkedIn и Linktree.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Партнерское раскрытие: этот пост может содержать партнерские ссылки