OWASP Top 10

OWASP (Open Web Application Security Project, Open Web Application Security Project) — это онлайн-сообщество, некоммерческая глобальная организация по безопасности с открытым исходным кодом. Оно в основном предоставляет статьи, методологии, документы, инструменты и технологии в области безопасности веб-приложений. и занимается исследованием безопасности прикладного программного обеспечения.

Миссия OWASP — сделать прикладное программное обеспечение более безопасным, позволяя предприятиям и организациям принимать более четкие решения о рисках безопасности приложений. В настоящее время OWASP имеет 250 филиалов по всему миру и почти 70 000 членов, которые совместно продвигают разработку технологий безопасности приложений, таких как стандарты безопасности, инструменты тестирования безопасности и руководства по безопасности.

В рейтинге OWASP Top 10 перечислены признанные наиболее опасные дыры в безопасности веб-приложений, обобщены и обновлены десять наиболее вероятных, распространенных и опасных уязвимостей в веб-приложениях.

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

инъекция

Такие недостатки, как SQLинъекцияNOSQLинъекция, OSинъекция и LDAP-инъекция, возникают, когда ненадежные данные отправляются анализатору как часть команды или запроса. Вредоносные данные злоумышленника могут заставить анализатор выполнить непреднамеренные команды и получить доступ к данным без надлежащей авторизации.

Приложение уязвимо и уязвимо, если:

• Данные, предоставленные пользователем, не проверяются, не фильтруются и не очищаются приложением.
• Операторы динамического запроса или непараметризованные вызовы используются в интерпретаторе без контекстно-зависимого экранирования.
• Вредоносные данные используются в параметрах поиска ORM, поэтому результаты поиска содержат конфиденциальные или неавторизованные данные.
• Вредоносные данные используются или подключаются напрямую, например операторы SQL или команды, содержащие структуры и вредоносные данные в операторах динамических запросов, командах или хранимых процедурах.

Для предотвращения инъекционных уязвимостей необходимо отделить данные от командных операторов и операторов запроса.

• Лучший вариант — использовать API Безопасности.,Полностью избегайте использования переводчика,или предоставляет интерфейс для параметризованных интерфейсов,Или Перейдите на ORMилиEntity Framework.
• Правильно нормализованные методы проверки ввода с использованием правильного или «белого списка» также помогут предотвратить инъекционные атаки.,Но это не полная защита,Поскольку многие приложения требуют ввода специальных символов,Например, textarea или API для мобильных приложений.
• Для любых оставшихся динамических запросов специальные символы могут быть экранированы с использованием специального синтаксиса экранирования этого интерпретатора. Java Encoder OWASP и аналогичные библиотеки предоставляют такие процедуры экранирования.
• Использование LIMIT и других элементов управления SQL в запросах,Чтобы предотвратить утечку большого количества записей в SQL-инъекцию.

Сломанная аутентификация

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

Уязвимости аутентификации могут существовать, когда приложение имеет следующие условия:

• Позволяет подстановку учетных данных, что позволяет злоумышленнику получить список действительных имен пользователей и паролей.
• Позволяет грубую силу или другие автоматические атаки
• Разрешить использование паролей по умолчанию, слабых или общеизвестных паролей, таких как «Пароль1» или «admin/admin».
• Используйте слабые или просроченные учетные данные для аутентификации, забудьте программы паролей, такие как «ответы на основе знаний».
• Используйте открытый текст, шифрование и слабо хешированные пароли (см.: Конфиденциальные данные утекли).
• Многофакторная аутентификация отсутствует или сломана.
• Предоставление идентификатора сеанса в URL-адресе (например, перезапись URL-адреса)
• Идентификатор сеанса не обновляется после успешного входа в систему
• Неправильная аннулирование идентификаторов сеансов. Пользовательские сеансы или токены аутентификации (особенно токены единого входа (SSO)) не выходят из системы должным образом или срок их действия истекает, когда пользователь неактивен.

Стратегия защиты следующая:

