COMENTARIO
A medida que las organizaciones recurren a plataformas de código bajo/sin código (LCNC) para agilizar el desarrollo y empoderar a los desarrolladores ciudadanos, los riesgos de seguridad se vuelven cada vez más difíciles de gestionar. Uno de los más desconocidos LCNC La amenaza es la inyección de OData, un vector de ataque que puede exponer datos corporativos confidenciales y prevalece en los sistemas de Microsoft. plataforma de poder. Los profesionales de la seguridad en entornos LCNC, donde faltan las protecciones tradicionales, no comprenden bien esta nueva vulnerabilidad.
¿Qué es OData?
OData, o Protocolo de Datos Abiertos, es un Estándar OASIS que ha ganado terreno en las plataformas LCNC como una forma de gestionar y entregar datos a través de API REST. Se adopta ampliamente porque permite una comunicación fluida entre aplicaciones y fuentes de datos, independientemente del modelo de almacenamiento de datos subyacente. En entornos LCNC, se usa comúnmente como lenguaje de consulta para recuperar datos de diversas fuentes, como bases de datos SQL, SharePoint o Dataverse.
OData es particularmente valioso en las plataformas LCNC debido a su simplicidad: los desarrolladores no necesitan ser expertos en bases de datos para usarlo y el mismo lenguaje de consulta se puede usar para cosas muy diferentes.
La amenaza de la inyección de OData
La inyección de OData manipula la entrada del usuario que luego es utilizada por una aplicación o automatización para formar una consulta de OData. Luego, la consulta se aplica a una fuente de datos comerciales. Esto permite a un atacante obtener acceso no autorizado para manipular o filtrar datos confidenciales de usuarios y empresas.
Mientras Inyección SQL (SQLi) Como lo entienden generalmente los profesionales de la seguridad, la inyección de OData plantea un conjunto diferente de desafíos, particularmente en entornos LCNC, donde múltiples fuentes de datos a menudo están conectadas y administradas por desarrolladores ciudadanos con una formación mínima en seguridad. A diferencia de SQLi, que se limita a bases de datos relacionales, OData puede conectarse a una amplia gama de fuentes de datos, incluidas aplicaciones personalizadas y servicios de terceros, ampliando el impacto potencial de un ataque.
OData también carece de las prácticas de seguridad bien establecidas que se desarrollaron para SQL. Por ejemplo, SQLi generalmente puede mitigarse mediante consultas parametrizadas, una práctica que se ha convertido en estándar a lo largo de los años. La inyección de OData, sin embargo, no ofrece una solución universal similar. Los desarrolladores deben crear mecanismos de validación de entradas personalizados: un proceso manual y propenso a errores. Además, la falta general de conocimiento de las técnicas de inyección de OData reduce aún más la probabilidad de que se implementen métodos de validación personalizados.
Una nueva superficie de ataque externa
Las vulnerabilidades de OData en entornos LCNC a menudo surgen de riesgos no reconocidos asociados con la entrada de datos externos. Con frecuencia, estos se integran en flujos de trabajo que manipulan datos comerciales críticos, incluidos formularios web, correo electrónico, redes sociales y aplicaciones web externas. Estas entradas generalmente se aceptan sin una validación rigurosa, lo que deja la superficie de ataque vulnerable y, a menudo, indefensa, ya que los desarrolladores y los equipos de seguridad pueden pasar por alto estas fuentes como riesgos potenciales.
Esta supervisión permite a los atacantes explotar estas entradas inyectando consultas OData maliciosas. Por ejemplo, se podría aprovechar un formulario simple de comentarios sobre el producto para extraer datos confidenciales o modificar la información almacenada.
Desafíos de seguridad
Porque la mayoría de los desarrolladores ciudadanos no tienen entrenamiento de seguridad y a menudo no están familiarizados con los peligros de aceptar entradas externas no controladas en sus flujos de trabajo, las vulnerabilidades de inyección de OData pueden prosperar sin ser detectadas.
Además, a diferencia de la inyección SQL, validar la entrada del usuario en consultas OData requiere un enfoque más práctico. Los desarrolladores deben limpiar manualmente las entradas, eliminar caracteres dañinos, garantizar el formato correcto y proteger contra técnicas de inyección comunes. Este proceso requiere tiempo, esfuerzo y conocimientos de programación más avanzados de los que carecen la mayoría de los desarrolladores de LCNC.
Además, en los entornos de desarrollo tradicionales, las vulnerabilidades de seguridad a menudo se rastrean y reparan mediante sistemas de tickets o herramientas de gestión de trabajos pendientes como Jira. Este proceso formal no existe en la mayoría de los entornos de desarrollo LCNC, donde los desarrolladores pueden no ser codificadores de tiempo completo y no tienen una forma formalizada de manejar el seguimiento de errores o la gestión de vulnerabilidades.
Mejores prácticas de mitigación
Combatir la inyección de OData requiere una estrategia de seguridad proactiva. Idealmente, los desarrolladores de LCNC deberían estar capacitados sobre los riesgos de las consultas OData y cómo se podrían explotar las entradas externas. Esto no es realista, ya que los desarrolladores ciudadanos no son codificadores a tiempo completo.
En cambio, la automatización puede desempeñar un papel importante en el monitoreo y detección de vulnerabilidades de inyección de OData. Los equipos de seguridad deben implementar herramientas que evalúen continuamente los entornos LCNC en busca de posibles vulnerabilidades, especialmente a medida que se crean nuevas aplicaciones y flujos de trabajo. Esto identificará rápidamente las debilidades y brindará rápidamente a los desarrolladores información útil sobre cómo solucionarlas.
La colaboración entre los equipos de seguridad y los desarrolladores de LCNC es otra pieza esencial del rompecabezas. Los equipos de seguridad necesitan acceso para monitorear el proceso de desarrollo en tiempo real, especialmente en entornos donde se procesan datos comerciales críticos. Cuando se identifican vulnerabilidades, el personal de seguridad debe comunicarse claramente con los desarrolladores, ofreciendo orientación específica sobre cómo resolver los problemas. Esto podría incluir mejores prácticas para la validación y saneamiento de insumos, así como herramientas para automatizar el proceso cuando sea posible.
Finalmente, la seguridad debe integrarse en el ciclo de vida de desarrollo de LCNC. Al igual que el “desplazamiento a la izquierda“En el desarrollo de software tradicional, los controles de seguridad deben integrarse en el flujo de trabajo de LCNC desde el principio. Se pueden aprovechar las herramientas de prueba automatizadas para buscar vulnerabilidades a medida que se crean las aplicaciones, lo que reduce la probabilidad de que las vulnerabilidades de inyección de OData pasen desapercibidas.
A medida que la adopción de LCNC continúa creciendo, también lo hace la complejidad de las amenazas que enfrentan las organizaciones. Abordar de inmediato las vulnerabilidades de LCNC, como la inyección de OData, ayudará a mantener las empresas seguras a largo plazo.