Веб безопасность: Безопасность веб-приложений / Хабр

Безопасность веб-приложений / Хабр

TL;DR

Статья является обзором на книгу «Безопасность веб-приложений» Эндрю Хоффмана, варианты векторов атак и защиты из книги разобраны на «реальных» примерах ниже.

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

Сторонние зависимости

Как и все разработчики, Вася использует библиотеки, чтобы написать свой сайт как можно быстрее и удобнее. Библиотеки он берёт как общепризнанные и популярные, так и увиденные им где-то в статьях на Медиуме/Хабре/<ЛюбойДругойРесурс>. При запуске прототипа магазина у себя на локальной машине Вася видит загрузку CPU максимум на всех ядрах, при заходе на любую страницу через браузер. Открыв вкладку network Вася видит много запросов на какую-то крипто биржу, и понимает, что в его приложении где-то лежит встроенный майнер.

Проблема с вредоносным кодом в зависимостях не нова. Может произойти всё что угодно — от майнинга до слития данных злоумышленнику. Пакеты с вредоносным кодом могут быть как в популярных библиотеках, так и в мимикрирующих под них — пример 1, пример 2, пример 3. Помимо этого в самих библиотеках могут быть CVE-уязвимости.

Как себя обезопасить?

• Использовать сканер уязвимостей. Например, у Python есть safety, у npm — встроенный npm audit.

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

• Использовать зависимости только определённых версий. Никогда не знаешь в какой версии появляется та или иная уязвимость, поэтому крайне рекомендую использовать статичную версию, ещё лучше — с хэшем, т.к. версию можно подменить. а хэш — нет. Но это не значит, что версия должна быть старая. Она просто должна быть зафиксирована и проверена, хотя бы сканером уязвимостей, перед её использованием. В Python можно использовать команду pip freeze или другие утилиты, такие как pip-compile-multi, poetry, pipenv и другие

• Настроить CSP политику. На бэкенде можно задать список разрешённых хостов, откуда фронтенд может скачивать статику. Это может быть полезно, чтобы исключить вариант, когда в ссылке есть ссылка на ссылку на вредоносный код. У Django, как вариант, есть django-csp.

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

XSS

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

Как такое произошло? Ведь Вася думал, что всё предусмотрел. Однако мало обеспечить безопасность зависимостей — нужно сделать безопасным свой код. Вася наткнулся на типичную XSS атаку — он не проверял пользовательский ввод на наличие html и js кода, а после вставлял к себе на страницу как есть.

Как себя обезопасить?

Так как типы XSS атак могут быть разными, то разная может быть и защита. Вася столкнулся с самым простым, но опасным типом — хранимым XSS. Варианты защиты самые разные:

• Периодически сканировать базу — поиск html тегов, их удаление через регулярку

• При записи в базу проверять пользовательский ввод и выводить сообщение об ошибке или молча запрещать сохранять потенциальный XSS в базу

• Если html теги всё же нужны — сделать список разрешённых тегов

• Добавление данных на страницу исключительно как строку (innerText вместо innerHTML)

Также XSS может быть отражённым. Например:

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

2. При переходе по ссылке пользователь становится захваченным.

3. Скрипт выполняется в браузере пользователя.

4. Браузер отправляет cookies злоумышленнику, обеспечивая доступ к личным данным пользователя.

Как себя обезопасить?

• Проверка uri параметров перед их выполнением. Например, какой-то из параметров в процессе выполнения может вставляться через element.innerHTML на страницу.

• Обязательный urlencode ссылок перед их выполнением. К примеру, в JavaScript можно вставить ссылку в a.href атрибут, который выполняет urlencode.

XSS на базе DOM. Это тот же хранимый XSS, который не обязательно может храниться в базе. Например, вредоносный код в document. cookie. Или же внутри SVG/XML кода.

Как себя обезопасить?

• По возможности избегать element.innerHTML, element.outerHTML, Blob, SVG, document.write, document.writeln, DOMParser.parseFromString, document.implementation.

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

Потратив время на изучение XSS Вася обезопасил себя как только мог, проверил возможные места, где HTML мог вставляться в DOM, не пользуется innerHTML и подобными и всегда делает urlencode ссылок.

XXE

Казалось бы, он защитился везде как только можно, однако в какой-то момент он переходит на свою страницу с обратной связью и снова видит:

Что же теперь могло произойти? Дело в том, что при открытии страницы с обратной связью для Васи также подгружается аватар пользователя. Этот аватар может быть SVG файлом. А внутри SVG файла и находится этот злополучный алерт! Вася столкнулся с типичной XXE атакой, ведь SVG файл это тот же XML! Васе повезло уже в который раз, что там такой безобидный вредоносный код. А ведь всё могло закончиться куда хуже.

Как себя обезопасить?

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

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

• Заменить XML на JSON (YAML, BSON, EDN и др), если возможно

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

CSRF

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

Вася столкнулся с первой серьёзной проблемой, в которой ему пришлось возместить деньги пользователю, т.к. Вася дорожит репутацией. А проблема заключается в том, что у Васи нет CSRF защиты для эндпоинтов с изменением состояния (CRUD запросов). Злоумышленник встроил скрипт на свой сайт, чтобы тайно делался запрос от пользователя на оплату товаров в магазине Васи. Вася польщён, что для его интернет-магазина есть целый вредоносный скрипт, однако решает защититься.

Как себя обезопасить?

• Запросы GET/HEAD/OPTION должны быть без сохранения состояния

• CSRF защита должна быть на уровне приложения в целом, а не на уровне отдельных вьюх. В Django, к примеру, есть встроенная мидлваря CsrfViewMiddleware.

Правда, сейчас этот вектор атаки уже не так актуален

Существуют разные источники, в которых говорится, что 99% от этой проблемы ушло с помощью SameSite атрибута в куках, которые поддерживаются уже достаточно долго во всех современных браузерах. Однако это не спасёт, если пользователь заходит со старого браузера или чтобы защититься от атаки с сабдомена (если SameSite=Lax). Подробнее по ссылке выше.

Вася подключил CSRF мидлварю в свой фреймворк и попробовал пройти по ссылкам, которые любезно предоставил Петя, увидел пару странных запросов в логах, но с карты Васи ничего не списалось. Вася перепроверил, теперь его GET/HEAD/OPTIONзапросы точно не меняют состояние.

CORS

Василий исправил очередную уязвимость и неимоверно горд собой! Правда, теперь он скорее ждёт — а что же будет дальше и решил изучить наперёд ещё виды защиты своего сайта. И его взгляд упал на CORS. CORS позволяет выполнять запросы с другого домена, который разрешён настройками CORS. По умолчанию CORS запрещён. Что же ему делать?

• Внимательно прочитать все заголовки CORS и заняться их тонкой настройкой

• Изучить и использовать уже существующие библиотеки для реализации CORS механизма. В Python у Django, к примеру, есть замечательная библиотека django-cors-headers

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

Code injection

Магазин у Васи работает уже не одну неделю и начинает приносить ему прибыль. Он вносит всё больше фич, даже решил сделать очень кастомизированный интерфейс для просмотра заказов. Спустя пару дней ему приходят резко сотни отзывов, что пользователи не могут зайти в аккаунт. Вася с ужасом обнаруживает, что в его базе пропали все пользователи! В срочном порядке он накатывает бэкап базы за вчера и быстро решает проблемы пользователей по поводу пропавших заказов. Но также, в срочном порядке, закопавшись в код, ищет причину проблемы. И по логам находит странный запрос от одного из пользователей, после которого повалили обращения. И видит там запрос, примерно как на картинке выше. Вася начинает искать решение и открывает для себя SQL Injection.

Как себя обезопасить?

SQL Injection лишь один из нескольких возможных Code Injection. Другие связаны с запуском произвольного запроса в командной строке через параметры запроса, или, к примеру, перезаписи существующего файла статики из-за конфликта имён и плохо спроектированного API.

