sábado, 22 de octubre de 2016

Fundamentals: Instalación de Proxychain y Tor en Kali



Autor: @txambe

En el articulo de hoy vamos a ver  cómo instalar, configurar y utilizar Proxychains y Tor en Kali Linux de manera a que nuestra privacidad esté siempre garantizada y podamos que, aunque el servidor nos identifique, poder cambiar nuestra identidad fácilmente pudiendo seguir manteniendo al máximo nuestro anonimato.
Lo primero que debemos hacer es actualizar el sistema con los parches y con las aplicaciones más recientes, para ello abriremos un terminal y teclearemos:
  • sudo apt-get update && sudo apt-get upgrade
Esperaremos a que se actualicen los repositorios y se instalen todas las actualizaciones antes de continuar con este proceso. Una vez actualizado nuestro sistema instalaremos Tor en él desde los mismos repositorios tecleando:

  • sudo apt-get install tor


Cuando finalice la instalación de este módulo iniciamos el servicio :
  • sudo service tor start
Comprobamos que se ha iniciado correctamente con:
  • sudo service tor status

Con Tor ya iniciado vamos a modificar el archivo de configuración de Proxychains, para ello teclearemos:
  • sudo nano /etc/proxychains.conf
En este archivo debemos realizar los siguientes cambios:
  • Des-comentar borrando el # la línea dynamic_chain
  • Comentar con un # la línea strict_chain
  • Añadir al final de archivo: socks5 127.0.0.1 9050


Con estos pasos ya tenemos todo listo. Ya podemos abrir una nueva pestaña de navegación anónima tecleando:
  • proxychains iceweasel www.loquesea.net
Y comprobar desde cual-es-mi-ip.net que la IP que obtenemos no es la misma que tenemos realmente en nuestra conexión, sino que está ofuscada por la red Tor.

A partir de ahora, todo el tráfico que generemos en la ventana del navegador abierta desde el comando anterior mucho cuidado con esto ,será totalmente anónima, pudiendo establecer una conexión directa no anónima desde cualquier otra ventana que abramos manualmente del mismo navegador.

Happy h@cking

sábado, 15 de octubre de 2016

Creando URLs con CSRF implícito

Resultado de imagen de csrf

Autor: Samuel Lopez Saura

CSRF son las siglas de Cross Site Request Forgery. Esto es una técnica a través de la cual un usuario víctima realiza determinadas acciones programadas sin ser consciente de ello.

Imaginémonos el siguiente escenario.

El usuario A es administrador del sitio web empresadeejemplo.com

Dentro de empresadeejemplo.com puede realizar las siguientes acciones.

•  Ver empleados de la empresa
•  Ver  nómina de un empleado
•  Subir sueldo a un empleado
•  Ver mi sueldo
•  Mi historial

El sitio web empresadeejemplo.com tiene un mecanismo de sesiones y solo permite que el usuario admin realice las acciones marcadas en rojo.


Para subir el sueldo de un empleado se encuentra con el siguiente escenario.


El usuario administrador elige un usuario, la cantidad a subir su sueldo y al darle a enviar genera una URL tal que

http://empresadeejemplo.com/admin/subirsueldo.php?usuario=juan_ejemplo_perez&aumento=100

Dentro de la petición HTTP se manda la Cookie de sesión del administrador. La aplicación comprobará que la cookie de sesión es válida y que pertenece a un usuario con privilegios administrativos.

Dentro del código de la aplicación habrá algo parecido a esto:

$usuario = $_REQUEST[‘usuario’];
$aumento = $_REQUEST[‘aumento’];

→ si el usuario al que corresponde la sesión es admin
        subir_sueldo($usuario, $cantidad);
        header(‘Location: /admin’); /* Redirigimos al panel de administración */

→  si el usuario al que corresponde la sesión no es admin
        header(‘Location: /’);  /* Redirigimos a la raíz del sitio */

