SCW 아이콘
영웅 배경, 구분선 없음
블로그

Las 10 mejores API de la serie OWASP de Coders Conquer Security: gestión inadecuada de activos

마티아스 마두, Ph.
게시일 : 2020년 12월 22일
마지막 업데이트: 2026년 3월 6일

A diferencia de la mayoría de las vulnerabilidades de las diez principales API de OWASP, la gestión inadecuada de los activos no se centra específicamente en las fallas de codificación. Por el contrario, esta vulnerabilidad es más bien un problema humano o administrativo que permite que las API antiguas permanezcan en su lugar mucho tiempo después de que deberían haber sido reemplazadas por versiones más nuevas y seguras. También puede ocurrir si las API que aún están en desarrollo quedan expuestas al entorno de producción antes de que estén completamente protegidas contra las amenazas.

Esta vulnerabilidad es particularmente difícil de gestionar debido a la llegada de los microservicios y la computación en nube. En ese entorno, es posible que los nuevos servicios se pongan en marcha rápidamente para satisfacer una necesidad temporal y luego se olviden de ellos y nunca se retiren del mercado. Si las API antiguas se dejan conectadas al entorno de producción, se puede poner en peligro toda la red.

¿Quieres probar un desafío gamificado sobre este error de seguridad? Entra en nuestra arena: [Empieza aquí]

¿Cómo afectan las fallas de administración inadecuada de activos a las API?

La falla en la administración inadecuada de activos es un producto de los tiempos modernos. Las organizaciones que avanzan a la velocidad de los negocios a veces pueden ofrecer cientos o miles de servicios y microservicios todos los días. Con frecuencia, esto se hace de forma rápida y sin necesidad de crear ninguna documentación complementaria ni de ninguna explicación sobre para qué se utilizan las API asociadas, durante cuánto tiempo serán necesarias o su importancia. Esto puede generar rápidamente una expansión de las API que podría volverse incontrolable con el tiempo, especialmente si no existen políticas generales que definan durante cuánto tiempo pueden existir las API.

En ese entorno, es muy posible que algunas API se pierdan, se olviden o nunca se den de baja.

Los usuarios con permiso para crear nuevos servicios fuera del proceso normal también tienen la culpa a veces. Por ejemplo, un grupo de marketing puede crear un servicio para ayudar a respaldar un evento próximo, como el lanzamiento de un producto, y luego no volver a suspenderlo una vez finalizado el evento. Si alguien consulta ese servicio y sus API asociadas más adelante, puede que no sepa por qué existen y, si no hay documentación, podría seguir siendo un misterio. Es posible que no se sientan cómodos eliminando esas API del entorno de producción o incluso actualizándolas a versiones más recientes porque no tienen ni idea de su importancia ni de lo que hacen.

La vulnerabilidad se vuelve peligrosa porque la seguridad de las API en los marcos mejora con el tiempo. Es posible que un investigador descubra una vulnerabilidad o que se añada una seguridad adicional para detener un tipo de ataque cada vez más popular. Las API antiguas pueden seguir siendo vulnerables a esos ataques a menos que se actualicen, por lo que los piratas informáticos suelen buscarlas o utilizar herramientas automatizadas para encontrarlas.

En un ejemplo real proporcionado por OWASP, una empresa actualizó las API que utilizaba para buscar en las bases de datos de usuarios a fin de corregir una falla crítica. Sin embargo, dejaron las API antiguas en su lugar por error.

Un atacante observó que la ubicación de la nueva API era algo así como (api.criticalservice.com/v2). Al reemplazar la URL por (api.criticalservice.com/v1), pudieron usar la API antigua con la vulnerabilidad conocida. En última instancia, esto expuso los registros personales de más de 100 millones de usuarios.

Eliminar las fallas en la administración inadecuada de activos

La única manera de eliminar la falla de administración de activos inadecuada de su entorno es mantener un inventario ajustado de todas las API, sus usos y versiones. Esto debe comenzar con un inventario de las API existentes, centrándose en factores como el entorno en el que deben implementarse (por ejemplo, de producción o desarrollo), quién debe tener acceso a ellas en red y, por supuesto, su versión.

