Las 10 mejores API de la serie OWASP de Coders Conquer Security: exposición excesiva de datos

La vulnerabilidad de exposición excesiva de datos se diferencia de otros problemas de API de la lista de OWASP, ya que implica un tipo de datos muy específico. La mecánica real detrás de la vulnerabilidad es similar a la de otros, pero la exposición excesiva de datos, en este caso, se define como la exposición excesiva de datos que están protegidos legalmente o son altamente sensibles. Esto puede incluir cualquier información de identificación personal, que a menudo se denomina PII. O podría incluir información sobre el sector de las tarjetas de pago (PCI, por sus siglas en inglés). Por último, la exposición excesiva de datos puede incluir cualquier información que esté sujeta a las leyes de privacidad, como el Reglamento General de Protección de Datos (GDPR) en Europa o la Ley de Portabilidad y Responsabilidad de los Seguros Médicos (HIPAA) en los Estados Unidos.

Como se 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ás preparado para enfrentarte al dragón de la exposición de datos, dirígete a nuestro desafío gamificado:

¿Cuál fue tu puntuación? Siga leyendo y obtenga más información:

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

Una de las principales razones por las que se produce una exposición excesiva de los datos es porque los desarrolladores y programadores no tienen suficiente información sobre el tipo de datos que utilizarán sus aplicaciones. Por este motivo, los desarrolladores tienden a utilizar procesos genéricos en los que todas las propiedades de los objetos quedan expuestas a los usuarios finales.

A veces, los desarrolladores también asumen que los componentes de la interfaz filtrarán los datos antes de mostrar cualquier información a los usuarios. En el caso de la mayoría de los datos genéricos, esto rara vez supone un problema. Sin embargo, exponer a los usuarios datos confidenciales o protegidos legalmente como parte de un identificador de sesión, por ejemplo, puede generar grandes problemas tanto desde el punto de vista legal como de seguridad.

Como ejemplo de la facilidad con la que se pueden compartir accidentalmente datos confidenciales, el informe de OWASP prevé un escenario en el que un guardia de seguridad tenga acceso a cámaras específicas basadas en IoT en una instalación. Es posible que esas cámaras vigilen zonas cerradas y seguras, mientras que otras cámaras que vigilan a personas deberían estar restringidas a guardias o supervisores con permisos más altos.

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

/api/sites/111/cámaras

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 parece funcionar bien. El guardia, que utiliza la interfaz gráfica de usuario de la aplicación, solo verá las imágenes de la cámara 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 de la instalación. Cualquiera que rastree la red y capture esos datos, o ponga en peligro la cuenta del guardia, podrá descubrir las ubicaciones y la nomenclatura de cada cámara de la red. De este modo, podrían acceder a esos datos sin restricciones.

Eliminar la exposición excesiva de datos

La clave más importante para evitar la exposición excesiva de los 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 opción peligrosa que conduce a muchas violaciones de seguridad evitables.

Además de comprender las protecciones de datos pertinentes, también es importante detener el proceso de enviar todo a un usuario con API genéricas. Por ejemplo, se deben evitar códigos 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 esa información exclusivamente.

Como forma de garantizar que ningún dato protegido se comparta accidentalmente en exceso, las organizaciones deberían considerar la posibilidad de implementar un mecanismo de validación de respuestas basado en esquemas como una capa adicional de seguridad. Debe definir y hacer cumplir los datos que devuelven todos los métodos de API, incluidas las reglas para la notificación de errores.

Por último, todos los datos clasificados como que contienen PII o PCI, o la información que está protegida por normativas como el RGPD o la HIPAA, deben protegerse mediante un cifrado seguro. De este modo, incluso si la ubicación de esos datos se pierde debido a una vulnerabilidad de exposición excesiva de los datos, existe una buena línea de defensa secundaria que debería proteger los datos incluso si caen en manos de un usuario malintencionado o de un actor de amenazas.

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