La aplicación funcionaría y en principio un usuario que no fuera admin no podría realizar la acción.

La pregunta es, ¿qué pasaría si admin hiciera clic en http://empresadeejemplo.com/admin/subirsueldo.php?usuario=juan_ejemplo_perez&aumento=9000 sin ser consciente de ello?

Su navegador realizaría una petición GET  y mandaría su cookie de sesión el servidor comprobaría que realmente es admin quién está realizando la acción y subiría en 9000€ el sueldo al empleado juan ejemplo perez.

Pero ¿cómo va a hacer clic en eso el administrador? Volvamos atrás, cuando hacemos clic emitimos una petición GET al servidor y esta la procesa. Esta petición también la realizamos cuando, por ejemplo, cargamos una imagen. Entonces si el usuario administrador visitara un sitio web que cargase esa URL su navegador emitiría una petición GET al servidor como si el propio administrador conscientemente hiciera la petición.

– Una imagen dice más de mil palabras


Además, ¿y si los datos se pasaran por el método POST en lugar de por el método GET?
Desde PHP podemos recibir parámetros con $_GET, $_POST, $_REQUEST. El primero contiene un array asociativo con los datos mandados por el método GET. El segundo por el método POST y el tercero por cualquiera de los dos métodos.

La utilización de $_REQUEST es una práctica muy común y sin una validación adecuada podemos enviar en un método GET parámetros que el servidor procesaría como si fuera un método POST para un campo que se espera ser recibido solo por POST. Es decir, en una URL podríamos simular un “POST” implícito en ella si al recibir el parámetro lo recibiéramos mediante $_REQUEST.


junto a un método POST los parámetros de usuario y aumento.


Si el documento PHP tuviese en cuenta por donde vienen los datos. Utilizando $_POST o $_GET en lugar de la opción genérica $_REQUEST. Y la acción fuera dada por el método POST habría que simular el envío de un formulario con esos valores al servidor pero el mecanismo sería muy similar a la opción de la imagen con la excepción de que sería un código javascript quién realizase la petición POST o activase el envío de un formulario.

La tarde del miércoles creé una micro aplicación que bajo un fin educativo automatizaba este proceso.



Arriba a la derecha tenemos un botón que pone Nueva URL. Esto levantará una ventana donde podremos poner los parámetros.



Lo que nos genera una URL como la siguiente:

Cuando copiemos la URL y la peguemos en la barra del navegador nos encontraremos con esto:


Lo que está pasando en realidad es lo siguiente:

•  Se accede a http://cj.curiosoinformatico.com, lo primero en cargar es un script que comprueba si tenemos parámetros en la URL que nos indiquen a donde redirigir y donde hacer clic.
•  De tenerlos carga el sitio que hemos escogido para hacer clic como una imagen nada sospechosa y cambia la URL del documento al sitio destino.
•  No obstante como la URL es un poco sospechosa podemos usar un acortador de enlaces como bit.ly para hacerla más confiable.

¡Magia! Esta poderosa URL subirá nuestro sueldo en 9000 euros sin que nadie se entere y le informará a nuestro jefe de un evento donde aprender y mejorar su seguridad. http://bit.ly/2ea3VFM



Nota del autor: Actualmente la página no tiene soporte para peticiones POST -si tiene para GET y para los POST que recoja PHP a través de $_REQUEST (que en realidad se envían como GET)-. Imagino que en un hueco libre que tenga se lo pondré pero si alguien quiere adelantarse aquí dejo el github del mismo.

https://github.com/curiosoinformatico/two_steps_redirector 


******************* ACTUALIZACIÓN *********************

Tras publicar este articulo Vicente Aguilera Diaz se puso en contacto con nosotros y nos indico varios interesantes enlaces de sus publicaciones sobre CSRF y redes sociales, aquí podéis consultarlos:

Caso Facebook: http://www.isecauditors.com/advisories-2011#2011-002