• Там, где это возможно, внедрите многофакторную аутентификацию, чтобы предотвратить автоматические атаки, подброс учетных данных, перебор и повторное использование украденных учетных данных.
• Не используйте учетные данные по умолчанию для отправки или развертывания, особенно для пользователей с правами администратора.
• Выполните проверку слабых паролей, например тестирование новых или измененных паролей, чтобы исправить «10 000 самых слабых паролей».
• Согласуйте политику длины, сложности и ротации паролей с рекомендациями NIST-800-63 B (Помнить секреты) или другими современными политиками паролей, основанными на фактических данных.
• Подтвердите регистрацию, восстановление учетных данных и пути API для защиты от атак с перечислением учетных записей, используя одно и то же сообщение для всех выходных результатов.
• Ограничьте или постепенно отложите неудачные попытки входа в систему. Регистрируйте все сбои и предупреждайте администраторов при обнаружении подброса учетных данных, грубой силы или других атак.
• Используйте встроенный менеджер сеансов серверной безопасности.,После входа в систему создайте новый, очень сложный, случайный идентификатор сеанса. Идентификатор сеанса не может быть в URL,Можно сохранить и выйти из системы Безопасность, праздничный, Деактивируйте его после абсолютного таймаута.

Конфиденциальные данные утекли

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

Для конфиденциальных данных определите:

• Используется ли передача открытого текста при передаче данных? Это связано с протоколом передачи, например: HTTP, SMTP и FTP. Внешний сетевой трафик очень опасен. Проверьте все внутренние коммуникации, например между балансировщиками нагрузки, веб-серверами или серверными системами.
• Когда данные хранятся в течение длительного времени, шифруются ли они независимо от того, где они хранятся, включая данные резервных копий?
• Используются ли еще какие-либо старые или слабые алгоритмы шифрования по умолчанию или в исходном коде?
• Используются ли ключи шифрования по умолчанию, создаются или повторно используются слабые ключи шифрования, отсутствует ли надлежащее управление ключами или откат ключей?
• Обязательно ли шифрование конфиденциальных данных? Зашифрованы ли команды пользовательского агента (например, браузера) и транспортные протоколы?
• Пользовательский агент (например, приложение, почтовый клиент) не проверяет действительность сертификата на стороне сервера?

в целом,Стратегия защиты следующая:

• Классифицируйте данные, обрабатываемые, хранимые или передаваемые системой, и осуществляйте контроль доступа на основе классификации.
• Ознакомьтесь с законами и правилами, касающимися защиты конфиденциальных данных, и защищайте конфиденциальные данные в соответствии с каждым нормативным требованием.
• Важные и конфиденциальные данные, которые не нужно хранить, следует как можно скорее удалить или пометить или перехватить с помощью PCIDSS.
• Убедитесь, что все хранящиеся конфиденциальные данные зашифрованы.
• Убедитесь, что используются современные надежные стандартные алгоритмы или шифры, параметры, протоколы и ключи, а также имеется управление ключами.
• Убедитесь, что данные шифруются при передаче (HTTPS).
• Отключите кеширование ответов, содержащих конфиденциальные данные.
• Обязательно храните пароли с использованием алгоритмов, специфичных для паролей. Установите рабочий коэффициент (коэффициент задержки) в пределах допустимого диапазона.
• Проверьте достоверность каждого элемента конфигурации «Безопасность» отдельно.

Внешний объект XML (XXE)

Злоумышленники могут использовать внешние объекты для кражи внутренних и общих файлов с помощью обработчиков файлов URI, прослушивания внутренних портов сканирования, выполнения удаленного кода и проведения атак типа «отказ в обслуживании».

Приложения, особенно веб-службы на основе XML или нисходящая интеграция, могут быть уязвимы по следующим причинам:

• Приложение принимает файлы XML напрямую или принимает загрузки файлов XML, особенно файлов из ненадежных источников, или вставляет ненадежные данные в файлы XML и отправляет их процессору XML для анализа.
• В SOAP на основе приложения или веб-службы все процессоры XML поддерживают определение типа документа (DTDS). Потому что точный механизм отключения процессов DTD варьируется от процессора к процессору.
• Если для достижения Безопасности или единого входа (SSO),Приложение использует SAML для аутентификации. SAML использует XML для проверки личности.,Тогда приложение уязвимо для атак XXE.
• Если приложение использует SOAP до версии 1.2 и передает объекты XML в структуру SOAP, оно может быть уязвимо для атак XXE.
• Приложения с недостатками XXE более уязвимы к атакам типа «отказ в обслуживании», в том числе: атакам BilionLaughs.

