Выполняет ли проект Grizzly заботу о переполнении буфера или об отказах в обслуживании?

Question

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

В настоящее время, единственным, что я могу сделать в моей программе, что я раскрываю свои классы ресурсов (аннотированный @Path - Я использую Джерси) к Гризли, следующий код:

final Map<String, String> initParams = new HashMap<String, String>(); 
initParams.put("com.sun.jersey.config.property.packages","MyServer.resources"); 
SelectorThread threadSelector; 
try{ 
    threadSelector = GrizzlyWebContainerFactory.create(
uri, initParams); 
    System.out.println("Press enter to stop server..."); 
    System.in.read(); 
    threadSelector.stopEndpoint(); 
}catch(...){...} 

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

Я проверю размер в теле метода обработчика запроса, который после получения запроса полностью получен сервером. Это достаточно?

В документах Grizzly говорится, что у него хорошее управление буфером (возможно, я смешиваю переполнение буфера с отказом в обслуживании), но я не знаю, должен ли я устанавливать какие-либо настройки или он по умолчанию защищает?

EDIT:

Я получил хороший ответ на часть моего вопроса, но я до сих пор ищу некоторые намеки особенно о гризли или Джерси, и есть ли единая точка входа, в котором я может сделать некоторые проверки для всех входящих запросов?

Спасибо!

Answer 1

Если вы используете Java, вы в значительной степени невосприимчивы к классическим атакам переполнения буфера, если только вы не используете собственные библиотеки кода для обработки материалов, которые вы получаете из сети.

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

EDIT

К «Всей системе» подход, я имею в виду тот, который учитывает влияние на вашей пропускной способности сети, инфраструктуру и серверные сервера, а также только ваш веб-сервере. Например, атака, направленная на вашу сеть или DNS, может отвлечь вас от эфира независимо от того, как вы реализуете свой веб-сервер. С другой стороны, кто-то может ориентироваться на аспекты вашего веб-приложения; например знание того, что конкретный запрос очень дорог ... или что он утечки ресурсов и в конечном итоге сбой вашего приложения.

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