День 1240. #Безопасность #СписокУязвимостей
Памятка по Уязвимостям в C# Приложениях. Начало
Защита приложений — непростая задача. Приложение состоит из множества компонентов: серверная логика, клиентская логика, хранилище и передача данных и многое другое. Поэтому создание безопасного приложения может показаться действительно сложной задачей. К счастью, большинство реальных уязвимостей имеют одни и те же основные причины. Первый шаг к их устранению— знать, что искать. Вот список распространённых уязвимостей, которые могут встретиться в C# приложениях.
1. Атаки на внешние сущности XML (XML External Entity - XXE)
При XXE-атаках злоумышленники используют синтаксический анализатор XML для чтения произвольных файлов на вашем сервере. Используя XXE, злоумышленники также могут получить информацию о пользователе, файлы конфигурации или другую конфиденциальную информацию, например учетные данные AWS.
Внешние сущности могут быть определены через URI, вследствие чего XML-парсер может обработать этот URI и подставить полученное содержимое в XML-документ. Пример XML-документа, в котором определена внешняя сущность:
Таким образом, атака возможна, если:
- злоумышленник может передать приложению XML-файл с внешними сущностями, и приложение выполнит парсинг этого файла;
- XML-парсер имеет небезопасную конфигурацию;
- данные парсинга (значения сущностей) могут попасть обратно к злоумышленнику.
Чтобы предотвратить XXE-атаки, необходимо явно отключить этот функционал.
2. Небезопасная десериализация
Небезопасная десериализация возникает, когда злоумышленник может манипулировать сериализованным объектом и вызывать непредвиденные последствия в ходе выполнения программы. Ошибка небезопасной десериализации часто приводит к обходу аутентификации, отказу в обслуживании или даже к выполнению произвольного кода.
Чтобы предотвратить небезопасную десериализацию, нужно следить за исправлениями и поддерживать зависимости в актуальном состоянии. Многие уязвимости десериализации возникают из-за зависимостей, поэтому убедитесь, что ваш сторонний код безопасен. Также помогает отказ от использования сериализованных объектов и использование вместо них простых типов данных.
3. Утечки конфиденциальных данных
Происходит, когда приложение не может должным образом защитить конфиденциальную информацию, предоставляя пользователям доступ к информации, которую не должно предоставлять. Информация может включать в себя технические детали, помогающие атаке, такие как номера версий программного обеспечения, внутренние IP-адреса, конфиденциальные имена файлов и пути к файлам, а также может включать исходный код. Иногда приложение выдаёт личную информацию пользователей, такую как номера их банковских счетов, адреса электронной почты и почтовые адреса.
Некоторые распространённые способы, с помощью которых приложение может утечь конфиденциальные технические данные, включают чрезмерно подробные заголовки ответов, сообщения об ошибках с трассировкой стека или сообщения об ошибках базы данных, открытые списки каталогов в файловой системе или открытые комментарии в HTML и файлах шаблонов.
4. Атаки на отказ в обслуживании (Denial of service – DoS)
DoS-атаки нарушают работу целевой машины, так что законные пользователи не могут получить доступ к её сервисам. Злоумышленники могут запускать DoS-атаки, истощая все ресурсы сервера, вызывая сбои процессов или выполняя одновременно слишком много длительных HTTP-запросов.
От этого типа атак трудно защититься, но есть способы минимизировать риск, максимально усложнив задачу для злоумышленников. Например, вы можете развернуть брандмауэр, обеспечивающий защиту от DoS-атак, установить ограничения на размер файлов или запретить определенные типы файлов.
Продолжение следует…
Источник: https://dzone.com/articles/c-applications-vulnerability-cheatsheet
Памятка по Уязвимостям в C# Приложениях. Начало
Защита приложений — непростая задача. Приложение состоит из множества компонентов: серверная логика, клиентская логика, хранилище и передача данных и многое другое. Поэтому создание безопасного приложения может показаться действительно сложной задачей. К счастью, большинство реальных уязвимостей имеют одни и те же основные причины. Первый шаг к их устранению— знать, что искать. Вот список распространённых уязвимостей, которые могут встретиться в C# приложениях.
1. Атаки на внешние сущности XML (XML External Entity - XXE)
При XXE-атаках злоумышленники используют синтаксический анализатор XML для чтения произвольных файлов на вашем сервере. Используя XXE, злоумышленники также могут получить информацию о пользователе, файлы конфигурации или другую конфиденциальную информацию, например учетные данные AWS.
Внешние сущности могут быть определены через URI, вследствие чего XML-парсер может обработать этот URI и подставить полученное содержимое в XML-документ. Пример XML-документа, в котором определена внешняя сущность:
<?xml version="1.0" encoding="utf-8" ?>Здесь определена сущность
<!DOCTYPE foo [
<!ENTITY xxe SYSTEM "file://D:/XXETarget.txt">
]>
<foo>&xxe;</foo>
'&xxe;'. При обработке этого XML-документа парсер подставит вместо '&xxe;' содержимое файла 'D:\XXETarget.txt'.Таким образом, атака возможна, если:
- злоумышленник может передать приложению XML-файл с внешними сущностями, и приложение выполнит парсинг этого файла;
- XML-парсер имеет небезопасную конфигурацию;
- данные парсинга (значения сущностей) могут попасть обратно к злоумышленнику.
Чтобы предотвратить XXE-атаки, необходимо явно отключить этот функционал.
2. Небезопасная десериализация
Небезопасная десериализация возникает, когда злоумышленник может манипулировать сериализованным объектом и вызывать непредвиденные последствия в ходе выполнения программы. Ошибка небезопасной десериализации часто приводит к обходу аутентификации, отказу в обслуживании или даже к выполнению произвольного кода.
Чтобы предотвратить небезопасную десериализацию, нужно следить за исправлениями и поддерживать зависимости в актуальном состоянии. Многие уязвимости десериализации возникают из-за зависимостей, поэтому убедитесь, что ваш сторонний код безопасен. Также помогает отказ от использования сериализованных объектов и использование вместо них простых типов данных.
3. Утечки конфиденциальных данных
Происходит, когда приложение не может должным образом защитить конфиденциальную информацию, предоставляя пользователям доступ к информации, которую не должно предоставлять. Информация может включать в себя технические детали, помогающие атаке, такие как номера версий программного обеспечения, внутренние IP-адреса, конфиденциальные имена файлов и пути к файлам, а также может включать исходный код. Иногда приложение выдаёт личную информацию пользователей, такую как номера их банковских счетов, адреса электронной почты и почтовые адреса.
Некоторые распространённые способы, с помощью которых приложение может утечь конфиденциальные технические данные, включают чрезмерно подробные заголовки ответов, сообщения об ошибках с трассировкой стека или сообщения об ошибках базы данных, открытые списки каталогов в файловой системе или открытые комментарии в HTML и файлах шаблонов.
4. Атаки на отказ в обслуживании (Denial of service – DoS)
DoS-атаки нарушают работу целевой машины, так что законные пользователи не могут получить доступ к её сервисам. Злоумышленники могут запускать DoS-атаки, истощая все ресурсы сервера, вызывая сбои процессов или выполняя одновременно слишком много длительных HTTP-запросов.
От этого типа атак трудно защититься, но есть способы минимизировать риск, максимально усложнив задачу для злоумышленников. Например, вы можете развернуть брандмауэр, обеспечивающий защиту от DoS-атак, установить ограничения на размер файлов или запретить определенные типы файлов.
Продолжение следует…
Источник: https://dzone.com/articles/c-applications-vulnerability-cheatsheet
👍8
День 1245. #Безопасность #СписокУязвимостей
Памятка по Уязвимостям в C# Приложениях. Продолжение
Начало
5. Обход аутентификации
Под аутентификацией понимается подтверждение личности перед выполнением конфиденциальных действий или доступом к конфиденциальным данным. Если аутентификация реализована в приложении неправильно, злоумышленники могут использовать это для получения доступа к функциям, которые им не должны быть доступны.
6. Неправильный контроль доступа
Проблема возникает, когда контроль доступа в приложении реализован неправильно и может быть обойдён злоумышленником. Проблемы обхода аутентификации, по сути, подмножество проблем контроля доступа. Однако помимо аутентификации, которая просит пользователя подтвердить свою личность («Кто вы?»), авторизация отвечает за вопрос: «Что разрешено делать этому пользователю?». Надлежащие аутентификация и авторизация вместе гарантируют, что пользователи не смогут получить доступ к функциям за пределами их разрешений.
Существует несколько способов настройки авторизации для пользователей: управление доступом на основе ролей или утверждений, списки контроля доступа и многое другое.
7. Обход каталога
Ещё один тип ненадлежащего контроля доступа. При этом злоумышленники могут просматривать, изменять или исполнять файлы, к которым у них не должно быть доступа, манипулируя путями к файлам в полях пользовательского ввода, например, добавляя ../ или другие специальные символы к пути. Добавив ../ к пути, можно перейти к родительскому каталогу и получить доступ к системным файлам за пределами веб-каталога.
Злоумышленники часто могут использовать обход каталога для доступа к конфиденциальным файлам, таким как файлы конфигурации, файлы журналов и исходный код. Чтобы предотвратить обход каталога, вы должны проверять пользовательский ввод и избегать прямых ссылок на имена файлов, вместо этого используя косвенные идентификаторы.
8. Запись произвольного файла
Уязвимости записи произвольных файлов работают аналогично обходу каталогов. Если приложение записывает файлы на компьютер и определяет имя выходного файла с помощью пользовательского ввода, злоумышленники могут создавать произвольные файлы по любому пути, который они хотят, или перезаписывать существующие системные файлы. Злоумышленники могут изменить важные системные файлы, такие как файлы паролей или файлы журналов, или добавить свои собственные исполняемые файлы в каталоги сценариев.
Лучший способ снизить этот риск — не создавать имена файлов на основе каких-либо данных, вводимых пользователем, включая информацию о сеансе, данные HTTP или вообще чего-либо, что контролируется пользователем. Вы должны контролировать имя файла, путь и расширение для каждого создаваемого файла. Например, вы можете генерировать случайное буквенно-цифровое имя файла каждый раз, когда пользователю нужно создать уникальный файл. Вы также можете удалять введенные пользователем специальные символы перед созданием файла.
9. Уязвимости шифрования
Проблемы с шифрованием, вероятно, являются одной из самых серьёзных уязвимостей, которые могут возникнуть в приложении. Уязвимости шифрования относятся к случаям, когда шифрование и хеширование реализованы неправильно. Это может привести к массовым утечкам данных и обходу аутентификации из-за спуфинга сеанса, когда злоумышленник выдаёт себя за аутентифицированного пользователя, чтобы получить доступ к важным данным или информации.
Некоторые распространённые ошибки, которые допускают разработчики при реализации шифрования на сайте:
- Использование слабых алгоритмов,
- Использование неправильного алгоритма для заданной цели,
- Использование собственного алгоритма шифрования,
- Генерация слабых случайных чисел,
- Использование кодировки вместо шифрования.
Продолжение следует…
Источник: https://dzone.com/articles/c-applications-vulnerability-cheatsheet
Памятка по Уязвимостям в C# Приложениях. Продолжение
Начало
5. Обход аутентификации
Под аутентификацией понимается подтверждение личности перед выполнением конфиденциальных действий или доступом к конфиденциальным данным. Если аутентификация реализована в приложении неправильно, злоумышленники могут использовать это для получения доступа к функциям, которые им не должны быть доступны.
6. Неправильный контроль доступа
Проблема возникает, когда контроль доступа в приложении реализован неправильно и может быть обойдён злоумышленником. Проблемы обхода аутентификации, по сути, подмножество проблем контроля доступа. Однако помимо аутентификации, которая просит пользователя подтвердить свою личность («Кто вы?»), авторизация отвечает за вопрос: «Что разрешено делать этому пользователю?». Надлежащие аутентификация и авторизация вместе гарантируют, что пользователи не смогут получить доступ к функциям за пределами их разрешений.
Существует несколько способов настройки авторизации для пользователей: управление доступом на основе ролей или утверждений, списки контроля доступа и многое другое.
7. Обход каталога
Ещё один тип ненадлежащего контроля доступа. При этом злоумышленники могут просматривать, изменять или исполнять файлы, к которым у них не должно быть доступа, манипулируя путями к файлам в полях пользовательского ввода, например, добавляя ../ или другие специальные символы к пути. Добавив ../ к пути, можно перейти к родительскому каталогу и получить доступ к системным файлам за пределами веб-каталога.
Злоумышленники часто могут использовать обход каталога для доступа к конфиденциальным файлам, таким как файлы конфигурации, файлы журналов и исходный код. Чтобы предотвратить обход каталога, вы должны проверять пользовательский ввод и избегать прямых ссылок на имена файлов, вместо этого используя косвенные идентификаторы.
8. Запись произвольного файла
Уязвимости записи произвольных файлов работают аналогично обходу каталогов. Если приложение записывает файлы на компьютер и определяет имя выходного файла с помощью пользовательского ввода, злоумышленники могут создавать произвольные файлы по любому пути, который они хотят, или перезаписывать существующие системные файлы. Злоумышленники могут изменить важные системные файлы, такие как файлы паролей или файлы журналов, или добавить свои собственные исполняемые файлы в каталоги сценариев.
Лучший способ снизить этот риск — не создавать имена файлов на основе каких-либо данных, вводимых пользователем, включая информацию о сеансе, данные HTTP или вообще чего-либо, что контролируется пользователем. Вы должны контролировать имя файла, путь и расширение для каждого создаваемого файла. Например, вы можете генерировать случайное буквенно-цифровое имя файла каждый раз, когда пользователю нужно создать уникальный файл. Вы также можете удалять введенные пользователем специальные символы перед созданием файла.
9. Уязвимости шифрования
Проблемы с шифрованием, вероятно, являются одной из самых серьёзных уязвимостей, которые могут возникнуть в приложении. Уязвимости шифрования относятся к случаям, когда шифрование и хеширование реализованы неправильно. Это может привести к массовым утечкам данных и обходу аутентификации из-за спуфинга сеанса, когда злоумышленник выдаёт себя за аутентифицированного пользователя, чтобы получить доступ к важным данным или информации.
Некоторые распространённые ошибки, которые допускают разработчики при реализации шифрования на сайте:
- Использование слабых алгоритмов,
- Использование неправильного алгоритма для заданной цели,
- Использование собственного алгоритма шифрования,
- Генерация слабых случайных чисел,
- Использование кодировки вместо шифрования.
Продолжение следует…
Источник: https://dzone.com/articles/c-applications-vulnerability-cheatsheet
👍5
День 1251. #Безопасность #СписокУязвимостей
Памятка по Уязвимостям в C# Приложениях. Продолжение
Начало 1-4
Продолжение 5-9
10. Небезопасная конфигурация TLS и неправильная проверка сертификата
Помимо правильного шифрования информации в ваших хранилищах данных, вам также необходимо убедиться, что вы общаетесь с доверенным компьютером, а не со злоумышленником. TLS использует цифровые сертификаты в качестве основы для шифрования с открытым ключом, и вам необходимо проверить эти сертификаты, прежде чем устанавливать соединение с третьей стороной. Вы должны убедиться, что сервер, к которому вы пытаетесь подключиться, имеет сертификат, выданный доверенным центром сертификации (certificate authority - CA), и что ни один из сертификатов в цепочке не просрочен.
11. Массовое присвоение (оверпостинг)
Относится к практике присвоения значений нескольким переменным или свойствам объекта. Уязвимости массового присвоения возникают, когда приложение автоматически назначает пользовательский ввод нескольким переменным, объектам или свойствам. Это функция многих платформ приложений, предназначенная для упрощения разработки.
Однако эта функция иногда позволяет злоумышленникам перезаписывать, изменять или создавать новые переменные или свойства объекта по своему желанию. Это может привести к обходу аутентификации и манипулированию логикой программы. Чтобы предотвратить массовое присвоение, вы можете отключить эту функцию в используемой вами среде или использовать белый список, чтобы разрешить присвоение только для определённых свойств или переменных. Например, в ASP.NET можно использовать атрибут Bind на аргументе метода действия контроллера.
12. Отравление заголовка Host
Веб-серверы часто размещают несколько разных веб-сайтов на одном и том же IP-адресе. После того, как HTTP-запрос поступает на IP-адрес, сервер перенаправляет запрос на хост, указанный в заголовке Host. Хотя заголовки Host обычно устанавливаются браузером пользователя, они всё равно являются пользовательским вводом, и поэтому им нельзя доверять.
Если веб-приложение не проверяет заголовок Host перед его использованием для создания относительных адресов, злоумышленники могут запустить ряд атак, таких как XSS, подделка запросов на стороне сервера (SSRF) или атак с отравлением веб-кэша через заголовок Host. Например, если приложение использует заголовок Host для определения местоположения сценариев, злоумышленник может отправить вредоносный заголовок Host, чтобы приложение выполнило вредоносный сценарий:
Веб-сайты часто должны автоматически перенаправлять своих пользователей на другие страницы. Например, такой сценарий возникает, когда не прошедшие авторизацию пользователи пытаются получить доступ к странице, требующей входа в систему. Веб-сайт обычно перенаправляет их на страницу входа, а затем возвращает в исходное местоположение после авторизации.
Во время атаки с открытым перенаправлением злоумышленник обманом заставляет пользователя посетить внешний сайт, предоставляя ему URL-адрес законного сайта, который перенаправляет куда-то еще. Это может заставить пользователей поверить, что они все ещё находятся на исходном сайте, и помочь мошенникам создать более правдоподобную фишинговую страницу (см. подробнее).
Чтобы предотвратить открытые перенаправления, вам необходимо убедиться, что приложение не перенаправляет пользователей на вредоносные места. Например, вы можете полностью запретить перенаправления за пределы сайта, проверяя URL-адреса перенаправления. Есть много других способов предотвращения открытых перенаправлений, таких как проверка реферера запросов или использование индексов страниц для перенаправлений. Однако из-за сложности проверки URL-адресов открытые перенаправления остаются распространенной проблемой в современных веб-приложениях.
Продолжение следует…
Источник: https://dzone.com/articles/c-applications-vulnerability-cheatsheet
Памятка по Уязвимостям в C# Приложениях. Продолжение
Начало 1-4
Продолжение 5-9
10. Небезопасная конфигурация TLS и неправильная проверка сертификата
Помимо правильного шифрования информации в ваших хранилищах данных, вам также необходимо убедиться, что вы общаетесь с доверенным компьютером, а не со злоумышленником. TLS использует цифровые сертификаты в качестве основы для шифрования с открытым ключом, и вам необходимо проверить эти сертификаты, прежде чем устанавливать соединение с третьей стороной. Вы должны убедиться, что сервер, к которому вы пытаетесь подключиться, имеет сертификат, выданный доверенным центром сертификации (certificate authority - CA), и что ни один из сертификатов в цепочке не просрочен.
11. Массовое присвоение (оверпостинг)
Относится к практике присвоения значений нескольким переменным или свойствам объекта. Уязвимости массового присвоения возникают, когда приложение автоматически назначает пользовательский ввод нескольким переменным, объектам или свойствам. Это функция многих платформ приложений, предназначенная для упрощения разработки.
Однако эта функция иногда позволяет злоумышленникам перезаписывать, изменять или создавать новые переменные или свойства объекта по своему желанию. Это может привести к обходу аутентификации и манипулированию логикой программы. Чтобы предотвратить массовое присвоение, вы можете отключить эту функцию в используемой вами среде или использовать белый список, чтобы разрешить присвоение только для определённых свойств или переменных. Например, в ASP.NET можно использовать атрибут Bind на аргументе метода действия контроллера.
12. Отравление заголовка Host
Веб-серверы часто размещают несколько разных веб-сайтов на одном и том же IP-адресе. После того, как HTTP-запрос поступает на IP-адрес, сервер перенаправляет запрос на хост, указанный в заголовке Host. Хотя заголовки Host обычно устанавливаются браузером пользователя, они всё равно являются пользовательским вводом, и поэтому им нельзя доверять.
Если веб-приложение не проверяет заголовок Host перед его использованием для создания относительных адресов, злоумышленники могут запустить ряд атак, таких как XSS, подделка запросов на стороне сервера (SSRF) или атак с отравлением веб-кэша через заголовок Host. Например, если приложение использует заголовок Host для определения местоположения сценариев, злоумышленник может отправить вредоносный заголовок Host, чтобы приложение выполнило вредоносный сценарий:
var scriptURL = $"https://{Request.Host}/script.js";
13. Открытые перенаправленияВеб-сайты часто должны автоматически перенаправлять своих пользователей на другие страницы. Например, такой сценарий возникает, когда не прошедшие авторизацию пользователи пытаются получить доступ к странице, требующей входа в систему. Веб-сайт обычно перенаправляет их на страницу входа, а затем возвращает в исходное местоположение после авторизации.
Во время атаки с открытым перенаправлением злоумышленник обманом заставляет пользователя посетить внешний сайт, предоставляя ему URL-адрес законного сайта, который перенаправляет куда-то еще. Это может заставить пользователей поверить, что они все ещё находятся на исходном сайте, и помочь мошенникам создать более правдоподобную фишинговую страницу (см. подробнее).
Чтобы предотвратить открытые перенаправления, вам необходимо убедиться, что приложение не перенаправляет пользователей на вредоносные места. Например, вы можете полностью запретить перенаправления за пределы сайта, проверяя URL-адреса перенаправления. Есть много других способов предотвращения открытых перенаправлений, таких как проверка реферера запросов или использование индексов страниц для перенаправлений. Однако из-за сложности проверки URL-адресов открытые перенаправления остаются распространенной проблемой в современных веб-приложениях.
Продолжение следует…
Источник: https://dzone.com/articles/c-applications-vulnerability-cheatsheet
👍2
День 1259. #Безопасность #СписокУязвимостей
Памятка по Уязвимостям в C# Приложениях. Продолжение
Начало 1-4
Продолжение 5-9
Продолжение 10-13
14. Подделка межсайтовых запросов (Cross-Site Request Forgery – CSRF)
CSRF — это техника атаки на других пользователей веб-приложения, используемая на стороне клиента. С помощью CSRF злоумышленники могут отправлять HTTP-запросы, которые якобы исходят от жертвы, выполняя нежелательные действия от имени жертвы. Например, злоумышленник может изменить ваш пароль или перевести деньги с вашего банковского счета без вашего разрешения. См. пример.
В отличие от открытых перенаправлений, существует надежный способ предотвратить CSRF: использовать комбинацию токенов CSRF и SameSite-куки, а также избегать использования запросов GET для действий по изменению состояния.
15. Подделка запроса на стороне сервера (Server-Side Request Forgery – SSRF)
SSRF — это уязвимость, которая возникает, когда злоумышленник может отправлять запросы от имени сервера. Она позволяет злоумышленникам «подделывать» сигнатуры запросов уязвимого сервера, тем самым занимая привилегированное положение в сети, обходить средства управления брандмауэром и получать доступ к внутренним службам.
В зависимости от разрешений, предоставленных уязвимому серверу, злоумышленник может читать конфиденциальные файлы, выполнять внутренние вызовы API и получать доступ к внутренним службам, таким как скрытые инструменты администратора. Самый простой способ предотвратить уязвимости SSRF — никогда не делать исходящие запросы на основе пользовательского ввода. Если их приходится делать, необходимо проверять эти адреса перед инициированием запроса.
16. Нарушение границ доверия
«Границы доверия» относятся к тому, где ненадёжные пользовательские данные входят в контролируемую среду. Например, HTTP-запрос считается ненадёжными данными до тех пор, пока он не будет проверен сервером.
Должно быть чёткое различие между тем, как вы храните, транспортируете и обрабатываете доверенные и ненадёжные входные данные. Нарушения границ доверия происходят, когда это различие не соблюдается, а надёжные и ненадёжные данные смешиваются друг с другом. Например, если доверенные и недоверенные данные хранятся в одной и той же структуре данных или базе данных, приложение начнёт их путать. В этом случае ненадёжные данные могут быть ошибочно приняты за проверенные.
Хороший способ предотвратить нарушение границ доверия — никогда не записывать ненадёжные входные данные в хранилища, пока они не будут проверены.
17. Удалённое выполнение кода (Remote Code Execution - RCE)
RCE, представляют собой класс уязвимостей, которые возникают, когда злоумышленники могут выполнить свой код на вашем компьютере. Один из способов — уязвимости внедрения команд, когда пользовательский ввод объединяется непосредственно с системной командой. Приложение не может различить, где находится пользовательский ввод, а где системная команда, поэтому приложение выполняет пользовательский ввод как код. Злоумышленник сможет выполнять произвольные команды на машине.
Самый простой способ предотвратить удалённое выполнение кода — убедиться, что код, представленный в виде строки, и предназначенный для исполнения, получен только из надёжных источников, или внедрить надёжную проверку ввода в виде списка разрешений.
Продолжение следует…
Источник: https://dzone.com/articles/c-applications-vulnerability-cheatsheet
Памятка по Уязвимостям в C# Приложениях. Продолжение
Начало 1-4
Продолжение 5-9
Продолжение 10-13
14. Подделка межсайтовых запросов (Cross-Site Request Forgery – CSRF)
CSRF — это техника атаки на других пользователей веб-приложения, используемая на стороне клиента. С помощью CSRF злоумышленники могут отправлять HTTP-запросы, которые якобы исходят от жертвы, выполняя нежелательные действия от имени жертвы. Например, злоумышленник может изменить ваш пароль или перевести деньги с вашего банковского счета без вашего разрешения. См. пример.
В отличие от открытых перенаправлений, существует надежный способ предотвратить CSRF: использовать комбинацию токенов CSRF и SameSite-куки, а также избегать использования запросов GET для действий по изменению состояния.
15. Подделка запроса на стороне сервера (Server-Side Request Forgery – SSRF)
SSRF — это уязвимость, которая возникает, когда злоумышленник может отправлять запросы от имени сервера. Она позволяет злоумышленникам «подделывать» сигнатуры запросов уязвимого сервера, тем самым занимая привилегированное положение в сети, обходить средства управления брандмауэром и получать доступ к внутренним службам.
В зависимости от разрешений, предоставленных уязвимому серверу, злоумышленник может читать конфиденциальные файлы, выполнять внутренние вызовы API и получать доступ к внутренним службам, таким как скрытые инструменты администратора. Самый простой способ предотвратить уязвимости SSRF — никогда не делать исходящие запросы на основе пользовательского ввода. Если их приходится делать, необходимо проверять эти адреса перед инициированием запроса.
16. Нарушение границ доверия
«Границы доверия» относятся к тому, где ненадёжные пользовательские данные входят в контролируемую среду. Например, HTTP-запрос считается ненадёжными данными до тех пор, пока он не будет проверен сервером.
Должно быть чёткое различие между тем, как вы храните, транспортируете и обрабатываете доверенные и ненадёжные входные данные. Нарушения границ доверия происходят, когда это различие не соблюдается, а надёжные и ненадёжные данные смешиваются друг с другом. Например, если доверенные и недоверенные данные хранятся в одной и той же структуре данных или базе данных, приложение начнёт их путать. В этом случае ненадёжные данные могут быть ошибочно приняты за проверенные.
Хороший способ предотвратить нарушение границ доверия — никогда не записывать ненадёжные входные данные в хранилища, пока они не будут проверены.
17. Удалённое выполнение кода (Remote Code Execution - RCE)
RCE, представляют собой класс уязвимостей, которые возникают, когда злоумышленники могут выполнить свой код на вашем компьютере. Один из способов — уязвимости внедрения команд, когда пользовательский ввод объединяется непосредственно с системной командой. Приложение не может различить, где находится пользовательский ввод, а где системная команда, поэтому приложение выполняет пользовательский ввод как код. Злоумышленник сможет выполнять произвольные команды на машине.
Самый простой способ предотвратить удалённое выполнение кода — убедиться, что код, представленный в виде строки, и предназначенный для исполнения, получен только из надёжных источников, или внедрить надёжную проверку ввода в виде списка разрешений.
Продолжение следует…
Источник: https://dzone.com/articles/c-applications-vulnerability-cheatsheet
👍8
День 1268. #Безопасность #СписокУязвимостей
Памятка по Уязвимостям в C# Приложениях. Продолжение
1-4
5-9
10-13
14-17
Инъекции. Начало
Проблемы с инъекциями возникают, когда приложение не может правильно отличить ненадёжные пользовательские данные от кода.
18. SQL-инъекции
При атаке с SQL-инъекцией злоумышленник вводит данные для управления командами SQL. Когда приложение не проверяет пользовательский ввод должным образом, злоумышленники могут вставлять спецсимволы языка SQL, чтобы нарушить логику запроса; тем самым выполняя произвольный код SQL.
Это позволит злоумышленнику изменять структуру SQL-запросов для кражи или изменения данных, или потенциального выполнения произвольных команд в операционной системе. Лучший способ предотвратить SQL-инъекции — использовать параметризованные запросы, что делает SQL-инъекции практически невозможными.
19. NoSQL-инъекции
Относятся к атакам, которые внедряют данные в логику языков NoSQL (Not Only SQL) баз данных. Современные базы данных NoSQL, такие как MongoDB, Couchbase, Cassandra и HBase, уязвимы для атак путем инъекций. Синтаксис запросов NoSQL зависит от базы данных, и запросы часто пишутся на языке приложения. По той же причине методы предотвращения NoSQL-инъекций в каждую базу данных также зависят от базы данных.
20. LDAP-инъекции
Облегчённый протокол доступа к каталогам (Lightweight Directory Access Protocol - LDAP) — это способ запроса к службе каталогов о пользователях и устройствах системы. Например, он используется для запросов к Microsoft Active Directory. Когда приложение использует ненадёжные входные данные в запросах LDAP, злоумышленники могут отправлять специально созданные данные и обходить аутентификацию или портить данные, хранящиеся в каталоге.
21. Инъекции в журналы
Вы задумывались когда-нибудь о том, что записи в файле журнала могут вам лгать? Файлы журнала, как и другие системные файлы, могут быть изменены злоумышленниками (например, чтобы замести следы во время атаки). Инъекции в журналы происходят, когда злоумышленник обманом заставляет приложение записывать поддельные записи в ваши файлы журналов.
Часто они происходят, когда приложение не экранирует символы новой строки «\n» во входных данных, записываемых в журналы. Злоумышленники могут использовать символ новой строки для вставки новых записей в журналы приложений. Другой способ заключается во внедрении вредоносного HTML в записи журнала, чтобы попытаться провести XSS-атаку на браузер администратора, который просматривает журналы.
Чтобы предотвратить атаки через инъекции в журналы, вам нужен способ отличить настоящие записи журнала от поддельных, введённых злоумышленником. Один из способов сделать это — добавить к каждой записи журнала дополнительные метаданные, такие как отметка времени, идентификатор процесса и имя хоста. Вы также должны относиться к содержимому файлов журналов как к ненадёжным входным данным и проверять их перед доступом к ним или операциями с ними.
22. Инъекции в почте
Многие веб-приложения отправляют электронные письма пользователям в зависимости от их действий. Например, если вы подписались на ленту новостей, веб-сайт может отправить вам письмо с подтверждением.
Инъекции в почте происходят, когда приложение использует пользовательский ввод, чтобы определить, на какие адреса отправлять электронные письма. Это может позволить спамерам использовать ваш сервер для массовых рассылок пользователям или позволить мошенникам проводить фишинговые кампании через ваш адрес электронной почты.
Окончание следует…
Источник: https://dzone.com/articles/c-applications-vulnerability-cheatsheet
Памятка по Уязвимостям в C# Приложениях. Продолжение
1-4
5-9
10-13
14-17
Инъекции. Начало
Проблемы с инъекциями возникают, когда приложение не может правильно отличить ненадёжные пользовательские данные от кода.
18. SQL-инъекции
При атаке с SQL-инъекцией злоумышленник вводит данные для управления командами SQL. Когда приложение не проверяет пользовательский ввод должным образом, злоумышленники могут вставлять спецсимволы языка SQL, чтобы нарушить логику запроса; тем самым выполняя произвольный код SQL.
Это позволит злоумышленнику изменять структуру SQL-запросов для кражи или изменения данных, или потенциального выполнения произвольных команд в операционной системе. Лучший способ предотвратить SQL-инъекции — использовать параметризованные запросы, что делает SQL-инъекции практически невозможными.
19. NoSQL-инъекции
Относятся к атакам, которые внедряют данные в логику языков NoSQL (Not Only SQL) баз данных. Современные базы данных NoSQL, такие как MongoDB, Couchbase, Cassandra и HBase, уязвимы для атак путем инъекций. Синтаксис запросов NoSQL зависит от базы данных, и запросы часто пишутся на языке приложения. По той же причине методы предотвращения NoSQL-инъекций в каждую базу данных также зависят от базы данных.
20. LDAP-инъекции
Облегчённый протокол доступа к каталогам (Lightweight Directory Access Protocol - LDAP) — это способ запроса к службе каталогов о пользователях и устройствах системы. Например, он используется для запросов к Microsoft Active Directory. Когда приложение использует ненадёжные входные данные в запросах LDAP, злоумышленники могут отправлять специально созданные данные и обходить аутентификацию или портить данные, хранящиеся в каталоге.
21. Инъекции в журналы
Вы задумывались когда-нибудь о том, что записи в файле журнала могут вам лгать? Файлы журнала, как и другие системные файлы, могут быть изменены злоумышленниками (например, чтобы замести следы во время атаки). Инъекции в журналы происходят, когда злоумышленник обманом заставляет приложение записывать поддельные записи в ваши файлы журналов.
Часто они происходят, когда приложение не экранирует символы новой строки «\n» во входных данных, записываемых в журналы. Злоумышленники могут использовать символ новой строки для вставки новых записей в журналы приложений. Другой способ заключается во внедрении вредоносного HTML в записи журнала, чтобы попытаться провести XSS-атаку на браузер администратора, который просматривает журналы.
Чтобы предотвратить атаки через инъекции в журналы, вам нужен способ отличить настоящие записи журнала от поддельных, введённых злоумышленником. Один из способов сделать это — добавить к каждой записи журнала дополнительные метаданные, такие как отметка времени, идентификатор процесса и имя хоста. Вы также должны относиться к содержимому файлов журналов как к ненадёжным входным данным и проверять их перед доступом к ним или операциями с ними.
22. Инъекции в почте
Многие веб-приложения отправляют электронные письма пользователям в зависимости от их действий. Например, если вы подписались на ленту новостей, веб-сайт может отправить вам письмо с подтверждением.
Инъекции в почте происходят, когда приложение использует пользовательский ввод, чтобы определить, на какие адреса отправлять электронные письма. Это может позволить спамерам использовать ваш сервер для массовых рассылок пользователям или позволить мошенникам проводить фишинговые кампании через ваш адрес электронной почты.
Окончание следует…
Источник: https://dzone.com/articles/c-applications-vulnerability-cheatsheet
👍6
День 1269. #Безопасность #СписокУязвимостей
Памятка по Уязвимостям в C# Приложениях. Окончание
1-4
5-9
10-13
14-17
18-22
Инъекции. Окончание
23. Инъекции в шаблоны
Шаблоны предоставляют разработчикам способ указать, как должна отображаться страница, комбинируя данные приложения с макетом страницы, тем самым отделяя бизнес-логику приложения от клиентского кода представления.
В зависимости от разрешений скомпрометированного приложения злоумышленники могут использовать уязвимость инъекции в шаблон для чтения конфиденциальных файлов, выполнения кода или повышения своих привилегий в системе.
24. Инъекции в регулярные выражения
Иногда приложения позволяют пользователям предоставлять серверу собственные шаблоны регулярных выражений. Атака с инъекцией в регулярное выражение – вид атаки на «отказ в обслуживании» (ReDoS – подробнее об этой атаке в будущих постах) - происходит, когда злоумышленник предоставляет механизму регулярных выражений шаблон, для оценки которого требуется много времени.
25. XPath-инъекции
XPath — это язык запросов, используемый в XML-документах для запроса и выполнения операций с данными, хранящимися в XML-документах. XPath-инъекция — это инъекция в выражения XPath, чтобы изменить результат запроса. Подобно SQL-инъекции, её можно использовать для обхода бизнес-логики, повышения привилегий пользователя и утечки конфиденциальных данных. Поскольку приложения всё ещё часто используют XML для передачи конфиденциальных данных между системами и веб-сервисами, именно эти места наиболее уязвимы для XPath-инъекций.
26. Инъекции в заголовки
Происходят, когда заголовки ответов HTTP динамически создаются из ненадёжных входных данных. В зависимости от того, на какой заголовок ответа влияет уязвимость, инъекция в заголовок может привести к межсайтовому скриптингу, открытому перенаправлению или краже сессии.
Например, если заголовком Location можно управлять с помощью параметра URL, злоумышленники могут вызвать открытое перенаправление, указав свой вредоносный сайт. Злоумышленники могут даже выполнять вредоносные сценарии в браузере жертвы или заставлять жертв загружать вредоносное ПО, отправляя жертве полностью контролируемые HTTP-ответы посредством инъекции в заголовок.
Вы можете предотвратить эту атаку, избегая записи пользовательского ввода в заголовки ответов, удаляя символы новой строки из пользовательского ввода (символы новой строки используются для создания новых заголовков ответов HTTP) или используя белый список для проверки значений заголовков.
27. Инъекции в сессии и небезопасные cookie
Если злоумышленник может манипулировать содержимым cookie-файла сессии или украсть чужие cookie, он может обмануть приложение, заставив его думать, что он является кем-то другим. Существует три основных способа, с помощью которых злоумышленник может получить доступ к чужой сессии:
1) Перехват сессии, когда злоумышленник крадёт чужой cookie-файл сессии и использует его как свой. Злоумышленники часто крадут cookie-файлы сессии с помощью атак XSS или MITM (man-in-the-middle).
2) Фальсификация сессии, когда злоумышленники могут изменить свой cookie-файл сессии, чтобы изменить то, как сервер интерпретирует их личность. Это происходит, когда состояние сессии передаётся в файле cookie, а он неправильно подписан или не зашифрован.
3) Спуфинг сессии – это «подделка» сессии, когда её идентификатор предсказуем. В этом случае злоумышленники могут подделывать настоящие cookie-файлы сессии и входить в систему как кто-то другой.
Источник: https://dzone.com/articles/c-applications-vulnerability-cheatsheet
Памятка по Уязвимостям в C# Приложениях. Окончание
1-4
5-9
10-13
14-17
18-22
Инъекции. Окончание
23. Инъекции в шаблоны
Шаблоны предоставляют разработчикам способ указать, как должна отображаться страница, комбинируя данные приложения с макетом страницы, тем самым отделяя бизнес-логику приложения от клиентского кода представления.
В зависимости от разрешений скомпрометированного приложения злоумышленники могут использовать уязвимость инъекции в шаблон для чтения конфиденциальных файлов, выполнения кода или повышения своих привилегий в системе.
24. Инъекции в регулярные выражения
Иногда приложения позволяют пользователям предоставлять серверу собственные шаблоны регулярных выражений. Атака с инъекцией в регулярное выражение – вид атаки на «отказ в обслуживании» (ReDoS – подробнее об этой атаке в будущих постах) - происходит, когда злоумышленник предоставляет механизму регулярных выражений шаблон, для оценки которого требуется много времени.
25. XPath-инъекции
XPath — это язык запросов, используемый в XML-документах для запроса и выполнения операций с данными, хранящимися в XML-документах. XPath-инъекция — это инъекция в выражения XPath, чтобы изменить результат запроса. Подобно SQL-инъекции, её можно использовать для обхода бизнес-логики, повышения привилегий пользователя и утечки конфиденциальных данных. Поскольку приложения всё ещё часто используют XML для передачи конфиденциальных данных между системами и веб-сервисами, именно эти места наиболее уязвимы для XPath-инъекций.
26. Инъекции в заголовки
Происходят, когда заголовки ответов HTTP динамически создаются из ненадёжных входных данных. В зависимости от того, на какой заголовок ответа влияет уязвимость, инъекция в заголовок может привести к межсайтовому скриптингу, открытому перенаправлению или краже сессии.
Например, если заголовком Location можно управлять с помощью параметра URL, злоумышленники могут вызвать открытое перенаправление, указав свой вредоносный сайт. Злоумышленники могут даже выполнять вредоносные сценарии в браузере жертвы или заставлять жертв загружать вредоносное ПО, отправляя жертве полностью контролируемые HTTP-ответы посредством инъекции в заголовок.
Вы можете предотвратить эту атаку, избегая записи пользовательского ввода в заголовки ответов, удаляя символы новой строки из пользовательского ввода (символы новой строки используются для создания новых заголовков ответов HTTP) или используя белый список для проверки значений заголовков.
27. Инъекции в сессии и небезопасные cookie
Если злоумышленник может манипулировать содержимым cookie-файла сессии или украсть чужие cookie, он может обмануть приложение, заставив его думать, что он является кем-то другим. Существует три основных способа, с помощью которых злоумышленник может получить доступ к чужой сессии:
1) Перехват сессии, когда злоумышленник крадёт чужой cookie-файл сессии и использует его как свой. Злоумышленники часто крадут cookie-файлы сессии с помощью атак XSS или MITM (man-in-the-middle).
2) Фальсификация сессии, когда злоумышленники могут изменить свой cookie-файл сессии, чтобы изменить то, как сервер интерпретирует их личность. Это происходит, когда состояние сессии передаётся в файле cookie, а он неправильно подписан или не зашифрован.
3) Спуфинг сессии – это «подделка» сессии, когда её идентификатор предсказуем. В этом случае злоумышленники могут подделывать настоящие cookie-файлы сессии и входить в систему как кто-то другой.
Источник: https://dzone.com/articles/c-applications-vulnerability-cheatsheet
👍8