Esta es una buena pregunta y recientemente me interesé en el tema. Escribí una publicación de blog sobre pruebas de seguridad de API , una descripción general de exploits comunes, ejemplos famosos y cómo probar esas vulnerabilidades.
Reiteraré esos puntos aquí:
Comando / inyección SQL
- ¿Cuál es la forma más fácil de construir una plataforma de video?
- ¿Cuáles son los diferentes tipos de cookies web?
- ¿Cuáles son las diversas ventajas de Laravel que lo hacen preferible a otros marcos?
- ¿Alguien se ha convertido en un buen desarrollador web sin mucho conocimiento de las matemáticas?
- ¿Cómo se puede mejorar la codificación en el front-end?
Este es, con mucho, el tipo de ataque más común contra las API, y realmente cualquier servicio web. Esto sucede cuando un usuario puede hacer que la API se ejecute de forma remota, generalmente enviándola en un parámetro o cuerpo POST. Tome un ejemplo de algún código PHP que permita a un usuario eliminar un archivo:
$ fn = $ _GET ['nombre de archivo'];
sistema ("rm $ file")
¿Puedes ver que el usuario podría ejecutar CUALQUIER comando simplemente agregándolo al parámetro `filename`? Me gusta esto:
https://example.com/delete?name=file.txt;rm%20/
Para cuando se ejecuta el comando `system`, el atacante ha empalmado un segundo comando que eliminaría (hipotéticamente) el contenido de todo el servidor. Lo mismo puede suceder con comandos SQL, llamadas a servicios de terceros, etc.
La moraleja de la historia es asegurarse de que todos los comandos de la base de datos, las llamadas al sistema y cualquier cosa aceptada como parámetro de la API se desinfecten correctamente y, por supuesto, se prueben.
Autorización y gestión de sesiones
OWASP enumera esto como el segundo tipo de ataque más común. Que básicamente son métodos de autenticación rotos, inicio de sesión / manejo de cookies, etc.
La mejor práctica con CUALQUIER API es Denegar por defecto. Si su API ha requerido autenticación en algunos puntos finales, pero otros puntos finales no lo requieren, debe codificar su aplicación para negar todas las solicitudes primero. Luego, agregue la lógica de exclusión voluntaria a los controladores que no lo requieren.
Obviamente, es mejor que se deniegue una solicitud autorizada, que que se acepte una solicitud no autorizada.
Manipulación de parámetros
Esta es una de las vulnerabilidades más comunes que pueden conducir a exploits como XSS. Similar a la inyección de comandos, el mejor curso de acción aquí es limpiar cuidadosamente cualquier dato que provenga de la solicitud de API de un usuario.
NUNCA CONFÍE EN QUE UN USUARIO ENVIARÁ DATOS BIEN FORMADOS.
Fuzzing
Fuzzing es más un tipo de prueba, pero la idea básica es que un atacante intentará bloquear su API o encontrar vulnerabilidades enviando datos incorrectamente formateados o incorrectos.
Si su API acepta una cadena en un parámetro, un atacante enviará cadenas grandes, cadenas pequeñas, números, etc. ¡Si su API acepta un número, enviará números negativos, números grandes y cadenas!
Afortunadamente, esta es una de las cosas más fáciles de probar. La mejor práctica más común aquí es incluir en la lista blanca, no en la lista negra, cuando sea posible. En otras palabras, su validación debe ser lo que es bueno y no lo que es malo. Aquí hay una buena descripción general de este tipo de validación.
Estos son solo algunos, pero son los más comunes y proporcionan un excelente punto de partida. Definitivamente recomiendo revisar cualquier cosa y todo en OWASP que esté relacionado con su aplicación.
¡Feliz pirateo!
Cody Reichert
