Остановка целочисленного переполнения в ASP.NET - PullRequest
Новая
       32

Остановка целочисленного переполнения в ASP.NET

5 голосов
/ 29 июля 2011

Мы используем Acunetix на работе для проверки безопасности наших приложений. Недавно мы натолкнулись на следующую ошибку целочисленных уязвимостей:

Integer Vulnerabilities

Из того, что я могу сказать, похоже, что отчет говорит нам, что мы не прекращаем целочисленные атаки на переполнение внутри строк запросов. Хотя мы используем строки запросов, которые в конечном итоге преобразуются в целые числа, они сначала шифруются, а затем дешифруются и преобразуются в int с использованием Convert.ToInt32(), прежде чем мы их используем. Я знаю, что мы должны использовать TryParse() вместо этого, но даже если хакер введет целочисленное значение выше, чем max, он потерпит неудачу при попытке расшифровать, прежде чем даже попытаться преобразовать в целое число, в котором переполнение целого будет происходить в мое мнение. То есть разве ошибка возникает при сбое расшифровки?

Я довольно смущен этим, и поиски в Google не сильно помогли, так как большинство из них относится к неуправляемым языкам, таким как c ++, а не c # и asp.net. Любая помощь будет высоко ценится.

1 Ответ

2 голосов
/ 30 июля 2011

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

Автоматические сканеры немного сходят с ума по ошибкам HTTP 500.Они не знают, что на самом деле происходит под прикрытием и насколько серьезна ошибка, чтобы вы могли утверждать, что это ложноположительный результат.С другой стороны, ваши сотрудники по безопасности будут утверждать, что веб-сайты, легко возвращающие HTTP 500, с большей вероятностью будут подвергнуты дальнейшему исследованию, если бот обнаружит, что вы регулярно выбрасываете эти ошибки в результате манипулирования строками запросов.

Простой ответ: "Все входные данные должны быть проверены по белому списку допустимых диапазонов значений." (от здесь ).

...