Previniendo la inyección de SQL en Node.js

Solución:

los node-mysql la biblioteca realiza automáticamente el escape cuando se usa como ya lo está haciendo. Ver https://github.com/felixge/node-mysql#escaping-query-values

La biblioteca tiene una sección en el archivo Léame sobre cómo escapar. Es nativo de Javascript, por lo que no sugiero cambiar a node-mysql-native. La documentación establece estas pautas para escapar:

Editar: node-mysql-native es también una solución de Javascript puro.

• Los números quedan intactos
• Los booleanos se convierten en true / false instrumentos de cuerda
• Los objetos de fecha se convierten a YYYY-mm-dd HH:ii:ss instrumentos de cuerda
• Los búferes se convierten en cadenas hexadecimales, p. Ej. X'0fa5'
• Las cadenas se escapan de forma segura
• Las matrices se convierten en lista, p. Ej. ['a', 'b'] se convierte en 'a', 'b'
• Las matrices anidadas se convierten en listas agrupadas (para inserciones masivas), p. Ej. [['a', 'b'], ['c', 'd']] se convierte en ('a', 'b'), ('c', 'd')
• Los objetos se convierten en key = 'val' pares. Los objetos anidados se convierten en cadenas.
• undefined / null se convierten a NULL
• NaN / Infinity se dejan como están. MySQL no los admite, e intentar insertarlos como valores activará errores de MySQL hasta que implementen el soporte.

Esto le permite hacer cosas como estas:

var userId = 5;
var query = connection.query('SELECT * FROM users WHERE id = ?', [userId], function(err, results) {
  //query.sql returns SELECT * FROM users WHERE id = '5'
});

Tan bien como esto:

var post  = {id: 1, title: 'Hello MySQL'};
var query = connection.query('INSERT INTO posts SET ?', post, function(err, result) {
  //query.sql returns INSERT INTO posts SET `id` = 1, `title` = 'Hello MySQL'
});

Aparte de esas funciones, también puede utilizar las funciones de escape:

connection.escape(query);
mysql.escape(query);

Para escapar de los identificadores de consulta:

mysql.escapeId(identifier);

Y como respuesta a su comentario sobre declaraciones preparadas:

Desde una perspectiva de usabilidad, el módulo es excelente, pero aún no ha implementado algo parecido a las Declaraciones Preparadas de PHP.

Las declaraciones preparadas están en la lista de tareas pendientes para este conector, pero este módulo al menos le permite especificar formatos personalizados que pueden ser muy similares a las declaraciones preparadas. Aquí hay un ejemplo del archivo Léame:

connection.config.queryFormat = function (query, values) {
  if (!values) return query;
  return query.replace(/:(w+)/g, function (txt, key) {
    if (values.hasOwnProperty(key)) {
      return this.escape(values[key]);
    }
    return txt;
  }.bind(this));
};

Esto cambia el formato de consulta de la conexión para que pueda usar consultas como esta:

connection.query("UPDATE posts SET title = :title", { title: "Hello MySQL" });
//equivalent to
connection.query("UPDATE posts SET title = " + mysql.escape("Hello MySQL");

En lo que respecta a probar si un módulo que está utilizando es seguro o no, hay varias rutas que puede tomar. Hablaré de los pros y los contras de cada uno para que pueda tomar una decisión más informada.

Actualmente, no hay vulnerabilidades para el módulo que está utilizando, sin embargo, esto a menudo puede conducir a una falsa sensación de seguridad, ya que podría haber una vulnerabilidad que actualmente explote el módulo / paquete de software que está utilizando y no lo haría. recibir una alerta sobre un problema hasta que el proveedor aplique una solución / parche.

1. Para mantenerse al tanto de las vulnerabilidades, deberá seguir las listas de correo, foros, IRC y otras discusiones relacionadas con la piratería. PRO: A menudo, es posible que se dé cuenta de posibles problemas dentro de una biblioteca antes de que un proveedor haya sido alertado o haya emitido una solución / parche para remediar la posible vía de ataque a su software. CON: Esto puede llevar mucho tiempo y muchos recursos. Si sigue esta ruta, un bot que usa feeds RSS, análisis de registros (registros de chat IRC) o un scrapper web que usa frases clave (en este caso, node-mysql-native) y notificaciones puede ayudar a reducir el tiempo dedicado a controlar estos recursos.

2. Cree un fuzzer, use un fuzzer u otro marco de vulnerabilidad como metasploit, sqlMap, etc. para ayudar a probar los problemas que el proveedor puede no haber buscado. PRO: Este puede resultar un método seguro para garantizar a un nivel aceptable si el módulo / software que está implementando es seguro para el acceso público o no. CONTRA: Esto también consume mucho tiempo y es costoso. El otro problema se derivará de falsos positivos, así como de una revisión no educada de los resultados donde reside un problema pero no se nota.

La seguridad real y la seguridad de las aplicaciones en general pueden consumir mucho tiempo y recursos. Una cosa que los gerentes siempre usarán es una fórmula para determinar la rentabilidad (mano de obra, recursos, tiempo, pago, etc.) de realizar las dos opciones anteriores.

De todos modos, me doy cuenta de que esta no es una respuesta de ‘sí’ o ‘no’ que puede haber estado esperando, pero no creo que nadie pueda dártelo hasta que realicen un análisis del software en cuestión.

---

---

Utiliza Nuestro Buscador