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

Question

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

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

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

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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

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

Threat Modeling, once again - Ларри Остерман

Как описано в The New Threat Modeling Process на Microsoft Security Development Lifecycle (SDL)Blog, расширил Ларри Остермана seriesofarticles по моделированию угроз (обновлено here) и продемонстрировал его Threat Modeling Again, Presenting the PlaySound Threat Model post, в любом месте данные пересекает доверительные границы вам необходимо определить возможные угрозы.