Эффект снежного обвала сервисов:

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

Решение проблемы снежного обвала сервисов с использованием фреймворка Hystrix от компании Netflix: 1. Изоляция сервисов, каждый сервис использует отдельный пул потоков для изоляции сервисов. Преимуществом является полная независимость от других сервисов, недостатком — большое потребление памяти. Также можно использовать счетчики для изоляции сервисов.

2. Отключение сервисов (фузинг), когда частота запросов к сервису становится слишком большой, происходит автоматическое понижение уровня сервиса.

3. Отключение и изоляция сервисов используются вместе.

4. Ограничение количества запросов к сервису. Различные способы ограничения:
       1. Использование счетчиков, с использованием атомарных классов AtomicInteger для простой реализации счетчиков, но с проблемой критического значения.
       2. Использование скользящего окна счетчиков, что решает проблему критического значения.
       3. Использование бакета токенов, разработанного компанией Google в фреймворке Guava, RateLimiter. Принцип работы заключается в том, что токены добавляются в бакет с определенной частотой, и запросы, которые могут получить токен, могут быть обработаны.
       4. Использование бакета для ограничения, где капли воды добавляются в бакет с любой частотой, а выход капель регулируется с фиксированной частотой. Когда емкость бакета достигает максимума, сервис становится недоступным.Основные функции, реализованные в этом проекте:

1. Использование Hystrix для изоляции сервисов, фузинга, понижения уровня сервиса и ограничения запросов.
2. Использование AOP + аннотаций + RateLimiter для ограничения запросов к сервисам.

Частые методы атаки веб-приложений и их решения: 1. Атака XSS, например, вставка исполняемого JavaScript кода в параметры запроса, который затем отображается на другой странице, что может быть использовано для атаки сайта. Решение: использование фильтров для перезаписи параметров запроса или отклонение запроса.

2. Технология защиты от кражи ссылок, например, кража изображений. Решение: проверка реферера запроса, если запрос не пришел с сайта, отклонение запроса или возврат сообщения или другого изображения.

3. SQL-инъекции в MyBatis. Использование #{} вместо ${}.

4. Атака CSRF (Cross-Site Request Forgery), аналогичная атаке типа DDOS:
  Решение:
        1. Использование токенов для решения проблемы неатомарности, например, получение токена перед выполнением запроса и проверка его существования.
        2. Ограничение запросов.
        3. Для критически важных операций, таких как оплата, переводы, заказы, лучше использовать SMS-коды или распознавание лиц.

5. Уязвимость при восстановлении пароля. Принцип эксплуатации: при смене пароля используется подтверждение по SMS-коду. Например, если код подтверждения состоит из 4 цифр, то можно использовать многопоточное создание кодов подтверждения и постоянные запросы через httpClient, пока не будет получен успешный код.Решение:

1. При неудачных попытках смены пароля использовать CAPTCHA.

2. Ограничить доступ по IP-адресу.

3. Сделать правила генерации кода подтверждения более сложными, избегая использования только цифр.

4. Уязвимость при загрузке файлов. При загрузке изображений, если не ограничивать типы файлов, можно загрузить исполняемый файл, например, внедрить исполняемый код в JSP-файл. При последующем доступе к этому файлу, это может привести к форматированию всего диска и краху сервера.

Решение:

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

Процесс аутентификации OAuth 2.0:

1. По appid и appsecret перенаправляются на страницу аутентификации третьей стороны, возвращается code.
2. По code запрашивается access_token.
3. По code и access_token получается userId.Симметричное и асимметричное шифрование:
4. Симметричное шифрование: шифрование и дешифрование используют один ключ. Примеры симметричного шифрования: DES, AES. Преимущества: пользователю необходимо создать только один ключ, который можно использовать для шифрования и дешифрования. По сравнению с асимметричным шифрованием, вычислительная нагрузка меньше, скорость выше, простота использования. Подходит для шифрования и дешифрования больших объемов данных. Подходит для коммуникации между серверами (например, между backend системами). Длина ключа должна быть кратной 8. Недостатки: после декомпиляции исходного кода, если ключ будет утечкой, это будет небезопасно.
5. Асимметричное шифрование:
   • Защита безопасности интерфейсов мобильных приложений:
     1. HTTPS-трансляция, асимметричное шифрование RSA, использование токена.
   • Состоит из пары ключей: открытого ключа и закрытого ключа. Пара ключей генерируется с помощью третьей стороны. Один ключ используется для шифрования, другой для дешифрования.
   • Шифрование с использованием открытого ключа и дешифрование с использованием закрытого ключа (чаще всего используется).
   • Шифрование с использованием закрытого ключа и дешифрование с использованием открытого ключа (не рекомендуется).
   • Открытый ключ можно использовать публично, закрытый ключ должен оставаться конфиденциальным. - Недостаток: низкая эффективность.Что такое пробитие кэша? Как избежать? Что такое кэш-апокалипсис? Как избежать?

Пробитие кэша:

