В этом выпуске шпаргалки мы сосредоточимся на десяти лучших практиках безопасности Java как для сопровождающих с открытым исходным кодом, так и для разработчиков. Хотя большинство разработчиков понимают, что безопасное кодирование важно, безопасность – это не первое, о чем думают разработчики. Используя OWASP Top 10 уязвимостей в качестве начальной отправной точки, я создал этот топ-10. Для этой шпаргалки я сотрудничал с Джимом Манико, чемпионом Java и основателем Manicode Security.
Итак, без дальнейших объяснений я с гордостью представляю 10 Java security лучшие практики
1. Используйте параметризацию запроса, чтобы предотвратить внедрение
В версии OWASP Top 10 уязвимостей 2017 года инъекция появилась в верхней части списка как уязвимость номер один в этом году. При рассмотрении типичной SQL-инъекции в Java параметры последующего запроса наивно объединяются со статической частью запроса. Ниже приведено небезопасное выполнение SQL в Java, которое может быть использовано злоумышленником для получения большего количества информации, чем предполагалось в противном случае.
public void selectExample(String parameter) throws SQLException {
Connection connection = DriverManager.getConnection(DB_URL, USER, PASS);
String query = "SELECT * FROM USERS WHERE lastname = " + parameter;
Statement statement = connection.createStatement();
ResultSet result = statement.executeQuery(query);
printResult(result);
}
Если параметр в этом примере имеет значение " ИЛИ , то результат содержит каждый отдельный элемент в таблице. Это может быть еще более проблематично, если база данных поддерживает несколько запросов, а параметр будет "; UPDATE USERS SET .
Чтобы предотвратить это в Java, мы должны параметризовать запросы с помощью подготовленного оператора. Это должен быть единственный способ создания запросов к базе данных. Определяя полный код SQL и передавая параметры в запрос позже, код становится более понятным. Самое главное, что благодаря различению кода SQL и данных параметров запрос не может быть захвачен вредоносным вводом.
public void prepStatmentExample(String parameter) throws SQLException {
Connection connection = DriverManager.getConnection(DB_URL, USER, PASS);
String query = "SELECT * FROM USERS WHERE lastname = ?";
PreparedStatement statement = connection.prepareStatement(query);
statement.setString(1, parameter);
System.out.println(statement);
ResultSet result = statement.executeQuery();
printResult(result);
}
В приведенном выше примере входные данные привязываются к типу String и, следовательно, являются частью кода запроса. Этот метод предотвращает вмешательство ввода параметров в код SQL.
2. Используйте OpenID для подключения с помощью 2FA
Управление идентификацией и контроль доступа затруднены, и нарушение аутентификации часто является причиной утечки данных. Фактически, это № 2 в списке 10 лучших уязвимостей OWASP. Есть много вещей, которые вы должны учитывать при самостоятельном создании аутентификации: безопасное хранение паролей, надежное шифрование, извлечение учетных данных и т.д. Во многих случаях гораздо проще и безопаснее использовать такие интересные решения, как OpenID Connect. OpenID Connect (OIDC) позволяет проверять подлинность пользователей на веб-сайтах и в приложениях. Это избавляет от необходимости владеть файлами паролей и управлять ими. OpenID Connect – это расширение OAuth 2.0, которое предоставляет информацию о пользователе. Он добавляет идентификационный токен в дополнение к токену доступа, а также /userinfo конечная точка, где вы получаете дополнительную информацию. Он также добавляет функцию обнаружения конечной точки и динамическую регистрацию клиента.
Настройка OpenID Connect с такими библиотеками, как Spring Security, является простой и распространенной задачей. Убедитесь, что ваше приложение применяет 2FA (двухфакторную аутентификацию) или MFA (многофакторную аутентификацию), чтобы добавить дополнительный уровень безопасности в вашу систему.
Добавляя зависимости oauth2-client и Spring security в свое приложение Spring Boot, вы используете сторонние клиенты, такие как Google, Github и Okta, для обработки OIDC. После создания вашего приложения вам просто нужно подключить его к определенному клиенту по вашему выбору, указав его в конфигурации вашего приложения; это может быть ваш идентификатор клиента GitHub или Okta и секрет клиента, как показано ниже.
После создания вашего приложения вам просто нужно подключить его к определенному клиенту по вашему выбору, указав его в конфигурации вашего приложения; это может быть ваш идентификатор клиента GitHub или Okta и секрет клиента, как показано ниже.
org.springframework.boot spring-boot-starter-oauth2-client org.springframework.boot spring-boot-starter-security
После создания вашего приложения вам просто нужно подключить его к определенному клиенту по вашему выбору, указав его в конфигурации вашего приложения; это может быть ваш идентификатор клиента GitHub или Okta и секрет клиента, как показано ниже.
spring:
security:
oauth2:
client:
registration:
github:
client-id: 796b0e5403be4729ca01
client-secret: f379318daa27502254a05e054361074180b840a9
okta:
client-id: 0oa1a4wascEpYu6yk358
client-secret: hqxj7a9lVe_TudbS2boBW7AWwxTlZiHNrJxdc_Sk
client-name: Okta
provider:
okta:
issuer-uri: https://dev-844689.okta.com/oauth2/default
3. Проверьте свои зависимости на наличие известных уязвимостей
Есть большая вероятность, что вы не знаете, сколько прямых зависимостей использует ваше приложение. Также весьма вероятно, что вы также не знаете, сколько транзитивных зависимостей использует ваше приложение. Это часто бывает правдой, несмотря на то, что зависимости составляют большую часть вашего общего приложения. Злоумышленники все больше и больше нацеливаются на зависимости с открытым исходным кодом, поскольку их повторное использование обеспечивает злоумышленнику множество жертв. Важно убедиться, что во всем дереве зависимостей вашего приложения нет известных уязвимостей.
Snyk проверяет артефакты сборки вашего приложения, отмечая те зависимости, которые имеют известные уязвимости. Он предоставляет вам список уязвимостей, существующих в пакетах, которые вы используете в своем приложении в качестве панели мониторинга.
Кроме того, он предлагает обновить версии или предоставить исправления для устранения ваших проблем с безопасностью с помощью запроса на извлечение из вашего хранилища исходного кода. Snyk также защищает вашу среду, гарантируя, что любые будущие запросы на извлечение, создаваемые в вашем репозитории, автоматически проверяются (с помощью webhooks), чтобы убедиться, что они не вводят новые известные уязвимости.
Snyk доступен как через веб-интерфейс, так и через КЛИП, поэтому вы интегрируете его со своей средой CI и настраиваете так, чтобы он нарушал вашу сборку при наличии уязвимостей с серьезностью, превышающей установленный вами порог.
Используйте Snyk бесплатно для проектов с открытым исходным кодом или для частных проектов с ограниченным количеством ежемесячных тестов.
4. Обращайтесь с конфиденциальными данными осторожно
Раскрытие конфиденциальных данных, таких как личные данные или номера кредитных карт вашего клиента, может быть вредным. Но даже более тонкий случай, чем этот, может быть столь же вредным. Например, раскрытие уникальных идентификаторов в вашей системе вредно, если этот идентификатор может быть использован в другом вызове для получения дополнительных данных.
Прежде всего, вам нужно внимательно присмотреться к дизайну вашего приложения и определить, действительно ли вам нужны данные. Кроме того, убедитесь, что вы не раскрываете конфиденциальные данные, возможно, с помощью ведения журнала, автозаполнения, передачи данных и т.д.
Простой способ предотвратить попадание конфиденциальных данных в ваши журналы – это очистить методы toString() объектов вашего домена. Таким образом, вы не сможете случайно напечатать конфиденциальные поля. Если вы используете project Lombok для создания вашего метода toString() , попробуйте использовать @toString. Исключить , чтобы поле не было частью toString() вывод.
Кроме того, будьте очень осторожны с предоставлением данных внешнему миру. Например: если у нас есть конечная точка в системе, которая показывает все имена пользователей, нет необходимости показывать внутренний уникальный идентификатор. Этот уникальный идентификатор может быть использован для передачи другой, более конфиденциальной информации пользователю с помощью других конечных точек. Если вы используете Jackson для сериализации и десериализации POJOs в JSON, попробуйте использовать @JsonIgnore и @JsonIgnoreProperties для предотвращения сериализации или десериализации этих свойств.
Если вам нужно отправить конфиденциальные данные в другие службы, зашифруйте их должным образом и убедитесь, что ваше соединение защищено, например, с помощью HTTPS.
5. Очистите все входные данные
Межсайтовый скриптинг (XSS) – хорошо известная проблема, которая в основном используется в приложениях JavaScript. Однако Java не застрахована от этого. XSS – это не что иное, как внедрение кода JavaScript, который выполняется удаленно. Правило № 0 для предотвращения XSS, согласно OWASP, гласит: “Никогда не вставляйте ненадежные данные, кроме как в разрешенных местах”. Основным решением для этого является максимально возможное предотвращение ненадежных данных и очистка всего остального перед использованием данных. Хорошей отправной точкой является библиотека кодирования Java OWASP, которая предоставляет вам множество кодеров.
org.owasp.encoder encoder 1.2.2
String untrusted = ""; System.out.println(Encode.forHtml(untrusted)); // output:
Очистка пользовательского текстового ввода является очевидной задачей. Но как насчет данных, которые вы извлекаете из базы данных, даже если это ваша собственная база данных? Что делать, если ваша база данных была взломана и кто-то поместил какой-то вредоносный текст в поле базы данных или документ?
Кроме того, следите за входящими файлами. Уязвимость Zip-slip во многих библиотеках существует из-за того, что путь к архивированным файлам не был очищен. Zip-файлы, содержащие файлы с путями ../../../..//foo.xy может быть извлечен и потенциально переопределять произвольные файлы. Хотя это не атака XSS, это хороший пример того, почему вы должны очищать все входные данные. Каждый ввод потенциально вредоносен и должен быть соответствующим образом очищен.
Это только первые 5 из моих топ-10 . Хотите узнать больше о следующих 5? Подробнее…
Оригинал: “https://dev.to/brianverm/10-java-security-best-practices-be8”