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-запрос создан и отправлен интерпретатору, как показано ниже.
ВЫБРАТЬ * ИЗ пользователей, ГДЕ Имя_пользователя = 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
При запуске приведенного выше сценария браузер загрузит невидимый фрейм, указывающий на http://google.com .
Атаку можно сделать серьезной, запустив вредоносный скрипт в браузере.
Рекомендации
- Поля ввода в белый список
- Кодировка ввода вывода
Нарушенная аутентификация и управление сеансом
Описание
Веб-сайты обычно создают файл cookie сеанса и идентификатор сеанса для каждого действительного сеанса, и эти файлы cookie содержат конфиденциальные данные, такие как имя пользователя, пароль и т. Д. Когда сеанс завершается либо выходом из системы, либо внезапным закрытием браузера, эти файлы cookie должны быть аннулированы, т.е. для каждого сеанса должен быть новый файл cookie.
Если файлы cookie не признаны недействительными, конфиденциальные данные будут существовать в системе. Например, пользователь, использующий общедоступный компьютер (Cyber Cafe), файлы 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 долларов.
Рекомендация
- Обязательное присутствие пользователя при выполнении конфиденциальных действий.
- Внедрите такие механизмы, как 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
Рекомендации
- Просто избегайте использования переадресации и пересылки в приложении. Если используется, не включайте использование параметров пользователя при вычислении пункта назначения.
- Если невозможно избежать параметров назначения, убедитесь, что предоставленное значение является допустимым и авторизованным для пользователя.
Эта статья предоставлена Прашанти Иати