Contents
Понимание уязвимостей внедрения
Уязвимости для внедрения существуют, когда информация, предоставленная пользователями приложения, не проверяется или не очищается должным образом перед ее использованием.. В случае межсайтового скриптинга это будет означать, что поле позволяет вводить JavaScript, который затем повторно отображается клиенту. Для внедрения SQL это означает, что поле, которое записывается в базу данных, не проверяется должным образом, и функция очистки SQL не запускается для данных перед их отправкой в базу данных как часть команды для выполнения. Последняя уязвимость, которую они перечисляют, — «Внешний контроль имени файла или пути». Это означает, что поле позволяет пользователю вставить имя файла или путь, который используется для записи или чтения из базовой операционной системы на сервере. В каждом случае у нас отсутствует проверка данных. Итак, для нашего рабочего определения давайте возьмем это:
Уязвимости, связанные с инъекциями, — это отсутствие проверки и дезинфекции пользовательского ввода, что позволяет пользователю получить доступ к большему количеству данных, чем ему следует.
Выявление отсутствующих валидаций и исправлений в Code Review
Отсутствующие проверки и дезинфекция входных данных нелегко обнаружить с помощью автоматизированного тестирования, и они не всегда обнаруживаются с помощью тестирования приложений перед развертыванием. Большинство тестировщиков недостаточно обучены векторам атак, чтобы найти эти проблемы, и многие из них скрыты в API или могут быть скрыты проверкой данных на стороне клиента. Однако, как только вы знаете, что искать, эти уязвимости исчезают с экрана в обзоре кода.
Обнаружение уязвимостей JavaScript-инъекций
Уязвимости внедрения JavaScript, соответствующего компонента межсайтового скриптинга, чаще всего возникают, когда текстовое поле ввода записывается в базу данных, а затем отображается позже без какой-либо очистки отображаемой информации. Итак, какая санитарная обработка нам нужна здесь? В первую очередь нам нужно преобразовать определенные специальные символы в их сущность-кодировку перед отображением.
Итак, если кто-то вводит это в текстовое поле:
Когда мы записываем его обратно на страницу, мы хотим превратить его в это:
Символы «больше» и «меньше» были преобразованы в эквиваленты HTML-сущностей, поэтому это не будет интерпретироваться как HTML, а включенная функция JavaScript не будет выполняться.
Разные языки имеют разные методы экранирования HTML. Чтение этих методов поможет вам подготовиться. Я знаю, что в Ruby нужно искать следующие контрольные признаки:
- Использование
.html_safeфункции в представлениях Rails. - Не использовать
CGI::escapeHTMLконтексты вне поля зрения с автоматическим экранированием. - Использование необработанной уценки, скомпилированной без защиты от внедрения тегов JavaScript.
В зависимости от языка вы обнаружите множество различных контрольных признаков уязвимостей внедрения JavaScript, которые могут привести к межсайтовому скриптингу. Познакомьтесь с системой экранирования HTML на языке, который вы используете изо дня в день, и вы найдете свой собственный список для поиска .
Отлов уязвимостей SQL-инъекций
Уязвимости SQL-инъекций возникают, когда строки от клиента вставляются непосредственно в оператор SQL без предварительной очистки. Наиболее распространенным способом, которым это происходит, является интерполяция строк.
В Ruby, например, следующий код небезопасен:
Это связано с тем, что параметр ID может быть заменен любой строкой, которую пожелает пользователь, и он будет вставлен непосредственно в оператор SQL без какого-либо экранирования. Безопасная версия будет использовать ORM для выполнения того же запроса:
Правильное использование ORM, как правило, устраняет любой риск SQL-инъекций, хотя правильный подход отличается от ORM к ORM. В ActiveRecord есть методы, принимающие дополнительные аргументы, которые позволяют безопасно вставлять информацию в строки SQL.
Например:
Синтаксис вопросительного знака указывает ORM, куда вставить экранированную версию второго параметра. Большинство других ORM будут обеспечивать аналогичную функциональность, но рекомендуется понимать, насколько санитизация выполняется на уровне ORM, а также ограничения ORM при обработке санитизации.
Самый большой красный флажок, на который следует обращать внимание при проверке кода, — это интерполяция строк, используемая в SQL-запросах . Это вообще небезопасно.
Перехват внешнего управления путями к файлам
Внешний контроль над путями к файлам возникает, когда пользователям разрешено загружать файл или инициализировать ресурс на стороне сервера, например базу данных SQLite. Это также может произойти при чтении, если система не настроена должным образом для чтения только из определенных мест.
Опасность разрешения пользователю управлять путем заключается в том, что он может попытаться записать файлы в опасные места или получить доступ к содержимому исходного кода или другим файлам, содержащим привилегированную информацию.
Чтобы выявить проблему безопасности такого типа, программист или рецензент должен знать о случаях, когда путь к файлу может быть вставлен в параметр — это может быть что-то простое, например, путь загрузки файла или команда чтения файла, или что-то более неожиданное, например, строка подключения к базе данных.
Я ищу случаи, когда эта информация передается как полный путь, а не как вложенный путь к содержащей папку, или более безопасный путь сохранения по предполагаемому пути в базу данных, но запись файла в случайное место на диске для избежать возможных проблем с безопасностью .
Вывод
Уязвимости для инъекций возникают из-за небезопасной обработки пользовательских данных. Их относительно просто исправить, как только будут поняты основные проблемы, которые их вызывают, и их часто находят опытные рецензенты, которые знают, что искать. Распространенность инъекционных уязвимостей сегодня является одним из лучших аргументов в пользу продолжения проверки кода во многих организациях — этот тип уязвимости чаще всего выявляется в ходе проверки кода, нарушающего правила, человеком.
Статья является переводом hackerone.com
