Защитите себя от DoS-атак

Создание собственного десериализатора, в котором я хотел десериализовать определенное поле в виде текста i.s.o. правильное DTO, это решение, которое я придумал.

Я написал свой собственный JsonToStringDeserializer следующим образом:

import com.fasterxml.jackson.core.JsonParser;
import com.fasterxml.jackson.core.TreeNode;
import com.fasterxml.jackson.databind.DeserializationContext;
import com.fasterxml.jackson.databind.JsonDeserializer;
import lombok.NoArgsConstructor;
import org.apache.commons.lang3.StringEscapeUtils;

import java.io.IOException;

/**
 * Deserialiser to deserialise any Json content to a String.
 */
@NoArgsConstructor
public class JsonToStringDeserializer extends JsonDeserializer<String> {


    /**
     * Deserialise a Json attribute that is a fully fledged Json object, into a {@link String}.
     * @param jsonParser Parsed used for reading JSON content
     * @param context Context that can be used to access information about this deserialization activity.
     * @return The deserialized value as a {@link String}.
     * @throws IOException
     */
    @Override
    public String deserialize(JsonParser jsonParser, DeserializationContext context) throws IOException {

        final TreeNode node = jsonParser.getCodec().readTree(jsonParser);

        final String unescapedString = StringEscapeUtils.unescapeJava(node.toString());
        return unescapedString.substring(1, unescapedString.length()-1);
    }
}

Аннотируйте поле, которое вы хотите десериализовать, следующим образом:

@JsonDeserialize(using = JsonToStringDeserializer.class)

Сначала я следовал совету, который сказал использовать TreeNode как this:

    final TreeNode treeNode = jsonParser.getCodec().readTree(jsonParser);
    return treeNode.toString();

Но тогда вы получите строку Json, которая содержит escape-символы.

18
задан MPelletier 6 October 2011 в 01:35
поделиться

4 ответа

Асинхронные серверы, например, более или менее устойчивы к этой конкретной форме атак. Я, например, обслуживаю свои приложения Django с помощью обратного прокси-сервера Nginx, и атака, похоже, никак не повлияла на его работу. Другой популярный асинхронный сервер - lighttpd.

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

необоснованно сложные или необоснованно огромные запросы как можно быстрее (и регистрировать их, чтобы помочь в обнаружении атаки)
  • Не используйте чистый LRU-кеш, если запросы от неаутентифицированных клиентов могут привести к удалению вещей из этого кеша, потому что вы будут подвергаться атакам с отравлением кеша (когда злонамеренный клиент запрашивает множество разных редко используемых вещей, в результате чего вы вытесняете все полезные вещи из своего кеша и вам нужно выполнять гораздо больше работы для обслуживания своих законных клиентов)
  • Помните, важно полностью отклонять регулируемые запросы (например, с ответом HTTP 503: Service Unavailable или аналогичным ответом, подходящим для любого используемого вами протокола), а не ставить регулируемые запросы в очередь. Если вы поставите их в очередь, очередь просто съест всю вашу память, и DoS-атака будет по крайней мере столь же эффективной, как и без дросселирования.

    Еще несколько конкретных советов для HTTP-серверов:

    • Убедитесь, что ваш веб-сервер настроен отклонять сообщения POST без сопутствующего заголовка Content-Length и отклонять запросы (и блокировать нарушителя), которые превышают заявленную Content-Length , и отклонять запросы с Content-Length , что неоправданно длинно для службы, на которую нацелен POST (или PUT ))
    46
    ответ дан 30 November 2019 в 06:35
    поделиться

    Для этой конкретной атаки (пока запрашивается GET) будет работать балансировщик нагрузки или WAF, который основывает только полные запросы к веб-серверу.

    Проблемы начинаются, когда вместо Используется GET POST (что легко), потому что вы не можете знать, является ли это вредоносным POST или просто очень медленной загрузкой от пользователя.

    Из-за DoS как такового вы не можете действительно защитить свое веб-приложение из-за простого факт. Ваши ресурсы ограничены, в то время как злоумышленник потенциально имеет неограниченное время и ресурсы для выполнения DoS-атаки. И в большинстве случаев для злоумышленника дешево выполнить необходимые действия. например, эта атака упомянула несколько 100 медленно работающих соединений -> нет проблем

    1
    ответ дан 30 November 2019 в 06:35
    поделиться

    Краткий ответ:

    Вы не можете защитить себя от DoS.

    И я не согласен, что это относится к serverfault, поскольку DoS классифицируется как проблема безопасности и определенно относится к программированию

    0
    ответ дан 30 November 2019 в 06:35
    поделиться

    Асинхронные серверы, например, более или менее устойчивы к этой конкретной форме атак. Я, например, обслуживаю свои приложения Django с помощью обратного прокси-сервера Nginx, и атака, похоже, никак не повлияла на его работу. Другой популярный асинхронный сервер - lighttpd.

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

    1
    ответ дан 30 November 2019 в 06:35
    поделиться
    Другие вопросы по тегам:

    Похожие вопросы: