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

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

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

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(...){...}

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

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

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

РЕДАКТИРОВАТЬ:

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

Спасибо!


person samaneh    schedule 14.12.2010    source источник


Ответы (1)


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

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

ИЗМЕНИТЬ

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

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

person Stephen C    schedule 14.12.2010
comment
спасибо, не могли бы вы немного конкретизировать подход «всей системы», приведя пример? Я не нашел конкретного подхода с этим именем в программировании и безопасности, поэтому это должно быть общее выражение.. извините, я не знаком с этой областью, и я не являюсь носителем английского языка. - person samaneh; 14.12.2010
comment
Да, по той же причине я ищу, как я могу контролировать неправильное использование таких вещей, как дорогостоящие запросы (например, контроль количества входящих запросов в течение срока) в трикотаже, в то время как каждый запрос обрабатывается непосредственно методом ответа и Я не вижу, где эти запросы изначально получены, а затем направлены на эти методы ответа. - person samaneh; 20.12.2010