Si el usuario de mi base de datos es de solo lectura, ¿por qué debo preocuparme por la inyección de sql?

Question

¿Pueden (usuarios malintencionados) describir tablas y obtener información vital? ¿Qué pasa si bloqueo al usuario a tablas específicas? No digo que quiera inyectar sql, pero me pregunto si el código antiguo que tenemos es susceptible, pero el usuario de db está bloqueado. Gracias.

EDIT: Entiendo lo que dices, pero si no tengo respuesta. Escribe para los demás datos, ¿cómo pueden verlo? Traer a rastrear y tener sentido, también lo hacen los demás, pero ¿cómo verían realmente los datos?

Answer 1

Alguien podría inyectar SQL para hacer que una verificación de autorización devuelva el equivalente de verdadero en lugar de falso para obtener acceso a cosas que deberían estar fuera de los límites.

O bien podrían inyectarse una tabla de catálogo 20 o 30 veces para llevar el rendimiento de la base de datos a un rastreo.

O podrían llamar a un procedimiento almacenado que se ejecuta como un usuario de base de datos diferente que qué modificar datos.

Answer 2

'); SELECT * FROM Users 

Sí, debería bloquear hacia abajo a sólo los datos (tablas/vistas) que en realidad debería ser capaz de ver, especialmente si se enfrenta públicamente.

Answer 3

Sólo si no te importa usuarios arbitrarios lectura de toda la base de datos . Por ejemplo, he aquí una sencilla secuencia, inyectable entrada:

select * from UserTable where userID = 'txtUserName.Text' and password = 'txtPassword.Text' 

if(RowCount > 0) { 
    // Logged in 
} 

Sólo tengo que iniciar sesión con cualquier nombre de usuario y contraseña 'o 1 = 1 iniciar la sesión como ese usuario.

Answer 4

Ten mucho cuidado. Supongo que eliminó la tabla desplegable, alter table, create table y truncate table, ¿verdad?

Básicamente, con una buena inyección de SQL, debería poder cambiar todo lo que dependa de la base de datos. Esto podría ser autorización, permisos, acceso a sistemas externos, ...

¿Alguna vez escribió datos en el disco que se recuperaron de la base de datos? En ese caso, podrían cargar un archivo ejecutable como perl y un archivo perl y luego ejecutarlos para obtener un mejor acceso a su cuadro.

También puede determinar qué datos son aprovechando una situación donde se espera un valor de retorno específico. Es decir. si el SQL devuelve verdadero, la ejecución continúa; si no, la ejecución se detiene. Luego, puede usar una búsqueda binaria en su SQL. select count (*) donde user_password> 'H'; Si el recuento es> 0, continúa. Ahora puede encontrar la contraseña exacta de texto plano sin necesidad de que se imprima nunca en la pantalla.

Además, si su aplicación no está reforzada contra errores de SQL, puede haber un caso en el que puedan insertar un error en el SQL o en el SQL del resultado y mostrar el resultado en la pantalla durante el controlador de errores. La primera instrucción SQL recopila una buena lista de nombres de usuario y contraseñas. La segunda declaración intenta aprovecharlos en una condición SQL para la cual no son apropiados. Si se muestra la instrucción SQL en esta condición de error, ...

Jacob

Answer 5

Sí, siguen preocupados por la inyección de SQL. Las sentencias SQL maliciosas no se tratan solo de escrituras.

Imagine también si había servidores enlazados o si la consulta se escribió para acceder a recursos cross-db. es decir,

SELECT * from someServer.somePayrollDB.dbo.EmployeeSalary; 

Answer 6

Hubo un error de Oracle que permite que se bloquee la instancia llamando a un método público (pero no documentado) con parámetros incorrectos.

Answer 7

He leído esta pregunta y sus respuestas porque estaba en el proceso de crear un SQL tutorial website con un usuario de solo lectura que permitiría a los usuarios finales ejecutar cualquier SQL.

Obviamente esto es arriesgado y cometí varios errores. Esto es lo que aprendí en las primeras 24 horas (sí, la mayoría de esto está cubierto por otras respuestas, pero esta información es más accionable).

• No permitir el acceso a su mesa o del sistema las tablas de usuario:

Postgres:

REVOKE ALL ON SCHEMA PG_CATALOG, PUBLIC, INFORMATION_SCHEMA FROM PUBLIC 

• Asegúrese de que su usuario de sólo lectura sólo tiene acceso a las tablas que necesita en el esquema que desea:

Postgres:

GRANT USAGE ON SCHEMA X TO READ_ONLY_USER; 
GRANT SELECT ON ALL TABLES IN SCHEMA X TO READ_ONLY_USER 

• Configure su base de datos para dejar correr largas consultas

Postgres:

Set statement_timeout in the PG config file 
/etc/postgresql/(version)/main/postgresql.conf 

• Considere poner la información sensible dentro de su propio esquema

Postgres:

GRANT USAGE ON SCHEMA MY_SCHEMA TO READ_ONLY_USER; 

GRANT SELECT ON ALL TABLES IN SCHEMA MY_SCHEMA TO READ_ONLY_USER; 

ALTER USER READ_ONLY_USER SET SEARCH_PATH TO MY_SCHEMA; 

• tener cuidado para bloquear los procedimientos almacenados y asegurarse de que no se pueden ejecutar por el usuario de solamente lectura

Editar: Nota al eliminar por completo el acceso a las tablas del sistema que ya no permite al usuario t o hacer llamadas como cast(). Así que es posible que desee ejecutar este nuevo para permitir el acceso:

GRANT USAGE ON SCHEMA PG_CATALOG to READ_ONLY_USER;