• Защита от SQL инъекций

  • Использовать orm или query builder

  • Подготовленные операторы (при использовании raw sql, например PREPARE в PostgreSQL) 

  • Экранирование SQL с помощью средств библиотеки

• Защита от других видов внедрения

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

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

  • Белый список команд (проще контролировать определённые команды, нежели запрещать все остальные).

Теперь Вася осторожнее и вдумчиво пилит новые фичи, предоставляя пользователям только то, что ему нужно, прикрыв старые SQL Injection уязвимости и с помощью ORM и через возможности экранирования в psycopg2 библиотеке там, где ORM использовать не получается.

DoS

Интернет-магазин Василия имеет популярность, его DAU насчитывает уже более трёхсот, а WAU — более тысячи пользователей. Он собирается в скором времени увольняться с основной работы, т.к. его интернет-магазин начал приносить уже весомую прибыль. Но в один из дней Вася замечает, что его интернет-магазин перестал работать и отдаёт 521 Web Server Is Down. Василий судорожно начинает, в очередной раз, читать логи и видит огромную активность у анонимов на главной странице, из-за которых заняты все CPU ресурсы. Он раньше только слышал, но понимает, что это DDoS.

Вася столкнулся лишь с одной разновидностью DoS атаки. Существует ещё парочка:

• ReDoS (regular-expression-based DoS) — атака на эндпоинты, использующие регекс, из-за вызова которых в большом количестве может замедлиться работа приложения. Например, регекс проверки пароля или составленные пользователем регексы для какой-либо задачи (evil regex, malicious regex) или слишком сложные, составленные разработчиком. Правильно подобранная строка может парситься на порядок, а то и несколько порядков дольше, чем остальные.

• логические DoS уязвимости — злоумышленник шлёт много запросов, требующих много вычислительных ресурсов.

Как защититься:

• Фиксация всех запросов вместе с количеством времени, которое было потрачено на их выполнение

• Для ReDoS атак:

  • Искать регулярное выражение, которое приводит к поиску с возвратом, использовать инструменты OSS для поиска, синтаксический анализатор. Я для себя открыл regexploit.

  • По возможности запретить пользовательский ввод регулярных выражений

• Для логических DoS атак:

• для DDoS атак: 

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

Безопасное программирование

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

• чёрные списки -> белые списки

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

• разрешения на взаимодействие с системой или внешними компонентами вместо «рута» (rwx права на определённые папки, доступы в базу в зависимости от роли)

• разделение клиента и сервера (не должны брать ответственность друг друга)

Также Вася задумался о термине «Безопасное программирование» и систематизировал свои знания:

• Анализ требований к ПО

  • какими данными обменивается клиент и сервер

  • как эти данные интерпретируются сервером

  • оценка баз данных, журналов регистрации, загруженных файлов, библиотек и всего, что вызывают конечные API точки

  • оставшаяся часть функциональности, предоставляемая клиенту

  • проверка на доступы API точек

  • оставшийся код

• Аутентификация и авторизация

  • использовать SSL/TLS, чтоб обеспечить защиту от MITM атак.  

  • защита учётных данных (как и где эти данные будут храниться. Доступы к ним. и т.п.), 

  • хэширование паролей, 

  • 2FA

Итог

В самом начале Вася недооценивал необходимость базовой защиты своего интернет-магазина, т.к. не считал, что это полезная трата времени. Однако время показало, что он заблуждался, и это чуть ли не самое важное после фич. В последние дни, во время хакерских взломов, защита веб-приложений актуальна как никогда. Я понимаю, что описал лишь самые базовые вещи, и что защита — это не сделал и забыл, а процесс, актуализировать который нужно постоянно, чтобы не обнаружить потерю пользовательских данных, репутации и денег. Успехов в создании своего «интернет-магазина», друзья!

Безопасность сайтов и веб-приложений

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

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

То есть причинами угроз безопасности — взломов и утечек данных — могут быть:

• Уязвимости самого сайта / приложения перед кибератакой — например, отсутствие защиты от перебора паролей, возможность внедрения стороннего кода (XSS, SQL-инъекции, отсутствие защиты от CSRF)
• Недостаточное быстродействие системы или повышенная ресурсоёмкость обработки запросов, что приводит к уязвимости к атакам типа «отказ в обслуживании» — (D)DoS
• Ошибки, допущенные администратором веб-сервера — несвоевременное обновление ПО или небезопасное конфигурирование сервисов
• Незнание или несоблюдение сотрудниками банальных правил безопасности — простые пароли, ввод данных на фишинговых сайтах, заражение вирусами ПК.

Рекомендации

• Доверяйте разработку требовательных к уровню безопасности сервисов опытным специалистам. Новички, как правило, могут добиться работоспособности приложения, но не в состоянии учесть риски взлома и атак типа «отказ в обслуживании».
• Администрированием сервера должен на регулярной основе заниматься компетентный специалист, большинство заражений сайтов вирусами происходит из-за того, что серверное ПО никто не обновляет, а очень много утечек данных связаны с неверным конфигурированием серверных служб (из банального — открытые «в мир» порты систем хранения).
• Обучайте пользователей основам информационной безопасности, урезайте права до необходимого для работы минимума и используйте мониторинг доступа к чувствительной информации. Огромное количество проблем связано именно с некомпетентностью нетехнического персонала, возникающих как из-за банальной некомпетентности (попался на фишинг, «случайно» удалил данные), так и по злому умыслу (хищение клиентской базы, слив заказов конкурентам и т.д.)
• Если вас мучают сомнения о безопасности вашего сайта, то закажите аудит безопасности у независимой компании. Мы на своей практике были по обе стороны этого процесса — и мы проверяли сторонние разработки на уязвимости, и разработанные нами системы проверяли — особенно много и тщательно в банковской / финансовой сфере.

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

Информационная безопасность — обеспечение конфиденциальности, целостности и доступности информации.

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

Узнать больше →

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

DoS-атака — это атака типа «отказ в обслуживании» — Denial of Service. DDоS — это атака того же типа, но распределённая (distributed), то есть производящаяся с более чем одного атакующего компьютера.

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

Узнать больше →

DDoS — весьма часто используемый вектор атаки на веб-приложения, но очень часто его путают с банальными проблемами производительности.

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

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

Узнать больше →

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

Cтатьи по теме:

Вирусы на сайтах

24.01.2019  |  Статьи  —  системное администрирование  /  информационная безопасность  /  веб-разработка

Откуда берутся вирусы на сайтах? Как с ними бороться?

Основные угрозы в информационной безопасности

12.01.2020  |  Статьи  —  системное администрирование  /  информационная безопасность  /  веб-разработка

Попробуем ответить на частый вопрос: «а кому и зачем может понадобиться атаковать проект?» — рассмотрим мотивацию атакующих, проведем их классификацию, а также рассмотрим основные векторы атак, оценим их риски и возможные последствия.

Надёжность, доступность и отказоустойчивость сайтов и веб-приложений

09.08.2019  |  Статьи  —  системное администрирование  /  бэкенд-разработка  /  отказоустойчивость  /  серверы  /  веб-разработка

Действительно серьёзные проекты должны работать без перебоев даже в случае отказа отдельных подсистем. Причин для сбоев в работе немало: выход из строя «железа», сбои программного обеспечения, аварии на уровне дата-центров. Всех этих рисков можно избежать или минимизировать их последствия.

SSH — сетевой протокол для управления серверами

07.11.2019  |  Статьи  —  системное администрирование  /  информационная безопасность  /  протоколы

SSH или Secure Shell («безопасная оболочка») — сетевой протокол прикладного уровня, позволяющий производить удалённое управление операционной системой и туннелирование TCP-соединений (например, для передачи файлов).

XSS — атаки на веб-системы типа «межсайтовый скриптинг»

12.04.2014  |  Статьи  —  фронтенд-разработка  /  информационная безопасность  /  веб-разработка

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

