El final completo son simples 4 letras. Datos curiosos sobre el sexo que nadie te contó antes. Evite la conversión de tipos en PHP
Hola. Mi nombre es Sasha Barannik. En Mail.Ru Group dirijo el departamento de desarrollo web, que consta de 15 empleados. Hemos aprendido a crear sitios web para decenas de millones de usuarios y podemos hacer frente fácilmente a varios millones de audiencias diarias. Yo mismo he estado desarrollando web durante unos 20 años y durante los últimos 15 años he estado programando principalmente en PHP para mi trabajo. Aunque las capacidades del lenguaje y el enfoque de desarrollo han cambiado mucho durante este tiempo, comprender las principales vulnerabilidades y la capacidad de protegerse contra ellas siguen siendo habilidades clave para cualquier desarrollador.
Puede encontrar muchos artículos y guías de seguridad en Internet. Encontré este libro bastante detallado, pero conciso y comprensible. Espero que le ayude a aprender algo nuevo y a hacer que sus sitios sean más confiables y seguros.
P.D. El libro es largo, por lo que la traducción se publicará en varios artículos. Así que comencemos...
¿Otro libro sobre seguridad PHP? Hay muchas formas de empezar un libro sobre seguridad PHP. Desafortunadamente, no he leído ninguno de ellos, así que tendré que descubrirlo mientras escribo. Quizás empezaré por lo más básico y espero que todo salga bien.Si consideramos una aplicación web abstracta lanzada en línea por la Compañía X, podemos suponer que contiene una serie de componentes que, si son pirateados, pueden causar un daño significativo. ¿Cuál, por ejemplo?
Desafortunadamente, los problemas de seguridad a menudo se resuelven después del hecho. Se cree que lo más importante es crear una aplicación funcional que satisfaga las necesidades de los usuarios, dentro de un presupuesto y un plazo aceptables. Es un conjunto de prioridades comprensible, pero la seguridad no puede ignorarse para siempre. Es mucho mejor tenerlo presente constantemente, implementando soluciones específicas durante el desarrollo, cuando el coste de los cambios aún es pequeño.
La naturaleza secundaria de la seguridad es en gran medida el resultado de la cultura de programación. Algunos programadores sudan frío al pensar en una vulnerabilidad, mientras que otros pueden cuestionar la existencia de una vulnerabilidad hasta que puedan demostrar que no es una vulnerabilidad en absoluto. Entre estos dos extremos, hay muchos programadores que simplemente se encogen de hombros porque las cosas todavía no les han ido mal. Les resulta difícil comprender este extraño mundo.
Debido a que la seguridad de las aplicaciones web debe proteger a los usuarios que confían en los servicios de la aplicación, es necesario conocer las respuestas a las siguientes preguntas:
El objetivo de esta paranoia es facilitar la categorización mental de todo lo que interactúa con su aplicación web (“Usuario”, “Hacker”, “Base de datos”, “Entrada no confiable”, “Administrador”, “API REST”). luego asigne a cada categoría un índice de confianza. Obviamente, no se puede confiar en el “Hacker”, pero ¿qué pasa con la “Base de datos”? La “entrada no confiable” recibió su nombre por una razón, pero ¿realmente filtrarías una publicación de blog del feed Atom confiable de tu colega?
Aquellos que se toman en serio el hackeo de aplicaciones web aprenden a aprovechar esta forma de pensar, atacando a menudo fuentes de datos confiables en lugar de aquellas vulnerables, que es menos probable que cuenten con una buena seguridad. No se trata de una decisión aleatoria: en la vida real, los sujetos con un mayor índice de confianza son menos desconfiados. Son estas fuentes de datos a las que primero presto atención cuando analizo una aplicación.
Volvamos a “Bases de datos”. Suponiendo que un hacker pueda obtener acceso a la base de datos (y nosotros, los paranoicos, siempre asumimos esto), nunca se puede confiar en ella. La mayoría de las aplicaciones confían en las bases de datos sin ninguna duda. Desde fuera, la aplicación web parece un todo, pero por dentro es un sistema de componentes individuales que intercambian datos. Si consideramos que todos estos componentes son confiables, si uno de ellos es pirateado, todos los demás se verán rápidamente comprometidos. Estos catastróficos problemas de seguridad no se pueden resolver con la frase “Si la base de datos es pirateada, igual perderemos”. Puedes decirlo, pero no es en absoluto un hecho que tendrás que hacer esto si inicialmente no confías en la base y no actúas en consecuencia.
¿Cómo pueden atacarnos? La respuesta a la segunda pregunta es una lista bastante extensa. Puede ser atacado desde cualquier lugar donde cada componente o capa de una aplicación web reciba datos. Básicamente, las aplicaciones web simplemente procesan datos y los mueven de un lugar a otro. Solicitudes de usuarios, bases de datos, API, fuentes de blogs, formularios, cookies, repositorios, variables de entorno PHP, archivos de configuración, más archivos de configuración e incluso archivos PHP que usted ejecute: todos ellos pueden potencialmente infectarse con datos para violar la seguridad y causar daños. Básicamente, si los datos maliciosos no están presentes explícitamente en el código PHP utilizado para realizar la solicitud, es probable que lleguen como una "carga útil". Esto supone que a) usted escribió el código fuente PHP, b) ha sido revisado adecuadamente por pares yc) no le han pagado organizaciones criminales.Si utiliza fuentes de datos sin verificar que los datos sean completamente seguros y adecuados para su uso, entonces está potencialmente expuesto a ataques. También debe verificar que los datos que recibe coincidan con los datos que envía. Si los datos no se hacen completamente seguros para su salida, usted también tendrá serios problemas. Todo esto se puede expresar como una regla para PHP “Validar entrada; escapar de la salida."
Éstas son fuentes obvias de datos que de alguna manera debemos controlar. Las fuentes también pueden incluir almacenamiento del lado del cliente. Por ejemplo, la mayoría de las aplicaciones reconocen a los usuarios asignándoles ID de sesión únicos, que pueden almacenarse en cookies. Si un atacante obtiene el valor de una cookie, puede hacerse pasar por otro usuario. Aunque podemos mitigar algunos de los riesgos asociados con la interceptación o manipulación de los datos del usuario, no podemos garantizar la seguridad física de la computadora del usuario. Ni siquiera podemos garantizar que los usuarios consideren "123456" la contraseña más estúpida después de "contraseña". Un toque adicional lo aporta el hecho de que hoy en día las cookies no son el único tipo de almacenamiento por parte del usuario.
Otro riesgo que a menudo se pasa por alto es la integridad del código fuente. En PHP, el desarrollo de aplicaciones basado en una gran cantidad de bibliotecas, módulos y paquetes para frameworks débilmente acoplados se está volviendo cada vez más popular. Muchos de ellos se descargan de repositorios públicos como Github y se instalan mediante instaladores de paquetes como Composer y su compañero web Packagist.org. Por lo tanto, la seguridad del código fuente depende completamente de la seguridad de todos estos servicios y componentes de terceros. Si Github se ve comprometido, lo más probable es que se utilice para distribuir código con un aditivo malicioso. Si es Packagist.org, el atacante podrá redirigir las solicitudes de paquetes a sus propios paquetes maliciosos.
Actualmente, Composer y Packagist.org están sujetos a vulnerabilidades conocidas en la detección de dependencias y distribución de paquetes, por lo que siempre verifique todo en su entorno de producción y verifique el origen de todos los paquetes de Packagist.org.
¿Cómo podemos detenerlos? Romper la seguridad de una aplicación web puede ser una tarea ridículamente simple o que requiere mucho tiempo. Es justo suponer que cada aplicación web tiene una vulnerabilidad en alguna parte. La razón es simple: todas las aplicaciones las hacen personas y las personas cometen errores. Así que la seguridad perfecta es una quimera. Todas las aplicaciones pueden contener vulnerabilidades y la tarea de los programadores es minimizar los riesgos.Tendrá que pensar detenidamente para reducir la probabilidad de daños por un ataque a una aplicación web. A medida que avance la historia, hablaré sobre posibles métodos de ataque. Algunas de ellas son obvias, otras no. Pero en cualquier caso, para solucionar el problema es necesario tener en cuenta algunos principios básicos de seguridad.
Principios básicos de seguridad Al desarrollar medidas de seguridad, su eficacia se puede evaluar utilizando las siguientes consideraciones. Ya he citado algunos arriba.Las fuentes especializadas de conocimientos sobre seguridad (centradas en PHP y de otro tipo) generalmente proporcionan conocimientos más detallados. Lo más parecido a una Biblia sobre seguridad de PHP es OWASP, que ofrece artículos, guías y consejos. Si no se recomienda hacer algo en OWASP, ¡nunca lo hagas!
8. Si no ha sido probado, no funciona. Al implementar medidas de seguridad, debes escribir todas las pruebas de funcionamiento necesarias para la verificación. Incluyendo fingir que eres un hacker por el que llora la prisión. Puede parecer descabellado, pero familiarizarse con las técnicas de hacking de aplicaciones web es una buena práctica; aprenderá sobre posibles vulnerabilidades y su paranoia aumentará. Al mismo tiempo, no es necesario contarle a la gerencia su recién adquirida gratitud por piratear una aplicación web. Asegúrese de utilizar herramientas automatizadas para identificar vulnerabilidades. Son útiles, pero, por supuesto, no reemplazan las revisiones de código de alta calidad e incluso las pruebas manuales de la aplicación. Cuantos más recursos gaste en pruebas, más confiable será su aplicación.9. ¡Siempre es tu culpa! Los programadores están acostumbrados a pensar que las vulnerabilidades de seguridad se descubrirán en ataques aislados y sus consecuencias son insignificantes.Por ejemplo, las filtraciones de datos (un tipo de piratería informática bien documentada y generalizada) suelen considerarse problemas de seguridad menores porque no afectan directamente a los usuarios. Sin embargo, la filtración de información sobre versiones de software, lenguajes de desarrollo, ubicaciones del código fuente, lógica empresarial y de aplicaciones, estructura de la base de datos y otros aspectos del entorno y las operaciones internas de una aplicación web suele ser fundamental para un ataque exitoso.
Al mismo tiempo, los ataques a los sistemas de seguridad suelen ser combinaciones de ataques. Individualmente son insignificantes, pero a veces abren el camino a otros ataques. Por ejemplo, la inyección SQL a veces requiere un nombre de usuario específico, que se puede obtener mediante un ataque de sincronización contra la interfaz administrativa, en lugar de la fuerza bruta, mucho más costosa y visible. A su vez, la inyección SQL le permite implementar un ataque XSS en una cuenta administrativa específica sin llamar la atención con una gran cantidad de entradas sospechosas en los registros.
El peligro de considerar las vulnerabilidades de forma aislada es subestimar su amenaza y, por tanto, ser demasiado descuidado con ellas. Los programadores suelen ser perezosos a la hora de corregir una vulnerabilidad porque la consideran demasiado menor. También es una práctica común transferir la responsabilidad del desarrollo seguro a los programadores o usuarios finales, a menudo sin documentar problemas específicos: ni siquiera se reconoce la existencia de estas vulnerabilidades.
La aparente insignificancia no es importante. Es irresponsable obligar a los programadores o usuarios a corregir sus vulnerabilidades, especialmente si ni siquiera estaba informado sobre ellas.
Validación de entrada La validación de entrada es el perímetro de defensa exterior de su aplicación web. Protege la lógica empresarial central, el procesamiento de datos y la generación de resultados. Literalmente, todo lo que esté fuera de este perímetro, excepto el código ejecutado por la solicitud actual, se considera territorio enemigo. Todas las posibles entradas y salidas del perímetro están vigiladas día y noche por centinelas militantes que disparan primero y hacen preguntas después. Los "aliados" vigilados por separado (y de aspecto muy sospechoso) están conectados al perímetro, incluidos el "Modelo", la "Base de datos" y el "Sistema de archivos". Nadie quiere dispararles, pero si prueban suerte... ¡bang! Cada aliado tiene su propio perímetro, que puede confiar o no en el nuestro.¿Recuerdas lo que dije sobre en quién puedes confiar? A nadie ni a nada. En el mundo PHP, el consejo de no confiar en la "entrada del usuario" está en todas partes. Esta es una de las categorías según el grado de confianza. Suponiendo que no se puede confiar en los usuarios, asumimos que se puede confiar en todo lo demás. Esto está mal. Los usuarios son la fuente de información más obvia y poco confiable porque no los conocemos y no podemos controlarlos.
Criterios de validación La validación de los datos de entrada es la protección más obvia y menos confiable de una aplicación web. La gran mayoría de vulnerabilidades se producen por fallos en el sistema de verificación, por lo que es muy importante que esta parte de la protección funcione correctamente. Puede fallar, pero aun así cumpla con las siguientes consideraciones. Tenga siempre en cuenta al implementar validadores personalizados y utilizar bibliotecas de validación de terceros que las soluciones de terceros tienden a realizar tareas genéricas y omitir procedimientos de validación clave que su aplicación pueda necesitar. Cuando utilice bibliotecas destinadas a necesidades de seguridad, asegúrese de verificarlas de forma independiente para detectar vulnerabilidades y su correcto funcionamiento. También recomiendo tener en cuenta que PHP puede presentar un comportamiento extraño y posiblemente inseguro. Mire este ejemplo tomado de funciones de filtrado:Filter_var("php://ejemplo.org", FILTER_VALIDATE_URL);
El filtro pasa sin preguntas. El problema es que la URL php:// recibida puede pasarse a una función PHP que espera recibir una dirección HTTP remota en lugar de devolver datos del script PHP en ejecución (a través del controlador PHP). La vulnerabilidad se produce porque la opción de filtrado no tiene un método para restringir los URI válidos. Aunque la aplicación espera un enlace http, https o mailto y no algún URI específico de PHP. Este enfoque demasiado general de las pruebas debe evitarse a toda costa.
Digamos que recibí datos que contienen un nombre. Puedo comprobar con bastante facilidad si hay apóstrofes, guiones, paréntesis, espacios y una gran cantidad de caracteres alfanuméricos Unicode. El nombre son datos válidos que se pueden utilizar para su visualización (primer uso previsto). Pero si lo usa en otro lugar (por ejemplo, en una consulta de base de datos), terminará en un nuevo contexto. Y algunos de los caracteres que son legales en un nombre resultarán peligrosos en este contexto: si el nombre se convierte en una cadena para realizar una inyección SQL.
Resulta que la verificación de los datos de entrada es inherentemente poco confiable. Es más eficaz para eliminar valores claramente no válidos. Digamos cuando algo necesita ser un número entero, una cadena alfanumérica o una URL HTTP. Estos formatos y valores tienen sus limitaciones y, si se verifican adecuadamente, es menos probable que representen una amenaza. Otros valores (texto ilimitado, matrices GET/POST y HTML) son más difíciles de verificar y es más probable que contengan datos maliciosos.
Dado que la mayor parte del tiempo nuestra aplicación pasará datos entre contextos, no podemos simplemente verificar todos los datos de entrada y dar por terminado el día. El control en la entrada es sólo la primera línea de protección, pero no la única.
Además de comprobar los datos de entrada, a menudo se utiliza un método de protección como el blindaje. Con su ayuda, se verifica la seguridad de los datos al ingresar a cada nuevo contexto. Este método se suele utilizar para proteger contra secuencias de comandos entre sitios (XSS), pero también se utiliza en muchas otras tareas, como herramienta de filtrado.
El escape protege contra malas interpretaciones por parte del destinatario de los datos salientes. Pero esto no es suficiente: a medida que los datos ingresan a un nuevo contexto, se necesita una verificación específica para un contexto específico.
Si bien esto puede percibirse como una duplicación de la validación de entrada inicial, los pasos de validación adicionales en realidad abordan mejor las características específicas del contexto actual cuando los requisitos de datos son muy diferentes. Por ejemplo, los datos provenientes de un formulario pueden contener un número porcentual. La primera vez que lo usamos comprobamos que efectivamente el valor es un número entero. Pero cuando se transfiere a nuestro modelo de aplicación, pueden surgir nuevos requisitos: el valor debe encajar dentro de un cierto rango, que es necesario para que funcione la lógica empresarial de la aplicación. Y si esta comprobación adicional no se realiza en el nuevo contexto, pueden surgir problemas graves.
Utilice sólo listas blancas, no listas negras Las listas negras y las listas blancas son los dos enfoques principales para validar los datos de entrada. El negro significa comprobar si hay datos no válidos y el blanco significa comprobar si hay datos válidos. Las listas blancas son preferibles porque durante la verificación solo se transmiten los datos que esperamos. A su vez, las listas negras sólo tienen en cuenta las suposiciones de los programadores sobre todos los posibles datos erróneos, por lo que es mucho más fácil confundirse, perderse algo o cometer un error.Un buen ejemplo es cualquier procedimiento de validación diseñado para hacer que HTML sea seguro en términos de salida sin escape en la plantilla. Si utilizamos una lista negra, entonces debemos verificar que el HTML no contenga elementos, atributos, estilos ni JavaScript ejecutable peligrosos. Esto supone mucho trabajo y los desinfectantes HTML basados en listas negras siempre consiguen omitir combinaciones de códigos peligrosas. Y las herramientas de listas blancas eliminan esta ambigüedad al permitir solo elementos y atributos permitidos conocidos. Todos los demás simplemente serán separados, aislados o eliminados, independientemente de cuáles sean.
Por lo tanto, las listas blancas son preferibles para cualquier procedimiento de verificación debido a su mayor seguridad y confiabilidad.
Nunca intente corregir los datos de entrada. La verificación de los datos de entrada suele ir acompañada de un filtrado. Si durante la verificación simplemente evaluamos la exactitud de los datos (dando un resultado positivo o negativo), entonces el filtrado cambia los datos que se están verificando para que satisfagan reglas específicas.Esto suele ser algo perjudicial. Los filtros tradicionales incluyen, por ejemplo, eliminar todos los caracteres excepto los números de los números de teléfono (incluidos paréntesis y guiones adicionales) o recortar espacios horizontales o verticales innecesarios. En tales situaciones, se realiza una limpieza mínima para eliminar errores en la visualización o transmisión. Sin embargo, puede dejarse llevar demasiado por el uso de filtros para bloquear datos maliciosos.
Una consecuencia de intentar corregir los datos de entrada es que un atacante puede predecir el impacto de sus correcciones. Digamos que hay algún valor de cadena no válido. Lo buscas, lo borras y terminas de filtrar. ¿Qué pasa si un atacante crea un valor separado por cadena para burlar su filtro?
alerta(documento.cookie);
En este ejemplo, simplemente filtrar por etiqueta no hará nada: eliminar la etiqueta explícita hará que los datos se consideren un elemento completamente válido del script HTML. Lo mismo puede decirse del filtrado por cualquier formato específico. Todo esto muestra claramente por qué comprobar los datos de entrada no debería ser el último bucle de seguridad de la aplicación.
En lugar de intentar corregir la entrada, simplemente utilice un validador basado en lista blanca y rechace dichos intentos de entrada por completo. Y cuando necesites filtrar, filtra siempre antes de realizar la comprobación, nunca después.
Nunca confíe en herramientas de validación externas y supervise constantemente las vulnerabilidades. Señalé anteriormente que la validación es necesaria siempre que los datos se transfieren a un nuevo contexto. Esto también se aplica a la validación realizada fuera de la propia aplicación web. Estos incluyen validación u otras restricciones aplicadas a formularios HTML en el navegador. Mire este formulario de HTML 5 (etiquetas omitidas):Reps. De Irlanda Reino Unido
Los formularios HTML pueden imponer restricciones a los datos ingresados. Puede limitar la selección utilizando una lista de elementos fijos, establecer valores mínimos y máximos y también limitar la longitud del texto. Las posibilidades de HTML 5 son aún más amplias. Los navegadores pueden comprobar URL y direcciones de correo electrónico, y controlar fechas, números y rangos (aunque la compatibilidad con los dos últimos es bastante irregular). Los navegadores también pueden validar la entrada utilizando expresiones regulares de JavaScript incluidas en el atributo de plantilla.
Con todos estos controles disponibles, es importante recordar que su propósito es mejorar la usabilidad de su aplicación. Cualquier atacante puede crear un formulario que no contenga las restricciones del formulario original. ¡Incluso puedes crear un cliente HTTP para completar formularios automáticamente!
Otro ejemplo de herramientas de verificación externa es la recepción de datos de API de terceros, como Twitter. Esta red social tiene buena reputación y suele ser de confianza sin lugar a dudas. Pero como somos paranoicos, ni siquiera deberíamos confiar en Twitter. Si se ven comprometidas, sus respuestas contendrán datos inseguros para los cuales no estaremos preparados. Por eso, incluso aquí, utiliza tu propio control para no quedar indefenso si pasa algo.
Cuando confiamos en las herramientas de verificación externas, es conveniente monitorear las vulnerabilidades. Por ejemplo, si un formulario HTML establece un límite de longitud máxima y recibimos entradas cuyo tamaño ha alcanzado el límite, entonces es lógico suponer que el usuario está intentando eludir la verificación. De esta manera podemos registrar infracciones en herramientas externas y tomar medidas adicionales contra posibles ataques limitando el acceso o el número de solicitudes.
Evite la conversión de tipos en PHP PHP no es un lenguaje fuertemente tipado y la mayoría de sus funciones y operaciones no son seguras para escribir. Esto puede provocar problemas graves. Además, no son los valores en sí los que son especialmente vulnerables, sino los validadores. Por ejemplo:Afirmar(0 == "0ABC"); //devuelve VERDADERO afirmar(0 == "ABC"); //devuelve VERDADERO (¡incluso sin un número al principio!) afirmar(0 === "0ABC"); //devuelve NULL/Da una advertencia sobre la imposibilidad de verificar la declaración
Al diseñar validadores, asegúrese de utilizar comparaciones estrictas y conversión de tipos manual cuando los valores de entrada o salida puedan ser una cadena. Por ejemplo, los formularios pueden devolver una cadena, por lo que si trabaja con datos que deben ser un número entero, asegúrese de verificar su tipo:
Función checkIntegerRange($int, $min, $max) ( if (is_string($int) && !ctype_digit($int)) ( return false; // contiene caracteres que no son dígitos ) if (!is_int((int) $int )) ( return false; // otro valor no entero o mayor PHP_MAX_INT ) return ($int >= $min && $int = $min && $int array("verify_peer" => TRUE))); $cuerpo = file_get_contents("https://api.example.com/search?q=sphinx", false, $contexto);
UPD. En PHP 5.6+, la opción ssl.verify_peer está configurada en TRUE de forma predeterminada.
La extensión cURL incluye el check-out del servidor, por lo que no es necesario configurar nada. Sin embargo, los programadores a veces adoptan un enfoque irreflexivo respecto de la seguridad de sus bibliotecas y aplicaciones. Este enfoque se puede encontrar en cualquier biblioteca de la que dependerá su aplicación.
Curl_setopt(CURLOPT_SSL_VERIFYPEER, falso);
Deshabilitar la verificación del servidor en un contexto SSL o cuando se usa curl_setopt() resultará en vulnerabilidad a ataques de intermediario. Pero está deshabilitado precisamente para solucionar el problema de los molestos errores que indican un ataque o una aplicación que intenta contactar con un host cuyo certificado SSL está configurado incorrectamente o ha caducado.
Las aplicaciones web a menudo pueden actuar como proxy de la actividad del usuario, como un cliente de Twitter. Lo mínimo que podemos hacer es mantener nuestras aplicaciones con los altos estándares establecidos por los navegadores que advierten a los usuarios y tratan de protegerlos para que no se conecten a servidores sospechosos.
Conclusiones A menudo tenemos todas las capacidades para crear una aplicación segura. Pero nosotros mismos eludimos algunas restricciones razonables para facilitar el desarrollo, la depuración y desactivar la aparición de errores molestos. O, por buenas intenciones, intentamos complicar innecesariamente la lógica de la aplicación.Pero los hackers tampoco se comen el pan en vano. Están buscando nuevas formas de eludir nuestras protecciones imperfectas y están estudiando las vulnerabilidades en los módulos y bibliotecas que utilizamos. Y si nuestro objetivo es crear una aplicación web segura, entonces el de ellos es comprometer nuestros servicios y datos. En última instancia, todos trabajamos para mejorar nuestros productos.
¿Necesita determinar el mejor momento para concebir, prevenir un embarazo no deseado o averiguar cuándo será mejor tener relaciones sexuales con su pareja? Antes, las mujeres tenían que acudir al médico para una consulta, pero ahora tienen un nuevo mejor amigo: el teléfono inteligente.
En los últimos años, ha surgido una variedad de aplicaciones para mujeres que facilitan el seguimiento de los días fértiles y los tiempos de ovulación, así como la toma de notas personales. Aparte de esto, tienen muchas otras características. Una de esas aplicaciones es Glow, que ya utilizan 47 millones de mujeres. Glow te permite realizar un seguimiento de cosas como el estado de ánimo de las mujeres y la calidad y frecuencia del sexo. Gracias a esta aplicación es posible obtener estos datos interesantes sobre la vida íntima de mujeres de todo el mundo.
Los mejores países para las mujeres.1. ¿Te falta intimidad? Ve a Canadá. Resulta que las mujeres canadienses tienen relaciones sexuales un 45% más a menudo que los usuarios promedio de aplicaciones.
2. Pero cuidado: Canadá es un gran lugar para quedar embarazada. Las mujeres canadienses pueden quedar embarazadas un 21% más fácilmente que otras.
3. Las mujeres australianas también tienen relaciones sexuales con frecuencia: un 37% más que el promedio de usuarios de aplicaciones.
4. No hace falta decir que las mujeres en Australia también tienen buenas posibilidades de quedar embarazadas. Son un 14% más altos que otros usuarios.
5. Estados Unidos es un buen lugar para ser feliz. Las mujeres estadounidenses tienen un 16% más de probabilidades que otras mujeres de tener relaciones sexuales.
6. ¿El peor lugar para ser feliz? América Latina. Aquí, las mujeres tienen relaciones sexuales un 4% menos que los usuarios promedio de aplicaciones.
1. El apetito sexual de una mujer corresponde a su ciclo mensual. El primer día del ciclo es el primer día de la menstruación, que dura aproximadamente cinco días. Por tanto, las mujeres están menos interesadas en el sexo entre uno y cinco días al mes.
2. Muchas mujeres informan cambios en los niveles de energía o en el estado de ánimo durante este tiempo, y esto suele estar asociado con una disminución del deseo sexual. Las mujeres también están menos interesadas en el sexo durante una semana completa después de su período.
3. La mayoría de las mujeres vuelven a tener relaciones sexuales el día 12 de su ciclo.
4. Muchas mujeres tienen relaciones sexuales regulares entre los 12 y 14 días del ciclo. La aplicación Glow llama a estos días "pico sexy".
5. Las mujeres realmente se sienten más sexys en los días 13 y 14 de su ciclo. Pero aquí está lo interesante: no necesariamente obtienen el mejor y más satisfactorio sexo en este momento.
6. Las mujeres disfrutan más del sexo durante el último día 30 de su ciclo. Este día en Glow se designa como "orgasmos máximos".
1. Las mujeres se sienten más felices los días 15 y 16 de su ciclo, y también si han tenido mucho sexo en los días anteriores.
2. Los usuarios de Glow registraron 7,6 millones de encuentros sexuales en dos años.
3. Esto significa que cada minuto al menos siete mujeres que usan la aplicación Glow tienen relaciones sexuales.
4. Por cierto, los usuarios también informaron sobre la persona que les gusta 2 millones de veces. La aplicación también rastrea los ciclos sexuales y la fertilidad de 88.000 parejas.
5. Lamentablemente, a pesar de los contactos sexuales existentes, no todas las mujeres están satisfechas con ellos. Casi un tercio de las mujeres preferiría renunciar al sexo antes que a un teléfono inteligente.
6. Pero eso todavía significa que dos tercios preferirían dejar sus teléfonos antes que tener sexo.