в целом,Стратегия защиты следующая:

• По возможности используйте простые форматы данных (например, JSON) и избегайте сериализации конфиденциальных данных.
• Своевременно исправляйте или обновляйте все процессоры и библиотеки XML, используемые приложениями или базовой операционной системой. В то же время обновите SOAP до версии 1.2 или выше посредством обнаружения зависимостей.
• Отключите внешний объект XML и процессы DTD во всех анализаторах XML приложения.
• Внедрите агрессивную («белый список») проверку, фильтрацию и очистку входных данных на стороне сервера, чтобы предотвратить появление вредоносных данных в заголовках или узлах XML-документа.
• Функция проверки загрузки файлов XML или XSL использует проверку XSD или другие аналогичные методы проверки для проверки загруженных файлов XML.
• Хотя во многих интегрированных средах,Ручная проверка кода — лучший вариант для больших и сложных приложений.,Но инструменты SAST могут обнаружить уязвимости XXE в исходном коде. Если эти элементы управления невозможны,Рассмотрите возможность использования шлюза безопасности Virtual Fix API и брандмауэра веб-приложений (WAF) для обнаружения, мониторинга и предотвращения атак XXE.

Нарушен контроль доступа

Для аутентифицированных пользователей не реализованы надлежащие средства управления доступом. Злоумышленники могут использовать эти недостатки для доступа к несанкционированным функциям или данным, например: доступ к учетным записям других пользователей, просмотр конфиденциальных файлов, изменение данных других пользователей, изменение разрешений доступа и т. д.

К распространенным уязвимостям контроля доступа относятся:

• Обходите проверки контроля доступа, изменяя URL-адреса, внутреннее состояние приложения или HTML-страницы или просто используя специальные инструменты атаки API.
• Позволяет изменить первичный ключ записи другого пользователя, например просмотреть или изменить чужую учетную запись.
• Повышение привилегий. Притворитесь пользователем, не входя в систему, или действуйте как администратор, войдя в систему как пользователь.
• Манипулирование метаданными, например воспроизведение или подделка токенов управления доступом JWT, файлов cookie или скрытых полей для повышения привилегий.
• Ошибка конфигурации CORS обеспечивает несанкционированный доступ к API.
• Принудительный просмотр в качестве неаутентифицированного пользователя страниц, которые можно просмотреть только посредством аутентификации, или доступ к страницам с соответствующими разрешениями в качестве обычного пользователя, или API не обеспечивает контроль доступа для POST, PUT и DELETE.

Контроль доступа эффективен только в доверенном серверном коде или бессерверных API, поэтому злоумышленники не могут изменить проверки или метаданные управления доступом.

• По умолчанию доступ запрещен, за исключением общедоступных ресурсов.
• Используйте одноразовые механизмы контроля доступа и постоянно используйте их во всем приложении, включая минимизацию использования CORS.
• Создайте модель контроля доступа, чтобы обеспечить соблюдение записей о собственности, а не принимать любые записи, созданные, прочитанные, обновленные или удаленные пользователем.
• Управление доступом к домену уникально для каждого приложения, но требования к бизнес-ограничениям должны обеспечиваться моделью домена.
• Отключите списки каталогов веб-сервера и убедитесь, что метаданные файлов (например: git) не существуют в корневом каталоге веб-сайта.
• Записывайте сбои контроля доступа и при необходимости предупреждайте администраторов (например, о повторяющихся сбоях).
• Ограничьте скорость доступа к API и контроллерам, чтобы минимизировать ущерб от автоматических инструментов атак.
• Когда пользователь выходит из системы, срок действия токена JWT на сервере истекает.

Ошибка конфигурации безопасности

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

Приложения могут быть уязвимы для атак, если:

• В любой части стека приложений отсутствует соответствующее усиление безопасности.,Неправильно настроены разрешения облачного сервиса.
• Приложение включает или устанавливает ненужные функции (например: ненужные порты, службы, веб-страницы, учетные записи или разрешения). Пароль для учетной записи по умолчанию по-прежнему доступен и не менялся.
• Механизмы обработки ошибок раскрывают пользователю трассировку стека или другую обширную информацию об ошибках.
• Для более новых систем «Запрещать безопасность» не настраивает новейшие функции безопасности.
• сервер приложений、Платформа приложения (Struts、Spring、ASP.NET)、файл библиотеки、База данных и т. д. не настраиваются Безопасностью.
• Сервер не отправил заголовок «Безопасность» или сервер не был настроен для «Безопасности».
• Ваше приложение устарело и уязвимо (см.: Использование компонентов с известными уязвимостями).