Caso Linkedin: http://seclists.org/fulldisclosure/2013/Mar/216

Caso Gmail: http://www.securiteam.com/securitynews/5ZP010UQKK.html



Muchas gracias Vicente.







jueves, 13 de octubre de 2016

NMAP SCRIPTING ENGINE




Autor : @txambe

En el articulo de hoy vamos a ver una forma distinta de utilizar esta herramienta tan potente como es nmap normalmente utilizada como escaneador de puertos, en esta ocasión la utilizaremos como escaner de vulnerabilidades , no llega a la potencia de Nessus , Openvas , pero en determinados escenarios que no podamos utilizar dichos programas, nmap es un gran aliado a tener en cuenta.

Nmap Scripting Engine ( NSE ) es una de las opciones mas potentes que tiene nmap a parte de su función como escaner de red. Permite escribir scripts para automatizar tareas de red. Esos scripts pueden ser ejecutados en paralelo para así aprovecharse de de la velocidad y eficiencia de nmap.

Con NSE podemos acabar distintas tareas.

·         Auth: Verifica procesos de autenticación.
·         brute: Obtención de información por medio de fuerza bruta.
·         discovery: Recuperación de información de equipos.
·         dos: Relacionados con ataques del tipo DoS.
·         external: Script que utilizan servicios de terceras partes.
·         intrusive: Utiliza scripts que son considerados intrusivos para la víctima o target.
·         safe: ejecuta scripts “seguros” en cuanto a la intrusión de sistemas.
·         vuln: Verifica la existencia de las vulnerabilidades más conocidas.

Para mantener actualizados los scripts debemos ejecutar el comando nmap con –script-updatedb como parámetro.

En /usr/share/nmap/scripts/ (dependiendo el SO que corremos), se encuentran todos los scripts disponibles.

Comentar que los script de nmap están realizados en lenguaje LUA.

Para activar NSE deberemos escribir en la linea de comandos la opción -sC o --script si se quiere indicar un conjunto de scripts. Nmap soporte dos tipos de scripts de tipo servicio y de host..

Los  de tipo servicio relacionan  puertos abiertos ( servicio asociado )  en el objetivo.



Usando NSE

Para iniciar el motor de scripts:

 $nmap -sC 

Para seleccionar un script:

 $nmap –script

Pasar argumentos a los scripts:

   --script-args “http.useragent=0, hhtp.pipeline=15”
   --script-args  http.useragent=CUM,pipeline=10
   --script-args  whois={whodb=”no follow”}


Para realizar una selección  avanzada de scripts:

 nmap -p80 –script “http-*and(not(httpd-brute or http-slowloris))” < objetivo>


Recomendaciones de uso

No usar los dns de tu ISP , mejor usar los de google , por ejemplo:

nmap –dns-servers 8.8.8.8,8.8.4.4


Variar la configuración de tiempo:

nmap T5
Usar el filtro -p si solo interesa el resultado de cierto servicio:

$nmap -p80 –script http-trace 

Si trabajamos con scripts de tipo HTTP , mi recomendación es cambiar el user-agent:

$nmap -p80 –script http-enum 

Debido a la cantidad de argumentos que tiene , es recomendable tener otra consola abierta , en la carpeta donde están los scripts y usar:

c a t < script > | grep @args

O también entrar dentro de la carpeta de los scripts y desde ahí lanzar los scripts.


También una buena fuente de información sobre scripts no aceptados al repositorio oficial:


Enlaces interesantes a scripts no oficiales:

·         vulscan
·         http-google-email
·         http-screenshot

En este punto quería hablaros de una herramienta interesante , NSEarch no es mas que un buscador de scripts la podéis descargar de https://github.com/JKO/nsearch


Una vez descargada la herramienta , solo hay que descomprimir y lanzar su instalador. Cuando ya se encuentra instalada se puede ejecutar con el siguiente comando:

python nsearch.py



En el siguiente enlace podéis encontrar mas información:


Para distinguir entre versiones:

            Para la versión 5:  local http = require “http”

            Para la versión 6:  require “http”


Reglas de ejecución

Todos los scripts tendrán por lo menos una  de las siguientes funciones:

·         prerule()
·         hostrule(host)
·         postrule(host,port)
·         postrule()

Ejemplos de reglas de ejecución

Hay aliases como shortport.http

http = shortport_or_service ({80, 443 , 631 , 7080 , 8080 , 8088 , 5800 , 3872 , 8180 , 8000 }, {“http”,”https”,”ipp”,”http-alt”,”vnc-http”,”oem-agent”})

Una regla para servidores:

posrtrule = shortport.http


Formatos de salida

Nmap soporta distintos formatos de salida de datos XML, greppable ( aunque esta ya en desuso todavia nos puede ser útil en ciertas situaciones )  y normal. Pero solo se guardarán los datos si seleccionamos los formatos XML o normal.

Formato XML

Nmap genera elementos para el escaneo de puertos, detección de servicios y NSE. Anteriormente se guardaba en un elemento llamado ·         EXPOITABLE
·         VULNERABLE
·         NOT_VULN
 
Es muy recomendable asignarlo durante la ejecución:
 
vuln.state = vulns.STAT.VULN
 
Para generar el reporte se utiliza la función vulns.Report.make_output():
 
local report = vulns.Report:new(SCRIPT_NAME,host,port) return report:make_output(vuln_table)
 
 
Referencias:
 
·         https://nmap.org/book/nse.html
·         https://nmap.org/nsedoc/
 
 
Espero que os resulte de interés.
 
 
Happy h@cking.
 

 


-->< script > dentro del atributo ouput.

Al usar la función stdnse.output_table para guardar nuestros datos de salida se auto genera todo el árbol XML.

            Nse:

            local ouput_tab = stdnse.ouput_table()
            ouput_tab.ip = host.ip
            output_tab.hosts = domains

            return output_tab

Reporte de vulnerabilidades

Para realizar un reporte de vulnerabilidades, utilizaremos la librería vulns. La librería tiene una variable que lleva el registro del estado de la vulnerabilidad encontrada:

·         EXPOITABLE
·         VULNERABLE
·         NOT_VULN

Es muy recomendable asignarlo durante la ejecución:

vuln.state = vulns.STAT.VULN

Para generar el reporte se utiliza la función vulns.Report.make_output():

local report = vulns.Report:new(SCRIPT_NAME,host,port) return report:make_output(vuln_table)


Referencias:

·         https://nmap.org/book/nse.html
·         https://nmap.org/nsedoc/


Espero que os resulte de interés.


Happy h@cking.


domingo, 9 de octubre de 2016

Error de GPG al actualizar paquetes en Kali


Autor: @txambe

Esta semana se estrena en nuestro blog @txambe y nos cuenta sus problemas al actualizar Kali Linux, esta fue su experiencia.

Después de actualizar Kali Linux a la última versión  cuando ejecute un apt-get update me daba el error de GPG :
 “ GPG error: http://http.kali.org /kali Release: The following signatures couldn't be verified because  the  public key is not available  “


root@kali:~# aptitude update

