Securitatea HTTPS, avem sau n-avem?

HTTPS este un protocol foarte cunoscut și totodată foarte utilizat. Traficul cu serverul este criptat, așa că se elimină  posibilitatea unui atac man-in-the-middle.  Până aici toate bune, practic cu o conexiune https putem fi siguri că parola noastră este ascunsă. Însă, și aici este un mare ”însă”, sesiunile și identificatorii lor sunt stocate ușor ”la vedere”, în cookie-uri. Adică folosind un script malițios și câteva șmecherii pentru a păcăli navigatorul un atacator le-ar putea extrage, și fără să știe datele de autentificare să obțină acces la contul utilizatorului, în care tocmai s-a autentificat.

Desigur ca să reușească atacul, inițiatorul trebuie să aibă câțiva ași în mânecă: să fie bine plasat în rețea pentru a putea ”asculta” cererile sau să aibă control asupra proxy-ului prin care trece traficul.

Prima dată s-a discutat de BEAST, care exploata o vulnerabilitate cunoscută a TLS, însă clasificată ca ”teoretică”. Acum discutăm de CRIME, care exploatează de data aceasta direct navigatorul utilizatorului. Și desigur dacă serverul urmărit are și el câteva scăpări deschide mai multe posibilități.

Ca utilizator, te poți proteja de aceste tentative prin folosirea unui navigator actualizat la zi (personal recomand Firefox sau Chrome) în modul privat sau incognito (CTRL+SHIFT+N – pe Chrome), prin conectarea la rețele de încredere (nb. evitați cele ”de cartier”), și desigur printr-un antivirus actualizat și ce are și module de scanare a traficului prin rețea. Nu știu cât protejează ultima opțiune dar în cazul în care vă conectați la o rețea ne-securizată, acesta din urmă ar trebui să fie primul care vă atenționează.

AJAX – „javascript e dependent de platforma…”

Am inceput acest articol cu un citat, pe care fiecare developer trebuie sa il tina minte. Este raspunsul la multe intrebari pe care si le pun atat cei ce fac aplicatii in JavaScript cat si cei care le testeaza ( in cel mai nefericit caz, clientii).

De curand am facut o aplicatie care foloseste AJAX, si testand-o pe mai multe browsere, in faza finala am avut si eu de a face probleme de acest gen.

Ieri am realizat un script care sa faca o cerere http utilizand AJAX, ca sa ma conving asupra timpului de interactiune cu serverul pe diferite browsere. Rezultatele sunt graitoare:

Incepem cu Internet Explorer 7, care spre surprinderea mea este campion la viteza. Foloseste un obiect ActiveX (ActiveXObject), care a fost optimizat fata de versiunea Msxml2.XMLHTTP. Conexiunea este deschisa foarte rapid si raspunsul este incarcat instant.

Pe locul doi, desi nu ma asteptam sa fie diferente fata de Firefox 3 se pare totusi ca Opera 9.5 deschide foarte rapid conexiunea dupa care trimite la fel de rapid datele. Mai asteapta putin raspunsul, ceea ce se pare ca ii ia o secunda.

 

Firefox 3 in acest moment este pe ultimul loc. La acest capitol nu l-a intrecut pe IE. Se observa ca raspunsul trece prin toate cele 3 stari dupa trimiterea cererii, iar o secunda este timpul pierdut pentru trecerea de la starea 1 la 2 adica de la deschiderea conexiunii pana la trimiterea efectiva a cererii. Probleme cu stabilirea conexiunii au fost si in Firefox 2, unde refolosirea la intervale mici de timp ale unui obiect duce la 408, adica „Request Timeout” si accesarea campului status da o eroare, care binenteles duce la blocarea obiectului.
Cel mai simplu mod, dar nu si garantat 100% de rezolvare a erorii este distrugerea si reinitializarea obiectului inainte de a face o cerere.
Cea mai buna insa si garantata totodata este folosirea unui bloc try{}catch(){}, ascunzand astfel eroarea browserului. Putem sa recreem obiectul si in acest caz, sau putem sa apelam metoda abort().