Una vez que esté completo, debe implementar un proceso en el que la documentación se añada automáticamente a cualquier API o servicio nuevo que se cree. Esto debe incluir todos los aspectos de la API, incluida la limitación de velocidad, la forma en que gestiona las solicitudes y respuestas, el intercambio de recursos, los puntos finales a los que se puede conectar, las políticas pertinentes que se apliquen y cualquier otra cosa que sea necesaria para auditarlas posteriormente. También debes evitar utilizar en producción las API que no sean de producción o las del entorno de desarrollo. Considera también la posibilidad de añadir un límite de tiempo a las API cuando sus propietarios deban justificar su uso continuo para evitar el desmantelamiento automático.

Siempre que haya nuevas versiones de las API activas disponibles, realice una evaluación de riesgos para determinar si debe actualizarse y cómo debe llevarse a cabo ese proceso para evitar interrumpir el entorno de producción. Una vez que haya migrado a las nuevas API, elimine completamente las antiguas del entorno.

Hacer todo esto puede ayudar a evitar que la vulnerabilidad de la administración inadecuada de activos perjudique a su organización, a los usuarios o a la red. Eche un vistazo a 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.

리소스 보기
리소스 보기

Esta vulnerabilidad es más bien un problema humano o de administración que permite que las API antiguas permanezcan en su lugar mucho después de que deberían haber sido reemplazadas por versiones más nuevas y seguras.

더 알고 싶으신가요?

마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.

더 알아보세요

Secure Code Warrior 귀사의 조직이 소프트웨어 개발 라이프사이클 전반에 걸쳐 코드를 보호하고 사이버보안을 최우선으로 하는 문화를 조성하도록 Secure Code Warrior . AppSec 관리자, 개발자, CISO 또는 보안 관련 담당자라면 누구든, 저희는 귀사의 조직이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 돕습니다.

데모 예약하기
공유하기:
링크드인 브랜드사회적x 로고
저자
마티아스 마두, Ph.
게시일: 2020년 12월 22일

마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.

Matias는 15년 이상의 소프트웨어 보안 경험을 가진 연구원이자 개발자입니다. 그는 Fortify 소프트웨어와 같은 회사와 자신의 회사를 위한 솔루션을 개발했습니다. Sensei 안전. 그의 경력을 통해, Matias는 상용 제품으로 주도하고 자신의 벨트 아래 10 개 이상의 특허를 자랑하는 여러 응용 프로그램 보안 연구 프로젝트를 주도하고있다. 마티아스는 책상에서 떨어져 있을 때 고급 응용 프로그램 보안 교육을 위한 강사로 일했습니다. courses RSA 컨퍼런스, 블랙 햇, 데프콘, BSIMM, OWASP AppSec 및 브루콘을 포함한 글로벌 컨퍼런스에서 정기적으로 강연합니다.

마티아스는 겐트 대학교에서 컴퓨터 공학 박사 학위를 취득했으며, 프로그램 난독화를 통해 응용 프로그램 보안을 연구하여 응용 프로그램의 내부 작동을 숨깁니다.

공유하기:
링크드인 브랜드사회적x 로고

A diferencia de la mayoría de las vulnerabilidades de las diez principales API de OWASP, la gestión inadecuada de los activos no se centra específicamente en las fallas de codificación. Por el contrario, esta vulnerabilidad es más bien un problema humano o administrativo que permite que las API antiguas permanezcan en su lugar mucho tiempo después de que deberían haber sido reemplazadas por versiones más nuevas y seguras. También puede ocurrir si las API que aún están en desarrollo quedan expuestas al entorno de producción antes de que estén completamente protegidas contra las amenazas.

Esta vulnerabilidad es particularmente difícil de gestionar debido a la llegada de los microservicios y la computación en nube. En ese entorno, es posible que los nuevos servicios se pongan en marcha rápidamente para satisfacer una necesidad temporal y luego se olviden de ellos y nunca se retiren del mercado. Si las API antiguas se dejan conectadas al entorno de producción, se puede poner en peligro toda la red.

¿Quieres probar un desafío gamificado sobre este error de seguridad? Entra en nuestra arena: [Empieza aquí]

¿Cómo afectan las fallas de administración inadecuada de activos a las API?