Hit http://dl.google.com stable Release.gpg
Hit http://dl.google.com stable Release                                                      
Hit http://dl.google.com stable/main amd64 Packages                                          
Des: 1 http://repo.kali.org kali-bleeding-edge Release.gpg [819 B]                                                                                      
Des: 2 http://repo.kali.org kali-bleeding-edge Release [11,0 kB]
Err http://repo.kali.org kali-bleeding-edge Release                                             
Ign http://dl.google.com stable/main Translation-es_SV         
Ign http://dl.google.com stable/main Translation-es
Ign http://dl.google.com stable/main Translation-en
Des: 3 http://security.kali.org kali/updates Release.gpg [819 B]
Des: 4 http://http.kali.org kali Release.gpg [819 B]
Des: 5 http://security.kali.org kali/updates Release [11,0 kB]
Err http://security.kali.org kali/updates Release             
Des: 6 http://http.kali.org kali Release [21,1 kB]
Err http://http.kali.org kali Release
Descargados 23,6 kB en 3seg. (7.332 B/s)
W: Se produjo un error durante la verificación de las firmas. El repositorio no está actualizado y se utilizarán los ficheros de índice antiguos. El error GPG es: http://repo.kali.org kali-bleeding-edge Release: Las siguientes firms fueron inválidas: KEYEXPIRED 1425567400 KEYEXPIRED 1425567400 KEYEXPIRED 1425567400

W: Se produjo un error durante la verificación de las firmas. El repositorio no está actualizado y se utilizarán los ficheros de índice antiguos. El error GPG es: http://security.kali.org kali/updates Release: Las siguientes firms fueron inválidas: KEYEXPIRED 1425567400 KEYEXPIRED 1425567400 KEYEXPIRED 1425567400

W: Se produjo un error durante la verificación de las firmas. El repositorio no está actualizado y se utilizarán los ficheros de índice antiguos. El error GPG es: http://http.kali.org kali Release: Las siguientes firms fueron inválidas: KEYEXPIRED 1425567400 KEYEXPIRED 1425567400 KEYEXPIRED 1425567400

W: Se produjo un fallo al descargar http://repo.kali.org/kali/dists/kali-bleeding-edge/Release:
W: Se produjo un fallo al descargar http://security.kali.org/kali-security/dists/kali/updates/Release:
W: Se produjo un fallo al descargar http://http.kali.org/kali/dists/kali/Release:
W: Some index files failed to download. They have been ignored, or old ones used instead.


El problema tal como se muestra es que la llave pública GPG ha caducado, así que tenemos que importar la llave nueva que firma y da validez a los repositorios de Kali Linux.


Primero, debemos listar las claves de los repositorios que tenemos en el llavero (key-ring) con el comando apt-key list, por aquí el comando y su resultado:



root@kali:~# apt-key list



/etc/apt/trusted.gpg
--------------------
pub   1024D/7FAC5991 2007-03-08
uid                  Google, Inc. Linux Package Signing Key
sub   2048g/C07CB649 2007-03-08

/etc/apt/trusted.gpg.d//debian-archive-jessie-automatic.gpg
-----------------------------------------------------------
pub   4096R/2B90D010 2014-11-21 [caduca: 2022-11-19]
uid                  Debian Archive Automatic Signing Key (8/jessie)

/etc/apt/trusted.gpg.d//debian-archive-jessie-security-automatic.gpg
--------------------------------------------------------------------
pub   4096R/C857C906 2014-11-21 [caduca: 2022-11-19]
uid                  Debian Security Archive Automatic Signing Key (8/jessie)

/etc/apt/trusted.gpg.d//debian-archive-jessie-stable.gpg
--------------------------------------------------------
pub   4096R/518E17E1 2013-08-17 [caduca: 2021-08-15]
uid                  Jessie Stable Release Key

/etc/apt/trusted.gpg.d//debian-archive-squeeze-automatic.gpg
------------------------------------------------------------
pub   4096R/473041FA 2010-08-27 [caduca: 2018-03-05]
uid                  Debian Archive Automatic Signing Key (6.0/squeeze)

/etc/apt/trusted.gpg.d//debian-archive-squeeze-stable.gpg
---------------------------------------------------------
pub   4096R/B98321F9 2010-08-07 [caduca: 2017-08-05]
uid                  Squeeze Stable Release Key

/etc/apt/trusted.gpg.d//debian-archive-wheezy-automatic.gpg
-----------------------------------------------------------
pub   4096R/46925553 2012-04-27 [caduca: 2020-04-25]
uid                  Debian Archive Automatic Signing Key (7.0/wheezy)