• Обычные системы кэширования используют ключ для поиска в кэше. Если соответствующего значения нет, система должна обратиться к backend системе (например, к базе данных).
• Некоторые злонамеренные запросы могут специально искать несуществующие ключи, создавая большую нагрузку на backend систему. Это и называется пробитием кэша.
• Как избежать?
  1. Кэшировать результаты запросов, которые не содержат значений, с коротким временем жизни кэша или очисткой кэша после вставки соответствующих данных.
  2. Фильтрация ключей, которые точно не существуют. Все возможные ключи можно добавить в большое битовое поле, а запросы можно фильтровать с помощью этого битового поля.Кэш-апокалипсис:
• Когда сервер кэширования перезапускается или большое количество кэшированных данных одновременно истекает, это может создать большую нагрузку на backend систему, что может привести к её отказу.
• Как избежать?
  1. После истечения времени жизни кэша, использовать блокировку или очередь для контроля количества потоков, которые читают данные из backend системы и записывают их в кэш. Например, для определённого ключа разрешается только одному потоку читать данные и записывать их в кэш, остальные потоки ожидают.
  2. Создать вторичный кэш: A1 - исходный кэш, A2 - копия кэша. Когда A1 истекает, можно использовать A2. Время жизни кэша A1 должно быть коротким, а A2 - долгим.
  3. Разные ключи, разные сроки жизни, чтобы время истечения кэша было как можно более равномерно распределено. Циклические зависимости:
  4. A зависит от B, B зависит от A
  5. Прямое внедрение или внедрение через сеттер-методы допустимы. В процессе инициализации A Spring сначала выполняет конструктор, затем присваивает свойство B, обнаруживает, что значение свойства пустое, и временно сохраняет его в кэше. Затем инициализирует B, и при присваивании свойства A, берёт значение из кэша. Затем присваивает значение B свойству A. Это основано на передаче ссылок в Java.
  6. Внедрение через конструктор не работает, newInstance(Obj) не может принимать пустое значение.http抓包工具, fiddle:1. Принцип редиректа заключается в том, что сервер сначала возвращает код состояния 302 браузеру, браузер получает значение location и выполняет повторный запрос. Это эквивалентно двум запросам.

2. Когда вы подключаетесь к чужому Wi-Fi, хакер может использовать инструменты для перехвата пакетов, чтобы перехватывать все запросы и изменять данные запроса и ответа. Решение:
   • Использование HTTPS для передачи данных, шифрование на стороне клиента, использование клавиатуры для ввода пароля.
   • Шифрование и проверка подписи. Симметричное шифрование: DES и AES. Асимметричное шифрование: RSA.

HTTPS запросы:

1. Конфигурация nginx с сертификатом, публичным и приватным ключами.

2. Когда клиент отправляет запрос, он сначала обращается к nginx, чтобы получить сертификат (включающий информацию о центре сертификации, срок действия сертификата и т.д.) и публичный ключ. Затем клиент генерирует случайное число и шифрует параметры запроса симметричным алгоритмом, а затем шифрует случайное число публичным ключом и отправляет его на сервер.

3. Сервер, получив запрос, сначала расшифровывает случайное число с помощью приватного ключа, а затем расшифровывает параметры запроса с помощью соответствующего симметричного алгоритма. Это обеспечивает безопасность запроса, но снижает производительность по сравнению с HTTP запросами из-за нескольких действий шифрования и расшифровки.Кэширование, ehcache:

4. Это встроенный кэш JVM, который может использоваться только для приложений, написанных на Java.

5. Обычно используется вместе с Redis для создания двухуровневого кэша. Сначала данные проверяются в Redis, затем в ehcache, и, наконец, в базе данных.

Распределенные блокировки:

1. Redis, setnx (необходимо учитывать возможность возникновения мертвых琐锁，释放锁时，如果锁的时间到了但业务尚未处理完成，锁的时间难以控制), Redisson
2. Zookeeper, создание временного узла для получения блокировки, затем, когда сессия закрывается, временный узел становится недействительным, и уведомление о недействительности узла отправляется другим потокам для получения блокировки.
3. Управление блокировками с помощью базы данных

Распределенные сессии:

1. Spring-Session будет хранить все сессии в Redis.
2. Cookie-способ.
3. Токен-способ, сначала на сервере генерируется зашифрованный токен (UUID + время создания + срок действия + соль), который записывается на клиент, затем каждый раз при запросе токен передается, расшифровывается, проверяется срок действия и легальность.

Заметка: Как гарантировать, что сессии не будут недействительными при выпуске проекта?

1. Можно использовать двухуровневое кэширование, где сессия хранится как в памяти, так и в Redis.
2. Токен-способ, токен, который не будет недействительным.

Почему возникает проблема с��域？ Кросс-доменные (cross-domain) проблемы возникают из-за политики безопасности браузеров, которая ограничивает доступ к ресурсам на других доменах. Это предотвращает возможность злоупотребления сайтов, которые могут получить доступ к данным пользователя без его ведома. Кратко говоря, проблема заключается в том, что домен и порт браузера не совпадают с путём, по которому осуществляется запрос AJAX, что вызывает ограничения безопасности браузера.Решение:

1. Использование JSONP, которое поддерживает только GET-запросы, POST-запросы не поддерживаются.
2. Установка заголовков ответа. Например, httpResponse.setHeader("Access-Control-Allow-Origin", "*")
3. Настройка Nginx для создания API-шлюза, который различает серверы по пути.
4. В микросервисах использование Zuul для решения проблемы кросс-доменных запросов.