10 наиболее распространенных уязвимостей веб-безопасности
Оливер Джонс
OWASP или Open Web Security Project — это некоммерческая благотворительная организация, деятельность которой направлена на повышение безопасности программного обеспечения и веб-приложений.
Организация публикует список основных уязвимостей веб-безопасности на основе данных различных организаций по безопасности.
Уязвимости веб-безопасности имеют приоритет в зависимости от возможности использования, обнаружения и воздействия на программное обеспечение.
- Возможность использования –Что необходимо для эксплуатации уязвимости безопасности? Наивысшая возможность использования, когда для атаки нужен только веб-браузер, а наименьшая — продвинутое программное обеспечение и инструменты.
- Обнаруживаемость – Насколько легко обнаружить угрозу? Наивысшим значением является информация, отображаемая в URL-адресе, форме или сообщении об ошибке, а наименьшим значением является исходный код.
- Удар или повреждение –Какой ущерб будет нанесен, если уязвимость безопасности будет обнаружена или атакована? Самый высокий показатель — полный сбой системы, а самый низкий — отсутствие вообще ничего.
Основная цель OWASP Top 10 — информировать разработчиков, дизайнеров, менеджеров, архитекторов и организации о наиболее важных уязвимостях безопасности.
Топ-10 уязвимостей безопасности по версии OWASP Top 10:
SQL-инъекция
Описание
Инъекция — это уязвимость безопасности, которая позволяет злоумышленнику изменить серверную часть SQL операторы путем манипулирования данными, предоставленными пользователем.
Внедрение происходит, когда пользовательский ввод отправляется интерпретатору как часть команды или запроса и заставляет интерпретатор выполнять непредусмотренные команды и дает доступ к неавторизованным данным.
Команда SQL, которая при выполнении веб-приложения также может предоставить доступ к внутренней базе данных.
импликация
- Злоумышленник может внедрить вредоносный контент в уязвимые поля.
- Конфиденциальные данные, такие как имена пользователей, пароли и т. д., можно прочитать из базы данных.
- Данные базы данных можно изменить (вставить/обновить/удалить).
- Администрация Operaоперации могут выполняться в базе данных
Уязвимые объекты
- Поля ввода
- URL-адреса, взаимодействующие с базой данных.
Примеры:
- SQL-инъекция на странице входа
Вход в приложение без действительных учетных данных.
Доступно действительное имя пользователя, а пароль недоступен.
Тестовый URL: http://demo.testfire.net/default.aspx
Имя пользователя: sjones
Пароль: 1=1’ или pass123.
SQL-запрос создан и отправлен в интерпретатор, как показано ниже.
ВЫБЕРИТЕ * ИЗ Пользователей ГДЕ Имя_пользователя = sjones И Пароль = 1=1’ или pass123;
Рекомендации
- Белый список полей ввода
- Избегайте отображения подробных сообщений об ошибках, которые могут быть полезны злоумышленнику.
Скрипты для сайта
Описание
Межсайтовый скриптинг также известен как XSS.
XSS-уязвимости нацелены на сценарии, встроенные в страницу, которые выполняются на стороне клиента, то есть в браузере пользователя, а не на стороне сервера. Эти недостатки могут возникнуть, когда приложение берет ненадежные данные и отправляет их в веб-браузер без надлежащей проверки.
Злоумышленники могут использовать XSS для выполнения вредоносных сценариев на пользователях (в данном случае в браузерах жертвы). Поскольку браузер не может знать, является ли сценарий надежным или нет, сценарий будет выполнен, и злоумышленник сможет перехватить файлы cookie сеанса, испортить веб-сайты или перенаправить пользователя на нежелательные и вредоносные веб-сайты.
XSS — это атака, которая позволяет злоумышленнику выполнять сценарии в браузере жертвы.
Последствия:
- Воспользовавшись этой уязвимостью безопасности, злоумышленник может внедрить в приложение сценарии, украсть файлы cookie сеанса, испортить веб-сайты и запустить вредоносное ПО на компьютерах жертвы.
Уязвимые объекты
- Поля ввода
- URL-адреса
Примеры
1. http://www.vulnerablesite.com/home?”<script>alert(“xss”)</script>
При запуске приведенного выше сценария в браузере будет отображено окно сообщения, если сайт уязвим к XSS.
Более серьезная атака может быть осуществлена, если злоумышленник хочет отобразить или сохранить файлы cookie сеанса.
2. http://demo.testfire.net/search.aspx?txtSearch <iframe> http://google.com ширина = 500 высота 500>
При запуске приведенного выше сценария браузер загрузит невидимый фрейм, указывающий на http://google.com.
Атаку можно сделать серьезной, запустив в браузере вредоносный скрипт.
Рекомендации
- Поля ввода белого списка
- Кодирование ввода-вывода
Сломанная аутентификация и управление сеансом
Описание
Веб-сайты обычно создают файл cookie сеанса и идентификатор сеанса для каждого действующего сеанса, и эти файлы cookie содержат конфиденциальные данные, такие как имя пользователя, пароль и т. д. Когда сеанс завершается либо выходом из системы, либо внезапным закрытием браузера, эти файлы cookie должны быть признаны недействительными, т.е. для каждого сеанса. должен быть новый файл cookie.
Если файлы cookie не признаны недействительными, конфиденциальные данные будут существовать в системе. Например, если пользователь использует общедоступный компьютер (кибер-кафе), файлы cookie уязвимого сайта остаются в системе и доступны злоумышленнику. Злоумышленник использует тот же общедоступный компьютер, через некоторое время конфиденциальные данные будут скомпрометированы.
Точно так же пользователь, использующий общедоступный компьютер, вместо выхода из системы внезапно закрывает браузер. Злоумышленник использует ту же систему, при посещении одного и того же уязвимого сайта будет открыт предыдущий сеанс жертвы. Злоумышленник может делать все, что захочет, начиная от кражи информации профиля, данных кредитной карты и т. д.
Необходимо выполнить проверку, чтобы определить надежность аутентификации и управления сеансом. Ключи, токены сеанса и файлы cookie должны быть реализованы правильно, без ущерба для паролей.
Уязвимые объекты
- Идентификаторы сеансов, представленные в URL-адресе, могут привести к атаке с фиксацией сеанса.
- Идентификаторы сеансов одинаковы до и после выхода из системы и входа в систему.
- Таймауты сеансов реализованы неправильно.
- Приложение назначает один и тот же идентификатор сеанса для каждого нового сеанса.
- Аутентифицированные части приложения защищены с помощью SSL, а пароли хранятся в хешированном или зашифрованном формате.
- Сеанс может быть повторно использован пользователем с низким уровнем привилегий.
импликация
- Воспользовавшись этой уязвимостью, злоумышленник может перехватить сеанс, получить несанкционированный доступ к системе, что позволит раскрыть и изменить несанкционированную информацию.
- Сеансы могут быть взломаны с использованием украденных файлов cookie или сеансов с использованием XSS.
Примеры
- Приложение для бронирования авиабилетов поддерживает перезапись URL-адресов, помещая идентификаторы сеансов в URL-адрес:http://Examples.com/sale/saleitems;jsessionid=2P0OC2oJM0DPXSNQPLME34SERTBG/dest=Maldives (Продажа билетов на Мальдивы) Авторизованный пользователь сайта хочет сообщить своим друзьям о распродаже и отправляет электронное письмо. Друзья получают идентификатор сеанса и могут быть использованы для несанкционированного изменения или неправильного использования сохраненных данных кредитной карты.
- Приложение уязвимо для XSS, благодаря которому злоумышленник может получить доступ к идентификатору сеанса и может быть использован для перехвата сеанса.
- Таймауты приложений установлены неправильно. Пользователь использует общедоступный компьютер и закрывает браузер вместо выхода из системы и уходит. Некоторое время спустя злоумышленник использует тот же браузер, и сеанс аутентифицируется.
Рекомендации
- Все требования к аутентификации и управлению сеансами должны быть определены в соответствии со стандартом проверки безопасности приложений OWASP.
- Никогда не раскрывайте учетные данные в URL-адресах или журналах.
- Также следует приложить серьезные усилия, чтобы избежать недостатков XSS, которые могут быть использованы для кражи идентификаторов сеансов.
Небезопасные прямые ссылки на объекты
Описание
Это происходит, когда разработчик предоставляет ссылку на внутренний объект реализации, например файл, каталог или ключ базы данных, как в URL-адресе, так и в качестве параметра FORM. Злоумышленник может использовать эту информацию для доступа к другим объектам и организовать будущую атаку для доступа к неавторизованным данным.
импликация
- Используя эту уязвимость, злоумышленник может получить доступ к неавторизованным внутренним объектам, изменить данные или скомпрометировать приложение.
Уязвимые объекты
- В URL.
Примеры:
Изменение «идентификатора пользователя» в следующем URL-адресе может позволить злоумышленнику просмотреть информацию другого пользователя.
http://www.vulnerablesite.com/userid=123 Изменено на http://www.vulnerablesite.com/userid=124
Злоумышленник может просмотреть чужую информацию, изменив значение идентификатора пользователя.
Рекомендации:
- Внедрить проверки контроля доступа.
- Избегайте раскрытия ссылок на объекты в URL-адресах.
- Проверьте авторизацию для всех ссылочных объектов.
Подделка межсайтовых запросов
Описание
Подделка межсайтового запроса — это поддельный запрос, полученный с межсайтового запроса.
CSRF-атака — это атака, которая происходит, когда вредоносный веб-сайт, электронное письмо или программа заставляет браузер пользователя выполнять нежелательное действие на доверенном сайте, на котором пользователь в настоящее время аутентифицирован.
Атака CSRF вынуждает браузер жертвы, вошедшей в систему, отправить поддельный HTTP-запрос, включая файл cookie сеанса жертвы и любую другую автоматически включенную аутентификационную информацию, уязвимому веб-приложению.
Ссылка будет отправлена злоумышленником жертве, когда пользователь нажмет на URL-адрес при входе на исходный веб-сайт, данные будут украдены с веб-сайта.
импликация
- Используя эту уязвимость, злоумышленник может изменить информацию профиля пользователя, изменить статус, создать нового пользователя от имени администратора и т. д.
Уязвимые объекты
- Страница профиля пользователя
- Формы учетных записей пользователей
- Страница бизнес-операции
Примеры
Жертва зашла на сайт банка, используя действительные учетные данные. Он получает письмо от злоумышленника, в котором говорится: «Пожалуйста, нажмите здесь, чтобы пожертвовать 1 доллар на благотворительность».
Когда жертва нажмет на нее, будет создан действительный запрос на пожертвование 1 доллара на конкретную учетную запись.
http://www.vulnerablebank.com/transfer.do?account=cause&amount=1
Злоумышленник перехватывает этот запрос, создает приведенный ниже запрос и встраивает в кнопку с надписью «Я поддерживаю причину».
http://www.vulnerablebank.com/transfer.do?account=Attacker&amount=1000
Поскольку сессия аутентифицирована и запрос поступает через веб-сайт банка, сервер переведет злоумышленнику 1000 долларов.
Рекомендация
- Обеспечьте присутствие пользователя при выполнении конфиденциальных действий.
- Внедрить такие механизмы, как CAPTCВысокая доступность, повторная аутентификация и уникальные токены запроса.
Неправильная настройка безопасности
Описание
Конфигурация безопасности должна быть определена и развернута для приложения, платформ, сервера приложений, веб-сервера, сервера базы данных и платформы. Если они настроены правильно, злоумышленник может получить несанкционированный доступ к конфиденциальным данным или функциям.
Иногда такие недостатки приводят к полной компрометации системы. Поддержание программного обеспечения в актуальном состоянии также является хорошей защитой.
импликация
- Воспользовавшись этой уязвимостью, злоумышленник может перечислить базовую технологию и информацию о версии сервера приложений, информацию о базе данных и получить информацию о приложении для проведения еще нескольких атак.
Уязвимые объекты
- URL
- Поля формы
- Поля ввода
Примеры
- Консоль администратора сервера приложений устанавливается автоматически и не удаляется. Аккаунты по умолчанию не изменяются. Злоумышленник может войти в систему с паролями по умолчанию и получить несанкционированный доступ.
- Листинг каталогов не отключен на вашем сервере. Злоумышленник обнаруживает и может просто перечислить каталоги, чтобы найти любой файл.
Рекомендации
- Сильная архитектура приложения, обеспечивающая хорошее разделение и безопасность между компонентами.
- Измените имена пользователей и пароли по умолчанию.
- Отключите списки каталогов и внедрите проверки контроля доступа.
Небезопасное криптографическое хранилище
Описание
Небезопасное криптографическое хранилище — это распространенная уязвимость, которая существует, когда конфиденциальные данные не хранятся безопасно.
Учетные данные пользователя, информация профиля, сведения о состоянии здоровья, данные кредитной карты и т. д. относятся к конфиденциальной информации на веб-сайте.
Эти данные будут храниться в базе данных приложения. Если эти данные хранятся неправильно, без использования шифрования или хеширования*, они будут уязвимы для злоумышленников.
(*Хеширование — это преобразование символов строки в более короткие строки фиксированной длины или ключ. Для расшифровки строки должен быть доступен алгоритм, используемый для формирования ключа)
импликация
- Используя эту уязвимость, злоумышленник может украсть, изменить такие слабозащищенные данные для кражи личных данных, мошенничества с кредитными картами или других преступлений.
Уязвимые объекты
- База данных приложений.
Примеры
В одном из банковских приложений база данных паролей использует несоленые хэши* для хранения всех паролей. Ошибка внедрения SQL позволяет злоумышленнику получить файл паролей. Все несоленые хеши можно мгновенно перебрать, тогда как на соленые пароли потребуются тысячи лет.
(*Несоленые хэши — соль — это случайные данные, добавляемые к исходным данным. Соль добавляется к паролю перед хешированием)
Рекомендации
- Обеспечьте соответствующие строгие стандартные алгоритмы. Не создавайте собственные криптографические алгоритмы. Используйте только утвержденные общедоступные алгоритмы, такие как AES, криптография с открытым ключом RSA, SHA-256 и т. д.
- Убедитесь, что резервные копии за пределами офиса зашифрованы, но управление ключами и их резервное копирование выполняются отдельно.
Невозможность ограничить доступ к URL-адресу
Описание
Веб-приложения проверяют права доступа к URL-адресам перед отображением защищенных ссылок и кнопок. Приложениям необходимо выполнять аналогичные проверки контроля доступа каждый раз при доступе к этим страницам.
В большинстве приложений привилегированные страницы, местоположения и ресурсы не отображаются привилегированным пользователям.
Благодаря разумному предположению злоумышленник может получить доступ к страницам привилегий. Злоумышленник может получить доступ к конфиденциальным страницам, вызывать функции и просматривать конфиденциальную информацию.
импликация
- Воспользовавшись этой уязвимостью, злоумышленник может получить доступ к неавторизованным URL-адресам, не входя в приложение и не воспользовавшись уязвимостью. Злоумышленник может получить доступ к конфиденциальным страницам, вызывать функции и просматривать конфиденциальную информацию.
Уязвимые объекты:
- URL-адреса
Примеры
- Злоумышленник замечает, что URL-адрес указывает роль как «/user/getaccounts». Он модифицируется как «/admin/getaccounts».
- Злоумышленник может добавить роль к URL-адресу.
http://www.vulnerablsite.com можно изменить как http://www.vulnerablesite.com/admin
Рекомендации
- Внедрите строгие проверки контроля доступа.
- Политики аутентификации и авторизации должны быть основаны на ролях.
- Ограничьте доступ к нежелательным URL-адресам.
Недостаточная защита транспортного уровня
Описание
Занимается обменом информацией между пользователем (клиентом) и сервером (приложением). Приложения часто передают по сети конфиденциальную информацию, такую как данные аутентификации, данные кредитной карты и токены сеанса.
Использование слабых алгоритмов, использование просроченных или недействительных сертификатов или отказ от использования SSL может сделать соединение доступным для ненадежных пользователей, что может поставить под угрозу веб-приложение или украсть конфиденциальную информацию.
импликация
- Воспользовавшись этой уязвимостью веб-безопасности, злоумышленник может перехватить учетные данные законного пользователя и получить доступ к приложению.
- Может украсть данные кредитной карты.
Уязвимые объекты
- Данные передаются по сети.
Рекомендации
- Включите безопасный HTTP и принудительно передавайте учетные данные только через HTTPS.
- Убедитесь, что ваш сертификат действителен и срок его действия не истек.
Примеры:
1. Приложение, не использующее SSL, злоумышленник будет просто отслеживать сетевой трафик и наблюдать за аутентифицированным файлом cookie сеанса жертвы. Злоумышленник может украсть этот файл cookie и выполнить атаку «Человек посередине».
Непроверенные перенаправления и перенаправления
Описание
Веб-приложение использует несколько методов для перенаправления пользователей на другие страницы по назначению.
Если при перенаправлении на другие страницы не проводится надлежащая проверка, злоумышленники могут воспользоваться этим и перенаправить жертв на фишинговые сайты или сайты с вредоносным ПО или использовать переадресацию для доступа к неавторизованным страницам.
импликация
- Злоумышленник может отправить пользователю URL-адрес, содержащий подлинный URL-адрес, к которому добавлен закодированный вредоносный URL-адрес. Пользователь, просто увидев подлинную часть отправленного злоумышленником URL-адреса, может просмотреть его и стать жертвой.
Примеры
1.http://www.vulnerablesite.com/login.aspx?redirectURL=ownsite.com
Изменено на
http://www.vulnerablesite.com/login.aspx?redirectURL=evilsite.com
Рекомендации
- Просто избегайте использования перенаправлений и перенаправлений в приложении. Если они используются, не используйте параметры пользователя при расчете пункта назначения.
- Если параметры назначения невозможно избежать, убедитесь, что предоставленное значение допустимо и разрешено для пользователя.