/etc/apt/trusted.gpg.d//debian-archive-wheezy-stable.gpg
--------------------------------------------------------
pub   4096R/65FFB764 2012-05-08 [caduca: 2019-05-07]
uid                  Wheezy Stable Release Key

/etc/apt/trusted.gpg.d//kali-archive-keyring.gpg
------------------------------------------------
pub   4096R/7D8D0BF6 2012-03-05 [caducó: 2015-03-05]
uid                  Kali Linux Repository


Tal como se puede ver la fecha de caducidad, el uid de los repositorios de Kali Linux caducó el 5 de Marzo del año en curso 2015

Así que vamos a solucionar esto con el siguiente comando (más abajo el comando con su resultado):

apt-key adv --keyserver hkp://keys.gnupg.net --recv-keys 7D8D0BF6


root@kali:~# apt-key adv --keyserver hkp://keys.gnupg.net --recv-keys 7D8D0BF6

Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --secret-keyring /tmp/tmp.sYzbsBXbRo --trustdb-name /etc/apt//trustdb.gpg --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg --keyring /etc/apt/trusted.gpg.d//debian-archive-jessie-automatic.gpg --keyring /etc/apt/trusted.gpg.d//debian-archive-jessie-security-automatic.gpg --keyring /etc/apt/trusted.gpg.d//debian-archive-jessie-stable.gpg --keyring /etc/apt/trusted.gpg.d//debian-archive-squeeze-automatic.gpg --keyring /etc/apt/trusted.gpg.d//debian-archive-squeeze-stable.gpg --keyring /etc/apt/trusted.gpg.d//debian-archive-wheezy-automatic.gpg --keyring /etc/apt/trusted.gpg.d//debian-archive-wheezy-stable.gpg --keyring /etc/apt/trusted.gpg.d//kali-archive-keyring.gpg --keyserver hkp://keys.gnupg.net --recv-keys 7D8D0BF6

gpg: solicitando clave 7D8D0BF6 de hkp servidor keys.gnupg.net
gpg: clave 7D8D0BF6: "Kali Linux Repository " 32 firmas nuevas
gpg: no se encuentran claves absolutamente fiables
gpg: Cantidad total procesada: 1
gpg:               nuevas firmas: 32



root@kali:~# apt-key list

/etc/apt/trusted.gpg
--------------------
pub   1024D/7FAC5991 2007-03-08
uid                  Google, Inc. Linux Package Signing Key
sub   2048g/C07CB649 2007-03-08

/etc/apt/trusted.gpg.d//debian-archive-jessie-automatic.gpg
-----------------------------------------------------------
pub   4096R/2B90D010 2014-11-21 [caduca: 2022-11-19]
uid                  Debian Archive Automatic Signing Key (8/jessie)

/etc/apt/trusted.gpg.d//debian-archive-jessie-security-automatic.gpg
--------------------------------------------------------------------
pub   4096R/C857C906 2014-11-21 [caduca: 2022-11-19]
uid                  Debian Security Archive Automatic Signing Key (8/jessie)

/etc/apt/trusted.gpg.d//debian-archive-jessie-stable.gpg
--------------------------------------------------------
pub   4096R/518E17E1 2013-08-17 [caduca: 2021-08-15]
uid                  Jessie Stable Release Key

/etc/apt/trusted.gpg.d//debian-archive-squeeze-automatic.gpg
------------------------------------------------------------
pub   4096R/473041FA 2010-08-27 [caduca: 2018-03-05]
uid                  Debian Archive Automatic Signing Key (6.0/squeeze)

/etc/apt/trusted.gpg.d//debian-archive-squeeze-stable.gpg
---------------------------------------------------------
pub   4096R/B98321F9 2010-08-07 [caduca: 2017-08-05]
uid                  Squeeze Stable Release Key