La falla en la administración inadecuada de activos es un producto de los tiempos modernos. Las organizaciones que avanzan a la velocidad de los negocios a veces pueden ofrecer cientos o miles de servicios y microservicios todos los días. Con frecuencia, esto se hace de forma rápida y sin necesidad de crear ninguna documentación complementaria ni de ninguna explicación sobre para qué se utilizan las API asociadas, durante cuánto tiempo serán necesarias o su importancia. Esto puede generar rápidamente una expansión de las API que podría volverse incontrolable con el tiempo, especialmente si no existen políticas generales que definan durante cuánto tiempo pueden existir las API.

En ese entorno, es muy posible que algunas API se pierdan, se olviden o nunca se den de baja.

Los usuarios con permiso para crear nuevos servicios fuera del proceso normal también tienen la culpa a veces. Por ejemplo, un grupo de marketing puede crear un servicio para ayudar a respaldar un evento próximo, como el lanzamiento de un producto, y luego no volver a suspenderlo una vez finalizado el evento. Si alguien consulta ese servicio y sus API asociadas más adelante, puede que no sepa por qué existen y, si no hay documentación, podría seguir siendo un misterio. Es posible que no se sientan cómodos eliminando esas API del entorno de producción o incluso actualizándolas a versiones más recientes porque no tienen ni idea de su importancia ni de lo que hacen.

La vulnerabilidad se vuelve peligrosa porque la seguridad de las API en los marcos mejora con el tiempo. Es posible que un investigador descubra una vulnerabilidad o que se añada una seguridad adicional para detener un tipo de ataque cada vez más popular. Las API antiguas pueden seguir siendo vulnerables a esos ataques a menos que se actualicen, por lo que los piratas informáticos suelen buscarlas o utilizar herramientas automatizadas para encontrarlas.

En un ejemplo real proporcionado por OWASP, una empresa actualizó las API que utilizaba para buscar en las bases de datos de usuarios a fin de corregir una falla crítica. Sin embargo, dejaron las API antiguas en su lugar por error.

Un atacante observó que la ubicación de la nueva API era algo así como (api.criticalservice.com/v2). Al reemplazar la URL por (api.criticalservice.com/v1), pudieron usar la API antigua con la vulnerabilidad conocida. En última instancia, esto expuso los registros personales de más de 100 millones de usuarios.

Eliminar las fallas en la administración inadecuada de activos

La única manera de eliminar la falla de administración de activos inadecuada de su entorno es mantener un inventario ajustado de todas las API, sus usos y versiones. Esto debe comenzar con un inventario de las API existentes, centrándose en factores como el entorno en el que deben implementarse (por ejemplo, de producción o desarrollo), quién debe tener acceso a ellas en red y, por supuesto, su versión.

Una vez que esté completo, debe implementar un proceso en el que la documentación se añada automáticamente a cualquier API o servicio nuevo que se cree. Esto debe incluir todos los aspectos de la API, incluida la limitación de velocidad, la forma en que gestiona las solicitudes y respuestas, el intercambio de recursos, los puntos finales a los que se puede conectar, las políticas pertinentes que se apliquen y cualquier otra cosa que sea necesaria para auditarlas posteriormente. También debes evitar utilizar en producción las API que no sean de producción o las del entorno de desarrollo. Considera también la posibilidad de añadir un límite de tiempo a las API cuando sus propietarios deban justificar su uso continuo para evitar el desmantelamiento automático.

Siempre que haya nuevas versiones de las API activas disponibles, realice una evaluación de riesgos para determinar si debe actualizarse y cómo debe llevarse a cabo ese proceso para evitar interrumpir el entorno de producción. Una vez que haya migrado a las nuevas API, elimine completamente las antiguas del entorno.

Hacer todo esto puede ayudar a evitar que la vulnerabilidad de la administración inadecuada de activos perjudique a su organización, a los usuarios o a la red. Eche un vistazo a 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.

리소스 보기
리소스 보기

다음 양식을 작성하여 보고서를 다운로드하십시오.

귀하의 허락을 받아 당사 제품 또는 안전한 암호화 관련 주제에 대한 정보를 보내드리고자 합니다. 귀하의 개인정보는 항상 최대한 신중하게 처리하며, 마케팅 목적으로 타사에 판매하지 않을 것을 약속드립니다.

