WeGIA является веб-менеджером благотворительных учреждений. До версии 3.6.6 в приложении WeGIA существует критическая уязвимость инъекций S…
WeGIA является веб-менеджером благотворительных учреждений. До версии 3.6.6 в приложении WeGIA существует критическая уязвимость инъекций SQL. Скриптика remover_produto_ocultar.php использует extract($_REQUEST) для заселения локальных переменных, а затем непосредственно конкатенирует эти переменные в SQL-запрос, выполняемый с помощью PDO::questry. Это позволяет аутентифицированному (или обойденному) злоумышленнику выполнять произвольные команды SQL. Это может быть использовано для извлечения конфиденциальных данных из базы данных или, как показано в этом PoC, вызвать задержку, основанную на времени (отказ в обслуживании). Эта уязвимость зафиксирована в 3.6.6.
Продукт формирует команду SQL полностью или частично с использованием внешних входных данных из вышестоящего компонента, но не нейтрализует или некорректно нейтрализует специальные элементы, способные изменить замысленную команду при передаче нижестоящему компоненту. При недостаточном удалении или экранировании синтаксических конструкций SQL в управляемых пользователем входных данных сформированный запрос может привести к интерпретации этих данных как SQL вместо обычных пользовательских данных.
https://cwe.mitre.org/data/definitions/89.html →Открыть в коллекции CWE →Слепое внедрение SQL-кода является следствием недостаточного противодействия внедрению SQL-кода. Хотя подавление сообщений об ошибках базы данных считается надлежащей практикой, одного лишь подавления недостаточно для предотвращения SQL-инъекций. Слепое внедрение SQL-кода — это форма SQL-инъекции, преодолевающая отсутствие сообщений об ошибках. Не имея сообщений об ошибках, которые облегчают SQL-инъекцию, злоумышленник формирует входные строки, зондирующие цель с помощью простых булевых SQL-выражений. Злоумышленник может определить, было ли синтаксически и структурно корректно выполнено внедрение, на основании того, был ли выполнен запрос. Применяя этот метод итеративно, злоумышленник определяет, как и где цель уязвима к SQL-инъекции.
https://capec.mitre.org/data/definitions/7.html →Открыть в коллекции CAPEC →Данная атака эксплуатирует целевое программное обеспечение, формирующее SQL-запросы на основе пользовательского ввода. Злоумышленник формирует входные строки таким образом, чтобы в результате построения SQL-запросов на их основе получались SQL-выражения, выполняющие действия, отличные от предусмотренных приложением. Внедрение SQL-кода является следствием некорректной проверки входных данных приложением.
https://capec.mitre.org/data/definitions/66.html →Открыть в коллекции CAPEC →Злоумышленник использует стандартные методы внедрения SQL-кода для передачи данных в командную строку с целью их выполнения. Это может быть сделано напрямую — через злоупотребление такими директивами, как MSSQL_xp_cmdshell, — либо косвенно, путём внедрения данных в базу данных, которые впоследствии будут интерпретированы как команды командного интерпретатора. Через некоторое время непорядочное серверное приложение (или компонент того же приложения) извлекает внедрённые данные из базы данных и использует их в качестве аргументов командной строки без надлежащей проверки. Вредоносные данные выходят за пределы уровня данных, порождая новые команды для выполнения на хосте.
https://capec.mitre.org/data/definitions/108.html →Открыть в коллекции CAPEC →Злоумышленник эксплуатирует слабость в коде доступа к базе данных, сгенерированном инструментом объектно-реляционного отображения (ORM), или некорректное использование разработчиком фреймворка сохранения данных, внедряя собственные SQL-команды для выполнения в базовой базе данных. Атака схожа с обычным внедрением SQL-кода, однако приложение не использует JDBC для прямого обращения к базе данных, а вместо этого применяет уровень доступа к данным, сгенерированный ORM-инструментом или фреймворком (например, Hibernate). Хотя код, сгенерированный ORM-инструментом, в большинстве случаев содержит безопасные методы доступа, защищённые от внедрения SQL-кода, иногда — вследствие слабости сгенерированного кода или ненадлежащего использования разработчиком сгенерированных методов — внедрение SQL-кода всё же остаётся возможным.
https://capec.mitre.org/data/definitions/109.html →Открыть в коллекции CAPEC →Злоумышленник изменяет параметры SOAP-сообщения, направляемого от потребителя сервиса к поставщику, с целью осуществления атаки путём внедрения SQL-кода. На стороне поставщика SOAP-сообщение анализируется, а параметры перед использованием для обращения к базе данных не проходят надлежащую проверку и не используют привязку параметров, что позволяет злоумышленнику управлять структурой выполняемого SQL-запроса. Данный шаблон описывает атаку с внедрением SQL-кода, где средством доставки служит SOAP-сообщение.
https://capec.mitre.org/data/definitions/110.html →Открыть в коллекции CAPEC →Злоумышленник использует доступ к базе данных для чтения и записи данных в файловую систему, компрометации операционной системы, создания туннеля для доступа к хост-машине и дальнейшего возможного использования этого доступа для атак на другие машины в той же сети, что и машина базы данных. Традиционно SQL-инъекции рассматриваются как способ получения несанкционированного доступа к хранимым в базе данных, изменения, удаления данных и т. д. Однако практически каждая система управления базами данных (СУБД) включает средства, компрометация которых даёт злоумышленнику полный доступ к файловой системе, операционной системе и хост-машине, на которой работает база данных. Злоумышленник может затем использовать этот привилегированный доступ для проведения последующих атак. К таким средствам относятся: вызов командного интерпретатора, создание пользовательских функций, обращающихся к системным библиотекам хост-машины, хранимые процедуры и другие.
https://capec.mitre.org/data/definitions/470.html →Открыть в коллекции CAPEC →