/etc/apt/trusted.gpg.d//debian-archive-wheezy-automatic.gpg
-----------------------------------------------------------
pub   4096R/46925553 2012-04-27 [caduca: 2020-04-25]
uid                  Debian Archive Automatic Signing Key (7.0/wheezy)

/etc/apt/trusted.gpg.d//debian-archive-wheezy-stable.gpg
--------------------------------------------------------
pub   4096R/65FFB764 2012-05-08 [caduca: 2019-05-07]
uid                  Wheezy Stable Release Key

/etc/apt/trusted.gpg.d//kali-archive-keyring.gpg
------------------------------------------------
pub   4096R/7D8D0BF6 2012-03-05 [caduca: 2018-02-02]
uid                  Kali Linux Repository
sub   4096R/FC0D0DCB 2012-03-05 [caduca: 2018-02-02]


Como se puede ver, el llavero de claves del repositorio de Kali ahora caducará hasta el 2 de Febrero de 2018

Despues de actualizar la clave, ya pude ejecutar apt-get update sin problemas y actualizar la versión de los paquetes con apt-get upgrade


Happy H@cking

domingo, 2 de octubre de 2016

SSL (III): Servidor bien configurado, páginas con problemas


Autor: @RaulRenales

Por último, para terminar esta trilogía de post sobre SSL y su configuración escribo este post con el objetivo de mostrar algunos problemas típicos que suelen pasar en la construcción de las webs alojadas en nuestro servidor habilitado para https.

Básicamente cuando nuestros diseñadores/desarrolladores realizan su trabajo y generan los contenidos de las webs alojadas en los servidores podemos encontrar errores de utilización de referencias http en sus trabajos.

A este problema se le denomina “Errores de contenido mixto” y pueden desembocar en diferentes resultados, como por ejemplo que un recurso sea inaccesible por la codificación, fallos en pasarelas de pago, revelación de usuarios y contraseñas en el tráfico de la web al viajar en texto plano, etc …
Pongamos un ejemplo, Imaginemos que subimos un contenido que utiliza una url externa en http en el campo action de un formulario. Si enviamos este formulario pese a estar en un contexto de navegación https los contenidos enviados son fácilmente reconocibles:


Como podemos ver en la imagen, tenemos un formulario que incluye una llamada http, en Chrome este problema se identifica rápidamente dado que no ofrece “candadito verde” por problemas de contenido mixto, pero en otros navegadores sí que podemos ver el “candadito verde” y tener una cierta sensación de seguridad.

El código del formulario es este:
Como podemos ver se hace la llamada al buscador de una página de libros para realizar directamente la búsqueda desde nuestra web, podría haber sido un login u otra funcionalidad.

Al enviar el formulario podemos ver con ZAP como podemos capturar el texto plano del envió:


Bueno, desde el punto de vista de la seguridad no es gran cosa, no hemos descubierto una nueva vulnerabilidad, pero es muy común encontrarte estos problemas en la vida real y en ocasiones no son tan leves como nuestro ejemplo.

Recientemente he encontrado estos problemas en módulos de terceros utilizados en los más famosos CMS del mercado, en ocasiones incluso en alguna pasarela de pago muy famosa y avalada por uno de los primeros bancos de este país.

Por resumir, el uso de contenido mixto provoca:

  • Perdida de la encriptación del contenido
  • Problemas de accesos a los recursos
  • Falsa sensación de seguridad en el usuario

Bueno, espero que esta trilogía SSL haya sido de vuestro agrado y que os haya permitido tener una visión más amplia sobre HTTPs y SSL.

Como Bonustrack os ofrezco una serie de enlaces interesantes sobre otro problema relativo a la navegación segura, en concreto con el problema de seguimiento HSTS, no quiero desarrollarlo en este post para no hacer otro mastodonte, pero prometo hablar de él más a fondo en el futuro.