
API on Wheels: un viaje por carretera lleno de vulnerabilidades riesgosas
¿Cuándo fue la última vez que hiciste un viaje por carretera? Dependiendo del lugar del mundo en el que te encuentres, puede que solo sea un regreso reciente a la agenda, pero en realidad, no hay nada mejor que salir por la carretera y cambiar de aires.
A menos que seas una vulnerabilidad de software, por supuesto.
Hemos hablado extensamente sobre los peligros que representan las laxas medidas de ciberseguridad en la industria automotriz, con empresas como Tesla y Jeep ya está trabajando con investigadores de seguridad para encontrar errores explotables que podrían haber provocado problemas de seguridad graves si no se descubrían a tiempo y se solucionaban con prontitud. También hemos hablado de cómo es, en general, la seguridad del software Aún así en el Lejano Oeste. El software está en todas partes, y para muchos dispositivos conectados, vehículos y sus periféricos, las medidas de seguridad necesarias van mucho más allá de la educación y la vigilancia del usuario final.
Las vulnerabilidades de las API se están volviendo especialmente insidiosas, con el tráfico malicioso de API crece más de un 300% solo en los últimos seis meses. Esto es bastante preocupante, dado que los vehículos modernos son esencialmente API sobre ruedas. Están conectados, hablan mucho con otras aplicaciones y podrían quedar atrapados en ataques dirigidos por ser uno de los muchos terminales vulnerables.
Cuando el cargador de tu vehículo eléctrico dice demasiado
Los vehículos conectados han sido objeto de escrutinio por la seguridad de su software, pero ¿qué pasa con sus accesorios? El genial equipo de Pen Test Partners descubrió varias vulnerabilidades a nivel de código en seis marcas de recarga de vehículos eléctricos domésticos, así como en una amplia red pública de carga de vehículos eléctricos.
¿A quién le importa un cargador? ¿Qué puede ganar un agresor? Desafortunadamente, una de las desventajas de que una tecnología avanzada y potente trabaje horas extras para nosotros es que, por lo general, estos dispositivos tienen un caso grave de TMI. Los cargadores de vehículos eléctricos se comunican con las aplicaciones móviles complementarias a través de una API, en un entorno basado en la nube, y todo esto puede ser vulnerable a la explotación si no se codifica y configura de forma segura. Las API, por su diseño, abren las puertas a la comunicación entre aplicaciones y, si estos puntos finales no se configuran con cuidado, se podría compartir una cantidad excesiva de ellas o, lo que es peor, se podría acceder a ellas a través de la puerta trasera de una aplicación vulnerable.
Pen Test Partners descubrió vulnerabilidades extremadamente peligrosas que podrían haber provocado el secuestro de millones de cargadores de vehículos eléctricos, varios casos de problemas de autorización de API que permitían la apropiación de cuentas y el control/acceso remoto a una cuenta, e incluso la posibilidad de interrumpir la red eléctrica mediante el control sincronizado de varios dispositivos eléctricos. Todos estos problemas se solucionaron, pero el hecho de que solo unas pocas líneas de código se interpusieran entre los atacantes y la interrupción total de la funcionalidad básica y la infraestructura de servicios es muy preocupante.
Tampoco es que sea cosa de mentes maestras. Wallbox, por ejemplo, tenía dos referencias directas a objetos (IDOR) inseguras en su API, lo que habría permitido apoderarse de una cuenta en caso de haber sido explotadas. IDOR se clasifica en la categoría de autenticación fallida, que ocupa el puesto número dos en la Las 10 principales vulnerabilidades de la API de OWASP. Es tan común como la suciedad, lo que apunta a una falla en el aprendizaje y la implementación del código de calidad. No podemos seguir conectando dispositivos y aplicaciones sensibles a través de una miríada de vías de comunicación con errores, y las API mal configuradas son precisamente eso.
Trabajar de forma segura con las API de automoción requiere educación y paciencia
Lo frustrante de la seguridad de las API es que se promociona como una nueva ola de desastres de ciberseguridad para tratar de mitigarla, cuando en realidad no es más que un nuevo escenario para los mismos problemas de siempre que hemos visto durante décadas en el desarrollo web. La creación de scripts entre sitios, la inyección, los errores de configuración: ¿le suena familiar?
Los indicadores recientes de organizaciones como el NIST son prometedores y muestran que la seguridad del software está cada vez más regulada y estandarizada. Sin embargo, todavía estamos muy lejos de contar con los expertos necesarios para reducir la cantidad de medidas de protección que se necesitan para hacer frente a la avalancha de código que se escribe todos los días. Los desarrolladores deben aumentar sus conocimientos y responsabilidades en materia de seguridad, y no son ellos los que deben tomar la iniciativa. Si tienes un equipo trabajando en sistemas integrados en aparatos o en APIs que podrían convertir un coche en el juguete de control remoto de una persona, debes asegurarte de que están equipados con lo que necesitan para no introducir vulnerabilidades comunes.
Las diferencias entre una API segura y una vulnerable debido al XSS son mínimas, por ejemplo, pero los desarrolladores deben conocer los matices que diferencian un patrón de codificación deficiente de uno bueno. Además, en las configuraciones de API los procesos de desarrollo perezosos suelen seguir siendo los mismos, ya que muchas de ellas conceden amplios permisos que superan los requisitos mínimos para que puedan realizar las tareas establecidas, lo que abre una mayor superficie de amenaza y un posible robo de datos. Estos factores deben tenerse en cuenta durante la construcción, pero si no se incorporan a las prácticas de desarrollo aceptables, el proceso seguirá siendo un factor de riesgo.
Evitar el nuevo campo de juego de los actores de amenazas
El espectacular aumento del número de API como objetivo de los actores de amenazas demuestra que la atención se está centrando en algo que se percibe fácil de alcanzar... y, en este caso, es un objetivo que podría generar importantes beneficios, además de posibles amenazas para la vida en forma de una posible adquisición de vehículos.
Dejar la seguridad de las API al azar es una forma segura de introducir problemas más adelante, con consecuencias potencialmente devastadoras en el peor de los casos y, en el mejor de los casos, con una reelaboración frustrante y un bajo rendimiento. Debería ser una consideración fundamental como parte del ecosistema de comunicación del software y ocupar un lugar destacado en la lista de los mejores programas de seguridad de su clase. La clave para ello es tratar cada API como si fuera una persona y evaluar qué acceso debería tener. ¿Debería Jim, de Contabilidad, tener acceso a todos los documentos legales confidenciales de toda la empresa? Probablemente no, y por lo general, el control de acceso se determina correctamente en el caso de personal del mundo real. No se puede decir lo mismo de las API, y es importante recordar que son poderosas plataformas de conversación que harán que todo el mundo conozca tus secretos si no están configuradas con los mismos métodos de confianza cero que todos los demás.
La organización debe estar en alerta máxima, y los desarrolladores son los ojos necesarios sobre el terreno para crear un código de calidad que esté libre de la desesperación de estos portales vulnerables. Es hora de darles la oportunidad de crecer y prosperar como ingenieros conscientes de la seguridad, con la mentalidad adecuada para este objetivo y las habilidades prácticas necesarias para tomar las decisiones correctas en las etapas críticas de la creación.


