Могут ли другие типы данных, кроме строк, быть потенциально опасными, если получены из внешних источников?

Question

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

Чтобы избежать таких проблем, вы должны контролировать все строки, на которые могут влиять внешние ресурсы. Perl поддерживает это с помощью 'Taint-mode'.

Проблемы, о которых я знаю, все возникают из-за манипулирования строками. Знаете ли вы примеры проблем безопасности, возникающих от целых, поплавков и т. Д., Управляемых внешними воздействиями? Или эти типы данных считаются безопасными?

Answer 1

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

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

Скорее всего, строки могут вызывать проблемы, чем другие значения, но все вводимые пользователем данные должны рассматриваться как потенциально опасные.

Answer 2

Вы никогда не должны доверять любым данным, которые пересекают trust boundary.

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

Моделирование угроз, еще раз - Ларри Остерман

Как описано в Новый процесс моделирования угроз в жизненном цикле разработки безопасности Microsoft (SDL) Блог , дополненный серией Ларри Остермана из статей о моделировании угроз (обновлено здесь ) и продемонстрировано его Опять моделирование угроз, представив пост модели угроз PlaySound , везде, где данные пересекают границу доверия, вам необходимо определить возможные угрозы.

Answer 3

Это не типы данных, которые были бы безопасными или нет - это код внизу, который определяет это.

При этом строки обычно вызывают проблемы из-за переполнения буфера или атак в стиле внедрения на некоторый базовый интерпретатор (SQL или некоторый язык сценариев). Очевидно, вы не увидите такого рода проблем с переменными числового типа.

То, что может случиться, - это ошибки, связанные с неверными внешними значениями, которые могут привести к чему-то вроде атаки типа «отказ в обслуживании».

Answer 4

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