Materias · 🏛️ Universidad y trabajo
Seguridad de aplicaciones
Ejercicios resueltos de Seguridad de aplicaciones paso a paso, con el error que más se comete en cada uno: Inyección SQL, Control de acceso y más. Gratis y en español.
Preguntarle al tutor de Seguridad de aplicacionesSin instalar nada. Puedes probar antes de crear cuenta.
Ejercicios resueltos de Seguridad de aplicaciones
Resueltos paso a paso, como te los explicaría el tutor, y con el error que más se comete.
Inyección SQL
El login de una app arma la consulta pegando el texto que llega del formulario:
SELECT * FROM usuarios WHERE correo = '<correo>' AND clave = '<clave>'
¿Qué puede escribir un atacante en el campo de clave para entrar sin conocerla, y cómo se corrige la falla de raíz?
Cómo se resuelve
- 1El problema de fondo es que el dato del usuario se pega dentro del TEXTO de la consulta. Cuando el motor la recibe ya no hay forma de saber qué parte era instrucción y qué parte era dato: todo llegó como una sola cadena.
- 2El atacante escribe en el campo de clave el texto: ' OR '1'='1
- 3La comilla inicial cierra antes de tiempo la comilla que abrió el programa, y de ahí en adelante lo que sigue el motor lo lee como SQL y no como una contraseña.
- 4La consulta que llega al motor queda: ... AND clave = '' OR '1'='1'. El OR hace verdadera toda la condición, porque '1'='1' siempre lo es, y la consulta devuelve usuarios aunque la clave no coincida.
- 5La corrección de raíz son las consultas parametrizadas: se le manda al motor la plantilla con marcadores (correo = ? AND clave = ?) y los valores por un canal aparte. Un valor que llega por ese canal jamás se reinterpreta como SQL, sin importar qué contenga.
- 6Y de paso se corrige el otro problema que el ejemplo deja ver: la contraseña se está comparando en texto plano. Se guarda un hash con bcrypt o Argon2 y se verifica en la aplicación, para que una fuga de la base de datos no entregue las contraseñas de los usuarios.
Respuesta: Escribe ' OR '1'='1 en el campo de clave y la condición se vuelve siempre verdadera. Se corrige con consultas parametrizadas, donde los valores viajan aparte del texto de la consulta, y guardando la contraseña como hash con bcrypt o Argon2.
El error de siempre: «Arreglarlo» filtrando comillas o escapando caracteres a mano. Siempre queda una vía abierta (otras codificaciones, comentarios de SQL, campos numéricos que van sin comillas) y el filtro se le olvida al siguiente que escriba una consulta. La parametrización no es un filtro mejor: elimina el problema porque el valor deja de poder ser código, y eso no depende de acordarse.
Control de acceso
En una app de facturación, GET /api/facturas/4821 devuelve la factura del usuario. Un cliente cambia el número a 4820 en la barra de direcciones y ve la factura de otra empresa. Su sesión es válida y el token no está vencido. ¿Cuál es la falla y cómo se corrige?
Cómo se resuelve
- 1Se separan dos cosas que suelen confundirse: autenticación es saber QUIÉN es (el token válido lo resuelve) y autorización es saber si ESE quién puede tocar ESE recurso. Aquí lo primero está bien y lo segundo no existe.
- 2La falla se llama control de acceso roto, en su variante de referencia directa insegura a objetos: el identificador del recurso viaja en la URL y el servidor lo obedece sin preguntar de quién es.
- 3La corrección va en el servidor y en la consulta misma, no en la interfaz: el filtro del dueño se toma del token de sesión, nunca de algo que venga del cliente. Queda ... WHERE id_factura = 4820 AND id_empresa = (la del token).
- 4Si no aparece ninguna fila, se responde 404 y no 403. Un 403 confirma que la factura existe y de quién no es, y eso ya es información que el atacante no tenía.
- 5La regla general que evita repetir el error en el siguiente endpoint: denegar por defecto. La autorización se aplica en una capa por la que pasen todas las rutas, y lo excepcional es lo público, no lo protegido.
Respuesta: Es control de acceso roto (referencia directa insegura a objetos). Se corrige filtrando en la consulta por el dueño sacado del token de sesión, respondiendo 404 cuando no hay coincidencia y aplicando la autorización por defecto en todos los endpoints.
El error de siempre: Creer que cambiar los identificadores secuenciales por UUID lo soluciona. Eso solo los vuelve difíciles de adivinar, pero quien ya conoce uno ajeno (lo vio en un enlace compartido, en un correo reenviado, en el historial del navegador de la oficina) entra igual. Esconder el identificador no es controlar el acceso.
¿Y si tu ejercicio no es ninguno de estos?
No hace falta buscar el ejercicio exacto en internet. Trae el tuyo, o pide los que te falten.
Todo esto es gratis y sin instalar nada. Puedes probar antes de crear cuenta.
Lo que cubre
- Inyección SQL
- Control de acceso
Preguntas que le puedes hacer
- Inyección SQLExplícame «Inyección SQL» con un ejemplo práctico y dime en qué suele equivocarse la gente.
- Control de accesoExplícame «Control de acceso» con un ejemplo práctico y dime en qué suele equivocarse la gente.
Cómo enseña este tutor
Es riguroso y completo: justifica cada paso y nombra el teorema, la norma o la buena práctica que está aplicando, para que puedas citarla en tu trabajo o en el parcial.
- · Te muestra el camino completo, no solo el resultado.
- · Si algo no te cuadra, te lo explica otra vez de otra manera.
- · Con una foto de tu cuaderno te dice dónde está el error.
- · Te arma quizzes de lo que acabas de ver para saber si de verdad quedó.
Otras materias de Universidad y trabajo