Dejar la seguridad de las API al azar es una forma segura de introducir problemas más adelante, con consecuencias potencialmente devastadoras en el peor de los casos y, en el mejor de los casos, con una reelaboración frustrante y un bajo rendimiento.
Vorstandsvorsitzender, Chairman und Mitbegründer

Secure Code Warrior hier, um Ihrem Unternehmen dabei zu helfen, den Code während des gesamten Lebenszyklus der Softwareentwicklung zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie AppSec-Administrator, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Vorführung buchenVorstandsvorsitzender, Chairman und Mitbegründer
Pieter Danhieux ist ein weltweit anerkannter Sicherheitsexperte mit mehr als 12 Jahren Erfahrung als Sicherheitsberater und 8 Jahren als Principal Instructor für SANS, wo er offensive Techniken lehrt, wie man Organisationen, Systeme und Einzelpersonen auf Sicherheitsschwächen hin untersucht und bewertet. Im Jahr 2016 wurde er als einer der "Coolest Tech People in Australia" (Business Insider) ausgezeichnet, erhielt die Auszeichnung "Cyber Security Professional of the Year" (AISA - Australian Information Security Association) und besitzt die Zertifizierungen GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.


¿Cuándo fue la última vez que hiciste un viaje por carretera? Dependiendo del lugar del mundo en el que te encuentres, puede que solo sea un regreso reciente a la agenda, pero en realidad, no hay nada mejor que salir por la carretera y cambiar de aires.
A menos que seas una vulnerabilidad de software, por supuesto.
Hemos hablado extensamente sobre los peligros que representan las laxas medidas de ciberseguridad en la industria automotriz, con empresas como Tesla y Jeep ya está trabajando con investigadores de seguridad para encontrar errores explotables que podrían haber provocado problemas de seguridad graves si no se descubrían a tiempo y se solucionaban con prontitud. También hemos hablado de cómo es, en general, la seguridad del software Aún así en el Lejano Oeste. El software está en todas partes, y para muchos dispositivos conectados, vehículos y sus periféricos, las medidas de seguridad necesarias van mucho más allá de la educación y la vigilancia del usuario final.
Las vulnerabilidades de las API se están volviendo especialmente insidiosas, con el tráfico malicioso de API crece más de un 300% solo en los últimos seis meses. Esto es bastante preocupante, dado que los vehículos modernos son esencialmente API sobre ruedas. Están conectados, hablan mucho con otras aplicaciones y podrían quedar atrapados en ataques dirigidos por ser uno de los muchos terminales vulnerables.
Cuando el cargador de tu vehículo eléctrico dice demasiado
Los vehículos conectados han sido objeto de escrutinio por la seguridad de su software, pero ¿qué pasa con sus accesorios? El genial equipo de Pen Test Partners descubrió varias vulnerabilidades a nivel de código en seis marcas de recarga de vehículos eléctricos domésticos, así como en una amplia red pública de carga de vehículos eléctricos.
¿A quién le importa un cargador? ¿Qué puede ganar un agresor? Desafortunadamente, una de las desventajas de que una tecnología avanzada y potente trabaje horas extras para nosotros es que, por lo general, estos dispositivos tienen un caso grave de TMI. Los cargadores de vehículos eléctricos se comunican con las aplicaciones móviles complementarias a través de una API, en un entorno basado en la nube, y todo esto puede ser vulnerable a la explotación si no se codifica y configura de forma segura. Las API, por su diseño, abren las puertas a la comunicación entre aplicaciones y, si estos puntos finales no se configuran con cuidado, se podría compartir una cantidad excesiva de ellas o, lo que es peor, se podría acceder a ellas a través de la puerta trasera de una aplicación vulnerable.
Pen Test Partners descubrió vulnerabilidades extremadamente peligrosas que podrían haber provocado el secuestro de millones de cargadores de vehículos eléctricos, varios casos de problemas de autorización de API que permitían la apropiación de cuentas y el control/acceso remoto a una cuenta, e incluso la posibilidad de interrumpir la red eléctrica mediante el control sincronizado de varios dispositivos eléctricos. Todos estos problemas se solucionaron, pero el hecho de que solo unas pocas líneas de código se interpusieran entre los atacantes y la interrupción total de la funcionalidad básica y la infraestructura de servicios es muy preocupante.
Tampoco es que sea cosa de mentes maestras. Wallbox, por ejemplo, tenía dos referencias directas a objetos (IDOR) inseguras en su API, lo que habría permitido apoderarse de una cuenta en caso de haber sido explotadas. IDOR se clasifica en la categoría de autenticación fallida, que ocupa el puesto número dos en la Las 10 principales vulnerabilidades de la API de OWASP. Es tan común como la suciedad, lo que apunta a una falla en el aprendizaje y la implementación del código de calidad. No podemos seguir conectando dispositivos y aplicaciones sensibles a través de una miríada de vías de comunicación con errores, y las API mal configuradas son precisamente eso.
Trabajar de forma segura con las API de automoción requiere educación y paciencia
Lo frustrante de la seguridad de las API es que se promociona como una nueva ola de desastres de ciberseguridad para tratar de mitigarla, cuando en realidad no es más que un nuevo escenario para los mismos problemas de siempre que hemos visto durante décadas en el desarrollo web. La creación de scripts entre sitios, la inyección, los errores de configuración: ¿le suena familiar?
Los indicadores recientes de organizaciones como el NIST son prometedores y muestran que la seguridad del software está cada vez más regulada y estandarizada. Sin embargo, todavía estamos muy lejos de contar con los expertos necesarios para reducir la cantidad de medidas de protección que se necesitan para hacer frente a la avalancha de código que se escribe todos los días. Los desarrolladores deben aumentar sus conocimientos y responsabilidades en materia de seguridad, y no son ellos los que deben tomar la iniciativa. Si tienes un equipo trabajando en sistemas integrados en aparatos o en APIs que podrían convertir un coche en el juguete de control remoto de una persona, debes asegurarte de que están equipados con lo que necesitan para no introducir vulnerabilidades comunes.
Las diferencias entre una API segura y una vulnerable debido al XSS son mínimas, por ejemplo, pero los desarrolladores deben conocer los matices que diferencian un patrón de codificación deficiente de uno bueno. Además, en las configuraciones de API los procesos de desarrollo perezosos suelen seguir siendo los mismos, ya que muchas de ellas conceden amplios permisos que superan los requisitos mínimos para que puedan realizar las tareas establecidas, lo que abre una mayor superficie de amenaza y un posible robo de datos. Estos factores deben tenerse en cuenta durante la construcción, pero si no se incorporan a las prácticas de desarrollo aceptables, el proceso seguirá siendo un factor de riesgo.
Evitar el nuevo campo de juego de los actores de amenazas
El espectacular aumento del número de API como objetivo de los actores de amenazas demuestra que la atención se está centrando en algo que se percibe fácil de alcanzar... y, en este caso, es un objetivo que podría generar importantes beneficios, además de posibles amenazas para la vida en forma de una posible adquisición de vehículos.
Dejar la seguridad de las API al azar es una forma segura de introducir problemas más adelante, con consecuencias potencialmente devastadoras en el peor de los casos y, en el mejor de los casos, con una reelaboración frustrante y un bajo rendimiento. Debería ser una consideración fundamental como parte del ecosistema de comunicación del software y ocupar un lugar destacado en la lista de los mejores programas de seguridad de su clase. La clave para ello es tratar cada API como si fuera una persona y evaluar qué acceso debería tener. ¿Debería Jim, de Contabilidad, tener acceso a todos los documentos legales confidenciales de toda la empresa? Probablemente no, y por lo general, el control de acceso se determina correctamente en el caso de personal del mundo real. No se puede decir lo mismo de las API, y es importante recordar que son poderosas plataformas de conversación que harán que todo el mundo conozca tus secretos si no están configuradas con los mismos métodos de confianza cero que todos los demás.
La organización debe estar en alerta máxima, y los desarrolladores son los ojos necesarios sobre el terreno para crear un código de calidad que esté libre de la desesperación de estos portales vulnerables. Es hora de darles la oportunidad de crecer y prosperar como ingenieros conscientes de la seguridad, con la mentalidad adecuada para este objetivo y las habilidades prácticas necesarias para tomar las decisiones correctas en las etapas críticas de la creación.