SQL-инъекции — распространённый метод взлома веб-приложений и сайтов

01.04.2019  |  Статьи  —  бэкенд-разработка  /  СУБД  /  хранение данных  /  SQL  /  информационная безопасность  /  веб-разработка  /  серверное ПО

SQL-инъекции — это один из распространённых способов взлома сайтов и веб-приложений, работающих с реляционными базами данных. Этот способ основан на внедрении в выполняемый приложением запрос к базе данных произвольного SQL-кода, переданного злоумышленником.

HTTPS — защищенный протокол передачи гипертекста

14.04.2014  |  Статьи  —  системное администрирование  /  информационная безопасность  /  протоколы

HTTPS — расширение протокола HTTP, поддерживающее шифрование. Передаваемые по протоколу HTTPS данные зашифрованы, что обеспечивает защиту от прослушивания. HTTPS широко используется в мире и поддерживается всеми популярными браузерами.

Тематические технологии:

Веб-безопасность и безопасность веб-сайтов

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

Веб-безопасность является синонимом кибербезопасности и также охватывает безопасность веб-сайтов, которая включает защиту веб-сайтов от атак. Он включает в себя облачную безопасность и безопасность веб-приложений, которые защищают облачные службы и веб-приложения соответственно. Защита виртуальной частной сети (VPN) также подпадает под понятие веб-безопасности.

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

Чтобы соответствовать внутренним политикам, установленным государством критериям или стандартам Open Web Application Security Project (OWASP), специалисты по безопасности учитывают множество факторов. Соблюдение стандартов OWASP помогает сотрудникам службы безопасности соответствовать требованиям отраслевых стандартов в области веб-безопасности.

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

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

Брандмауэры веб-приложений (WAF)

Брандмауэр веб-приложений (WAF) защищает веб-приложения, отслеживая и фильтруя интернет-трафик, проходящий между приложением и Интернетом. Таким образом, WAF работает как безопасный веб-шлюз (SWG). Он обеспечивает защиту веб-приложений от атак, включая межсайтовый скриптинг, включение файлов, межсайтовую подделку, внедрение языка структурированных запросов (SQL) и другие угрозы.

В модели взаимодействия открытых систем (OSI) WAF работает на уровне 7. Несмотря на то, что он работает против многих интернет-угроз, он не предназначен для защиты от всех видов угроз. WAF часто работает в составе набора защитных инструментов, предназначенных для защиты сети, компьютера или приложения. Узнайте больше о том, что такое WAF.

Сканеры безопасности или уязвимостей

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

Инструменты для взлома паролей

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

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

Инструменты фаззинга

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

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

Инструменты тестирования черного ящика

Тестирование «черного ящика» означает проверку системы без каких-либо знаний о том, как она работает. Единственное, что видит тестировщик, — это ввод, который он набирает, и результирующий вывод. Во многих отношениях тестер знает о системе ровно столько, сколько имел бы случайный пользователь.

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

Инструменты тестирования белого ящика

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

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

SQL-инъекция

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

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

Межсайтовый скриптинг

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

Удаленное включение файлов

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

Взлом пароля

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

В других случаях хакеры используют метод, называемый распылением паролей, в котором они используют общие пароли, такие как «12345678» или «пароль123», и пробуют их один за другим, пока не получат доступ. Есть несколько других методов, таких как кейлоггеры или просто поиск записанного пароля и его использование.

Данные нарушения

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

Внедрение кода

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

Затем этот код вносит изменения в работу программного обеспечения и компьютера.

Назначение ресурсов

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

Веб-сканирование

Веб-сканирование включает в себя использование приложения для обхода веб-сайта в поисках уязвимостей, которые могут оставить его открытым для бота, шпионского ПО, руткита, троянского коня или распределенной атаки типа «отказ в обслуживании» (DDoS). Сканер проверяет все страницы сайта, формируя диаграмму со структурой, представляющей макет сайта. Затем он систематически проверяет весь сайт на наличие потенциальных уязвимостей.

