Моя команда выполняет миграцию с Coldfusion 8 на Windows Server 2003 и IIS 6 на Coldfusion 10 на Windows Server 2008R2 и IIS 7.5.
В нашей стандартной сборке для серверов CF10 мы реализовали значение по умолчанию 100 для максимального количества параметров запроса POST. Однако мои клиенты запрашивают повышение лимитов до 3000 из-за ошибок в server.log, показывающих:
"Error","ajp-bio-8018-exec-2","06/17/14","10:40:46",,"POST parameters exceeds the maximum limit 100 specified in the server. You can modify the setting in Administrator Server Settings."
Я хочу увеличить лимит, чтобы удовлетворить клиента, но не слишком высоко, чтобы повлиять на стабильность среды приложения и других приложений, размещенных на сервере. Каковы последствия увеличения этого параметра до 5000 или выше? Нет ли недостатков и ограничений IIS?
Спасибо.
Учтите, что раньше не было предела. Причина для этого сейчас заключается в решении серьезной проблемы безопасности, которая актуальна для всех языков веб-программирования, а не только для ColdFusion.
Возможно, у них есть большие формы, которые требуют более высокой настройки. Вместо того, чтобы выбирать какое-то произвольное значение, попросите их заглянуть в свою базу кода и определить фактическое наибольшее количество опубликованных параметров, которые им нужны, а затем дайте немного для заполнения.
Мне пришлось сделать это в моей компании, и в рамках наших стандартов кодирования мы установили ограничение на размер формы. Если появляется новая задача, которой требуется больше, чем лимит, то она изменяется так, чтобы требовать меньше лимита.
Эта статья объясняет атаку HashDos, которая является причиной этой настройки.
Сделайте шаг назад и узнайте об уязвимости HashDos
Сначала нам нужно понять уязвимость, которую этот параметр должен защищать, называемую HashDos. Для этого нам нужно сделать еще один шаг назад и узнать, как работают алгоритмы хеширования. Когда вы сохраняете что-то в структуре в ColdFusion, например form ["pete"], она создает хеш ключа, в данном случае "pete", хеширует значение до целого числа, предположим, что "pete" .hashCode ( ) == 8
Все алгоритмы хеширования имеют возможность создания коллизии, когда две разные строки приводят к одному и тому же хеш-коду. Скажем также, что "peter" .hashCode () == 8. Вы не хотите, чтобы form ["peter"] возвращал результат form ["pete"], поэтому хеш-таблица создает корзину для каждого целочисленного кода. Если ведро содержит несколько элементов, сравнивается каждый элемент в корзине (это медленно).
Поскольку это сравнение коллизий происходит очень медленно, здесь появляется возможность отказа в обслуживании. Если вы можете создать запрос, который приводит к тысячам поисков хеш-коллизий, обработка запроса может занять от нескольких секунд до нескольких минут. Например, при 50 000 столкновений моему четырехъядерному Mac Pro с 15 ГБ оперативной памяти потребовалось около 30 минут для обработки запроса (общий размер которого был менее 2 МБ).
HashDos относится не только к формированию переменных сообщений
Каждый раз, когда вы храните много ключей в структуре, у вас есть потенциал для HashDOS. Область URL потенциально также может быть уязвимой, но веб-сервер обычно ограничивает размер строки запроса. Это может произойти и в том случае, если вы принимаете строки Xml или JSON из внешних источников, которые затем анализируются в структуру. Так что имейте это в виду всякий раз, когда вы принимаете внешний ввод, который может дать структурные ключи.