¿Cuándo fue la última vez que hiciste un viaje por carretera? Dependiendo del lugar del mundo en el que te encuentres, puede que solo sea un regreso reciente a la agenda, pero en realidad, no hay nada mejor que salir por la carretera y cambiar de aires.
A menos que seas una vulnerabilidad de software, por supuesto.
Hemos hablado extensamente sobre los peligros que representan las laxas medidas de ciberseguridad en la industria automotriz, con empresas como Tesla y Jeep ya está trabajando con investigadores de seguridad para encontrar errores explotables que podrían haber provocado problemas de seguridad graves si no se descubrían a tiempo y se solucionaban con prontitud. También hemos hablado de cómo es, en general, la seguridad del software Aún así en el Lejano Oeste. El software está en todas partes, y para muchos dispositivos conectados, vehículos y sus periféricos, las medidas de seguridad necesarias van mucho más allá de la educación y la vigilancia del usuario final.
Las vulnerabilidades de las API se están volviendo especialmente insidiosas, con el tráfico malicioso de API crece más de un 300% solo en los últimos seis meses. Esto es bastante preocupante, dado que los vehículos modernos son esencialmente API sobre ruedas. Están conectados, hablan mucho con otras aplicaciones y podrían quedar atrapados en ataques dirigidos por ser uno de los muchos terminales vulnerables.
Cuando el cargador de tu vehículo eléctrico dice demasiado
Los vehículos conectados han sido objeto de escrutinio por la seguridad de su software, pero ¿qué pasa con sus accesorios? El genial equipo de Pen Test Partners descubrió varias vulnerabilidades a nivel de código en seis marcas de recarga de vehículos eléctricos domésticos, así como en una amplia red pública de carga de vehículos eléctricos.
¿A quién le importa un cargador? ¿Qué puede ganar un agresor? Desafortunadamente, una de las desventajas de que una tecnología avanzada y potente trabaje horas extras para nosotros es que, por lo general, estos dispositivos tienen un caso grave de TMI. Los cargadores de vehículos eléctricos se comunican con las aplicaciones móviles complementarias a través de una API, en un entorno basado en la nube, y todo esto puede ser vulnerable a la explotación si no se codifica y configura de forma segura. Las API, por su diseño, abren las puertas a la comunicación entre aplicaciones y, si estos puntos finales no se configuran con cuidado, se podría compartir una cantidad excesiva de ellas o, lo que es peor, se podría acceder a ellas a través de la puerta trasera de una aplicación vulnerable.
Pen Test Partners descubrió vulnerabilidades extremadamente peligrosas que podrían haber provocado el secuestro de millones de cargadores de vehículos eléctricos, varios casos de problemas de autorización de API que permitían la apropiación de cuentas y el control/acceso remoto a una cuenta, e incluso la posibilidad de interrumpir la red eléctrica mediante el control sincronizado de varios dispositivos eléctricos. Todos estos problemas se solucionaron, pero el hecho de que solo unas pocas líneas de código se interpusieran entre los atacantes y la interrupción total de la funcionalidad básica y la infraestructura de servicios es muy preocupante.
Tampoco es que sea cosa de mentes maestras. Wallbox, por ejemplo, tenía dos referencias directas a objetos (IDOR) inseguras en su API, lo que habría permitido apoderarse de una cuenta en caso de haber sido explotadas. IDOR se clasifica en la categoría de autenticación fallida, que ocupa el puesto número dos en la Las 10 principales vulnerabilidades de la API de OWASP. Es tan común como la suciedad, lo que apunta a una falla en el aprendizaje y la implementación del código de calidad. No podemos seguir conectando dispositivos y aplicaciones sensibles a través de una miríada de vías de comunicación con errores, y las API mal configuradas son precisamente eso.
Trabajar de forma segura con las API de automoción requiere educación y paciencia
Lo frustrante de la seguridad de las API es que se promociona como una nueva ola de desastres de ciberseguridad para tratar de mitigarla, cuando en realidad no es más que un nuevo escenario para los mismos problemas de siempre que hemos visto durante décadas en el desarrollo web. La creación de scripts entre sitios, la inyección, los errores de configuración: ¿le suena familiar?
Los indicadores recientes de organizaciones como el NIST son prometedores y muestran que la seguridad del software está cada vez más regulada y estandarizada. Sin embargo, todavía estamos muy lejos de contar con los expertos necesarios para reducir la cantidad de medidas de protección que se necesitan para hacer frente a la avalancha de código que se escribe todos los días. Los desarrolladores deben aumentar sus conocimientos y responsabilidades en materia de seguridad, y no son ellos los que deben tomar la iniciativa. Si tienes un equipo trabajando en sistemas integrados en aparatos o en APIs que podrían convertir un coche en el juguete de control remoto de una persona, debes asegurarte de que están equipados con lo que necesitan para no introducir vulnerabilidades comunes.
Las diferencias entre una API segura y una vulnerable debido al XSS son mínimas, por ejemplo, pero los desarrolladores deben conocer los matices que diferencian un patrón de codificación deficiente de uno bueno. Además, en las configuraciones de API los procesos de desarrollo perezosos suelen seguir siendo los mismos, ya que muchas de ellas conceden amplios permisos que superan los requisitos mínimos para que puedan realizar las tareas establecidas, lo que abre una mayor superficie de amenaza y un posible robo de datos. Estos factores deben tenerse en cuenta durante la construcción, pero si no se incorporan a las prácticas de desarrollo aceptables, el proceso seguirá siendo un factor de riesgo.
Evitar el nuevo campo de juego de los actores de amenazas
El espectacular aumento del número de API como objetivo de los actores de amenazas demuestra que la atención se está centrando en algo que se percibe fácil de alcanzar... y, en este caso, es un objetivo que podría generar importantes beneficios, además de posibles amenazas para la vida en forma de una posible adquisición de vehículos.
Dejar la seguridad de las API al azar es una forma segura de introducir problemas más adelante, con consecuencias potencialmente devastadoras en el peor de los casos y, en el mejor de los casos, con una reelaboración frustrante y un bajo rendimiento. Debería ser una consideración fundamental como parte del ecosistema de comunicación del software y ocupar un lugar destacado en la lista de los mejores programas de seguridad de su clase. La clave para ello es tratar cada API como si fuera una persona y evaluar qué acceso debería tener. ¿Debería Jim, de Contabilidad, tener acceso a todos los documentos legales confidenciales de toda la empresa? Probablemente no, y por lo general, el control de acceso se determina correctamente en el caso de personal del mundo real. No se puede decir lo mismo de las API, y es importante recordar que son poderosas plataformas de conversación que harán que todo el mundo conozca tus secretos si no están configuradas con los mismos métodos de confianza cero que todos los demás.
La organización debe estar en alerta máxima, y los desarrolladores son los ojos necesarios sobre el terreno para crear un código de calidad que esté libre de la desesperación de estos portales vulnerables. Es hora de darles la oportunidad de crecer y prosperar como ingenieros conscientes de la seguridad, con la mentalidad adecuada para este objetivo y las habilidades prácticas necesarias para tomar las decisiones correctas en las etapas críticas de la creación.

Klicken Sie auf den untenstehenden Link und laden Sie die PDF-Datei dieser Ressource herunter.
Secure Code Warrior hier, um Ihrem Unternehmen dabei zu helfen, den Code während des gesamten Lebenszyklus der Softwareentwicklung zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie AppSec-Administrator, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht anzeigenEine Vorführung buchenVorstandsvorsitzender, Chairman und Mitbegründer
Pieter Danhieux ist ein weltweit anerkannter Sicherheitsexperte mit mehr als 12 Jahren Erfahrung als Sicherheitsberater und 8 Jahren als Principal Instructor für SANS, wo er offensive Techniken lehrt, wie man Organisationen, Systeme und Einzelpersonen auf Sicherheitsschwächen hin untersucht und bewertet. Im Jahr 2016 wurde er als einer der "Coolest Tech People in Australia" (Business Insider) ausgezeichnet, erhielt die Auszeichnung "Cyber Security Professional of the Year" (AISA - Australian Information Security Association) und besitzt die Zertifizierungen GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.
¿Cuándo fue la última vez que hiciste un viaje por carretera? Dependiendo del lugar del mundo en el que te encuentres, puede que solo sea un regreso reciente a la agenda, pero en realidad, no hay nada mejor que salir por la carretera y cambiar de aires.
A menos que seas una vulnerabilidad de software, por supuesto.
Hemos hablado extensamente sobre los peligros que representan las laxas medidas de ciberseguridad en la industria automotriz, con empresas como Tesla y Jeep ya está trabajando con investigadores de seguridad para encontrar errores explotables que podrían haber provocado problemas de seguridad graves si no se descubrían a tiempo y se solucionaban con prontitud. También hemos hablado de cómo es, en general, la seguridad del software Aún así en el Lejano Oeste. El software está en todas partes, y para muchos dispositivos conectados, vehículos y sus periféricos, las medidas de seguridad necesarias van mucho más allá de la educación y la vigilancia del usuario final.
Las vulnerabilidades de las API se están volviendo especialmente insidiosas, con el tráfico malicioso de API crece más de un 300% solo en los últimos seis meses. Esto es bastante preocupante, dado que los vehículos modernos son esencialmente API sobre ruedas. Están conectados, hablan mucho con otras aplicaciones y podrían quedar atrapados en ataques dirigidos por ser uno de los muchos terminales vulnerables.
Cuando el cargador de tu vehículo eléctrico dice demasiado
Los vehículos conectados han sido objeto de escrutinio por la seguridad de su software, pero ¿qué pasa con sus accesorios? El genial equipo de Pen Test Partners descubrió varias vulnerabilidades a nivel de código en seis marcas de recarga de vehículos eléctricos domésticos, así como en una amplia red pública de carga de vehículos eléctricos.
¿A quién le importa un cargador? ¿Qué puede ganar un agresor? Desafortunadamente, una de las desventajas de que una tecnología avanzada y potente trabaje horas extras para nosotros es que, por lo general, estos dispositivos tienen un caso grave de TMI. Los cargadores de vehículos eléctricos se comunican con las aplicaciones móviles complementarias a través de una API, en un entorno basado en la nube, y todo esto puede ser vulnerable a la explotación si no se codifica y configura de forma segura. Las API, por su diseño, abren las puertas a la comunicación entre aplicaciones y, si estos puntos finales no se configuran con cuidado, se podría compartir una cantidad excesiva de ellas o, lo que es peor, se podría acceder a ellas a través de la puerta trasera de una aplicación vulnerable.
Pen Test Partners descubrió vulnerabilidades extremadamente peligrosas que podrían haber provocado el secuestro de millones de cargadores de vehículos eléctricos, varios casos de problemas de autorización de API que permitían la apropiación de cuentas y el control/acceso remoto a una cuenta, e incluso la posibilidad de interrumpir la red eléctrica mediante el control sincronizado de varios dispositivos eléctricos. Todos estos problemas se solucionaron, pero el hecho de que solo unas pocas líneas de código se interpusieran entre los atacantes y la interrupción total de la funcionalidad básica y la infraestructura de servicios es muy preocupante.
Tampoco es que sea cosa de mentes maestras. Wallbox, por ejemplo, tenía dos referencias directas a objetos (IDOR) inseguras en su API, lo que habría permitido apoderarse de una cuenta en caso de haber sido explotadas. IDOR se clasifica en la categoría de autenticación fallida, que ocupa el puesto número dos en la Las 10 principales vulnerabilidades de la API de OWASP. Es tan común como la suciedad, lo que apunta a una falla en el aprendizaje y la implementación del código de calidad. No podemos seguir conectando dispositivos y aplicaciones sensibles a través de una miríada de vías de comunicación con errores, y las API mal configuradas son precisamente eso.
Trabajar de forma segura con las API de automoción requiere educación y paciencia
Lo frustrante de la seguridad de las API es que se promociona como una nueva ola de desastres de ciberseguridad para tratar de mitigarla, cuando en realidad no es más que un nuevo escenario para los mismos problemas de siempre que hemos visto durante décadas en el desarrollo web. La creación de scripts entre sitios, la inyección, los errores de configuración: ¿le suena familiar?
Los indicadores recientes de organizaciones como el NIST son prometedores y muestran que la seguridad del software está cada vez más regulada y estandarizada. Sin embargo, todavía estamos muy lejos de contar con los expertos necesarios para reducir la cantidad de medidas de protección que se necesitan para hacer frente a la avalancha de código que se escribe todos los días. Los desarrolladores deben aumentar sus conocimientos y responsabilidades en materia de seguridad, y no son ellos los que deben tomar la iniciativa. Si tienes un equipo trabajando en sistemas integrados en aparatos o en APIs que podrían convertir un coche en el juguete de control remoto de una persona, debes asegurarte de que están equipados con lo que necesitan para no introducir vulnerabilidades comunes.
Las diferencias entre una API segura y una vulnerable debido al XSS son mínimas, por ejemplo, pero los desarrolladores deben conocer los matices que diferencian un patrón de codificación deficiente de uno bueno. Además, en las configuraciones de API los procesos de desarrollo perezosos suelen seguir siendo los mismos, ya que muchas de ellas conceden amplios permisos que superan los requisitos mínimos para que puedan realizar las tareas establecidas, lo que abre una mayor superficie de amenaza y un posible robo de datos. Estos factores deben tenerse en cuenta durante la construcción, pero si no se incorporan a las prácticas de desarrollo aceptables, el proceso seguirá siendo un factor de riesgo.
Evitar el nuevo campo de juego de los actores de amenazas
El espectacular aumento del número de API como objetivo de los actores de amenazas demuestra que la atención se está centrando en algo que se percibe fácil de alcanzar... y, en este caso, es un objetivo que podría generar importantes beneficios, además de posibles amenazas para la vida en forma de una posible adquisición de vehículos.
Dejar la seguridad de las API al azar es una forma segura de introducir problemas más adelante, con consecuencias potencialmente devastadoras en el peor de los casos y, en el mejor de los casos, con una reelaboración frustrante y un bajo rendimiento. Debería ser una consideración fundamental como parte del ecosistema de comunicación del software y ocupar un lugar destacado en la lista de los mejores programas de seguridad de su clase. La clave para ello es tratar cada API como si fuera una persona y evaluar qué acceso debería tener. ¿Debería Jim, de Contabilidad, tener acceso a todos los documentos legales confidenciales de toda la empresa? Probablemente no, y por lo general, el control de acceso se determina correctamente en el caso de personal del mundo real. No se puede decir lo mismo de las API, y es importante recordar que son poderosas plataformas de conversación que harán que todo el mundo conozca tus secretos si no están configuradas con los mismos métodos de confianza cero que todos los demás.
La organización debe estar en alerta máxima, y los desarrolladores son los ojos necesarios sobre el terreno para crear un código de calidad que esté libre de la desesperación de estos portales vulnerables. Es hora de darles la oportunidad de crecer y prosperar como ingenieros conscientes de la seguridad, con la mentalidad adecuada para este objetivo y las habilidades prácticas necesarias para tomar las decisiones correctas en las etapas críticas de la creación.
Inhaltsverzeichnis
Vorstandsvorsitzender, Chairman und Mitbegründer

Secure Code Warrior hier, um Ihrem Unternehmen dabei zu helfen, den Code während des gesamten Lebenszyklus der Softwareentwicklung zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie AppSec-Administrator, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Vorführung buchenHerunterladenRessourcen für den Einstieg
Themen und Inhalte der Schulung zum Thema sicherer Code
Unsere branchenführenden Inhalte werden ständig weiterentwickelt, um sich an die sich wandelnde Landschaft der Softwareentwicklung anzupassen und dabei Ihre Rolle zu berücksichtigen. Es werden Themen angeboten, die von KI bis hin zu XQuery-Injektion reichen und sich an verschiedene Positionen richten, von Architekten und Ingenieuren bis hin zu Produktmanagern und Qualitätskontrolleuren. Verschaffen Sie sich einen Überblick über unser Angebot an Inhalten nach Thema und Funktion.
Die Kamer van Koophandel setzt Maßstäbe für entwicklergesteuerte Sicherheit in großem Maßstab
Die Kamer van Koophandel berichtet, wie sie sicheres Codieren durch rollenbasierte Zertifizierungen, Trust Score-Benchmarking und eine Kultur der gemeinsamen Verantwortung für Sicherheit in die tägliche Entwicklungsarbeit integriert hat.
Bedrohungsmodellierung mit KI: So wird jeder Entwickler zum Bedrohungsmodellierer
Sie werden besser gerüstet sein, um Entwicklern dabei zu helfen, Ideen und Techniken zur Bedrohungsmodellierung mit den KI-Tools zu kombinieren, die sie bereits verwenden, um die Sicherheit zu erhöhen, die Zusammenarbeit zu verbessern und von Anfang an widerstandsfähigere Software zu entwickeln.
Ressourcen für den Einstieg
Cybermon ist zurück: Die KI-Missionen von Beat the Boss sind jetzt auf Abruf verfügbar.
Cybermon 2025 Beat the Boss ist jetzt das ganze Jahr über bei SCW verfügbar. Implementieren Sie fortschrittliche KI- und LLM-Sicherheitsherausforderungen, um die sichere Entwicklung von KI in großem Maßstab zu stärken.
Erläuterung des Gesetzes zur Cyberresilienz: Was bedeutet es für die Entwicklung sicherer Software?
Entdecken Sie, was das EU-Gesetz zur Cyberresilienz (CRA) verlangt, für wen es gilt und wie sich Ingenieurteams mit sicheren Designpraktiken, der Vermeidung von Schwachstellen und der Entwicklung von Fähigkeiten für Entwickler darauf vorbereiten können.
SCW feiert sein 11-jähriges Bestehen: eine Lektion in Echtzeit über Anpassungsfähigkeit und kontinuierliche Verbesserung
2025 war ein großartiges Jahr für KI, Cybersicherheit und SCW. Ich gehe mit ruhiger Zuversicht und dem Optimismus, den nur harte und lohnende Arbeit mit sich bringen kann, auf das Jahr 2026 zu.




%20(1).avif)
.avif)
