Las pautas de seguridad incluidas a continuación están destinadas a ayudarlo a realizar de forma segura las acciones de usuario más comunes, como autenticación, transferencia de archivos, etc. dentro de la plataforma Mmasivo y a través de las API de Mmasivo.

Seguridad de la cuenta

Una vez que cree una cuenta de Mmasivo, utilizará su nombre de usuario y contraseña para iniciar sesión en la cuenta de Mmasivo (también conocida como interfaz web de Mmasivo). Tenga en cuenta que su nombre de usuario no puede contener caracteres especiales y no se puede cambiar una vez generado.

Gestión de contraseñas

La seguridad de la contraseña de Mmasivo está configurada de forma predeterminada en muy segura. Los requisitos generales de contraseña son:

• Letra minúscula
• Letra mayúscula
• Número
• 10 a 50 caracteres
• Símbolo
• No más de 3 caracteres repetidos
• Caracteres permitidos de la A a la Z, de la a a la z, del 0 al 9 y símbolos

Siga estos importantes consejos sobre contraseñas para ayudar a proteger su cuenta:

• No utilice la misma contraseña para diferentes usuarios.
• No utilice contraseñas que utilice en otros lugares, especialmente para otros canales/servicios en línea.
• Cambie las contraseñas periódicamente, al menos trimestralmente.
• Nunca comparta sus contraseñas o claves API con terceros, incluido el personal de Mmasivo . En su lugar, utilice el formulario de restablecimiento de contraseña de la interfaz web de Mmasivo o administre las claves API a través de la interfaz adecuada.

Usuarios de cuenta

A continuación se explica cómo administrar las credenciales de usuario de la cuenta para máxima seguridad:

1. Dentro de la interfaz web de Mmasivo , navegue hasta Configuración → Usuario y equipos .
   • Deje al usuario administrador con la función de administrador de cuentas y elimine todas las funciones que permitan la difusión del tráfico. Para otros usuarios, elimine la función de Administrador de cuentas y asigne funciones para la difusión del tráfico.
   • Verificar el GSM y la dirección de correo electrónico del usuario.
2. Vaya a Configuración → Mi cuenta .  Utilice la siguiente lista como referencia y visite el tema Configuración de seguridad para obtener más detalles sobre cómo configurar cada configuración.
   • La autenticación de dos factores está habilitada de forma predeterminada, las opciones configurables son «Recordado» o «En cada inicio de sesión». 2FA no impedirá la conectividad API.
   • Configure la duración de la validez de la contraseña.
   • Configure el número máximo de intentos de inicio de sesión.
   • Configura los días de inactividad del usuario.

Seguridad del tráfico

Soporte para TLS

A partir del 5 de julio de 2021, solo admitimos TLS v1.2. El soporte para versiones anteriores ha sido descontinuado. Si está utilizando una versión de TLS inferior a 1.2, no podrá enviar ninguna solicitud a nuestra plataforma. Si no está seguro de qué versión de TLS tiene actualmente o necesita ayuda para actualizar a una nueva versión, comuníquese con [email protected] y estaremos encantados de ayudarle.

Usuarios específicos del punto de entrada

Las credenciales de usuario se pueden utilizar a través de una interfaz web o mediante API. Es importante no mezclar los usuarios de API y los usuarios que interactúan con Mmasivo a través de la conectividad de la interfaz web. Mantenga el usuario para la API (accesible únicamente desde la Lista segura de IP), use el resto de los usuarios para la interfaz web para evitar problemas de conectividad. Los usuarios de API solo deberían poder utilizar la API a través de URL que pertenezcan a la lista segura de IP para evitar problemas de conectividad.

Difusión de tráfico

Si usa la API sobre SMPP, cree un usuario dedicado para transmitir tráfico y use sus credenciales a través de una conexión SSL para transmitir tráfico.

Si utiliza la API a través de HTTP, evite transmitir tráfico con credenciales de usuario. Utilice una clave API en su lugar.

Aumente la seguridad para la conectividad API mediante el uso de una clave API o un tipo de autorización de token, como se sugiere en el tema Crear clave API . Esto es para mitigar el riesgo de interceptación de la transferencia de datos de la red.

Configure una lista segura de direcciones IP permitidas, por IP o por todo el rango de IP en las claves API.

Para hacerlo a través de la interfaz web de Mmasivo, inicie sesión y navegue hasta GESTIONAR CLAVES API . Para hacerlo a través de la API, utilice una solicitud POST API al crear una clave API.

A continuación se muestra un ejemplo de las IP permitidas y los rangos de IP que puede utilizar:

• Lista de IP permitidas: 192.168.1.1;192.168.1.2;192.168.1.3
• Rangos de IP: 192.168.1.0/24

Transmita siempre el tráfico a través de una conexión cifrada, utilice el protocolo SSL.

• Para el punto final SSL SMPP, visite especificación-smpp
• Para el punto final HTTP SSL, visite http-base-url

Lista de IP segura

La lista segura de IP le permite crear listas de direcciones IP confiables o rangos de IP desde los cuales los usuarios humanos o API pueden acceder a la plataforma Mmasivo.

Al utilizar listas seguras de IP, tenga en cuenta las siguientes convenciones y mejores prácticas:

• La lista segura de IP se puede configurar a nivel de usuario o a nivel de clave API:
  • Nivel de usuario
    • Las direcciones IP definidas en la lista segura se reconocerán una vez que un usuario inicie sesión en la interfaz web y una vez que sus credenciales se utilicen para transmitir tráfico.
    • Haga clic aquí para obtener más información sobre cómo agregar direcciones IP o rangos que pueden acceder a nuestros servicios.
  • Nivel de clave API
    • Las direcciones IP definidas en la lista segura se reconocerán una vez que se utilice esa clave API al transmitir tráfico.
    • La lista segura de IP en una clave API se puede configurar a través de la interfaz web ( Administrar claves API ) o al crear una clave API a través de la API .
• La lista segura de IP se puede configurar para una IP específica o para un rango de direcciones IP.
  • API: normalmente utiliza direcciones IP estáticas o rangos de empresa/ISP.
  • Interfaz web: puede originarse a partir de direcciones IP de origen dinámico (por ejemplo, usuarios que trabajan desde casa, se conectan a través de una red móvil o cuando viajan).

Controles de seguridad relacionados con API

Esta sección proporciona información sobre cómo aumentar la seguridad para la conectividad API.

Para mitigar el riesgo de interceptación de la transferencia de datos de la red:

• Nunca utilice una combinación de HTTP y SMS no seguros sobre parámetros de URL debido al alto riesgo de interceptación de la transferencia de datos de la red.
• Nunca utilice la conexión HTTP/SMPP sin cifrar y cambie a lo siguiente:
  • Conexiones cifradas SSL/TLS: esta es la opción preferida debido a una configuración más rápida y un mecanismo de conmutación por error más sólido.
  • una conexión VPN IPsec: esto es menos preferido debido a la necesidad de configuración manual y una gestión de incidentes más compleja en caso de problemas de disponibilidad.Esto proporcionará una ruta de datos cifrada entre su plataforma e Mmasivo.
• Abstenerse de utilizar métodos GET para enviar mensajes

Abuso de contraseña

Para mitigar el riesgo de abuso de contraseña, utilice una clave API con tiempo limitado o un tipo de autorización de token .

Las sesiones de API caducan una hora después del último token exitoso y esta opción no se puede modificar en el nivel de cuenta del cliente.

Las claves API, por otro lado, no tienen sesión y se envían con cada solicitud. Tienen un período de validez que se puede establecer por clave API, después del cual la clave API se considera inválida/caducada.

Para obtener más detalles sobre todo lo anterior, consulte Autenticación y clave API .

Riesgos potenciales si no se implementan controles

Las credenciales se filtran debido a intercepciones de tráfico cuando se utiliza tráfico HTTP/SMPP no cifrado. Esto puede suceder en las siguientes circunstancias:

• Cuando se utiliza HTTP inseguro combinado con una autorización básica (nombre de usuario y contraseña incluidos en el formulario codificado en el encabezado de Autorización), lo que podría haber ocurrido en cualquier nodo entre su red, los ISP y los servicios proxy (si se usan) y la interfaz web de Mmasivo.
• Al aplicar métodos MITM entre la red del cliente y la plataforma Mmasivo.
• Cuando se utiliza en un formato inseguro (texto sin formato) en cualquier tipo de almacenamiento (digital y analógico). Mmasivo almacena las contraseñas de los usuarios en un formato hash unidireccional con privilegios de acceso limitados a unos pocos empleados de confianza; El acceso no se concede a ningún tercero.
• Cuando se utiliza en un formato inseguro (texto sin formato) durante el intercambio/comunicaciones (a través de canales electrónicos, teléfono e incluso discusiones en vivo).
• Cuando no has cambiado tu contraseña en mucho tiempo.

Recomendaciones generales de seguridad

• Utilice siempre contraseñas más largas y complejas, diferenciadas por usuario. Reforzar el almacenamiento y la gestión de credenciales internas para mitigar la posible causa de fuga de datos en el futuro.
• Evite codificar las credenciales de usuario en un repositorio de código público.
• Trate sus tokens como contraseñas y manténgalos en secreto. Cuando trabaje con la API, utilice tokens como variables de entorno en lugar de codificarlos en sus programas.

Para obtener más información, consulte los controles de seguridad relacionados con la API .

Verifique la autenticidad de la página de inicio de sesión para evitar ataques de phishing

Preste mucha atención a la URL y al contenido del sitio:

Consulta Favicon. Los sitios web pueden poner el ícono que quieran en la pestaña.

Mire el nombre del dominio . El nombre de dominio puede ayudar a confirmar que está accediendo a un sitio legítimo de Mmasivo.

Verifique el estado de seguridad del sitio en la barra de direcciones de su navegador.  Para la mayoría de los navegadores, un sitio web seguro  mostrará un icono de candado verde a la izquierda de la URL del sitio web. Puede hacer clic en el icono del candado para verificar los detalles del sitio web (por ejemplo, el tipo de cifrado utilizado). Por ejemplo: 

• Múltiples guiones o símbolos en el nombre de dominio.
• Nombres de dominio que imitan empresas reales (por ejemplo, «inf0bip», «infoblp» o «infob1p»).
• Extensiones de dominio como «.biz» y «.info». Estos sitios tienden a no ser creíbles.
• Tenga en cuenta también que los sitios «.com», si bien no son intrínsecamente poco confiables, son las extensiones de dominio más fáciles de obtener.

Verifique el tipo de conexión del sitio web. El  sitio web de la interfaz web de Mmasivotiene una etiqueta «https» que es más segura y, por lo tanto, más confiable que un sitio que utiliza la designación «http» más común. Esto se debe a que la mayoría de los sitios ilegítimos no se molestarían en pasar por el proceso de certificación de seguridad que haría un sitio https típico.

Mire la ruta del archivo. La interfaz web de Mmasivotiene rutas de archivos sencillas según la parte de la interfaz web que desee visitar. En caso de que tengas dudas relacionadas con algún camino, contacta a nuestro Soporte en  [email protected] .

Evaluar la URL.  La URL de un sitio web consta del tipo de conexión («HTTP» o «HTTPS»), aplicación (p. ej., «portal»), nombre de dominio (p. ej., «Mmasivo»), extensión (.com») y la ruta del archivo ( por ejemplo «/panel de control»). Incluso si ha verificado que la conexión es segura, permanezca atento a las siguientes señales de alerta:

• El Favicon: los sitios web pueden poner el ícono que quieran en la pestaña. 
• Nombre de dominio: forma parte de la URL y es confiable, siempre y cuando sepas lo que estás buscando. 
• Ruta/directorio del archivo: esto es parte de la URL y es confiable, siempre y cuando sepas lo que estás buscando. 
• Área de contenido web: puede ser cualquier cosa que el atacante desee, incluida una parodia muy convincente de un sitio web legítimo de Mmasivo.

Busque inglés entrecortado en el sitio web.  Si nota una gran cantidad de palabras mal escritas (o faltantes), generalmente mala gramática o redacción incómoda, debe cuestionar la autenticidad del sitio. Incluso si el sitio en cuestión es técnicamente legítimo en la medida en que no sea una estafa, cualquier imprecisión en el lenguaje también generará dudas sobre la exactitud de su información, lo que lo convertirá en una mala fuente.

Revisar los detalles del certificado:

La mayoría de los navegadores le permiten ver el certificado haciendo clic en el icono del candado en la barra de direcciones.

Para Firefox: 

1. Haga clic en el icono del candado.
2. Haga clic en Más información .
3. Haga clic en Ver certificado.

Para Safari: 

1. Haga clic en el icono del candado.
2. Haga clic en Ver certificado .

Para cromo: 

1. Haga clic en el menú de 3 puntos > Más herramientas > Herramientas de desarrollador .
2. Haga clic en la pestaña Seguridad y Ver certificado .

-o- 

1. Haga clic en el icono del candado > Certificado .
2. Al hacer clic en Información del certificado , obtendrá toda la información que la CA verificó antes de emitir el certificado.

El certificado de Mmasivo se ve así:

Compartir información confidencial

Esta sección es una guía rápida sobre cómo utilizar y almacenar información confidencial de forma segura. 

Cómo utilizar S-Pass

S-PASS es una  aplicación de Mmasivopara compartir información confidencial con los empleados, clientes y otros terceros de Mmasivo. Tenga en cuenta que  la información compartida solo se puede leer una vez  y luego se borra permanentemente de S-PASS.

Es posible crear y enviar una nota secreta  a un destinatario o  acceder y leer una nota secreta  si ha recibido un token del remitente. En ambos casos, es necesario acceder  a https://s-pass.app/  utilizando un navegador web de su elección (puede verse diferente en diferentes navegadores web).

guardar un secreto

1. Accede a S-PASS . Haga clic  en Escribir una nota secreta  para compartir un secreto con alguien o  Leer una nota secreta  si recibió un token para leer notas secretas.

2. Escribe/pega la nota secreta  que deseas enviar. Selecciona cuánto tiempo deseas que tu nota secreta permanezca almacenada. Se conservará hasta su lectura o hasta que se supere el tiempo de almacenamiento seleccionado. Cuando termine, haga clic en Guardar secreto .

Su nota secreta ahora está almacenada . ¡Copie el token O copie el enlace directo para compartir su secreto del Secreto almacenado! surgir.

leer un secreto

Si tiene un enlace de acceso directo, péguelo en un navegador web y verá el secreto compartido en la sección Secreto. Si tiene un token de acceso , vaya a  https://s-pass.app/ , haga clic en Leer una nota secreta , pegue su token y haga clic en Enviar token .

Transferencia segura de archivos

Usando la interfaz web de Mmasivo, puede definir cómo desea exportar sus informes desde Mmasivo. Los métodos habilitados para este fin son FTP y SFTP.

FTP es un protocolo de transferencia de archivos que proporciona una capacidad básica de transferencia de archivos sin cifrar. Aunque permite tanto el acceso anónimo como las sesiones autenticadas, las credenciales del usuario y la carga de datos se transfieren a través de redes públicas en texto sin cifrar, lo que plantea un ALTO riesgo de acceso no autorizado a datos confidenciales y propagación de malware oculto. Al ser completamente reemplazado por alternativas más seguras (SFTP, FTPS, SCP…), el protocolo FTP SÓLO debe usarse con sistemas extremadamente confiables y aislados o para acceso público con un FTP anónimo, lo cual no es aplicable a ningún caso de uso de Mmasivo.

Recomendamos utilizar SFTP (FTP seguro) . Todo lo que necesita hacer es implementar un servidor SFTP en el lado del cliente y proporcionar parámetros de acceso, ya sea a través de la función EXPORTAR de la interfaz web de Mmasivo o hacia Atención al Cliente.

El proceso de implementación segura  generalmente se adhiere a estos consejos:

• Especifique un puerto no estándar (distinto del 22).
• Lista segura de direcciones IP entrantes (remitentes); para Mmasivo, estos serían 193.105.74.4 y 62.140.31.104 .
• Utilice credenciales dedicadas para CADA usuario cliente (es decir, credenciales dedicadas únicamente para Mmasivo).
• Elija contraseñas largas y complejas (mínimo 12 caracteres).
• Cambie las contraseñas con regularidad (por ejemplo, cada tres meses).

Aparte de las razones de seguridad, el uso de transferencias de datos cifradas es, en muchas industrias en todo el mundo,  un requisito de cumplimiento normativo  incluido en la política de seguridad de las empresas.

Cuando elige la versión insegura del FTP, acepta los riesgos de seguridad relacionados y, al mismo tiempo, Mmasivorenuncia a cualquier responsabilidad que pueda derivarse de dicho uso.

Autorización para realizar actividades de pruebas de seguridad contra los recursos de Mmasivo.

Mmasivo lleva a cabo pruebas de penetración externas periódicas involucrando a empresas externas de renombre y utilizando metodologías de mejores prácticas que abarcan:

• OSSTMM (Manual de metodología de pruebas de seguridad de código abierto),
• OWASP (Proyecto de seguridad de aplicaciones web abiertas),
• Metodologías de auditoría y pruebas de penetración del NIST, incluidas técnicas automatizadas y manuales diseñadas para evaluar la seguridad de nuestros sistemas de destino. 

Mmasivo proporciona informes detallados de estos ejercicios de prueba a sus clientes y socios, previa firma de un acuerdo de confidencialidad y limitados al alcance de los servicios contratados. Nuestros equipos de seguridad están disponibles para cualquier pregunta o discusión sobre el contenido de los informes u otros aspectos de nuestro programa de gestión de vulnerabilidades. El uso de informes y documentación existentes para verificar la seguridad de su cadena de suministro es beneficioso, ya que proporciona niveles de garantía adecuados y al mismo tiempo reduce las cargas operativas y los costos en ambas partes.  

Si estos argumentos no fueran suficientes, se podrían organizar pruebas de penetración o escaneo de vulnerabilidades de nuestro entorno de acuerdo con lo estipulado en los Términos y Condiciones del Servicio  y el contrato de servicio respectivo.

Se requerirá que el cliente/socio acepte compartir los resultados de las pruebas con el equipo de Seguridad Corporativa de Mmasivo.
En caso de que se descubran problemas especialmente graves y/o críticos dentro de los productos o servicios de Mmasivo, el cliente acepta informar sus hallazgos a Mmasivo sin demora alguna. 

Cada  actividad de prueba de seguridad externa debe anunciarse y debe enviarse una solicitud a un representante de Mmasivo (gerente de cuenta/ventas o soporte).

Cada una de estas solicitudes se evaluará con el permiso del cliente/socio actual para realizar la prueba.
Si la solicitud ha sido aprobada,  el  solicitante deberá  cumplir con un conjunto definido de requisitos  con respecto a su participación, documentados en el  Documento de Prueba de Penetración Externa  que será proporcionado por el departamento de Seguridad Corporativa de Mmasivo.

De acuerdo con las disposiciones de la NDA, el  Cliente asume la responsabilidad de proteger la confidencialidad de las vulnerabilidades encontradas. Cualquier información de este tipo, en cualquier forma,  no deberá divulgarse ni compartirse con terceros sin la aprobación previa del departamento de Seguridad Corporativa de Mmasivo. Si el Cliente viola esta cláusula de confidencialidad, Mmasivolo hará responsable según las disposiciones del contrato, y los posibles reclamos de reembolso tomarán en consideración el monto máximo de daños  resultantes de estas actividades no autorizadas.

Si las pruebas de penetración realizadas descubren vulnerabilidades en el sistema de Mmasivo, el departamento de Seguridad Corporativa de Mmasivo evaluará estos hallazgos. Si se marca como necesario para la corrección, la prueba de la corrección de las vulnerabilidades identificadas se proporcionará al tercero solicitante en forma de un informe interno compilado por los expertos en seguridad de aplicaciones dedicados y otros especialistas en seguridad relevantes.

Procesos internos del cliente.

Reforzar el almacenamiento y la gestión de credenciales internas para mitigar un riesgo potencial de fuga de datos internos en el futuro que podría resultar en acceso no autorizado a la plataforma Mmasivo y costos de tráfico.

Para proteger sus contraseñas, considere utilizar una de las herramientas de administración de contraseñas de nivel comercial.

Almacenar credenciales (cómo y cómo no hacerlo)

Si utiliza las API de Mmasivo, debe manejar datos confidenciales como contraseñas, tokens o secretos. Esto puede ser todo un desafío, especialmente si se deben enviar datos confidenciales de un servicio a otro para ejecutar operaciones de servicio.

La necesidad de almacenar datos confidenciales puede ser un caso de uso legítimo y puede ocurrir muchas veces durante la fase de diseño. En los casos en los que no pueda recurrir a métodos seguros para compartir recursos e iniciar operaciones, debe configurar mecanismos de seguridad adicionales que se configuran en capas y aumentan su defensa en profundidad.

Aquí hay un código de escenario de ejemplo donde la autorización está codificada:

public class Mmasivoapp{
 
    public static void main(String... args) {
        OkHttpClient client = new OkHttpClient().newBuilder().build();
        MediaType mediaType = MediaType.parse("application/json");
        RequestBody body = RequestBody.create(mediaType, "{\"messages\":[{\"from\":\"InfoSMS\",\"destinations\":[{\"to\":\"41793026727\"}],\"text\":\"This is a sample message\"}]}");
        Request request = new Request.Builder()
            .url("https://api.masivo.com/sms/2/text/advanced")
            .method("POST", body)
            // The sensitive secret is hardcoded in code below
            .addHeader("Authorization", "App 003026bbc133714df1834b8638bb496e-8f4b3d9a-e931-478d-a994-28a725159ab9")
            .addHeader("Content-Type", "application/json")
            .addHeader("Accept", "application/json")
            .build();
        Response response = client.newCall(request).execute();
        System.out.printf("%s: %d", number, response.code());
    }
}

Este es un escenario que queremos prevenir.

Analicemos algunos de esos mecanismos de seguridad y formas de proteger datos confidenciales.

Utilice el módulo de seguridad de hardware (HSM).

Los módulos de seguridad de hardware son dispositivos físicos especiales, generalmente certificados formalmente como dispositivos FIPS 140-2 nivel 3 a prueba de manipulaciones y diseñados para almacenar y proteger material secreto y realizar operaciones criptográficas de forma segura. La idea detrás de los HSM es almacenar datos o ejecutar operaciones en un entorno más seguro en lugar de en una computadora donde se implementa la aplicación. Hay muchos proveedores diferentes de HSM y la forma en que se utilizan y operan está dentro del alcance de la documentación del proveedor. Este es el mejor enfoque que puede utilizar para manejar datos confidenciales.

Nunca almacene datos confidenciales.

En lugar de almacenar datos confidenciales, inclúyalos en la aplicación cuando se implemente. Haga que la solicitud de la aplicación sea secreta al iniciar. Esto es lo mejor que puede hacer si no puede utilizar HSM ya que su contraseña solo está contenida en la memoria.

Hay otros riesgos asociados con esto. Por ejemplo, extraer contraseñas/claves directamente de la memoria o riesgos de disponibilidad, como el reinicio del servidor, en los casos en que la aplicación se implementa como un servicio. Este método es mucho más seguro que cualquiera de los otros métodos. Todos los demás métodos tienen el mismo riesgo asociado con la extracción de datos confidenciales de la memoria.

A continuación se muestra un ejemplo de cómo podría incorporar esto en una aplicación Spring Boot simple:

@SpringBootApplication
public class Mmasivoapp implements CommandLineRunner {

	private NumberRepository numberRepository;
	private SensitiveData sensitiveData;

	@Autowired
	public App(NumberRepository numberRepository, SensitiveData sensitiveData) {
		this.numberRepository = numberRepository;
		this.sensitiveData = sensitiveData;
	}

	@Override
	public void run(String... args) throws Exception {
		for (String number : numbersRepository.findAll()) {
        	OkHttpClient client = new OkHttpClient().newBuilder().build();
        	MediaType mediaType = MediaType.parse("application/json");
        	RequestBody body = RequestBody.create(mediaType, String.format("{\"messages\":[{\"from\":\"InfoSMS\",\"destinations\":[{\"to\":\"%s\"}],\"text\":\"This is a sample message\"}]}", number));
        	Request request = new Request.Builder()
            	.url("https://api.mmasivo.com/sms/2/text/advanced")
            	.method("POST", body)
				// Authorization is fetched from bean and sensitive data is not stored in code
            	.addHeader("Authorization", data.getAuthorization())
            	.addHeader("Content-Type", "application/json")
           		.addHeader("Accept", "application/json")
            	.build();
        	Response response = client.newCall(request).execute();
			System.out.printf("%s: %d", number, response.code());
		}
    }

    @Bean
    public SensitiveData getSensitiveData() {
		Console console = System.console();
		SensitiveData data = new SensitiveData();
		data.setAuthorization(console.readPassword("Input Mmasivo API authorization: "));
		return data;
    }

    public static void main(String... args) throws IOException {
		SpringApplication.run(MmasivoApp.class, args);
	}
}

¿Almacenar datos confidenciales? Está bien, pero establece capas adicionales.

En caso de que realmente necesite almacenar datos confidenciales, establezca capas de defensa adicionales.

Hay varias opciones aquí:

• Almacene secretos en un almacén cifrado verificado (por ejemplo, almacén de claves) y cargue esos secretos al iniciar la aplicación.
• Cifre secretos y almacene la clave de cifrado de forma segura y de manera que esté restringida solo a un usuario específico en el servicio.
• Almacene secretos en una variable de entorno y obtenga el valor en el código
• Utilice un proceso o servicio independiente que proporcione secretos a la aplicación después de haber sido autenticada.

Aquí hay un código de ejemplo de cómo se pueden recuperar secretos de una variable de entorno:

@SpringBootApplication
public class MmasivoApp implements CommandLineRunner {

	private NumberRepository numberRepository;

	@Autowired
	public App(NumberRepository numberRepository) {
		this.numberRepository = numberRepository;
	}

	@Override
	public void run(String... args) throws Exception {
		for (String number : numbersRepository.findAll()) {
        	OkHttpClient client = new OkHttpClient().newBuilder().build();
        	MediaType mediaType = MediaType.parse("application/json");
        	RequestBody body = RequestBody.create(mediaType, String.format("{\"messages\":[{\"from\":\"InfoSMS\",\"destinations\":[{\"to\":\"%s\"}],\"text\":\"This is a sample message\"}]}", number));
        	Request request = new Request.Builder()
            	.url("https://api.mmasivo.com/sms/2/text/advanced")
            	.method("POST", body)
				// Authorization is fetched from environment variable and sensitive data is not stored in code
            	.addHeader("Authorization", System.getenv("MMASIVO_API_AUTHORIZATION"))
            	.addHeader("Content-Type", "application/json")
           		.addHeader("Accept", "application/json")
            	.build();
        	Response response = client.newCall(request).execute();
			System.out.printf("%s: %d", number, response.code());
		}
    }

    public static void main(String... args) throws IOException {
		SpringApplication.run(MmasivoaPP.class, args);
	}
}

Directrices de seguridad para la prevención del fraude por SMS

Con el gran aumento de los ciberataques en Internet, las aplicaciones web son atacadas de diferentes maneras. Para defenderse eficazmente contra estos ataques, le brindamos pautas de seguridad de aplicaciones web que se pueden implementar desde una perspectiva de los problemas de aplicaciones web más comunes aprovechados en casos de fraude.

Problemas de aplicaciones web aprovechados en casos de fraude

1. Problemas de aplicaciones web aprovechados en casos de fraudeLimitar la frecuencia y cantidad de mensajes SMS a un número específico, para que ninguno de los usuarios pueda hacer un mal uso del servicio o plataforma. Al utilizar este enfoque, evitará el posible spam dirigido a los usuarios finales y el usuario final no agotará potencialmente los recursos. El límite de tasa debe implementarse a nivel de cuenta de usuario.
2. Falta de mecanismos de seguridad en encabezados HTTP y cookiesLos encabezados HTTP deben contener un conjunto de mecanismos de seguridad que puedan proporcionar una capa de seguridad adicional a la aplicación web. Las cookies de aplicaciones deben tener al menos las directivas «Secure» y «HttpOnly». Una opción adicional es incluir SameSite, lo que mitigará el riesgo de fuga de información de origen cruzado.

   Además de proteger las cookies, la aplicación debe usar X-Frame-Options para evitar ataques de clickjacking, X-XSS-Protection para mitigar los ataques XSS, Strict-Transport-Security para indicarle al navegador que use solo HTTPS, etc.

3. Falta autenticación o límite de velocidad en algunos de los puntos finales de la APIEs importante tener una gestión adecuada de los activos de todos los puntos finales de API, ya que algunos de ellos pueden estar en modo de depuración o prueba y la autenticación o el límite de velocidad podrían desactivarse para aquellos que se utilizan con fines de prueba. Esto es común en situaciones en las que desea mantener la compatibilidad con versiones anteriores en múltiples implementaciones de producción, ensayo, internas y de desarrollo.
4. Referencia de objeto directo inseguroLa aplicación debe verificar si el usuario que intentó acceder a un determinado objeto de la base de datos tiene acceso correcto a él. IDOR suele ocurrir cuando el usuario modifica una entrada, por ejemplo, cambiando el ID del objeto en una URL de 10 a 20. El usuario puede acceder al objeto que está vinculado a otro usuario. La aplicación debe evitar la exposición de un identificador real, como un ID, y utilizar un hash en su lugar porque el ID secuencial se puede adivinar fácilmente.
5. Mecanismo CAPTCHA faltante o inseguroUtilice reCAPTCHA o hCAPTCHA para hacer frente a los bots. Tenga en cuenta la existencia de solucionadores CAPTCHA automatizados que se resuelven mediante robots e interacción humana. Considere utilizar algunos de los métodos CAPTCHA no convencionales, como la resolución de acertijos gráficos o preguntas específicas del contexto.
6. Falta el token anti-CSRFSe recomienda utilizar tokens anti-CSRF en todas las solicitudes HTTP confidenciales. Se deben generar tokens CSRF para cada solicitud HTTP, ya que el rango de tiempo para la explotación es más corto en comparación con un token CSRF generado por sesión.
7. Uso de parámetros GET para enviar datos confidenciales a la APIEvite el uso de parámetros GET para enviar datos confidenciales o claves API, ya que la URL se puede almacenar en caché en servidores proxy HTTP, en el historial del navegador o en los registros del servidor web. Utilice el método HTTP POST para enviar datos confidenciales a la API.
8. La aplicación web no filtra ni desinfecta entradas peligrosas como cargas útiles de inyecciónDefina qué tipo de datos podrían usarse en una forma de aplicación web. Validar y escapar de la entrada; por ejemplo, no es necesario aceptar caracteres especiales en un campo de nombre de usuario, ya que solo acepta una cadena alfanumérica, un campo de número de teléfono solo debe usar números, etc.

   En lugar de utilizar la entrada del usuario directamente desde el formulario HTML, utilice procedimientos almacenados o declaraciones preparadas con consultas parametrizadas al interactuar con la base de datos subyacente para minimizar el riesgo de inyecciones de SQL. XSS debe abordarse mediante validación y desinfección de entrada en cada formulario que no tenga selección de entrada como fecha o selección de sí/no, siempre codifique caracteres especiales, como menos de (<) o más de (>).

9. Conexión insegura a través de HTTPEn lugar de utilizar HTTP, cambie a HTTPS, ya que ofrece cifrado del tráfico HTTP y protege contra la interceptación del tráfico. Al utilizar el protocolo HTTP simple, se podría detectar una clave API o credenciales de usuario si un usuario está conectado a un punto de acceso Wi-Fi público o a una red insegura. Evite el uso de SSL 2.0/3.0, desactive TLS 1.0 y use TLS 1.2 y TLS 1.3. Deshabilite los cifrados nulos y anónimos.

   Registro y seguimiento insuficientes

   La aplicación web debe poder producir una cantidad suficiente de registros con el nivel adecuado de integridad en reposo y tránsito. Además, los registros de aplicaciones deben desinfectarse de información confidencial como credenciales en texto sin formato, contenido de mensajes, etc. Esto se aplica especialmente a la autenticación y cualquier acción confidencial, como registro o cambio de contraseña/clave API, acceso denegado o errores de validación de entrada. El registro y la supervisión son requisitos para cualquier análisis forense futuro y examen de las acciones del usuario.