보내기
scw 성공 아이콘
scw 오류 아이콘
양식을 보내려면 '분석' 쿠키를 활성화하세요. 완료 후에는 언제든지 다시 비활성화해도 됩니다.

A diferencia de la mayoría de las vulnerabilidades de las diez principales API de OWASP, la gestión inadecuada de los activos no se centra específicamente en las fallas de codificación. Por el contrario, esta vulnerabilidad es más bien un problema humano o administrativo que permite que las API antiguas permanezcan en su lugar mucho tiempo después de que deberían haber sido reemplazadas por versiones más nuevas y seguras. También puede ocurrir si las API que aún están en desarrollo quedan expuestas al entorno de producción antes de que estén completamente protegidas contra las amenazas.

Esta vulnerabilidad es particularmente difícil de gestionar debido a la llegada de los microservicios y la computación en nube. En ese entorno, es posible que los nuevos servicios se pongan en marcha rápidamente para satisfacer una necesidad temporal y luego se olviden de ellos y nunca se retiren del mercado. Si las API antiguas se dejan conectadas al entorno de producción, se puede poner en peligro toda la red.

¿Quieres probar un desafío gamificado sobre este error de seguridad? Entra en nuestra arena: [Empieza aquí]

¿Cómo afectan las fallas de administración inadecuada de activos a las API?

La falla en la administración inadecuada de activos es un producto de los tiempos modernos. Las organizaciones que avanzan a la velocidad de los negocios a veces pueden ofrecer cientos o miles de servicios y microservicios todos los días. Con frecuencia, esto se hace de forma rápida y sin necesidad de crear ninguna documentación complementaria ni de ninguna explicación sobre para qué se utilizan las API asociadas, durante cuánto tiempo serán necesarias o su importancia. Esto puede generar rápidamente una expansión de las API que podría volverse incontrolable con el tiempo, especialmente si no existen políticas generales que definan durante cuánto tiempo pueden existir las API.

En ese entorno, es muy posible que algunas API se pierdan, se olviden o nunca se den de baja.

Los usuarios con permiso para crear nuevos servicios fuera del proceso normal también tienen la culpa a veces. Por ejemplo, un grupo de marketing puede crear un servicio para ayudar a respaldar un evento próximo, como el lanzamiento de un producto, y luego no volver a suspenderlo una vez finalizado el evento. Si alguien consulta ese servicio y sus API asociadas más adelante, puede que no sepa por qué existen y, si no hay documentación, podría seguir siendo un misterio. Es posible que no se sientan cómodos eliminando esas API del entorno de producción o incluso actualizándolas a versiones más recientes porque no tienen ni idea de su importancia ni de lo que hacen.

La vulnerabilidad se vuelve peligrosa porque la seguridad de las API en los marcos mejora con el tiempo. Es posible que un investigador descubra una vulnerabilidad o que se añada una seguridad adicional para detener un tipo de ataque cada vez más popular. Las API antiguas pueden seguir siendo vulnerables a esos ataques a menos que se actualicen, por lo que los piratas informáticos suelen buscarlas o utilizar herramientas automatizadas para encontrarlas.

En un ejemplo real proporcionado por OWASP, una empresa actualizó las API que utilizaba para buscar en las bases de datos de usuarios a fin de corregir una falla crítica. Sin embargo, dejaron las API antiguas en su lugar por error.

Un atacante observó que la ubicación de la nueva API era algo así como (api.criticalservice.com/v2). Al reemplazar la URL por (api.criticalservice.com/v1), pudieron usar la API antigua con la vulnerabilidad conocida. En última instancia, esto expuso los registros personales de más de 100 millones de usuarios.

Eliminar las fallas en la administración inadecuada de activos

La única manera de eliminar la falla de administración de activos inadecuada de su entorno es mantener un inventario ajustado de todas las API, sus usos y versiones. Esto debe comenzar con un inventario de las API existentes, centrándose en factores como el entorno en el que deben implementarse (por ejemplo, de producción o desarrollo), quién debe tener acceso a ellas en red y, por supuesto, su versión.

Una vez que esté completo, debe implementar un proceso en el que la documentación se añada automáticamente a cualquier API o servicio nuevo que se cree. Esto debe incluir todos los aspectos de la API, incluida la limitación de velocidad, la forma en que gestiona las solicitudes y respuestas, el intercambio de recursos, los puntos finales a los que se puede conectar, las políticas pertinentes que se apliquen y cualquier otra cosa que sea necesaria para auditarlas posteriormente. También debes evitar utilizar en producción las API que no sean de producción o las del entorno de desarrollo. Considera también la posibilidad de añadir un límite de tiempo a las API cuando sus propietarios deban justificar su uso continuo para evitar el desmantelamiento automático.

Siempre que haya nuevas versiones de las API activas disponibles, realice una evaluación de riesgos para determinar si debe actualizarse y cómo debe llevarse a cabo ese proceso para evitar interrumpir el entorno de producción. Una vez que haya migrado a las nuevas API, elimine completamente las antiguas del entorno.

Hacer todo esto puede ayudar a evitar que la vulnerabilidad de la administración inadecuada de activos perjudique a su organización, a los usuarios o a la red. Eche un vistazo a 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.

웹 세미나 보기
시작하다
더 알아보세요

아래 링크를 클릭하고 이 자료의 PDF를 다운로드하세요.

Secure Code Warrior 귀사의 조직이 소프트웨어 개발 라이프사이클 전반에 걸쳐 코드를 보호하고 사이버보안을 최우선으로 하는 문화를 조성하도록 Secure Code Warrior . AppSec 관리자, 개발자, CISO 또는 보안 관련 담당자라면 누구든, 저희는 귀사의 조직이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 돕습니다.

보고서 보기데모 예약하기
리소스 보기
공유하기:
링크드인 브랜드사회적x 로고
더 알고 싶으신가요?

공유하기:
링크드인 브랜드사회적x 로고
저자
마티아스 마두, Ph.
게시일: 2020년 12월 22일

마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.

Matias는 15년 이상의 소프트웨어 보안 경험을 가진 연구원이자 개발자입니다. 그는 Fortify 소프트웨어와 같은 회사와 자신의 회사를 위한 솔루션을 개발했습니다. Sensei 안전. 그의 경력을 통해, Matias는 상용 제품으로 주도하고 자신의 벨트 아래 10 개 이상의 특허를 자랑하는 여러 응용 프로그램 보안 연구 프로젝트를 주도하고있다. 마티아스는 책상에서 떨어져 있을 때 고급 응용 프로그램 보안 교육을 위한 강사로 일했습니다. courses RSA 컨퍼런스, 블랙 햇, 데프콘, BSIMM, OWASP AppSec 및 브루콘을 포함한 글로벌 컨퍼런스에서 정기적으로 강연합니다.

마티아스는 겐트 대학교에서 컴퓨터 공학 박사 학위를 취득했으며, 프로그램 난독화를 통해 응용 프로그램 보안을 연구하여 응용 프로그램의 내부 작동을 숨깁니다.

공유하기:
링크드인 브랜드사회적x 로고

A diferencia de la mayoría de las vulnerabilidades de las diez principales API de OWASP, la gestión inadecuada de los activos no se centra específicamente en las fallas de codificación. Por el contrario, esta vulnerabilidad es más bien un problema humano o administrativo que permite que las API antiguas permanezcan en su lugar mucho tiempo después de que deberían haber sido reemplazadas por versiones más nuevas y seguras. También puede ocurrir si las API que aún están en desarrollo quedan expuestas al entorno de producción antes de que estén completamente protegidas contra las amenazas.

Esta vulnerabilidad es particularmente difícil de gestionar debido a la llegada de los microservicios y la computación en nube. En ese entorno, es posible que los nuevos servicios se pongan en marcha rápidamente para satisfacer una necesidad temporal y luego se olviden de ellos y nunca se retiren del mercado. Si las API antiguas se dejan conectadas al entorno de producción, se puede poner en peligro toda la red.

¿Quieres probar un desafío gamificado sobre este error de seguridad? Entra en nuestra arena: [Empieza aquí]

¿Cómo afectan las fallas de administración inadecuada de activos a las API?

La falla en la administración inadecuada de activos es un producto de los tiempos modernos. Las organizaciones que avanzan a la velocidad de los negocios a veces pueden ofrecer cientos o miles de servicios y microservicios todos los días. Con frecuencia, esto se hace de forma rápida y sin necesidad de crear ninguna documentación complementaria ni de ninguna explicación sobre para qué se utilizan las API asociadas, durante cuánto tiempo serán necesarias o su importancia. Esto puede generar rápidamente una expansión de las API que podría volverse incontrolable con el tiempo, especialmente si no existen políticas generales que definan durante cuánto tiempo pueden existir las API.

En ese entorno, es muy posible que algunas API se pierdan, se olviden o nunca se den de baja.

Los usuarios con permiso para crear nuevos servicios fuera del proceso normal también tienen la culpa a veces. Por ejemplo, un grupo de marketing puede crear un servicio para ayudar a respaldar un evento próximo, como el lanzamiento de un producto, y luego no volver a suspenderlo una vez finalizado el evento. Si alguien consulta ese servicio y sus API asociadas más adelante, puede que no sepa por qué existen y, si no hay documentación, podría seguir siendo un misterio. Es posible que no se sientan cómodos eliminando esas API del entorno de producción o incluso actualizándolas a versiones más recientes porque no tienen ni idea de su importancia ni de lo que hacen.

La vulnerabilidad se vuelve peligrosa porque la seguridad de las API en los marcos mejora con el tiempo. Es posible que un investigador descubra una vulnerabilidad o que se añada una seguridad adicional para detener un tipo de ataque cada vez más popular. Las API antiguas pueden seguir siendo vulnerables a esos ataques a menos que se actualicen, por lo que los piratas informáticos suelen buscarlas o utilizar herramientas automatizadas para encontrarlas.

En un ejemplo real proporcionado por OWASP, una empresa actualizó las API que utilizaba para buscar en las bases de datos de usuarios a fin de corregir una falla crítica. Sin embargo, dejaron las API antiguas en su lugar por error.

Un atacante observó que la ubicación de la nueva API era algo así como (api.criticalservice.com/v2). Al reemplazar la URL por (api.criticalservice.com/v1), pudieron usar la API antigua con la vulnerabilidad conocida. En última instancia, esto expuso los registros personales de más de 100 millones de usuarios.

Eliminar las fallas en la administración inadecuada de activos

La única manera de eliminar la falla de administración de activos inadecuada de su entorno es mantener un inventario ajustado de todas las API, sus usos y versiones. Esto debe comenzar con un inventario de las API existentes, centrándose en factores como el entorno en el que deben implementarse (por ejemplo, de producción o desarrollo), quién debe tener acceso a ellas en red y, por supuesto, su versión.

Una vez que esté completo, debe implementar un proceso en el que la documentación se añada automáticamente a cualquier API o servicio nuevo que se cree. Esto debe incluir todos los aspectos de la API, incluida la limitación de velocidad, la forma en que gestiona las solicitudes y respuestas, el intercambio de recursos, los puntos finales a los que se puede conectar, las políticas pertinentes que se apliquen y cualquier otra cosa que sea necesaria para auditarlas posteriormente. También debes evitar utilizar en producción las API que no sean de producción o las del entorno de desarrollo. Considera también la posibilidad de añadir un límite de tiempo a las API cuando sus propietarios deban justificar su uso continuo para evitar el desmantelamiento automático.

Siempre que haya nuevas versiones de las API activas disponibles, realice una evaluación de riesgos para determinar si debe actualizarse y cómo debe llevarse a cabo ese proceso para evitar interrumpir el entorno de producción. Una vez que haya migrado a las nuevas API, elimine completamente las antiguas del entorno.

Hacer todo esto puede ayudar a evitar que la vulnerabilidad de la administración inadecuada de activos perjudique a su organización, a los usuarios o a la red. Eche un vistazo a 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.

목차

PDF 다운로드
리소스 보기
더 알고 싶으신가요?

마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.

더 알아보세요

Secure Code Warrior 귀사의 조직이 소프트웨어 개발 라이프사이클 전반에 걸쳐 코드를 보호하고 사이버보안을 최우선으로 하는 문화를 조성하도록 Secure Code Warrior . AppSec 관리자, 개발자, CISO 또는 보안 관련 담당자라면 누구든, 저희는 귀사의 조직이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 돕습니다.

데모 예약하기다운로드
공유하기:
링크드인 브랜드사회적x 로고
자원 센터

시작하기 위한 자료

더 많은 게시물
자원 센터

시작하기 위한 자료

더 많은 게시물