Serie de OWASP Top 10 API para desarrolladores: Exposición excesiva de datos

La vulnerabilidad de exposición excesiva de datos se distingue de otros problemas de API en la lista de OWASP porque implica un tipo de datos muy específico. La mecánica real detrás de la vulnerabilidad es similar a otras, pero la exposición excesiva de datos, en este caso, se define como aquella que involucra información legalmente protegida o altamente sensible. Esto puede incluir cualquier información de identificación personal, a menudo denominada PII. O podría involucrar información de la industria de tarjetas de pago, o PCI. Por último, la exposición excesiva de datos puede incluir cualquier información sujeta a leyes de privacidad, como el Reglamento General de Protección de Datos (RGPD) en Europa o la Ley de Portabilidad y Responsabilidad del Seguro Médico (HIPAA) en los Estados Unidos.

Como puede imaginar, esto es motivo de profunda preocupación, y es imperativo que los desarrolladores expertos aprendan a eliminar estos errores siempre que sea posible. Si ya está preparado para enfrentarse al dragón de la exposición de datos, diríjase a nuestro desafío gamificado:

¿Cuál fue su puntuación? Siga leyendo y aprenda más:

¿Cuáles son algunos ejemplos de exposición excesiva de datos?

Una de las razones principales por las que ocurre la exposición excesiva de datos es porque los desarrolladores y programadores no tienen suficiente conocimiento sobre el tipo de datos que utilizarán sus aplicaciones. Debido a esto, los desarrolladores tienden a utilizar procesos genéricos donde todas las propiedades de los objetos se exponen a los usuarios finales.

Los desarrolladores también asumen a veces que los componentes frontend realizarán un filtrado de datos antes de mostrar cualquier información a los usuarios. Para la mayoría de los datos genéricos, esto rara vez es un problema. Pero exponer datos legalmente protegidos o sensibles a los usuarios como parte de un ID de sesión, por ejemplo, puede generar grandes problemas tanto desde el punto de vista de la seguridad como desde el legal.

Como ejemplo de la facilidad con la que se pueden compartir datos sensibles accidentalmente, el informe de OWASP plantea un escenario en el que un guardia de seguridad recibe acceso a cámaras específicas basadas en IoT en una instalación. Quizás esas cámaras vigilan áreas selladas y seguras, mientras que otras cámaras que observan a personas deberían estar restringidas a guardias o supervisores con permisos superiores.

Para dar al guardia acceso a las cámaras autorizadas, los desarrolladores pueden usar una llamada a la API como la siguiente.

/api/sites/111/cameras

En respuesta, la aplicación enviaría detalles sobre las cámaras que el guardia puede ver en el siguiente formato:

{ "id":"xxx","live_access_token":"xxxxbbbbb","building_id":"yyy"}

A primera vista, esto parecería funcionar perfectamente. El guardia, que utiliza la interfaz gráfica de usuario en la aplicación, solo vería las transmisiones de las cámaras que está autorizado a ver. El problema es que, debido al código genérico utilizado, la respuesta real de la API contendría una lista completa de todas las cámaras en toda la instalación. Cualquiera que rastree la red y capture esos datos, o comprometa la cuenta del guardia, podría descubrir las ubicaciones y la nomenclatura de cada cámara en la red. Luego podrían acceder a esos datos sin restricciones.

Eliminación de la exposición excesiva de datos

La clave principal para prevenir la exposición excesiva de datos es comprender los datos y las protecciones que los rodean. Crear API genéricas y dejar que el cliente clasifique los datos antes de mostrarlos a los usuarios es una elección peligrosa que conduce a muchas brechas de seguridad evitables.

Además de comprender las protecciones de datos relevantes, también es importante detener el proceso de enviar todo a un usuario con API genéricas. Por ejemplo, se debe evitar el uso de código como to_json() y to_string(). En su lugar, el código debe seleccionar específicamente las propiedades que deben devolverse a los usuarios autorizados y enviar exclusivamente esa información.

Como forma de garantizar que no se compartan accidentalmente datos protegidos, las organizaciones deberían considerar la implementación de un mecanismo de validación de respuesta basado en esquemas como una capa adicional de seguridad. Debe definir y hacer cumplir los datos devueltos por todos los métodos de la API, incluidas las reglas para la notificación de errores.

Finalmente, todos los datos clasificados como PII o PCI, o la información protegida por regulaciones como el RGPD o la HIPAA, deben protegerse mediante un cifrado sólido. De esa manera, incluso si la ubicación de esos datos se filtra como parte de una vulnerabilidad de exposición excesiva de datos, existe una buena línea de defensa secundaria que debería proteger la información incluso si cae en manos de un usuario malintencionado o un actor de amenazas.

Eche un vistazo a las páginas del blog de Secure Code Warrior para obtener más información sobre esta vulnerabilidad y cómo proteger a su organización y a sus clientes de los estragos de otras fallas de seguridad. También puede probar una demostración de la plataforma de capacitación de Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.