10 типов уязвимостей безопасности

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

1. Внедрение базы данных

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

Приложение уязвимо для атаки путем внедрения, когда данные, предоставленные пользователем, не очищаются и не проверяются за счет использования динамических запросов без экранирования с учетом контекста и прямого использования враждебных данных. Недостатки внедрения могут быть легко обнаружены путем изучения кода и использования автоматизированных инструментов, таких как сканеры и фаззеры. Для предотвращения атак путем внедрения могут быть приняты некоторые меры, такие как отделение данных от команд и запросов, использование безопасного API, который предоставляет параметризованный интерфейс, использование проверки ввода на стороне сервера с помощью «белого списка» с помощью таких инструментов, как Snort, экранирование специальных символов с использованием специального синтаксиса экранирования и т.д.

Инъекционная атака может привести к массовой потере данных, раскрытию конфиденциальной информации, отказу в доступе и даже к полному захвату приложений. Некоторые элементы управления SQL, такие как LIMIT, могут использоваться для контроля потери огромных объемов данных в случае атаки. Некоторые типы атак с использованием инъекций: SQL, OS, NoSQL, атаки с использованием инъекций LDAP.

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

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

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

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

3. Раскрытие конфиденциальных данных:

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

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

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

4. Внешние объекты XML (XEE)

Плохо сконфигурированные процессоры XML обрабатывают ссылки на внешние сущности внутри документов XML. Эти внешние объекты могут использоваться для получения данных внутренних файлов, таких как / etc / passwd file, или для выполнения других вредоносных задач. Уязвимые XML-процессоры могут быть легко использованы, если злоумышленник может загрузить XML-документ или включить XML и т.д. Эти уязвимые XML-объекты могут быть обнаружены с помощью инструментов SAST и DAST или вручную путем проверки зависимостей и конфигураций.

Веб-приложение уязвимо для атаки XEE по многим причинам, например, если приложение принимает прямой ввод XML из ненадежных источников, включены определения типов документов (DTD) в приложении, приложение использует SAML для обработки идентификаторов, поскольку SAML использует XML для идентификации. вставки и т.д. Атаки XEE можно смягчить, избегая сериализации конфиденциальных данных, используя менее сложные форматы данных, например JSON, исправляя процессоры XML, которые приложение в настоящее время использует, и даже библиотеки, отключая DTD во всех синтаксических анализаторах XML, проверяя XML возможность загрузки файлов с использованием проверки XSD и т.д.

Приложение, уязвимое для этих типов атак, может привести к атаке DOS, атаке Billion Laughs, сканированию внутренних систем, сканированию внутренних портов, выполнению удаленной команды, которая влияет на все данные приложения.

5. Сломанный контроль доступа

Контроль доступа дает пользователям права выполнять определенные задачи. Уязвимость, связанная с нарушением контроля доступа, возникает, когда пользователи не ограничены должным образом в задачах, которые они могут выполнять. Злоумышленники могут воспользоваться этой уязвимостью, что может привести к несанкционированному доступу к функциям или информации. Допустим, веб-приложение позволяет пользователю изменить учетную запись, из которой он вошел в систему, просто изменив URL-адрес на учетную запись другого пользователя без дополнительной проверки. Использование уязвимости контроля доступа — это атака любого злоумышленника, эту уязвимость можно найти вручную, а также с помощью инструментов SAFT и DAFT. Эти уязвимости существуют из-за отсутствия тестирования и автоматического обнаружения веб-приложений, хотя лучший способ найти их — сделать это вручную.

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

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

6. Неправильная конфигурация безопасности

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

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

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

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

