Практика Open API Gateway (2) — Повтор атаки и защита

Как спроектировать и внедрить легкий открытый шлюз API для повторной атаки и защиты

Адрес статьи:blog.Park Ruiqing.com/2019/08/11/…

предисловие

Последняя статья "Практика Open API Gateway (1)"Дизайн интерфейса, упомянутый вtimestampиnonceРоль этих двух параметров заключается в предотвращении повторного воспроизведения.В этой статье обсуждаются повторные атаки и их защита.Во-первых, возникают два вопроса:

• Что такое повторная атака
• Как защититься от повторных атак

Что такое повторные атаки

что重放, Например:

Откройте инструмент отладки браузера и посетите веб-сайт, найдите запрос в сетевом инструменте и щелкните правой кнопкой мыши, чтобы выбратьReplay. Как показано:

вышеупомянутый重放Операция является широко используемым методом отладки интерфейса.Эта операция позволяет нам пропустить процесс генерации информации для аутентификации и напрямую инициировать несколько действительных запросов повторно.

и重放攻击Это распространенный метод атаки, используемый хакерами, также известный как重播攻击,回放攻击, означает, что злоумышленник отправляет хосту назначения已接收过的数据, чтобы достичь цели обмана системы, в основном используемой в процессе аутентификации личности, разрушая правильность аутентификации.

Чтобы привести простой для понимания пример:

• Сервер предоставляет платежный интерфейс.Пользователь А запрашивает сервер инициировать платеж в размере 5 юаней (с подписью и шифрованием), и сервер получает данные и правильно платит пользователю Б.
• Но этот запрос был перехвачен хакером (это может сделать пользователь B (￣▽￣)"), хакер отправил запрос на сервер в целости и сохранности, и сервер много раз по ошибке произвел платежи пользователю B. (Конечно, это все. Он основан на предпосылке, что платеж на стороне сервера не принимает идемпотентных превентивных мер и уровень безопасности низкий)
• Хотя запрос, инициированный A, подписан и зашифрован, B не нужно взламывать данные, просто同样的数据Повторная отправка на сервер может достичь цели обмана.

Имитация повторной атаки

экспериментальное оборудование

Экспериментальная процедура

1. Запустите сервер, запросите интерфейс и получите данные ответа.
2. Перехват DNS (изменение адреса DNS-сервера в маршрутизаторе для имитации захвата) и перехват данных запроса.
3. Многократная отправка перехваченных данных на сервер (атака повторного воспроизведения).

Запись процесса

Готов к работе

Настройка DNS, доменное имяreplay-test.piaoruiqing.comУкажите IP-адрес сервера в интрасети и запустите сервер.

нормальный запрос

использоватьpostmanСделать обычный запрос, где подпись уже естьPre-request-scriptгенерируется в.

Перехват данных посредством перехвата DNS

изменить интранетdnsmasqнастроить, установить доменное имяreplay-test.piaoruiqing.comуказывает на поддельный сервер10.33.30.100.

в это время кreplay-test.piaoruiqing.comИнициированный запрос будет отправлен на поддельный сервер (10.33.30.100), а запрошенные данные будут сохранены вручную.Поскольку запрос подписан и у злоумышленника нет закрытого ключа, запрос нельзя подделать, но можно быть Replay атака, Как показано, поддельный сервер успешно получил данные запроса:

повторный запрос

Используя данные, сохраненные на предыдущем шаге, отправьте запрос прямо на реальный сервер (с данными подписи), как показано на рисунке:

На самом деле такие методы, как подпись и шифрование, не могут предотвратить атаки повторного воспроизведения, потому что данные, перехваченные злоумышленником, уже являются правильными данными запроса, и даже если содержимое не может быть расшифровано, исходные данные могут быть воспроизведены и отправлены на сервер для достижения цель обмана.

Как защититься от повторных атак

Энциклопедия Байду

1. 加随机数: Преимущество этого метода в том, что обе стороны аутентификации не нуждаются в синхронизации времени, и обе стороны запоминают использованные случайные числа.Если обнаруживается, что в пакете есть ранее использовавшиеся случайные числа, это считается повторной атакой. Недостатком является то, что используемые случайные числа необходимо дополнительно сохранять, а если записываемый период времени большой, то накладные расходы на сохранение и запросы велики.

2. 加时间戳: Преимущество этого метода в том, что не нужно сохранять дополнительную информацию. Недостаток в том, что две стороны аутентификации нуждаются в точной синхронизации времени. Чем лучше синхронизация, тем меньше вероятность того, что она будет атакована. Но когда система очень большой и охватывает обширную область, это необходимо сделать. Точная синхронизация времени не очень проста.

3. 加流水号: То есть обе стороны добавляют к сообщению постепенно увеличивающееся целое число. Пока получено сообщение с прерывистым серийным номером (слишком большое или слишком маленькое), определяется, что существует угроза воспроизведения. Преимущество этого метода заключается в том, что он не требует синхронизации времени и сохраняет объем информации меньше, чем метод случайных чисел Недостаток заключается в том, что после того, как злоумышленник успешно расшифрует сообщение, он может получить серийный номер, так что серийный номер увеличивается каждый раз, чтобы обмануть терминал аутентификации.

При фактическом использовании 1 и 2 часто используются в комбинации, и случайное число оценивается в пределах периода действия метки времени, и оно напрямую отбрасывается вне периода действия.

Повторить практику защиты от атак

мы принимаем时间戳+随机数Способ реализации простого перехватчика атаки воспроизведения.Временные метки и случайные числа дополняют друг друга, что позволяет не только определить, является ли запрос повторным воспроизведением, проверив наличие случайных чисел в кеше в пределах допустимого диапазона времени, но и когда кеш недопустимо. После (время действия кеша и временной диапазон согласованы) отметка времени используется для проверки того, является ли запрос повторным. Как показано на рисунке:

код показывает, как показано ниже:

@Resource
private ReactiveStringRedisTemplate reactiveStringRedisTemplate;

private ReactiveValueOperations<String, String> reactiveValueOperations;

@PostConstruct
public void postConstruct() {
    reactiveValueOperations = reactiveStringRedisTemplate.opsForValue();
}

@Override
protected Mono<Void> doFilter(ServerWebExchange exchange, WebFilterChain chain) {
    // 此处的`ATTRIBUTE_OPEN_API_REQUEST_BODY`是前面过滤器存入的
    OpenApiRequest<String> body 
        = exchange.getRequiredAttribute(ATTRIBUTE_OPEN_API_REQUEST_BODY);
    if (!ObjectUtils.allNotNull(body, body.getTimestamp(), body.getNonce())) {
        return fail(exchange);
    }
    Long gmt = System.currentTimeMillis();
    // (一)
    if (gmt + effectiveTimeRange < body.getTimestamp() || 
        gmt - effectiveTimeRange > body.getTimestamp()) {
        return fail(exchange);
    }
    // (二)
    return reactiveValueOperations.setIfAbsent(MessageFormat.format(
            KEY_REPLAY_NONCE, body.getAppId(), body.getNonce()),
            String.valueOf(System.currentTimeMillis()),
            Duration.ofMillis(effectiveTimeRange * 2L))
        .log(LOGGER, Level.FINE, true)
        .flatMap(approved -> approved ? 
                 chain.filter(exchange) : fail(FORBIDDEN, exchange)
            );

• (一): Запросы, превышающие временной диапазон, будут отклонены.
• (二): время истечения кэша равно промежутку допустимого времени.Если случайное число уже существует в кэше, оно будет отклонено.

Эпилог

Ключевые моменты защиты от повторной атаки:

• Запишите идентификатор запроса и кэшируйте его, проверьте его при принятии запроса, откажитесь от повторного воспроизведения, в ближайшее времяnonceСохранить в кеше, отклонить то же самоеnonce
• Метод случайных чисел может привести к слишком большому кешу, поэтому его необходимо отфильтровать с отметкой времени, и все отметки времени, которые не находятся в допустимом диапазоне, будут отклонены.

Атака с повторным воспроизведением является распространенным и эффективным методом атаки, и ее вред нельзя игнорировать. Хотя правильность данных может быть гарантирована на бизнес-уровне, она по-прежнему создает ненужные накладные расходы для системы. Фильтрация запросов на воспроизведение на уровне шлюза представляет собой проблему. , Хороший выбор.

Если эта статья была вам полезна, ставьте лайк (￣▽￣)"

Серия статей:

• Практика открытия шлюза API (1) — проектирование шлюза API
• Практика Open API Gateway (2) — Повтор атаки и защита
• Практика Open API Gateway (3) — Текущее ограничение

Добро пожаловать в публичный аккаунт: