Los expertos de Varonis advierten sobre instancias de código Apex inseguras en las implementaciones Fuerza de ventas Muchas empresas han detectado vulnerabilidades graves que ponen en riesgo sus datos y flujos de trabajo. Dicen haber encontrado fallas críticas y de alta gravedad en el código Apex que utilizan varias empresas de Fortune 500 y agencias gubernamentales.
"Si se explotan, estas vulnerabilidades podrían provocar fugas y corrupción de datos e impactar en las funciones comerciales de Salesforce", dijeron los investigadores. En un informet. “Por eso es esencial realizar un seguimiento de las clases de Apex y sus propiedades, quién puede ejecutarlas y cómo se utilizan”.
Clases de Apex insuficientemente restringidas
Apex es un lenguaje de programación orientado a objetos con una sintaxis similar a Java que los desarrolladores pueden utilizar para ejecutar instrucciones de flujo y control en servidores de Salesforce, así como llamadas a través de la API de Salesforce. Apex permite a los usuarios personalizar sus instancias de Salesforce añadiendo lógica empresarial adicional a los eventos del sistema, incluidos los clics en botones, las actualizaciones de registros relacionados y las páginas de Visualforce. “Una clase de Apex es una plantilla o un plano que se utiliza para crear objetos de Apex”, explicaron los expertos. “Las clases incluyen otras clases, métodos definidos por el usuario, variables, excepciones de tipo y código de inicialización estático”. Por tanto, son una herramienta potente para los desarrolladores, pero también es muy importante considerar cuidadosamente sus capacidades y restringir quién puede acceder a ellas.
El código Apex puede funcionar en dos modos: "shared-nothing" y "shared-nothing". En el primer modo, el código Apex ignora los permisos de usuario y puede acceder y modificar cualquier registro, mientras que en el segundo modo, el código respeta los permisos de usuario a nivel de registro pero ignora los permisos a nivel de objeto y campo. Las clases Apex configuradas para funcionar en modo "shared-nothing" a veces son necesarias para implementar una funcionalidad importante, pero pueden representar un riesgo grave, especialmente cuando se ponen a disposición de invitados o usuarios externos. Algunos de los problemas más comunes que pueden surgir de las clases Apex incluyen referencias directas a objetos inseguras (IDOR), donde un atacante puede leer, manipular o eliminar tablas completas de datos a las que no debería tener acceso, o inyección SOQL; e inyección SOSL, donde el código tiene fallas que permiten a los atacantes manipular las solicitudes realizadas por la clase para exfiltrar datos o alterar el flujo de proceso previsto.
Comprobar la llamada a las clases de Apex
Los expertos recomiendan que las empresas comprueben quién puede llamar a las distintas clases de Apex que se utilizan en sus instancias y capacidades, especialmente las clases que funcionan en modo “nada compartido”. Esto se puede hacer manualmente revisando cada clase, pero es un proceso que lleva mucho tiempo. “Determinar quién puede llamar a una clase de Apex requiere comprobar tanto los perfiles como los conjuntos de permisos (desde Winter, si haces clic en “Seguridad” mientras miras la propia clase de Apex, solo puedes ver los perfiles, lo que no es suficiente para determinar quién puede llamar a una clase de Apex)”, advierten los investigadores. La forma correcta de hacerlo es ir primero a la sección “Usuario”, luego a “Perfiles” y marcar la casilla “Acceso a clase de Apex habilitado” en cada perfil. Luego, para cada entrada en la opción “Acceso a clase de Apex habilitado”, el administrador debe desplazarse hacia abajo hasta la sección Aplicaciones y hacer clic en la opción “Acceso a clase de Apex” para ver los permisos. Además, para verificar si una clase Apex está configurada para ejecutarse "no compartida", se puede examinar su código fuente, ya que la cadena "no compartida" se encuentra en una de las primeras líneas de la declaración de la clase.
El informe de Varonis también incluye las mejores prácticas sobre cómo proteger el código Apex para evitar entradas inseguras que puedan dar lugar a inyecciones SOQL o SOSL. Según el modelo de responsabilidad compartida, los clientes de Salesforce, no Salesforce, son responsables de la seguridad de su código Apex. “Una estrategia de seguridad integral debe garantizar que las clases de Apex hayan sido revisadas por especialistas en seguridad, no solo por desarrolladores y administradores de Salesforce”, afirmaron los investigadores. “Este suele ser el caso del código que forma parte de un paquete de AppExchange, pero no siempre es el caso de otro código que no forma parte de AppExchange. Esto es especialmente cierto para el código interno, que a menudo se pasa por alto”.
Otras noticias que te pueden interesar