No SSL: Seguridad de la aplicación web usando el identificador de fragmento html (#)

-4

Actualmente estoy ejecutando mi sitio web en alojamiento compartido, y no puedo registrar TLS / SSL para mi sitio web. Sin embargo, implementé jsencrypt [una biblioteca de Javascript para realizar el cifrado, descifrado y generación de claves RSA de OpenSSL] para cifrar todos los datos de formularios mediante AJAX o POST / GET normal.

Actualmente, tuve un problema con el enlace de restablecimiento de contraseña o algunos otros enlaces importantes que envié al usuario para acciones importantes relacionadas con la cuenta del usuario. Por ejemplo:

example.com/password?resetcode=%CODE%

Pero después de pensar en TLS / SSL, esta URL se puede ver fácilmente usando cualquier herramienta de monitoreo de tráfico, luego, un atacante puede obtener el enlace antes del usuario y restablecer la contraseña.

Una forma de evitar esto es usar fragment identifier ( # ) después de la url como:

example.com/password#code=%CODE%

Luego usa:

<script>
var securykey = "<?php echo $_SESSION['securykey']; ?>";//random secure key
var hash = encrypt(window.location.hash.substring(1)+"|count="+securykey );
window.location = "example.com/password?code=hash"; //hash encryped
</script>

Y luego en el lado del servidor:

<?php
$code = decrypt($hash);
if($_SESSION['securykey'] == $securykey_from_user){
 //its valid 
}
?>

¿La dosis por encima de la técnica es fuerte? y ¿usaremos el identificador de fragmento incluso para TLS / SSL?

ACTUALIZAR :

  1. No utilicé mi cifrado. Lo siento por mencionar AES, no fue AES sino openSSL utilizando JavaScript.
  2. Google también implementó el identificador de fragmento HTML! ejemplo: enlace
  3. jsencrypt: es la biblioteca que utilicé en el lado del cliente. enlace y luego usé PHP openssl para descifrarlo en el lado del servidor.

Demostración del código fuente:

  1. javaScript: enlace
  2. PHP:

    <?php $config = array( "digest_alg" => "sha512", "private_key_bits" => 4096, "private_key_type" => OPENSSL_KEYTYPE_RSA, ); $res = openssl_pkey_new($config); //$privKey = key saved in google cloud and accessed with https using curl openssl_pkey_export($res, $privKey); // Extract the public key from $res to $pubKey $pubKey = openssl_pkey_get_details($res); $pubKey = $pubKey["key"]; $data = 'plaintext data goes here';//$_POST['data'] // Encrypt the data to $encrypted using the public key openssl_public_encrypt($data, $encrypted, $pubKey); // Decrypt the data using the private key and store the results in $decrypted openssl_private_decrypt($encrypted, $decrypted, $privKey); ?>

pregunta Akam 21.05.2016 - 00:18
fuente

1 respuesta

8
  

Actualmente estoy ejecutando mi sitio web en alojamiento compartido, y no puedo registrar TLS / SSL para mi sitio web.

No hay una alternativa razonable a TLS, y tratar de recrearlo por tu cuenta está ciertamente condenado. Nunca ruede su propio cripto. Si su host compartido no admite TLS, busque uno que lo haga o acepte que su sitio no es seguro.

  

Sin embargo, implementé el cifrado AES en el lado del cliente para cifrar todos los datos del formulario mediante AJAX o POST / GET normal.

Esto no va a hacer mucho. Cualquiera que visite su sitio podrá ver la fuente y extraer la clave AES, luego descifrar el tráfico que haya capturado.

  

Sin embargo, implementé jsencrypt [Una biblioteca de Javascript para realizar el cifrado, descifrado y generación de claves RSA de OpenSSL] para cifrar todos los datos de formularios mediante AJAX o POST / GET normal.

Oh, espera, ahora estás diciendo que no fue AES, en realidad fue RSA. Su confusión en este punto es una señal de advertencia, ya que no solo son algoritmos diferentes, sino que son dos tipos de criptografía completamente diferentes (simétrico versus asimétrico), con propósitos completamente diferentes.

El uso de RSA aún no impide los ataques de intermediarios porque distribuye la clave pública en el mismo canal inseguro que intenta proteger. Así que un hombre en el medio intercepta su clave pública, la cambia a una clave pública de su elección y ahora tiene acceso a todo lo que el cliente está haciendo. Ha pasado de un ataque pasivo a un ataque activo, asumiendo que su sistema criptográfico no tiene fallas.

Sugerencia para profesionales: TLS incluye al hombre en el medio en su modelo de amenaza.

  

Actualmente, tuve un problema con el enlace de restablecimiento de contraseña o algunos otros enlaces importantes que envié al usuario para acciones importantes relacionadas con la cuenta del usuario.

Si está enviando por correo electrónico un token de restablecimiento de contraseña al usuario, entonces no tiene control sobre el cifrado de transporte: si el usuario usa IMAP o POP de texto sin formato, no puede hacer nada para evitar que el token sea detectado.

  

Una forma de evitar esto es usar el identificador de fragmento (#) después de la url, como ...

No tengo idea de lo que crees que esto logra. Puede cifrar el token con la misma facilidad cuando les envíe el correo electrónico.

Todavía no sabemos si su sistema criptográfico tiene fallas o no, porque no publicó ningún código fuente para las funciones encrypt() y decrypt() . La función encrypt() toma misteriosamente solo un mensaje, no una clave, y por alguna razón usted concatena la clave al final del mensaje. No tengo idea de lo que está tratando de lograr, pero no ha proporcionado suficientes detalles aquí para que alguien le dé una respuesta precisa. La naturaleza confusa de su código y de su pregunta me lleva a creer que no está calificado para desarrollar un sistema criptográfico.

Pero si su pregunta es si el fragmento de URL se envía al servidor, entonces esa es una pregunta para StackOverflow, no para Security.SE. La respuesta a esa pregunta es completamente ortogonal a la fuerza de su sistema criptográfico. Sí, evita filtrar un texto sin formato en un momento determinado, pero simplemente cambia el problema en otro lugar.

  

¿La técnica anterior es fuerte?

Usted admitió en su propio comentario que "seleccionó la mejor opción entre la lista de opciones malas". ¿Por qué preguntas si es bueno? ¿Por qué estás diciendo que es bueno cuando ya sabes que es malo?

No es solo malo. Es horrible. Use TLS o acepte que será inseguro. No trates de falsificar la seguridad construyéndolo todo tú mismo. Los expertos en criptografía arruinan el código criptográfico. El principiante promedio (yo incluido) no tiene ninguna posibilidad de implementar todo el cifrado correctamente.

    
respondido por el Mark E. Haase 21.05.2016 - 02:28
fuente

Lea otras preguntas en las etiquetas