Лучший способ защитить себя от внедрения sql в nodejs

Question

Вот настройка.

Я отправляю POST с помощью ajax, где я отправляю параметры для процедур на сервер nodejs. В данном конкретном случае - имя пользователя и код.

Этот POST вызывает request.get веб-службе, которая выполняет процедуру, которая использует эти два параметра.

Например

app.post('url/:username/:code', function(req,res,next){ 

var procedure = 'EXECUTE procedureName'+req.params.code; 

    request.get('myWslink/myService.asmx/service? 
    callback=&userName='+req.params.username+'&procedureName='+procedure, function(){}); 
}); 

Передний конечный пользователь не может видеть мое WebService URL, мой request.GET URL или мое имя процедуры, но он все еще может видеть параметры отправки (имя пользователя, код) и он может измените эти параметры, чтобы он мог выполнить процедуру, которую он не должен выполнять.

Он также может вызвать POST-запрос кучей раз и заполнить базу данных кучей хлама, если это процедура вставки.

Что было бы лучшим способом защитить себя от этих подвигов?

Answer 1

Несколько предложений здесь:

Не делать мета-программирования до такой степени. Сделайте отдельные маршруты в своем приложении для каждой процедуры, а затем введите эти «коды» самостоятельно. Это позволит вам выполнять такие действия, как проверка входных данных пользователей, чтобы убедиться, что они не передаются в мусорные данные, а также конкретные маршруты ограничения скорости, чтобы гарантировать, что БД не заполнено мусором.

Вы также можете создать белый список допустимых «кодов» и убедиться, что whitelist.instanceOf(procedure) != -1, но это не позволит вам выполнять валидацию ввода для каждого маршрута.

Даже если вы вручную включили процедуру, все еще есть проблема. В вашем существующем коде вызов внешней службы помещает параметр 'req.params.username' перед процедуройName. Для большинства инфраструктур синтаксического анализа HTTP сначала используются параметры. Одной из первых атак, которые я попробовал бы после просмотра этого кода, было бы ввести '&procedureName=something_i_shouldnt_be_able_to_call' в мое имя пользователя. Это приведет к тому, что атрибут procedureName, который вы включаете, должен быть проигнорирован, в то время как тот, который я представил, будет использоваться вместо этого. Вы можете предотвратить это, либо поместив параметры, основанные на пользовательском входе, и кодировку URI, введенную пользователем до интерполяции строк, либо включив в себя ваш запрос в виде объекта с именем «qs» passed into the options argument to request.

Независимо от того, создает ли это SQL уязвимость внедрения полностью зависит от того, как веб-служба анализирует аргументы и выполняет эту процедуру. Оптимальным случаем было бы то, что URI службы декодирует каждый параметр и затем передает их в качестве аргументов либо PDO, либо подготовленного оператора. Я предполагаю, что он использует PDO, учитывая то, как он называется.

Так что, в конечном итоге, я хотел бы предложить здесь URI кодировать каждый из ваших параметров, введенных пользователем, и использовать объект qs, переданный в параметры запроса, как указано выше, а не просто интерполировать строки.После того, как вы это сделали, вы можете предпринять все или все из этих шагов, чтобы помочь подтвердить:

1. Попытаться сделать так, как вводить одинарные кавычки в свой пользовательский ввод вручную.
2. Запустите инструмент, подобный sqlmap, на этом конкретном маршруте, чтобы протестировать SQL-инъекцию. Это даст вам достаточно надежное тестирование, не требуя глубоких знаний о методах SQL-инъекций.
3. Запланируйте оценку безопасности приложения с опытным специалистом по безопасности node.js. (Я доступен на liftsecurity.io)

Повторюсь - Не доверяйте пользователям, чтобы дать вам код процедуры - сделать раздельные маршруты и вставить, что данные сами, URI закодировать весь пользовательский ввод перед дальнейшей обработкой, и использовать объекты запроса, например: {qs:{name:value}} вместо интерполяции строк.

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

Надеюсь, это поможет!

Answer 2

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