¿Qué tipo de ataque es la inyección SQL? Estoy confundido porque este tipo de ataque se realiza a través del lado del cliente. Sin embargo, el objetivo de los atacantes es una base de datos que está "detrás" de un servidor. La mayoría de los ataques de OWASP Los 10 ataques principales son del lado del servidor, pero los ataques se realizan a través del lado del cliente. ¿Alguien puede explicar por qué está clasificado como servidor?
La base de datos está almacenada en el servidor. Esto significa que el servidor es lo que se daña directamente durante la inyección exitosa de SQL (puede haber efectos secundarios en el cliente, pero el servidor está dañado primero ).
Por lo tanto, la inyección SQL es, ante todo, un ataque del lado del servidor.
La inyección SQL es un ataque del lado del servidor porque modifica el retorno de la consulta SQL en el código de fondo para propósitos maliciosos.
Alguna información adicional: SOLO la validación del lado del cliente no es suficiente. Es un DEBE tener también la validación de entrada del lado del servidor. Debido a que el atacante puede capturar el paquete antes si se envía al servidor PERO después de que se haya enviado desde el navegador (después de la validación), vuelva a modificar el paquete y haga que sea malicioso.
Los ataques del lado del cliente consisten principalmente en Javacript, XSS, CSRF porque están manipulando o engañando al HTML / JavaScript.
Una manera fácil de pensar en esto es considerar dónde podría ocurrir una solución limpia. Si el cliente está parchado, entonces un atacante puede modificar su cliente para permitirle realizar el ataque de inyección SQL. Si el servidor está parchado, entonces el atacante ya no puede explotar el problema.
Para un ejemplo opuesto de un error de cliente: imagine que el servidor tiene una función donde cada usuario puede tener un texto de "biografía" editable por el usuario asociado a su perfil, y hay numerosos lugares públicos en la interfaz de usuario web y otros clientes. (como aplicaciones móviles o de escritorio que no están necesariamente basadas en HTML) que se muestra este texto. Imagine que uno de los muchos clientes trata accidentalmente este texto de biografía como HTML y permite los ataques XSS. Si intenta parchear esto en el servidor deshabilitando el HTML en el texto de la biografía, entonces los usuarios ya no pueden hablar sobre el HTML en sus biografías (que anteriormente funcionaba bien en todos los demás clientes). La vulnerabilidad está en un cliente en particular, y si ese cliente se solucionara, entonces el problema se solucionaría limpiamente y ya no sería explotable. (Si el servidor sabe qué cliente está hablando con él, entonces el servidor podría solucionar el error del cliente al codificar la biografía en HTML antes de dársela al cliente, pero esto no es exactamente una solución limpia. No quiere decir que no deba hacerlo ». Nunca se debe hacer como una medida provisional, simplemente diciendo que este tipo de solución no afecta a la cuestión de si se trata de un problema del servidor o del cliente.)
Lea otras preguntas en las etiquetas sql-injection