Уязвимости XSS возникают тогда, когда веб-приложение включает ненадежные данные на новую страницу веб-сайта без законного утверждения или экранирования, или обновляет текущую страницу сайта данными, предоставленными клиентом, с использованием API браузера, который может создавать HTML или JavaScript. Недостатки XSS возникают в том случае, если веб-сайт позволяет пользователю добавлять собственный код в URL-путь, который могут видеть другие пользователи. Эти недостатки используются для запуска вредоносного кода JavaScript в целевом браузере. Допустим, злоумышленник может отправить жертве ссылку, содержащую ссылку на сайт любой компании. В это соединение может быть встроен вредоносный код JavaScript. В случае, если веб-страница банка не защищена надлежащим образом от XSS-атак, при нажатии на ссылку вредоносный код будет запущен в браузере жертвы.

Межсайтовые сценарии — это уязвимость системы безопасности, которая присутствует почти в веб-приложений. Приложение уязвимо для XSS, если приложение хранит неанитизированный пользовательский ввод, который может быть увиден другим пользователем, за счет использования структур JavaScript, одностраничных приложений и API, которые мощно включают информацию, управляемую злоумышленником, на страницу, беспомощны против DOM XSS. Атаки XSS могут быть смягчены за счет использования фреймворков, которые ускользают и дезинфицируют ввод XSS по своей природе, таких как React JS и т.д., Изучая ограничения фреймворков и покрывая их, используя свои собственные случаи, избегая ненужных и ненадежных данных HTML повсюду, например, в атрибутах HTML, URI, Javascript и т.д., Использование контекстно-зависимой кодировки в случае изменения документа на стороне клиента и т.д.

Атаки на основе XSS бывают трех типов: отраженный XSS, DOM XSS и сохраненный XSS. Все типы этих атак оказывают значительное влияние, но в случае Stored XSS влияние еще больше, например, кража учетных данных, отправка вредоносного ПО жертве и т.д.

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

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

Когда приложение десериализует вредоносные объекты, предоставленные атакующим объектом. Это может привести к двум типам атак, то есть атакам, связанным со структурой данных и объектами, в которых злоумышленник изменяет логику приложения или выполняет удаленный код, и типичным атакам с подделкой данных, в которых существующие структуры данных используются с измененным содержимым, например, атаки, связанные с контролем доступа. Сериализация может использоваться при удаленном взаимодействии процессов (RPC) или межпроцессном взаимодействии (IPC), кэшировании данных, веб-службах, сервере кеширования баз данных, файловых системах, токенах аутентификации API, файлах cookie HTML, параметрах формы HTML и т.д. Атаки десериализации можно смягчить, отказавшись от сериализованных объектов из ненадежных источников, внедрив проверки целостности, изолировав код, работающий в среде с низким уровнем привилегий,

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

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

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

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

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

Большинство систем не принимают достаточных мер и шагов для обнаружения утечки данных. Среднее время реакции на инцидент составляет 200 дней после того, как он произошел, это много времени, чтобы сделать все неприятные вещи для атакующей сущности. Недостаточное ведение журнала и мониторинг позволяют злоумышленнику продолжать атаковать систему, удерживать систему, вмешиваться, удерживать и извлекать данные в соответствии с потребностями. Злоумышленники используют отсутствие мониторинга и реакции в свою пользу для атаки на веб-приложение.
Недостаточное ведение журнала и мониторинг происходят в любое время, т. Е. Журналы приложений, которые не отслеживаются на предмет необычных действий, отслеживаемые события, такие как неудачные попытки входа в систему и высокие значения транзакций, не регистрируются должным образом, предупреждения и ошибки генерируют нечеткие сообщения об ошибках, нет триггерного предупреждения в случае пентестинга с использованием автоматические инструменты DAST, неспособность быстро обнаруживать или предупреждать активные атаки и т.д. Их можно смягчить, обеспечив регистрацию всех входов в систему, сбоев контроля доступа и проверки входных данных на стороне сервера для идентификации злонамеренной учетной записи пользователя и хранения достаточного количества время для отложенного судебного расследования, гарантируя, что генерируемые журналы имеют формат, совместимый с централизованными решениями управления журналами, обеспечивая проверки целостности при транзакциях с высокой стоимостью,путем создания системы своевременного оповещения о подозрительной деятельности и т.д.

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

Заключение

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