в целом,Стратегия защиты следующая:

• Повторяемый процесс усиления защиты, который можно быстро и легко развернуть в другой изолированной среде. Среды разработки, контроля качества и производственная среда должны быть настроены одинаково.,И используйте разные пароли в каждой среде. Этот процесс должен быть автоматизирован,Минимизировать затраты на установку новой среды безопасности.
• Создайте минимальную платформу, не включающую ненужных функций, компонентов, документации и примеров. Удалите неподходящие функции и фреймворки.
• Проверьте и исправьте элементы конфигурации безопасности, чтобы адаптировать их к последним инструкциям, обновлениям и исправлениям безопасности.,и как часть процесса управления обновлениями,(Видеть:Используйте компоненты с известными уязвимости.). При проверке особое внимание следует уделить разрешениям на облачное хранилище.
• Сегментированная архитектура приложений, обеспечивающая эффективное разделение и отказоустойчивость между компонентами и пользователями, включая сегментированную контейнеризацию и облачные группы.
• Отправьте клиенту команду «Безопасность», например: заголовок «Безопасность».
• Автоматизированный процесс правильной настройки и настройки системы безопасности во всех средах.

Межсайтовый скриптинг (XSS)

Ошибки XSS возникают, когда приложение содержит новые веб-страницы, содержащие ненадежные данные, которые не были должным образом проверены или экранированы, или когда существующая веб-страница обновляется с использованием API-интерфейсов браузера, которые могут создавать HTML или JavaScript. XSS позволяет злоумышленникам выполнять сценарии в браузере жертвы и перехватывать пользовательские сеансы, портить веб-сайт или перенаправлять пользователей на вредоносные сайты.

Типичные XSS-атаки могут привести к краже сеансов, учетных записей, обходу MFA, замене DIV, атакам на браузеры пользователей (например, загрузка вредоносных программ, кейлоггинг) и другим атакам на стороне пользователя. Существует три типа XSS, которые обычно нацелены на браузер пользователя:

• Отраженный XSS:приложениеилиAPВключает непроверенный и неэкранированный пользовательский ввод.,какHTMLчасть вывода。一个成功的攻击Может让攻击ВОЗ在受害ВОЗбраузервыполнять произвольныйHTMLиJavaScript。 Как правило, пользователю необходимо взаимодействовать с какой-либо вредоносной ссылкой на страницу, контролируемую злоумышленником, например, веб-сайтом с вредоносным эксплойтом, рекламой или аналогичным контентом.
• Сохраненный XSS:ваше приложениеили ВОЗAPIНесанкционированный пользовательский ввод сохраняется,И оно будет отображаться на страницах других пользователей и администраторов позже. Сохраненный XSS обычно считается высоким или главным риском.
• XSS на основе DOM:会动态的将攻击ВОЗ可控的内容加入页面的JavaScriptрамка、одностраничная программаилиAPIЭтот тип уязвимости существует。В идеале,Вам следует избегать отправки данных, контролируемых злоумышленником, в API JavaScript, которые не предназначены для использования.

Обычно стратегия защиты заключается в следующем. Для предотвращения XSS необходимо отличать ненадежные данные от динамического содержимого браузера.

• Используйте платформу, предназначенную для автоматического написания кода для решения проблем XSS, например Ruby 3.0 или ReactJS.
• Чтобы избежать отраженных или сохраненных уязвимостей XSS, все ненадежные данные HTTP-запроса должны быть правильно экранированы в соответствии с контекстом вывода HTML (включая: тело, атрибуты, JavaScript, CSS или URL-адрес).
• Чтобы избежать атак DOM XSS при изменении документов браузера на стороне клиента, лучше всего реализовать контекстно-зависимое кодирование данных. Если этой ситуации нельзя избежать, аналогичные методы контекстно-зависимого экранирования можно применить к API браузера.
• Использование стратегии контента (CSP) — это стратегия глубокоэшелонированной защиты от XSS. Если не существует других уязвимостей, которые могли бы разместить вредоносный код через локальные файлы (например: переопределения обхода пути и уязвимые библиотеки, позволяющие передачу по сети).,тогда стратегия эффективна.

