2017-01-02 1 views
0

Я пытаюсь разработать приложение и отсканировать свой код с помощью checkmarx и получить проблему под - LDAP-инъекцией в методе ниже.Проблема с вводом LDAP в checkmarx:

Update(request.getparameter("userID")) 

мы называем этот метод и используя request.getParameter(), чтобы получить соответствующее значение, checkmarx показывает вопрос на request.getParameter ("UserID"),

Issue описание " значение этого элемента затем проходит через код без надлежащей очистки или подтверждено, и в конечном счете, используется в запросе LDAP в методе»

так, следуя является одним из способов, я попытался

String userID = request.getparameter("userID"); 
if(userID == null && userID.isEmpty){ 
    throw new ServletException(); 
} 
else 
    Update(userID); 

с вышеуказанными изменениями также проблема не устранена.

Любая идея для решения этой проблемы?

+0

Я не знаю checkmarx, но я думаю, что этот вопрос является входным параметром, который не продезинфицировать.Теоретически это не обязательно с жестко закодированным литералом, но я не знаю, как с ним строгая checkmarx. –

ответ

1

Похоже, что Checkmarx указан правильно, если ваш код уязвим для LDAP Injection.

Что такое инъекция LDAP?

Неправильная Нейтрализация специальных элементы используются в LDAP-запросы («LDAP Injection»)

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

Цитата взята из CWE-90: Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')

Как уменьшить?

Защита от инъекций LDAP требует точного кодирования и конфигурации безопасного сервера. Передние приложения должны выполнять проверку ввода и ограничивать все потенциально вредоносные символы. Разработчики могут использовать регулярные выражения для проверки ненадежного ввода. Следующее регулярное выражение может ограничить объем потенциальных атак, позволяя только цифры и буквы:

/[^0-9a-z]/i 

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

Quote и пример, взятый из LDAP Injection Vulnerability | CWE-90 Weakness | Exploitation and Remediation

+0

Я использовал регулярные выражения, чтобы проверить идентификатор пользователя. но все же проблема возникла. – dinky

+0

@vanam Можете ли вы разместить здесь код, который вы использовали для проверки идентификатора пользователя? – yaloner

+0

Спасибо yaloner за ваш быстрый ответ. Вот код, который я попробовал, используя регулярное выражение. userID = request.getParameter ("userID"); if (userID == null && userID.isEmpty) { throw new ServletException(); } else { Строка USERID_PATTERN = "[a-zA-Z] {2} \\ d {3} [a-zA-Z | 0-9] {1}"; \t Шаблон userID_Pattern = Pattern.compile (USERID_PATTERN); \t Matcher matcher = userID_Pattern.matcher (userID); \t if (! Matcher.matches()) { \t \t \t throw new ServletException(); \t \t} \t еще \t \t \t \t Обновление (идентификатор пользователя); } – dinky

Смежные вопросы