Les codeurs conquièrent la série des 10 meilleures API de l'OWASP en matière de sécurité : exposition excessive des données

La vulnerabilidad de exposición excesiva de datos es distinta 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 otras, pero la exposición excesiva de datos, en este caso, se define como la implicación de datos legalmente protegidos o altamente sensibles. Esto puede incluir cualquier información personal identificable, que a menudo se conoce como PII. También puede tratarse de información del sector de las tarjetas de pago, o PCI. 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 del Seguro Médico (HIPAA) en los Estados Unidos.

Como puedes imaginar, esto es motivo de gran preocupación, y es imperativo que los desarrolladores inteligentes aprendan a aplastar estos errores siempre que sea posible. Si ya estás preparado para enfrentarte a un dragón de exposición de datos, dirígete a nuestro reto gamificado:

¿Cuál fue su puntuación? Sigue leyendo y aprende más:

¿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 datos es porque los desarrolladores y codificadores no tienen suficiente conocimiento del tipo de datos que utilizarán sus aplicaciones. Por ello, los desarrolladores tienden a utilizar procesos genéricos en los que todas las propiedades de los objetos están expuestas a los usuarios finales.

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

Como ejemplo de la facilidad con la que los datos sensibles pueden ser compartidos accidentalmente, el informe de OWASP prevé un escenario en el que un guardia de seguridad tiene acceso a cámaras específicas basadas en el IoT en una instalación. Tal vez esas cámaras vigilan áreas selladas y seguras, mientras que otras cámaras que ven a las personas se supone que están restringidas a los guardias o supervisores con permisos superiores.

Para que el vigilante tenga acceso a las cámaras autorizadas, los desarrolladores pueden utilizar 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 vigilante, que utiliza la interfaz gráfica de usuario de la aplicación, sólo vería las imágenes 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 de las instalaciones. Cualquiera que husmee en la red y capture esos datos, o comprometa la cuenta del guardia, podría descubrir la ubicación y la nomenclatura de todas las cámaras de la red. Entonces podría acceder a esos datos sin restricciones.

Eliminación de la exposición excesiva de datos

La mayor clave para evitar la exposición excesiva de datos es la comprensión de los datos y las protecciones que los rodean. Crear APIs genéricas y dejar en manos del cliente la ordenación de los datos antes de mostrarlos a los usuarios es una opción peligrosa que da lugar a muchos fallos de seguridad evitables.

Además de entender las protecciones de datos relevantes, también es importante detener el proceso de enviar todo a un usuario con APIs genéricas. Por ejemplo, hay que evitar códigos como to_json() y to_string(). En su lugar, el código debe escoger específicamente las propiedades que deben ser devueltas 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 respuestas basado en esquemas como una capa adicional de seguridad. Debería definir y hacer cumplir los datos que devuelven todos los métodos de la API, incluidas las reglas de notificación de errores.

Por último, todos los datos clasificados como PII o PCI, o la información que está protegida por las regulaciones como GDPR o HIPAA deben ser protegidos utilizando un cifrado fuerte. De esta manera, incluso si la ubicación de esos datos se escapa como parte de una vulnerabilidad de exposición de datos excesiva, hay una buena línea de defensa secundaria que debería proteger los datos incluso si caen en manos de un usuario malicioso o un actor de amenaza.

Consulte las páginas del Secure Code Warrior 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 otros fallos de seguridad. También puede probar una demostración de la plataforma de formación Secure Code Warrior para mantener todos sus conocimientos de ciberseguridad perfeccionados y actualizados.