Блог

В моем проекте проблема с внедрением ресурсов возникает при создании нового URL (ресурса) (для статического сканирования). как это исправить?

 String username = "james";
String resource = "https://someWebsite.com/api" username;
URL url = new URL(resource); //here it is giving resource injection issue in fortify scan
System.setProperty("https.proxySet", "true");
System.setProperty("https.proxyHost", "11.09.11.111");
System.setProperty("https.proxyPort", "90");        
HttpsURLConnection conn = (HttpsURLConnection) url.openConnection();
  

Сразу же я вижу эту строку:

String resource = "https://someWebsite.com/api" username;

Я знаю, что у нас проблемы.

Почему? Я предложил вам комментарий, потому что вам нужно спросить себя: «Что я здесь делаю?»

Ваша первоначальная реакция, вероятно, будет: «Я объединяю имя пользователя со строкой URI. Это веб-сервис на основе REST, так в чем же дело? «

Это помечается, потому что вы не выполнили — в порядке важности:

1. Экранирование вывода по параметру, управляемому пользователем
2. Введите кодировку для параметра, управляемого пользователем.

Что здесь сделал avgvstvs? Почему он говорит о выводе, когда это явно ввод?

Как программист, на вас лежит ответственность, о которой вас никогда не учили в школе. При работе над приложением вы должны понимать поток данных ваших переменных, которые вы используете. Вам необходимо разделить все входные данные на 2 категории:

1. Материал, который МЫ (сервер) контролируем
2. Материал, которым управляет пользователь (враг)

Вам нужно подумать о пользователях, чьи намерения использовать вашу систему являются злыми; это не для того, чтобы заставить вас думать, что все пользователи являются врагами — хотя некоторые ветераны могут с этим поспорить — но когда вы пишете безопасный код, вам нужно думать о том, как злоумышленник будет злоупотреблять вашим кодом.

Как только вы поймете этот внешний контекст, это должно начать выглядеть для вас более понятным.

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

Прежде чем использовать какое-либо значение, оно должно быть проверено. Как написано в настоящее время, я могу выдавать себя за любого пользователя, зарегистрированного с этим URL API. Здесь имеет смысл несколько проверок ввода:

1. Аутентифицирован ли пользователь, о котором идет речь?
2. Действительно ли рассматриваемый пользователь существует в системе?
3. Авторизован ли пользователь для использования ресурсов, указанных в этом URI?
4. У пользователя есть действительный сеанс?
5. Какая байтовая кодировка используется моей платформой программирования и соответствует ли ей ввод?
6. Защищаем ли мы от пользователя, пытающегося использовать множественные или смешанные кодировки как на уровне байтов, так и на уровнях взаимодействия, которые мы потенциально будем использовать позже?

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

Зачем выводить кодировку / экранирование? Разве это не ввод?

Когда вы решите объединить имя пользователя с URI, а затем перейти к отправке запроса, спросите себя: «Что я на самом деле здесь делаю?»

Очевидно, что цель состоит в том, чтобы взять имя пользователя, объединить его со значением, которое будет использоваться …

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

7. Какому интерпретатору я передаю это значение после его проверки?

В этом случае вы передаете значение в контекст данных, который указывает, что оно будет использоваться в URI. Это означает, что данные должны быть правильно закодированы и экранированы для использования в URI, чтобы мы не вносили ошибок и, возможно, дополнительных уязвимостей в наш стек.

Для решения этой проблемы:

Ответьте на все 7 вопросов для переменной username, затем выберите подходящие методы, доступные вам из вашего стека приложений. Это правда, что вы отметили esapi, но esapi не может помочь вам со всеми 7 вопросами, только проверка ввода и кодировка вывода… которые, возможно, уже доступны для вас в рамках безопасности вашего приложения.