Веб-безопасность защищает организацию от некоторых наиболее распространенных интернет-угроз.

Украденные данные

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

Фишинговые схемы

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

Перехват сеанса

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

Вредоносные перенаправления

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

SEO-спам

При спам-атаке с поисковой оптимизацией (SEO) злоумышленники размещают на сайте ненормальные ссылки, комментарии или страницы, чтобы отвлечь посетителей или заставить их посетить вредоносные сайты.

Решение для обеспечения безопасности веб-приложений Fortinet FortiGuard имеет доступ к самым последним уязвимостям, подозрительным шаблонам URL-адресов, ботам, шаблонам типов данных и механизмам эвристического обнаружения. Он использует их, чтобы убедиться, что ваши веб-приложения защищены от угроз.

FortiGuard предлагает несколько методов обнаружения угроз, таких как поиск конкретных сигнатур атак, антивирусов и репутации интернет-протокола (IP). Таким образом, ваша организация может использовать обновления в режиме реального времени, чтобы остановить последние угрозы и снизить затраты на управление и эксплуатацию системы.

Что такое веб-безопасность?

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

Какова цель веб-безопасности?

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

Что такое угрозы веб-безопасности?

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

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

Тремя наиболее распространенными угрозами безопасности являются вредоносное ПО, схемы фишинга и украденные данные.

Что такое риск безопасности?

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

Веб-безопасность | MDN

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

Политика безопасности содержимого (CSP)

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

Безопасность транспортного уровня (TLS)

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

HTTPS

HTTPS ( Безопасный протокол передачи гипертекста ) — это зашифрованная версия протокола HTTP. Он использует SSL или TLS для шифрования всей связи между клиентом и сервером. Это безопасное соединение позволяет клиентам быть уверенными, что они подключены к нужному серверу, и обмениваться конфиденциальными данными.

Строгая транспортная безопасность HTTP

Строгая транспортная безопасность : HTTP-заголовок позволяет веб-сайту указать, что к нему можно получить доступ только с использованием HTTPS.

Прозрачность сертификата

Прозрачность сертификатов — это открытая платформа, предназначенная для защиты от неправильной выдачи сертификатов и отслеживания таких случаев. Вновь выпущенные сертификаты «записываются» в общедоступные, часто независимые журналы CT, которые поддерживают только добавление, криптографически гарантированную запись о выпущенных сертификатах TLS.

Смешанное содержимое

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

Как исправить веб-сайт с заблокированным смешанным содержимым

Если ваш веб-сайт предоставляет страницы HTTPS, весь активный смешанный контент, доставляемый через HTTP на этих страницах, будет заблокирован по умолчанию. Следовательно, ваш веб-сайт может показаться пользователям неработающим (если не загружаются iframe или плагины и т. д.). Пассивное смешанное содержимое отображается по умолчанию, но пользователи могут настроить блокировку и этого типа содержимого. На этой странице объясняется, что вы должны знать как веб-разработчик.

Безопасные контексты

Безопасный контекст — это Window или Worker , для которых есть достаточная уверенность в том, что содержимое было доставлено безопасным образом (через HTTPS/TLS), и для которого возможна связь с контекстами, которые не защищены ограничено. Многие веб-API и функции доступны только в безопасном контексте. Основная цель безопасных контекстов — предотвратить доступ злоумышленников-посредников к мощным API, которые могут еще больше скомпрометировать жертву атаки.

Функции ограничены безопасным контекстом

В этом справочнике перечислены функции веб-платформы, доступные только в безопасном контексте.

Слабые алгоритмы подписи

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

Перенаправление с кодами ответа 301 и 302

писать

Использование файлов cookie HTTP

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

Локальное хранилище

Свойство Window.localStorage объекта Window позволяет серверам сохранять данные о клиенте, сохраняющиеся между сеансами.

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

IFrame без учетных данных

Iframe без учетных данных предоставляет разработчикам механизм загрузки сторонних ресурсов в