Play Framework — это веб-фреймворк для Java и Scala. Версии до 2.8.16 уязвимы для создания сообщений об ошибках, содержащих конфиденциальну…
Play Framework — это веб-фреймворк для Java и Scala. Версии до 2.8.16 уязвимы для создания сообщений об ошибках, содержащих конфиденциальную информацию. Play Framework, при запуске в режиме разработки, отображает подробные ошибки для облегчения отладки, включая трассировку стека исключений. Play делает это, настраивая свой `DefaultHttpErrorHandler` для этого на основе режима приложения. В своем Scala API Play также предоставляет статический объект `DefaultHttpErrorHandler`, который настроен на постоянное отображение подробных ошибок. Он используется в качестве значения по умолчанию в некоторых API Play, поэтому можно непреднамеренно использовать эту версию в production. Также возможно неправильно настроить экземпляр объекта `DefaultHttpErrorHandler` в качестве внедренного обработчика ошибок. Обе эти ситуации могут привести к отображению подробных ошибок пользователям в production-приложении, что может привести к раскрытию конфиденциальной информации из приложения. В частности, конструктор для `CORSFilter` и метод `apply` для `CORSActionBuilder` используют статический объект `DefaultHttpErrorHandler` в качестве значения по умолчанию. Это исправлено в Play Framework 2.8.16. Объект `DefaultHttpErrorHandler` был изменен для использования поведения в prod-mode, а `DevHttpErrorHandler` был представлен для поведения в dev-mode. Доступно обходное решение. При создании `CORSFilter` или `CORSActionBuilder` убедитесь, что передан правильно настроенный обработчик ошибок. Как правило, это следует делать с помощью экземпляра `HttpErrorHandler`, предоставляемого через внедрение зависимостей, или через `BuiltInComponents` Play. Убедитесь, что приложение не использует статический объект `DefaultHttpErrorHandler` в каком-либо коде, который может выполняться в production.
Продукт формирует сообщение об ошибке, включающее конфиденциальные сведения о его среде, пользователях или связанных данных.
https://cwe.mitre.org/data/definitions/209.html →Открыть в коллекции CWE →Слепое внедрение SQL-кода является следствием недостаточного противодействия внедрению SQL-кода. Хотя подавление сообщений об ошибках базы данных считается надлежащей практикой, одного лишь подавления недостаточно для предотвращения SQL-инъекций. Слепое внедрение SQL-кода — это форма SQL-инъекции, преодолевающая отсутствие сообщений об ошибках. Не имея сообщений об ошибках, которые облегчают SQL-инъекцию, злоумышленник формирует входные строки, зондирующие цель с помощью простых булевых SQL-выражений. Злоумышленник может определить, было ли синтаксически и структурно корректно выполнено внедрение, на основании того, был ли выполнен запрос. Применяя этот метод итеративно, злоумышленник определяет, как и где цель уязвима к SQL-инъекции.
https://capec.mitre.org/data/definitions/7.html →Открыть в коллекции CAPEC →Злоумышленник, осведомлённый о местонахождении приложения (и, возможно, авторизованный для его использования), исследует структуру приложения и оценивает его устойчивость путём отправки запросов и анализа ответов. Нередко это осуществляется посредством отправки вариантов ожидаемых запросов в расчёте на то, что изменённые запросы могут вернуть информацию, выходящую за рамки того, что возвращает ожидаемый набор запросов.
https://capec.mitre.org/data/definitions/54.html →Открыть в коллекции CAPEC →Злоумышленник направляет случайные, некорректные или иным образом неожиданные сообщения целевому приложению и наблюдает за возвращаемыми журналами или сообщениями об ошибках приложения. Злоумышленник изначально не знает, как цель реагирует на отдельные сообщения, однако, перебирая большое количество вариантов сообщений, он может найти вариант, вызывающий желаемое поведение. В данной атаке целью фаззинга является наблюдение за журналом и сообщениями об ошибках приложения, хотя фаззинг цели иногда также может приводить к переходу цели в нестабильное состояние и её аварийному завершению.
https://capec.mitre.org/data/definitions/215.html →Открыть в коллекции CAPEC →Злоумышленник способен эффективно расшифровывать данные, не зная ключа дешифрования, если целевая система раскрывает информацию о том, возникла ли ошибка дополнения при расшифровке зашифртекста. Целевая система, утечку такой информации, становится оракулом дополнения, а злоумышленник может использовать этот оракул для эффективной расшифровки данных без знания ключа дешифрования, выполнив в среднем 128*b обращений к оракулу дополнения (где b — количество байт в блоке зашифртекста). Помимо расшифровки, злоумышленник способен также формировать корректные зашифртексты (то есть выполнять шифрование) с использованием оракула дополнения, не зная ключа шифрования.
https://capec.mitre.org/data/definitions/463.html →Открыть в коллекции CAPEC →