REST es una arquitectura de aplicación web extremadamente popular. Para llamar a funciones en el servidor, se utilizan solicitudes HTTP comunes con parámetros específicos (JSON o XML generalmente se usan para estructurar parámetros), mientras que no existe un estándar estricto para la arquitectura REST, que agrega flexibilidad (y, por supuesto, un poco de caos).
REST le permite abordar de manera flexible el tema de la seguridad o, que muchos pecados, no abordar la cuestión en absoluto. Basado en
OWASP , hemos preparado una lista de consejos para ayudarlo a mejorar la seguridad de su aplicación REST.
Como punto de partida en esos casos raros cuando se necesita aquí, usamos python y Django.
Regla 0
Https
Solo configúralo. Por favor La protección de los datos transmitidos no ha dañado a nadie. Incluso si cree que no hay nada que proteger en este momento, este no siempre será el caso y aún debe configurar HTTPS. Así que configúrelo mejor de inmediato, y todos estarán bien.
Regla 1
Autenticación
Parecería un consejo obvio, que, sin embargo, muchos prefieren descuidar. La aplicación siempre debe tener autenticación, incluso si ahora piensa que la usará solo dentro de la empresa y no hay diferencia sobre cuál de los empleados lo hace. Y si agrega más con revistas, entonces investigar incidentes y analizar la actividad será incomparablemente más simple.
Como tokens de acceso, actualmente se considera una buena práctica usar
JWT (tokens web JSON). ¡No use tokens con el valor {"alg": "none"} para el control de integridad, los tokens siempre deben contener una firma o MAC! Es preferible una firma debido al hecho de que las claves de generación y verificación de MAC son las mismas (o pueden calcularse fácilmente entre sí), es decir, si el servidor puede verificar el valor de MAC, también puede generar sus valores. La firma también confirma no solo la integridad del mensaje, sino también la identidad del remitente.
Regla 2
Denegar métodos HTTP que no use
Configure el servidor para incluir en la lista blanca los métodos con los que trabaja (GET, POST, PUT, etc.) y rechace todo lo que no se ajuste a esta lista. Es poco probable que su servidor necesite procesar solicitudes TRACE en producción (este método es parte del ataque XST (Cross-Site Tracing), que consiste en un ataque XSS y el método TRACE o TRACK. Este ataque permite, por ejemplo, robar las cookies del usuario, incluso si están marcados como HttpOnly). Cuanta menos información sobre su infraestructura esté disponible desde el exterior, mejor.
Regla 3
Acceso diferenciado
¿Todos sus usuarios necesitan todos los métodos, por ejemplo, ELIMINAR? Si no desea que algunos usuarios puedan realizar ciertas operaciones, configure el control de acceso en su aplicación. Por ejemplo, un usuario común puede acceder solo al método GET para algunas funciones, el administrador puede usar GET y POST, etc. Para esto, vale la pena establecer roles en la base de datos que pueden asignarse a los usuarios para un control de acceso conveniente.
Como resultado, cada función tendrá un bloque de verificación de aproximadamente este tipo:
if request.POST and user.is_manager: do_stuff()
Regla 4
Piense en limitar el número de consultas.
Si crees que tus usuarios no deberían enviarte cien mil solicitudes por segundo, entonces debes limitar este número. Use claves API o cualquier otro mecanismo conveniente para que pueda rastrear y limitar el número de solicitudes que se procesarán en un determinado período de tiempo de un usuario. Para Django, por ejemplo, django-ratelimit proporciona esta funcionalidad, donde puede establecer varios parámetros como un identificador para la restricción, no necesariamente las claves API, sino una dirección IP.
Regla 5
Asegúrese de validar / desinfectar la entrada
Nunca confíe en los parámetros de entrada transmitidos, siempre realice validación / saneamiento:
- Si es posible (y donde sea posible), establezca un límite en la longitud / tipo / formato de la entrada y la solicitud en sí. Rechace todas las solicitudes / datos transmitidos que excedan la longitud especificada por usted o que no coincidan con el tipo / formato.
- Al procesar cadenas, siempre escapa de todos los caracteres especiales.
- Si usa el marco, la mayoría de ellos contienen sus propias herramientas integradas de validación y saneamiento (por fuera de las populares: Django (python) y Yii2 (php)), por lo que es importante estudiar sus capacidades y si algún aspecto que necesita no está cubierto, encuentre una biblioteca que cierre esto o escriba dicha funcionalidad usted mismo.
- Realice un seguimiento de los errores de validación. Si las solicitudes de algunos usuarios fallan constantemente en la validación, piense en bloquear automáticamente a dichos usuarios.
- Asegúrese de que su analizador de entrada (o su versión actual) no sea susceptible a ningún ataque por sí mismo.
Regla 6
No brinde más información de la necesaria
Si alguna solicitud causó un error en la aplicación, o simplemente no está disponible por alguna razón, no proporcione detalles en la respuesta, devuelva el mensaje de error más abstracto. Algunos servidores devuelven stacktrace después de un error por defecto, así que asegúrese de reconfigurar esta lógica.
Regla 7
Mantenga siempre registros
Deje que cada evento (autenticación, error, solicitud, etc.) se registre lo más detallado posible. Regístrelos lógicamente para una búsqueda más conveniente en ellos si es necesario. Por si acaso, antes de grabar en los registros, desinfecte los datos grabados.
Regla 8
Indique el tipo de contenido correctamente: ¡esto es importante!
Para que el navegador (o cliente) lea correctamente los datos proporcionados, es importante el tipo de contenido especificado correctamente correspondiente a los datos proporcionados. En el caso de los navegadores, también vale la pena configurar el X-Content-Type-Options: encabezado nosniff para evitar que el navegador intente detectar otro tipo de contenido además del que realmente se envió (una medida contra los ataques XSS).
Regla 9
Validar tipo de contenido
- Vale la pena configurar el rechazo de las solicitudes si su tipo de contenido difiere de su contenido. Esto reducirá el riesgo de un procesamiento de datos incorrecto, lo que puede conducir a la inyección o la ejecución de código en el servidor / cliente.
- También vale la pena rechazar solicitudes cuyo tipo de contenido no es compatible, o para las que este encabezado generalmente está ausente. También evite las respuestas directas sobre qué función Content-Type acepta / emite, si esto no es necesario (esto ayudará a evitar ataques XXE).
- En los servicios REST, es común admitir varios tipos de respuestas (por ejemplo, json y xml), y el cliente indica el tipo preferido de respuesta en el encabezado Aceptar cuando solicita. Evite copiar el contenido del encabezado Aceptar en el Tipo de contenido de la respuesta como mecanismo para configurar este encabezado. También rechace las solicitudes para las cuales el encabezado Aceptar no contiene directamente al menos uno de los tipos admitidos.
Regla 10
No olvide configurar el uso compartido de recursos de origen cruzado (CORS)
CORS es un estándar que describe el trabajo con consultas entre dominios. Si su aplicación no admite CORS, desactive el trabajo con este tipo de encabezados. Si necesita usarlo, la política de acceso debe ser lo más específica y estricta posible.
Regla 11
No expanda parámetros en URL
Todos los datos críticos (contraseñas, claves, tokens e inicios de sesión, preferiblemente también) deben estar dentro del cuerpo de la solicitud o en los encabezados, pero en ningún caso deben aparecer en la URL. Si necesita pasar datos confidenciales a través del método GET, póngalo en el encabezado.
Es imposible:ejemplo .com / controller / 123 / action? apiKey = a53f435643de32
Usted puede:ejemplo .com / controller / 123 / action
Encabezados:Anfitrión: ejemplo.com
Usuario-Agente: Mozilla ...
X-APIkey: a53f435643de32
Regla 12
Piense en la protección contra los ataques CSRF
Puede leer más sobre todos los tipos de protección
aquí , por lo que el uso de tokens CSRF se considera la forma más popular de reducir el riesgo de ataques de este tipo.
Regla 13
Explore su marco
Si usa algún marco para implementar REST en su aplicación, debe estudiarlo y no usarlo ciegamente, como se hace a menudo. Lea la documentación detenidamente, especialmente la parte de seguridad. ¡No lo deje funcionando en la configuración predeterminada! Cada marco tiene sus propios matices, especialmente cuando se trata de seguridad, por lo que conocerlos es muy importante.