TechLead. Ajut la creșterea oricărei echipe.
Utilizați cheile RSA, fiecare utilizator are propria sa pereche de chei. Unul (public) este transferat pe server, celălalt (privat) rămâne cu utilizatorul. Când se efectuează o tranzacție, cum ar fi achiziția, atunci serverul ar trebui să primească informații:- ID-ul cumpărătorului
- numărul de cont al cumpărătorului
- ID-ul comerciantului
- numărul contului comerciantului
- ID de cumpărare
- valută
- suma exactă a achiziției
- momentul exact al trecerii în UTC
Fiecare tranzacție de tipărire trebuie să fie însoțită de o amprentă a tuturor acestor valori, semnată cu cheia privată a cumpărătorului. Pe server, această amprentă ar trebui să fie scanată utilizând cheia publică a aceluiași utilizator. O cheie publică poate fi stocată în aceeași bază de date. Este doar pentru verificare.
Pentru a efectua o tranzacție (achiziție), trebuie să verificați dacă fondurile sunt suficiente pentru soldul cumpărătorului-utilizator. Pentru a face acest lucru, trebuie să eliminați toate tranzacțiile clientului-cumpărător din baza de date, să efectuați o verificare a amprentelor digitale pentru fiecare tranzacție și să rezumați acelea cu imprimarea corectă.
Verificați timpul tranzacției. Pentru fiecare cumpărător, toate tranzacțiile trebuie să fie strict cronologice. Nu ar trebui să fie faptul că sa cumpărat N + 1 înainte de a cumpăra N.
Acesta este calculat lung. Pentru a accelera calculul soldului, puteți introduce un tip de tranzacție special "la începutul lunii". Trebuie să fie efectuată de un server de încredere de la o terță parte care are propria sa pereche de taste. Apoi soldul curent = ultimul sold la începutul lunii + toate încasările - toate plățile. Se calculează mult mai repede.
Dacă un atacator intră într-o bază de date, intrarea înregistrărilor va fi extrem de dificilă, deoarece va fi imposibil să se creeze o imprimare a tranzacției. Linie slabă - puteți descărca pur și simplu baza de date sau tabelul într-un fișier și apoi aruncați masa sau baza de date și șantajați-vă cu datele pierdute. Pentru a exclude acest lucru, nu permiteți utilizatorilor (nu clienților, ci celor care se conectează la baza de date) să facă DROP TABLE / DATABASE. Chiar și copii de rezervă. De asemenea, păstrați oglinda bazei de date.
Tot ceea ce am descris va fi inutil dacă atacatorul va înlocui codul sursă al serverului de plăți, deoarece el poate să reducă pur și simplu toate amprentele digitale. Prin urmare, serverul de plăți nu ar trebui să fie un server de script. Aceasta nu este PHP, nod, Python, Ruby. Trebuie să fie un cod compilat. Cu o semnătură digitală. Serverul nu trebuie să execute aplicații cu semnături digitale lipsă sau incorecte.
Dar acest lucru nu vă împiedică să înlocuiți lista de autorități de certificare de încredere de pe server pentru a rula o aplicație falsă în locul unui server de plăți. Prin urmare, pe partea DBMS, trebuie să implementați un mecanism care nu vă permite să vă conectați la baza de date la orice aplicație. Această aplicație trebuie să aibă un mecanism special de acces. Restricții la IP, anteturi speciale, sesiuni speciale. Deci, aceasta nu este MySQL și cel mai probabil nu este PostgreSQL.
Există chiar suficiente pentru a spune despre orice bâzâit?
Specialiștii de la WebMoney, PayPal, Yandex. Banii și băncile online nu ascund acum un zâmbet care se uită la algoritmul meu. Salutări tuturor, prieteni!
În ceea ce privește implementarea în PHP. Două servere cu solicitări prin AJAX nu vor face serverul mai fiabil, deoarece totul poate fi falsificat în browser.
Trebuie să împiedicați accesul utilizatorului la server. În Internet, un număr imens de articole pe această temă. Mă tem că nu-mi amintesc lista completă a instrumentelor de prevenire a accesului. În orice caz, există mai multe metode de hacking decât metodele de protecție în PHP.
Iată o listă a modalităților de reducere a probabilității de penetrare și a daunelor ireparabile:
Starea serverului- Păstrați serverul actualizat, urmați vulnerabilitățile găsite, actualizați aplicațiile serverului
- Faceți fișiere și baze de date, păstrați o bază de date oglindă; în caz de probleme - utilizați o copie
- Utilizați mașini virtuale, faceți instantanee periodice și, în caz de hacking, restaurați aparatele din imagini
- Nu-mi mai amintesc. Păstrează administratorul la îndemână.
- Dacă întreaga aplicație se află pe același serviciu, atunci toate serviciile interne (mysql, memcached, raddis, rabbit) ar trebui să asculte numai interfața 127.0.0.1. (Habrahabr.ru/post/212265)
- Dacă aplicația include mai multe servere (separat baza de date, separat PHP), adică este un cluster, atunci serviciile ar trebui să asculte numai acele IP-uri care aparțin clusterului.
- Modificați porturile standard ale tuturor serviciilor
- utilizatorii UNIX care funcționează PHP-FPM / Nginx / APACHE, trebuie să fie deschis pentru a scrie doar câteva directoare (încărcare, jurnalele, fișiere temporare), precum și pentru executarea - nimic nu este imposibil.
- Utilizatorii bazei de date trebuie să fie operațiuni distructive și nesigure accesibile (DROP / ALTER / CREATE PROCEDURA), poate chiar pentru INSERT / UPDATE / DELETE în datele finanțelor akkant utiliza o altă bază de date
nezzard. dacă vrei să spui că va avea acces la baza de date (login, password), atunci orice hash poate veni cu siguranță, în orice câmpuri multiple. Dar este mai ușor să blocați accesul la baza de date "din exterior" (restricționați accesul utilizatorilor numai de la localhost) și fără probleme. Dacă primește acces de pe serverul dvs., atunci va avea cel mai probabil acces la fișiere.
Vitaliy Orlov. Mulțumesc, dar dacă o astfel de opțiune. Contabilitatea este menținută în două baze de date pe servere diferite. Ieșirea este pe un alt server, adică atunci când apăsați „Print“ buton este cerere Ajax la un alt server, care verifică cele două tabele pe diferite servere, dacă totul este în regulă, display-uri. Ce zici de asta?
