No SSL: Sicurezza dell'applicazione Web utilizzando l'identificatore di frammento html (#)

Question

No SSL: Sicurezza dell'applicazione Web utilizzando l'identificatore di frammento html (#)

#1 da (8 voti)

-4

Attualmente sto gestendo il mio sito web in hosting condiviso, e non sono in grado di registrare TLS / SSL per il mio sito web. Tuttavia, ho implementato jsencrypt [Una libreria Javascript per eseguire OpenSSL RSA Encryption, Decryption e Key Generation] per crittografare tutti i dati dei moduli tramite AJAX o POST / GET normale.

Attualmente, ho riscontrato un problema con il link per la reimpostazione della password o altri link importanti che ho inviato all'utente per importanti azioni relative all'account utente. Ad esempio:

example.com/password?resetcode=%CODE%

Ma dopo aver pensato a TLS / SSL, questo url può essere visto facilmente utilizzando qualsiasi strumento di monitoraggio del traffico, quindi un utente malintenzionato può ottenere il collegamento prima dell'utente e reimpostare la password.

Un modo per evitare ciò è utilizzare fragment identifier ( # ) dopo url come:

example.com/password#code=%CODE%

Quindi usando:

<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>

E poi sul lato server:

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

La tecnica sopra la dose è strong? e dovremmo usare l'identificatore di frammento anche per TLS / SSL?

UPDATE:

Non ho usato la mia crittografia. Ci scusiamo per aver menzionato AES che non era AES ma openSSL che utilizza JavaScript.
Google ha anche implementato l'identificatore di frammento HTML! esempio: link
jsencrypt: è la libreria che ho usato nel lato client. link e poi ho usato PHP openssl per decrittografarlo sul lato server.

Demo codice sorgente:

javaScript: link
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); ?>

javascript client-side web-application tls appsec

posta Akam 21.05.2016 - 00:18

fonte

1 risposta

Leggi altre domande sui tag javascript client-side web-application tls appsec

Nozioni di base - IP spoofing È possibile guadagnarsi da vivere sfruttando gli exploit? [chiuso]

score 8 · Accepted Answer

I am currently running my website in shared hosting, and I am not able to register TLS/SSL for my website.

Non esiste un'alternativa ragionevole a TLS e provare a crearlo da solo è certamente destinato a fallire. Non rotolare mai la tua cripto. Se il tuo host condiviso non supporta TLS, trova quello che fa o accetta che il tuo sito non sia sicuro.

However, I implemented AES encryption in client side to encrypt all form data by AJAX or normal POST/GET.

Questo non farà molto. Chiunque visiti il tuo sito sarà in grado di visualizzare la fonte ed estrarre la chiave AES, quindi decrittografare il traffico che hanno catturato.

However, I implemented jsencrypt [A Javascript library to perform OpenSSL RSA Encryption, Decryption, and Key Generation] to encrypt all form data by AJAX or normal POST/GET.

Oh aspetta, ora stai dicendo che non era AES, in realtà era RSA. La tua confusione su questo punto è un segnale di avvertimento, perché non solo sono quei diversi algoritmi, sono due tipi di crittografia completamente diversi (simmetrici rispetto asimmetrici), con scopi completamente diversi.

L'uso di RSA non impedisce ancora attacchi man-in-the-middle perché stai distribuendo la chiave pubblica sullo stesso canale non sicuro che stai cercando di proteggere. Quindi un uomo nel mezzo intercetta la tua chiave pubblica, la trasforma in una chiave pubblica di loro scelta e ora ha accesso a tutto ciò che il client sta facendo. È passato da un attacco passivo ad un attacco attivo, assumendo che il tuo criptosistema non abbia difetti.

Suggerimento per i professionisti: TLS include man-in-the-middle nel suo modello di minaccia.

Currently, I got into an issue with password reset link or some other important links that I sent to user for important actions regarding user account.

Se invii un'email a un token di reimpostazione della password per l'utente, non hai alcun controllo sulla crittografia di trasporto: se l'utente utilizza IMAP o POP in chiaro, non c'è nulla che tu possa fare per impedire che il token venga sniffato.

One way to prevent this is to use fragment identifier (#) after url such as...

Non ho idea di cosa pensi che questo possa portare a compimento. Puoi facilmente crittografare il token quando invii loro l'e-mail.

Non sappiamo ancora se il tuo cryptosystem ha difetti o meno, perché non hai pubblicato alcun codice sorgente per le funzioni encrypt() e decrypt() . La funzione encrypt() prende misteriosamente solo un messaggio, non una chiave, e per qualche motivo si concatena la chiave alla fine del messaggio. Non ho idea di cosa stia cercando di realizzare, ma non hai fornito abbastanza dettagli per permettere a nessuno di darti una risposta precisa. La natura confusa del tuo codice e della tua domanda mi porta a credere che non sei qualificato per sviluppare un crittosistema.

Ma se la tua domanda è se il frammento di URL è stato inviato al server, allora questa è una domanda per StackOverflow, non Security.SE. La risposta a questa domanda è completamente ortogonale alla forza del tuo criptosistema. Sì, evita di far trapelare un testo in chiaro in un dato momento ma sposta il problema altrove.

Is the above technique is strong?

Hai ammesso nel tuo commento che tu "hai selezionato l'opzione migliore tra l'elenco di opzioni non valide". Perché stai chiedendo se è buono? Perché stai sostenendo che è buono quando sai già che è cattivo?

Non è solo male. È orribile. Utilizza TLS o accetta che non sia sicuro. Non cercare di falsificare la sicurezza costruendo tutto da solo. Gli esperti di crittografia regolarmente avviano codice crittografico. Il novizio medio (me compreso) non ha alcuna possibilità di implementare correttamente la crittografia.