Hogyan védheti meg a pénzt a helyszínen egy csomagolásból?
TechLead. Segítek minden csapat létrehozásában.
Használja az RSA kulcsokat, minden felhasználó saját kulcspárral rendelkezik. Az egyik (nyilvános) átkerül a kiszolgálóhoz, a másik (privát) a felhasználóval marad. Ha tranzakciót hajt végre, például vásárol, akkor a kiszolgálónak információt kell kapnia:- vásárló azonosítója
- a vevő számlaszámát
- kereskedői azonosító
- kereskedői számlaszám
- vásárlási azonosító
- valuta
- a vásárlás pontos összege
- a tranzakció pontos időpontja UTC-ben
Minden nyomtatási tranzakcióhoz csatolni kell az összes ilyen érték lenyomatát, amelyet a vevő privát kulcsával kell aláírni. A kiszolgálón ezt az ujjlenyomatot ugyanazon felhasználó nyilvános kulcsával kell beolvasni. Egy nyilvános kulcs tárolható ugyanabban az adatbázisban. Csak az ellenőrzésre.
Tranzakció (vásárlás) végrehajtásához ellenőriznie kell, hogy az alapok elegendőek-e a felhasználói vásárló egyenlegére. Ehhez el kell távolítania a felhasználói vevő minden tranzakcióját az adatbázisból, végrehajtania kell az egyes tranzakciók ujjlenyomat-ellenőrzését, és össze kell foglalnia azokat, akik a helyes nyomtatást kapják.
Ellenőrizze a tranzakció idejét. Minden vevő esetében minden ügyletnek szigorúan időrendinek kell lennie. Nem szabad, hogy az N + 1 felvásárlás az N felvásárlás előtt történt.
Ezt hosszúra kell számítani. Az egyenleg kiszámításának felgyorsításához különleges tranzakciótípust írhat be "állapotba a hónap elején". Ezt egy harmadik fél megbízható kiszolgálónak kell végrehajtania, amelynek saját kulcspárja van. Ezután a jelenlegi egyenleg = az utolsó mérleg a hónap elején + összes bevétel - minden kifizetés. A számítás sokkal gyorsabb.
Ha egy támadó egy adatbázisba bomlik, a rekordok beadása rendkívül nehéz lesz, mert lehetetlen a tranzakció kinyomtatása. Gyenge kapcsolat - egyszerűen eltávolíthatja az adatbázist vagy a táblázatot egy fájlba, majd levághatja az asztalt vagy az adatbázist, és megzsarolhatja az elveszett adatokat. Ennek kizárásához ne engedélyezze a (z) DROP TABLE / DATABASE (DROP TABLE / DATABASE) felhasználók (nem az ügyfelek, hanem azok számára, akik az adatbázishoz csatlakoznak). Még biztonsági másolatokat készítsen. Továbbá tartsa az adatbázis-tükröt is.
Mindaz, amit leírtam, akkor haszontalan lesz, ha a támadó a fizetési szerver forráskódját helyettesíti, mivel egyszerűen kivághatja az ujjlenyomatokat. Ezért a fizetési szerver nem lehet szkriptszerver. Ez nem PHP, csomópont, Python, Ruby. Készített kódnak kell lennie. Digitális aláírással. A kiszolgálónak nem kell végrehajtania a hiányzó vagy hibás digitális aláírással rendelkező alkalmazásokat.
Ez azonban nem akadályozza meg abban, hogy a hiteles hitelesítésszolgáltatók listáját helyettesítse a kiszolgálón egy hamisított alkalmazás futtatására a fizetési szerver helyett. Ezért a DBMS oldalán olyan mechanizmust kell végrehajtania, amely nem teszi lehetővé az adatbázishoz való kapcsolódást bármely alkalmazáshoz. Ennek az alkalmazásnak speciális hozzáférési mechanizmussal kell rendelkeznie. IP korlátozás, speciális fejlécek, speciális munkamenet. Tehát ez nem MySQL és valószínűleg nem PostgreSQL.
Van még elég, hogy elmondhasson bármit is?
A WebMoney, a PayPal, a Yandex szakemberei: a pénz és az online bankok most nem rejtenek el olyan mosolyt, amely az algoritmusomat vizsgálja. Üdvözlet mindenkinek, barátok!
A PHP-ben történő megvalósítás tekintetében. Két kiszolgáló az AJAX-n keresztül küldött kérésekkel nem fogja megbízhatóbbá tenni a kiszolgálót, mert minden a böngészőben kovácsolható.
Meg kell akadályoznia, hogy a felhasználó hozzáférjen a kiszolgálóhoz. Az interneten hatalmas cikkek száma ebben a témában. Attól tartok, hogy nem fogok emlékezni a hozzáférés-megelőzési eszközök teljes listájára. Mindenesetre több módszer van a hackelésre, mint a védelmi módszerek a PHP-ben.
És itt van egy lista a módszerekről a penetráció és a helyrehozhatatlan károk valószínűségének csökkentése érdekében:
Szerver állapota- Tartsa naprakészen a kiszolgálót, kövesse a talált sérülékenységeket, frissítse a kiszolgáló alkalmazásokat
- Csináljon fájlokat és adatbázisokat, tükör-adatbázist tartson; hiba esetén egy példányt használjon
- Használjon virtuális gépeket, rendszeres pillanatfelvételeket készítsen, és hackelés esetén állítsa vissza a gépeket a képekből
- Már nem emlékszem. Tartsa kézben az adminisztrátort.
- Ha a teljes alkalmazás ugyanazon a szolgáltatáson van, akkor minden belső szolgáltatás (mysql, memcached, raddis, nyúl) csak a 127.0.0.1 felületen hallgathatja meg. (Habrahabr.ru/post/212265)
- Ha az alkalmazás több kiszolgálót tartalmaz (külön-külön az adatbázis, külön PHP), azaz klaszter, akkor a szolgáltatások csak a klaszterhez tartozó IP-eket hallgatják.
- Módosítsa az összes szolgáltatás szabványos portját
- UNIX felhasználók ami működik PHP-FPM / nginx / apache, nyitottnak kell lenni az írás csak néhány könyvtárak (feltöltés, naplók, az ideiglenes fájlok), és a kivitelezés - semmi sem lehetetlen.
- Adatbázis felhasználó számára hozzáférhetőnek kell lennie destruktív és biztonságos működés (DROP / ALTER / CREATE ELJÁRÁS), talán még az INSERT / UPDATE / DELETE az adatokat a Pénzügyi akkant használjon másik adatbázisban
nezzard. ha azt jelenti, hogy hozzáférést kap az adatbázishoz (bejelentkezés, jelszó), akkor minden hash minden bizonnyal megjelenhet bármely több mezőben. De könnyebb blokkolni a hozzáférést az adatbázishoz "kívülről" (korlátozni a felhasználói hozzáférést csak a localhost-ból), és nem okoz problémákat. Nos, ha hozzáférést kap a szerverétől, valószínűleg hozzáférhet a fájlokhoz.
Vitaliy Orlov. Köszönöm, de ha ilyen lehet. A számlázást két adatbázisban tárolják különböző kiszolgálókon. A kimenet egy másik kiszolgálón található, azaz. amikor megnyomja a "Print" gombot, egy ajax kérést küld egy másik kiszolgálónak, ahol két táblát ellenőriznek különböző szervereken, ha minden rendben van, akkor a kimenet. Mi van ezzel?
