Tengo un token que está restringido para acceso de solo lectura. Si alguien obtiene ese token, ¿puede usarlo para realizar un ataque de inyección de SQL?
Dado que el token está autorizado para solo lectura, ¿alguien puede incrustar una consulta de eliminación en la solicitud, leerlo en el lado del servidor y realmente eliminar?
Lo primero y más importante: Si el token se concatena en una consulta de SQL (sin escaparse lo suficiente), entonces sí , se puede usar para inyección SQL. ¡No construyas consultas por concatenación!
Los tokens, por sí mismos, no tienen permisos; son solo identificadores La lógica de la aplicación determina qué permisos dar al portador del token, pero depende de la aplicación hacer cumplir eso, y una inyección de SQL (exitosa) pasa por alto tales controles. Las bases de datos también tienen permisos (al menos, los mejores) y la aplicación tendrá ciertos permisos en la base de datos que determinan qué puede hacer una consulta que la aplicación envía a la base de datos (y todo lo que es una inyección de SQL, desde la perspectiva de El DB, es una consulta que la aplicación envió a través de. Una aplicación muy preocupada por la seguridad utilizará el Principio de los privilegios mínimos (que dice que nunca debe otorgar más permisos de los necesarios para realizar su tarea), por ejemplo (una consulta de base de datos que se supone que es de solo lectura). se realice utilizando una conexión con permiso de solo lectura en la base de datos, y en tal caso, una subconsulta DELETE incrustada fallará. Sin embargo, en la práctica, muy pocos desarrolladores hacen esto, y la aplicación generalmente realiza todas las consultas utilizando una conexión con permisos completos en la base de datos.
Los permisos de la entidad identificada con token (probablemente un usuario de una aplicación web o similar) no tienen ninguna relación con los permisos que tiene la aplicación cuando habla con su base de datos. De hecho, dado que una inyección SQL requiere modificar el token, ya no es realmente el identificador correcto para ese usuario, por lo que definitivamente no estará sujeto a verificaciones de acceso específicas del usuario.
Lea otras preguntas en las etiquetas authentication sql-injection hardware-token