OWASP или Open Web Security Project — некоммерческая благотворительная организация, ориентированная на повышение безопасности программного обеспечения и веб-приложений.
Организация публикует список основных уязвимостей веб-безопасности на основе данных различных организаций по безопасности.
Уязвимости веб-безопасности имеют приоритет в зависимости от возможности использования, обнаружения и воздействия на программное обеспечение.
- Эксплуатация —
Что необходимо для использования уязвимости безопасности? Высочайшая эксплуатационная эффективность, когда для атаки требуется только веб-браузер, а минимальная — для программирования и инструментов.
- Обнаруживаемость —
Насколько легко обнаружить угрозу? Самое высокое — это информация, отображаемая в URL, форме или сообщении об ошибке, а самое низкое — исходный код.
- Воздействие или повреждение —
Какой ущерб будет нанесен, если уязвимость безопасности будет обнаружена или атакована? Самое высокое — это полный сбой системы, а самое низкое — вообще ничего.
Основная цель OWASP Top 10 — рассказать разработчикам, дизайнерам, менеджерам, архитекторам и организациям о наиболее важных уязвимостях безопасности.
Топ 10 уязвимостей безопасности согласно OWASP Top 10:
- SQL-инъекция
- Межсайтовый скриптинг
- Сломанная аутентификация и управление сессиями
- Небезопасные прямые ссылки на объекты
- Подделка межсайтовых запросов
- Неправильная настройка безопасности
- Небезопасное криптографическое хранилище
- Неспособность ограничить доступ к URL
- Недостаточная защита транспортного уровня
- Непроверенные перенаправления и пересылки
SQL-инъекция
Описание
Инъекция — это уязвимость безопасности, которая позволяет злоумышленнику изменять внутренние операторы SQL путем манипулирования данными, предоставленными пользователем.
Инъекция происходит, когда пользовательский ввод отправляется интерпретатору как часть команды или запроса и обманывает интерпретатор при выполнении непреднамеренных команд и дает доступ к неавторизованным данным.
Команда SQL, которая при выполнении веб-приложением также может предоставлять внутреннюю базу данных.
импликация
- Злоумышленник может внедрить вредоносный контент в уязвимые поля.
- Конфиденциальные данные, такие как имена пользователей, пароли и т. Д., Могут быть считаны из базы данных.
- Данные базы данных могут быть изменены (Вставить / Обновить / Удалить).
- Операции администрирования могут быть выполнены в базе данных
Уязвимые объекты
- Поля ввода
- URL-адреса, взаимодействующие с базой данных.
Примеры:
- SQL-инъекция на странице входа
Вход в приложение без действительных учетных данных.
Действительное имя пользователя доступно, а пароль недоступен.
Тестовый URL: http://demo.testfire.net/default.aspx
Имя пользователя: sjones
Пароль: 1 = 1 ‘или pass123
SQL-запрос создан и отправлен интерпретатору, как показано ниже
SELECT * FROM пользователей, ГДЕ User_Name = sjones И Пароль = 1 = 1 ‘или pass123;
рекомендации
- Белый список полей ввода
- Избегайте отображения подробных сообщений об ошибках, которые полезны для злоумышленника.
Межсайтовый скриптинг
Описание
Межсайтовый скриптинг также вскоре известен как XSS.
XSS-уязвимости предназначаются для сценариев, встроенных в страницу, которые выполняются на стороне клиента, т.е. в браузере пользователя, а не на стороне сервера. Эти недостатки могут возникнуть, когда приложение берет ненадежные данные и отправляет их в веб-браузер без надлежащей проверки.
Злоумышленники могут использовать XSS для выполнения вредоносных сценариев для пользователей в этом случае браузеров-жертв. Поскольку браузер не может знать, является ли сценарий надежным или нет, сценарий будет выполнен, и злоумышленник может перехватить файлы cookie сеанса, уничтожить веб-сайты или перенаправить пользователя на нежелательные и вредоносные веб-сайты.
XSS — это атака, которая позволяет атакующему выполнять сценарии в браузере жертвы.
Проявления:
- Используя эту уязвимость безопасности, злоумышленник может внедрить сценарии в приложение, может украсть сеансовые файлы cookie, испортить веб-сайты и запустить вредоносное ПО на компьютерах жертвы.
Уязвимые объекты
- Поля ввода
- URL-адрес
Примеры
1. http://www.vulnerablesite.com/home?» < script > alert(» xss») </ script >
Приведенный выше скрипт при запуске в браузере будет отображать окно сообщения, если сайт уязвим для XSS.
Более серьезная атака может быть сделана, если злоумышленник хочет отобразить или сохранить куки сессии.
2. http://demo.testfire.net/search.aspx?txtSearch <iframe > <src = http://google.com width = 500 height 500> </ iframe>
При запуске вышеуказанного скрипта браузер загрузит невидимый фрейм, указывающий на http://google.com .
Атака может быть сделана серьезной, запустив вредоносный скрипт в браузере.
рекомендации
- Белые поля ввода
- Кодирование ввода-вывода
Сломанная аутентификация и управление сессиями
Описание
Веб-сайты обычно создают файл cookie сеанса и идентификатор сеанса для каждого действительного сеанса, и эти файлы cookie содержат конфиденциальные данные, такие как имя пользователя, пароль и т. Д. Когда сеанс завершается либо из-за выхода из системы, либо из-за внезапного закрытия браузера, эти файлы cookie должны быть признаны недействительными, т.е. для каждого сеанса. должно быть новое печенье.
Если файлы cookie не признаны недействительными, конфиденциальные данные будут существовать в системе. Например, пользователь, использующий общедоступный компьютер (Cyber Cafe), куки-файлы уязвимого сайта размещает в системе и выставляет злоумышленнику. Злоумышленник использует тот же общедоступный компьютер, через некоторое время конфиденциальные данные подвергаются риску.
Таким же образом, пользователь, использующий общедоступный компьютер, вместо выхода из системы, он внезапно закрывает браузер. Злоумышленник использует ту же систему, когда просматривает тот же уязвимый сайт, открывается предыдущий сеанс жертвы. Злоумышленник может делать все, что захочет, от кражи данных профиля, информации о кредитной карте и т. Д.
Проверка должна быть сделана, чтобы найти силу аутентификации и управления сеансом. Ключи, сессионные токены, куки должны быть правильно реализованы без компрометации паролей.
Уязвимые объекты
- Идентификаторы сеанса, отображаемые в 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 долларов.
Рекомендация
- Мандат присутствия пользователя при выполнении чувствительных действий.
- Реализация таких механизмов, как CAPTCHA, повторная аутентификация и уникальные маркеры запросов.
Неправильная настройка безопасности
Описание
Конфигурация безопасности должна быть определена и развернута для приложения, сред, сервера приложений, веб-сервера, сервера базы данных и платформы. Если они правильно настроены, злоумышленник может иметь несанкционированный доступ к конфиденциальным данным или функциям.
Иногда такие недостатки приводят к полной компрометации системы. Поддержание программного обеспечения в актуальном состоянии также является хорошей безопасностью.
импликация
- Используя эту уязвимость, злоумышленник может перечислить информацию о базовой технологии и версии сервера приложений, информацию о базе данных и получить информацию о приложении, чтобы провести еще несколько атак.
Уязвимые объекты
- 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
рекомендации
- Просто избегайте использования перенаправлений и пересылок в приложении. Если используется, не используйте пользовательские параметры при расчете пункта назначения.
- Если нельзя избежать параметров назначения, убедитесь, что указанное значение является действительным и авторизованным для пользователя.
Эта статья предоставлена Прашанти Эати