Актуальна ли проблема инъекций в JavaScript?

В былые времена, когда веб разработка строилась на том, что серверные приложения направляли запросы в реляционные базы данных и выдавали на выходе HTML, часто встречался такой код:

// ВНИМАНИЕ: Плохой пример!
function popup(msg: string): string {
    return "<p class=\"popup\">" + msg + "</p>";
}

или такой:

// ВНИМАНИЕ: Плохой пример!
function getName(login: string): string {
    return "SELECT name FROM users WHERE login = \"" + login + "\"";
}

С тех пор мы научились использовать более безопасные подходы.

Широкое применение получили такие инструменты, как шаблонизаторы и привязка параметров. Сегодня редко можно встретить опасную конкатенацию строк.

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



Чтобы понять почему, разобьем один из неудачных примеров на более простые фрагменты. Вот так:

function f(userInput: A): A {
    const firstCommand: A = ...;
    const secondCommand: A = ...;
    return firstCommand.concat(userInput.concat(secondCommand));
}

Очевидно, что первопричина атак путем внедрения кода связана с тем, что для компьютера нет разницы между командой и вводом информации пользователем! Поэтому злоумышленник может ввести данные, которые в дальнейшем будут обрабатываться как код.

Естественно, как я уже говорил, существуют хорошо известные средства защиты от таких атак. Вместо вот этого:

"SELECT name FROM users WHERE login = \"" + login + "\""

лучше написать что-нибудь такое:

query("SELECT name FROM users WHERE login = :login", {login})

Таким образом команда SELECT name FROM users WHERE login =:login отчетливо отделяется от данных {login}. В то же время внутренние механизмы гарантируют, что данные будут подготовлены для использования в запросе SQL. Экранировать кавычки и внедрить вредоносный код не получится.

Однако разработка веб-приложений стремительно развивается. Все чаще встречается не только такое:

{
  paramA: "the value of the A parameter",
  paramB: "the value of the A parameter",
}

но и такое:

{
  paramA: "the value of the A parameter",
  paramB: {$in: [
    "the value of the B parameter",
    "the value of the C parameter",
  ]},
}

Существенным отличием между двумя вариантами является то, что значение параметра представляет собой объект, включающий в себя команду!

Допустим значения читаются из userInput:

{
  paramA: userInput.paramA,
  paramB: {$in: [
    userInput.paramB[0],
    userInput.paramB[1],
  ]},
}

Беспокоиться о том, что пользователь предоставит вредоносную строку, не надо. Все будет обработано безопасным образом.

Проблема в том, что значениями параметра могут быть не только простые значения наподобие the value of the A parameter, но и команды, например {$in: ["B", "C"]}. Пользователь может разными способами направить запрос, после дешифровки которого получается объект (форма, JSON или XML), и поэтому код может подвергаться атакам путем инъекций.

Допустим userInput.paramA равно {$empty: false}. Тогда запрос выглядит следующим образом:

{
  paramA: {$empty: false},
  paramB: {$in: [
    userInput.paramB[0],
    userInput.paramB[1],
  ]},
}

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

Чтобы избежать эту проблему, нужно всегда писать команды так, чтобы их нельзя было получить от пользователя. Это можно реализовать в том числе с помощью подхода, применяемого в React и Snabbdom-Signature (это небольшая библиотека для защиты от инъекций в виртуальный DOM), а именно отмечать каждый объект команды Symbol, чтобы его нельзя было отправить по сети.

Признаюсь, и сам не раз думал, что раз нет базы данных SQL или если я использую виртуальный DOM, атаки путем внедрения кода мне не угрожают. Как же я ошибался!

LOOKING.HOUSE — на проекте собрано более 150 точек looking glass в 40 странах. Можно быстро выполнить команды host, ping, traceroute и mtr.