Небезопасная десериализация

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

Десериализация вредоносных или подделанных объектов, предоставленных злоумышленником, сделает приложения и API уязвимыми. Это может привести к двум основным типам атак:

• Если в приложении есть класс, который может изменить свое поведение во время или после десериализации, злоумышленник может изменить логику приложения или осуществить атаки с удаленным выполнением кода. Мы называем это атакой на объекты и структуры данных.
• Типичные атаки с подделкой данных, такие как атаки, связанные с контролем доступа, при которых используются существующие структуры данных, но изменяется содержимое.

В приложении сериализация может использоваться для:

• Удаленная и межпроцессная связь (RPC/IPC)
• Протоколы проводной связи, веб-сервисы, брокеры сообщений
• Кэширование/постоянство
• База данных, кэш-сервер, файловая система
• Файлы cookie HTTP, параметры HTML-форм, токены аутентификации API

Безопасные архитектурные шаблоны заключаются в том, чтобы не принимать сериализованные объекты из ненадежных источников или использовать сериализованные носители, которые допускают только примитивные типы данных. Если это невозможно, рассмотрите возможность использования следующих методов:

• Выполняйте проверки целостности, такие как цифровые подписи любых сериализованных объектов, чтобы предотвратить создание вредоносных объектов или подделку данных.
• Строгие ограничения типов применяются до создания объектов, поскольку обычно ожидается, что код будет представлять собой определяемый набор классов. Способы обхода этой технологии уже проверены, поэтому полагаться исключительно на нее нецелесообразно.
• Если возможно, запускайте десериализованный код в изолированной среде с низким уровнем привилегий.
• Запишите исключения десериализации и информацию об ошибках, например: входящий тип не соответствует ожидаемому типу или исключения, вызванные обработкой десериализации.
• Ограничьте или отслеживайте входящие и исходящие десериализованные сетевые подключения из контейнера или сервера.
• Отслеживайте десериализацию и предупреждайте пользователя, когда он продолжает десериализацию.

Используйте компоненты с известными уязвимостями.

Компоненты (такие как библиотеки, платформы и другие программные модули) имеют те же разрешения, что и приложения. Если компонент приложения содержит известную уязвимость и используется злоумышленником,Может привести к серьезной потере данных и захвату сервера. в то же время,Используйте компоненты с известными Приложения и API-интерфейсы уязвимостей. могут поставить под угрозу защиту приложений, сделать возможными различные атаки и иметь серьезные последствия.

Приложение уязвимо для этого типа атаки, если выполняется одно из следующих условий:

• Неизвестна информация о версии всех используемых компонентов (включая сервер и клиент). Сюда входят компоненты, используемые напрямую, или компоненты, от которых они зависят.
• Если программное обеспечение уязвимо, больше не поддерживается или устарело. Сюда входят: ОС, веб-сервер, сервер приложений, система управления базами данных (СУБД), приложения, API и все компоненты, среды выполнения и библиотеки.
• Время от времени выполняйте сканирование уязвимостей и подписывайтесь на объявления о безопасности используемых вами компонентов.
• Если это не основано на риске и своевременно ремонтирует или обновляет базовую платформу, фреймворк и зависимые библиотеки. Вполне вероятно, что ежемесячные или ежеквартальные обновления выполняются на основе контроля изменений, в результате чего организация подвергается воздействию уязвимостей, которые были исправлены, но не исправлены за это время.
• Если инженеры-программисты не проводят тестирование совместимости новых, обновленных или исправленных компонентов.
• Если вы не настроили компонент.

Должен быть разработан процесс управления исправлениями:

• Удалите неиспользуемые зависимости, ненужные функции, компоненты, файлы и документацию.
• Используйте такие инструменты, как версии, DependencyCheck, retire.js и т. д., для непрерывной записи клиентов и сервисов. информация о версии сервера и зависимых от него библиотек. Постоянно контролировать выпуск использованных компонентов, таких как CVE и NVD. информация об уязвимости。Подпишитесь об использовании компонентов Безопасность Письма с предупреждениями об уязвимостях。
• Приобретайте компоненты только по официальным каналам и используйте механизмы подписи, чтобы снизить риск подделки компонентов и злонамеренных уязвимостей.
• Мониторинг библиотек и компонентов, которые больше не поддерживаются и не исправляются автором. Если вы не можете это исправить,Рассмотрите возможность развертывания виртуальных исправлений для мониторинга и обнаружения защиты. Каждая организация должна иметь план,Мониторинг всего жизненного цикла программного обеспечения, Обзор, Обновление и изменение конфигурации.

Неадекватное ведение журнала и мониторинг.

Неадекватное ведение журнала и мониторинг.,и отсутствие и неэффективная интеграция реагирования на инциденты,Позволяет злоумышленникам продолжать атаковать системы, сохранять постоянство и переходить на большее количество систем.,А также подделка, извлечение и уничтожение данных. Большинство исследований дефектов показывают,Дефект обнаруживался более 200 дней.,и обычно тестируются внешними сторонами тестирования,Вместо мониторинга проверок посредством внутренних процессов

Следующие условия могут привести к неадекватному ведению журнала, обнаружению, мониторингу и реагированию:

• События аудита, такие как входы в систему, неудачные входы в систему и транзакции с высокой стоимостью, не регистрируются.
• События сигналов тревоги и ошибок не генерируют или генерируют недостаточную и неясную информацию журнала.
• Информация журналов прикладных систем и API не используется для отслеживания подозрительных действий.
• Информация журнала хранится только локально.
• Неспособность определить разумные пороговые значения сигналов тревоги и разработать процедуры обработки ответов.
• Тестирование на проникновение и использование инструментов DAST (таких как: OWASP ZAP) сканирование не вызвало тревогу.
• Приложения не могут обнаруживать, обрабатывать и предупреждать об атаках в режиме реального времени или почти в реальном времени.

Обычные стратегии защиты следующие:

• Убедитесь, что все входы в систему, сбои управления доступом и сбои проверки ввода могут быть записаны в журналах, сохраните достаточно информации о пользовательском контексте для выявления подозрительных или вредоносных учетных записей и зарезервируйте достаточно времени для последующей экспертизы.
• Убедитесь, что журналы создаются в форме, которую может использовать решение для централизованного управления журналами.
• Убедитесь, что транзакции с высокой стоимостью содержат информацию аудита, контролируемую целостностью, чтобы предотвратить подделку или удаление. Например, информация аудита хранится в таблице базы данных, которая может только добавлять записи.
• Создайте эффективный механизм мониторинга и оповещения, чтобы подозрительные действия можно было обнаружить и отреагировать на них в течение приемлемого времени.
• Создайте или примите механизм реагирования на чрезвычайные ситуации и план восстановления, например NIST800-61rev2 или более позднюю версию.

В настоящее время существуют коммерческие платформы защиты приложений и приложения с открытым исходным кодом (например, OWASPAppSensor), межсетевые экраны веб-приложений (например, Modsecurity) и программное обеспечение для корреляции журналов с настраиваемыми информационными панелями и функциями оповещения.

Некоторые изображения в этой статье взяты из учебного курса для сертифицированных инженеров службы безопасности Sangfor. Они предназначены для удобства личного изучения и использования и не предназначены для коммерческого использования! ! ! ! Текстовый контент набран лично мной, а не перенесен напрямую! Если есть какие-либо нарушения, пожалуйста, свяжитесь с нами, чтобы удалить их! ! !

Информация, представленная в этом документе, предназначена только дляОбразовательные цели и тестирование на проникновение с явным разрешением。Любое несанкционированное использование технической информации, содержащейся в этом документе, строго запрещено.,И может нарушать «Сетевой закон Китайской Народной Республики» и связанные с ним законы и правила. Пользователи должны использовать полученные знания законным и соответствующим требованиям образом.,Он не может использоваться для незаконного вторжения, разрушения информационных систем и других злонамеренных действий. Мы настоятельно рекомендуем всем читателям соблюдать местные законы и этические правила.,Исследуйте информационные технологии в пределах правовых границ.

Я участвую в 21-дневном конкурсе Tencent по созданию технологий 2024 года: специальный сезон обзоров в середине года, накопление технологий в середине года, сохраните свой флаг, приходите и разделите со мной главный приз!