2010-03-26 2 views
2

Я просто столкнулся с this point, в котором содержится ссылка на уязвимость безопасности в веб-приложениях, которая зависит от просмотра размера зашифрованных веб-страниц для определения того, что делает использование. Самое простое решение этого, о котором я могу думать, - использовать инструмент для минимизации всего статического контента, чтобы (после шифрования) существовало лишь небольшое количество размеров результатов, чтобы минимизировать информацию, доступную для прослушивателя.Компиляция HTML/JavaScript для обеспечения безопасности

Есть ли инструменты для этого?

+0

Отличная статья, BTW! Спасибо за эту ссылку. –

ответ

1

Нет, я не знаю инструмент, чтобы предотвратить эту атаку. Причина в том, что это очень ограниченная атака, которая не распространена в реальном мире. Многие криптоадрессы совершенно бесполезны в реальном мире.

Чтобы предотвратить эту атаку, сервер может добавлять случайное дополнение к сообщению. В случае асинхронных скриптов вы можете добавить элементы junk xml или json. В других случаях вы можете добавлять комментарии html или javascript. Это тривиально реализовать, и я не думаю, что это гарантирует «инструмент».

Военные сети делают это для защиты от этой самой атаки с использованием постоянного потока данных. Я думаю, что он реализовал эфир на транспортном или сетевом уровне. Было бы сложно вывести это на прикладном уровне с помощью http. Кроме того, ширина полосы частот намного меньше, что менее важно, чем военные секреты, где это, вероятно, не так с вашим веб-приложением.

+0

Это обеспечит инструмент, если у вас есть 3k-файлы или вы хотите регулярно регулировать размеры файлов. – BCS

+0

Если у вас есть большое количество файлов, вы можете добавить произвольное количество поддельных заголовков HTTP ко всем запросам. Я не уверен, на какой платформе вы работаете, но PHP может это сделать. – rook

1

Обязательным условием для минимизации статического содержимого является включение HTTP Compression. Это немного уменьшит количество результатов.

Но учтите, что если вы уменьшите содержимое до половины размера, то не обязательно будет только вдвое меньше размеров результатов! Это было бы только в том случае, если ваш исходный контент использовал все возможные размеры. Скажем, ваш исходный контент предлагает 4 разных размера: 10 КБ, 12 КБ и 14 КБ

Если ваше сжатие сокращает каждый из них до половины размера, вы все равно получите три разных размера: 5kB, 6kB и 7kB.

Примечание Для того, чтобы понять (возможно, это не было): Это скорее совет против использования минификации/сжатия. См. Также мой комментарий.

+0

Хорошая точка на чистое сжатие. OTOH Я думал об удалении/добавлении белого пространства. Однако, когда вы смешиваете два, у вас будет другая проблема, потому что получение файла для сжатия, чтобы точно определить размер, путем настройки несжатого текста, может быть очень сложно/раздражать. – BCS

+0

Как это делает размер ответов менее предсказуемым? – rook

+0

@ The Rook: Это моя точка: это не так - по крайней мере, не так много! Вот почему я рекомендовал * против * minification (за исключением того, что вы удовлетворены минимальным выигрышем, который вы получаете, потому что, когда длина контента меньше, тогда статистически меньше возможных вариантов.) IOW, я бы посоветовал использовать padding - или даже лучше (хотя и нереалистично): отправка постоянного потока, независимо от того, передаете ли вы реальные данные или просто фиктивные данные. –

Смежные вопросы