Tervezési fázis

Funkcionális követelmények

A feladat egy webalkalmazás elkészítése, amely képes speciális fájlformátumú fájlok (CIFF,CAFF) kezelésére. Az alkalmazás két típusú felhasználóval rendelkezhet, ezek az alap felhasználó illetve az adminisztrációs jogkörrel rendelkezők (továbbiakban admin felhasználó. Előbbiek képesek a már feltöltött fájlokat böngészni, fájlokat letölteni feltölteni, illetve a fájlokhoz különböző hozzászólásokat elhelyezni. Az admin felhasználók képesek az előbbi említett funkciókon kívül más adminisztratív feladatokkal kapcsolatos funkciók használatára, ilyen például fájlok törlése, illetve a felhasználói adatok módosítása és törlése.

• A felhasználó a rendszerben található képeket megtekintheti
• A felhasználó a már feltöltött képekhez képes kommenteket írni.
• A felhasználó regisztrálhat majd regisztráció után beléphet a felületre.
• A felhasználó képes új CAFF fájlokat feltölteni, már meglévőket letölteni illetve adatok alapján fájlokat keresni.
• A rendszer rendelkezik adminisztratív jogkörrel rendelkező felhasználóval, aki képes a felhasználói adatok törlésére, illetve CAFF fájlok törlésére is.

Use Case modellek:

Felhasználó adminisztráció magában foglalja a felhasználói adatok törlését és módosítását.

Biztonsági követelmények és célok

Ebben a fejezetben a funkcionális követelmények tekintetében felvázoljuk a rendszert és annak környezetét. A weboldalt fogják használni felhasználók, valamint olyan felhasználók akik azonosításon túl még adminisztrátori jogkörrel is rendelkeznek. Mivel a velük történő interakciókat nem tudjuk befolyásolni, kontrollálni, ezért ez biztonsági kérdéseket vet fel. Ezt az ábrán piros szaggatott vonallal jeleztük.

A rendszer működéséhez szükséges lesz eltárolni a felhasználók adatait (regisztrált felhasználó és admin), valamint a képeket, és a hozzájuk tartozó információkat (például kommenteket, metaadatokat). A felhasználók mivel kommenteket írhatnak egy-egy animációhoz, így szükséges összekötni a kommenteket az felhasználókkal, továbbá a felhasználókat is szükséges összekötni az általuk feltöltött animációkkal, valamint a megvásárolt animációkkal.

Az online áruház - mint szoftver - biztonsági követelményeit hat nagy kategóriába sorolhatjuk: CIA és AAA. AZ egyes kategóriákhoz az alábbi követelményeket határozhatjuk meg.

Bizalmasság (Confidentiality)

• A regisztrált felhasználó adatait csak saját maguk ismerhetik, valamint az adminok. Az adminoknak szükséges ismerniük az adatokat ahhoz, hogy tudjanak esetlegesen segíteni a különböző (akár vásárlás során) felmerülő problémákban.
• A felhasználók csak a saját megvásárolt fájljait láthatják, a többi felhasználó vásárolt fájlját nem.
• Az admin(ok) minden felhasználó minden feltöltött és megvásárolt fájlját láthatják (ideértve más adminokét is)
• Az admin(ok) a naplófájlokat láthatják
• A feltöltött CAFF fájlokat csak megvásárlás után érthetik el a felhasználók, addig csak az előnézeti kép látható.

Integritás (Integrity)

• A felhasználók csak a saját személyes adataikat tudják módosítani.
• Csak admin törölhet és módosíthat egy feltöltött CAFF fájlt.
• Csak admin törölhet egy felhasználót (más admint is).
• Csak az admin módosíthat vagy törölhet már elküldött megjegyzést egy adott CAFF fájlhoz.

Elérhetőség (Availability)

• A rendszerbe normál üzemben bármikor lehetséges feltölteni és megvárolni CAFF fájlokat.

Autentikáció (Authentication)

• A rendszerbe minden felhasználó saját maga kell, hogy regisztráljon.
• Regisztráció nélkül az oldalon semmilyen funkció nem elérhető.

Autorizáció (Authorization)

• A feltöltött fájlok törlése és módosítása is admin szerepkörhöz kötött.
• A megírt kommentek törlése vagy módosítása is admin szerepkörhöz kötött.

Auditálás (Auditing)

• A felhasználóknak (ide értve az amint is) minden tevékenységét naplózni kell.

Threat assessment

A threat assessment két nagyobb elemből áll össze: assetek azonosítása és assetekre leselkedő veszélyek (threat) azonosítása. Az assetek azonosításához iteratívan kell elemeznünk a rendszer use case-eit, figyelembe véve a biztonsági követelményeket. A veszélyek megállapításához a STRIDE keretrendszer nyújt segítséget, melynek elemei a következők:

• Megszemélyesítés (spoofing)
• Hamisítás (tampering)
• Tevékenységek letagadása (repudiation)
• Információ szivárgás (information disclosure)
• Szolgáltatás-megtagadás (denial of service)
• Jogosultsági szint emelése (elevation of privilege)

Assetek megállapítása

Fizikai assetek: Maga a hardver, ahol a CAFF fájlokat, valamint a felhasználói adatokat tároljuk. Ezen fut a webszerver is.

Emberi assetek: felhasználó, admin felhasználó

Logikai assetek: CAFF fájlok és felhasználói adatok

Az asseteket összefoglaló adatfolyam diagram, piros szaggatott vonal jelöli azokat a határokat, ahol bizalmi kérdések merülnek fel:

Támadó modell kidolgozása

Lehetséges támadások:

1. Felhasználó által elvégzet olyan műveletek, amikhez csak az adminnak van jogosultsága:

• Saját vagy máshoz tartozó CAFF fájlok törlése.
• Saját vagy máshoz tartozó személyes fájlok módosítása.
• Belép más felhasználó fiókjába és megtekinti másnak a személyes adatait.

2. Egyéb:

• Felhasználó megtámadja az adatbázist és/vagy a webszervert, hogy megakadályozza a rendes működését.
• Felhasználó hozzáférést szerez a rendszerhez és megpróbálja elérhetetlenné tenni mások számára.

Biztonsági mechanizmusok

A szolgáltatásokhoz csak bejelentkezett felhasználók férhetnek hozzá, a bejelentkezés felhasználónév és jelszó megadásával történik. Amennyiben a megadott név és jelszó érvényes, a felhasználó egy JWT tokent kap, amelyből kiolvasható a felhasználó neve és jogköre. A tokennek lejárati ideje van, ezért abban az esetben, ha egy támadó szert tesz egy érvényes tokenre, nem tud korlátlan ideig hozzáférni a rendszerhez a nevében. A felhasználóknak két jogköre van, a normál felhasználó és az adminisztrátor. Egy adminisztrátornak teljes rálátása van a rendszerre, lehetősége van más felhasználók adatait, vagy a tárolt képeket módosítani.

A felhasználó hitelesítése a hívott művelet végrehajtásának első lépése, amennyiben ez nem sikeres, a hívás végrehajtása félbeszakad és az API a megfelelő HTTP státusz kódú válasszal jelzi a hiba okát. A bejelentkezéshez szükséges jelszavak adatbázisban vannak tárolva, titkosított formában, ezért ha egy illetéktelen személy betekintést nyer az adatbázisba, a jelszavak nem kompromitálódnak. Az API végpontok jogosultsági köröknek megfelelően védve vannak, ezért a felhasználók csak azokat a funkciókat használhatják, amelyekhez valóban joguk van.

Architektúra

A rendszer kliens-szerver architektúra szerint épül fel. A kliens egy ASP.NET Core keretrendszerben készült webes alkalmazás, a felhasználók ennek segítségével vehetik igénybe a rendszer szolgáltatásait. A backendet egy szintén ASP.NET Core alapú web API jelenti, ennek feladata az adatokhoz való hozzáférés biztosítása, valamint a jogosultságkezeléssel kapcsolatos feladatok intézése. Az authentikációhoz és authorizációhoz szükséges adatok egy SQL Server adatbázisban foglalnak helyet, a tárolt képek, pedig egy erre a célra kijelölt adattároló komponensben helyezekednek el. A képek feldolgozását egy C++ -ban írt parser komponens végzi.

A backend szolgáltatásai REST API-n keresztül érhetők el. Annak érdekében, hogy az adatátvitel biztonságosan történjen, a frontend és backend közti kommunikáció HTTPS protokollal történik. A biztonságos kommunikáció miatt, a felhasználókat nem fenyegeti az a veszély, hogy egy man in the middle típusú támadásból kifolyólag bizalmas adatai (pl authorizációs token) illetéktelen személyekhez kerüljenek.

Az interface leírása:

• Felhasználói fiók létrehozása: Felhasználói fiók létrehozása, amelyekkel a felhasználók beléphetnek.
• Felhasználói fiók törlése: Egy felhasználói fiók törlése minden adatával együtt. A felhasználó által feltöltött CAFF fájlok megmaradnak a rendszerben.
• Bejelentkezés: A felhasználó név és jelszó megadása után a rendszer ellenőrzi azok helyességét és bejelentkezteti a felhasználót/admin-t sikeresség esetén.
• Kijelentkezés: A felhasználók kilépetetése a rendszerből.
• Felhasználói adat módosítása: Az adminisztrátor ezen az interfészen képes megváltoztatni a felhasználókhoz tartozó adatokat.
• Felhasználói adat lekérdezése: A felhasználók adatait lekérdezheti ezen az interfészen keresztül az adminisztrátorok.
• CAFF fájlok feltöltése: A felhasználó vagy az adminisztrátor CAFF fájlokat töltenek fel, ami során a Parser ellenőrzi a feltöltendő fájlt.
• CAFF fájlok törlése: Az adminisztrátor törli a rendszerből az adott CAFF fájlt.
• CAFF fájlok letöltése: A felhasználó letölti a kívánt CAFF fájlt, ami során a Parser validálja a letöltendő fájlt.
• CAFF fájlok böngészése: A felhasználók ezen az interfészen képesek az elérhető CAFF fájlok előnézeti képét megtekinteni, valamint keresni azok között.
• Megjegyzés írása a CAFF fájlokhoz: Egy CAFF fájlhoz egy felhasználó vagy egy adminisztrátor megjegyzést ír
• Adminisztrátor felvétele: Egy adminisztrátor regisztrál egy új adminisztrátori fiókot.

A komponensek leírása:

• Felhasználói adatkezelő: Az összes, felhasználókkal kapcsolatos művelet elvégzéséért felelős. Kezeli a felhasználói adatbázist.
• Felhasználói adatbázis: A felhasználók adatait tárolja.
• CAFF adatkezelő: Az összes, CAFF fájllal kapcsolatos művelet elvégzéséért felelős, a CAFF parser-t használja a fájlok feldolgozására, a felhasználó kezelőt a szerepkörök lekérésére (felhasználó nem törölhet).
• Parser: A CAFF fájlokat dolgozza fel: előállítja az előnézeti képet, kiszedi a metaadatokat, validálja a fájlt.
• CAFF adatbázis: A CAFF fájlokat tárolja.

A rendszer viselkedése

A viselkedés diagramokat a megfelelő use-case-eknek megfelelően hoztuk létre. Minden objektumnak a működése során, minden hívás esetén naplózás történik. Ezt megjegyzésként terveztük hozzáadni a diagramokhoz, azonban ezt nem támogatta az általunk használt szerkesztő. Továbbá a viselkedés diagramokon nem minden esetben ábrázoljuk az ábrák érthetősége miatt, hogy a felhasználói adatkezelő minden esetben a felhasználói adatbázissal kommunikál, valamint a CAFF adatkezelő a CAFF adatbázissal.

A CAFF feltöltés felhasználói azonosítás után című szekvencia diagramon az olvashatóság kedvéért kihagytuk, hogy minden esetben meghívja a felhasználói adatkezelőt a CAFF adatkezelő, hogy azonosítsa a felhasználót, ami után végez csak műveletet. Ezt a CAFF adatkezelő felhasználói hitelesítés diagram ábrázolja

CAFF feltöltés felhasználói azonosítás után:

CAFF adatkezelő felhasználói hitelesítés:

CAFF törlés:

CAFF módosítás:

Felhasználó belépés:

További szekvencia diagramokat nem készítettünk, azok mindegyike a fentiek mintájára elkészíthető. Komment törlése hasonlóan működik, mint a CAFF kép törlése, csak más függvénynevek történnek meghívásra. Komment írásásához, valamint a képek nézegetésére mielőtt az aktor megkapja az adatot az adatkezelő ellenőrzi, hogy be van jelentkezve a felhasználó.

Tesztelési tervek

Funkcionális tesztelés

A projekt C# nyelven lesz megírva, ezért a Microsoft.VisualStudio.TestTools.UnitTesting könyvtárat fogjuk használni a unit tesztek elkészítéséhez. Frontendet manuális rendszertesztrel ellenőrizzük. A Parser funkcionális tesztelése a bemenetek és a kimenetek összehasonlításán fog történni. Annak érdekében, hogy a fejlesztés során folyamatosan ellenőrizni lehessen a helyes működést, az elkészített alkalmazások CI alapú tesztelésnek lesznek alávetve Github Action-ök formájában.

Biztonsági tesztelés

A C++ Parsert fuzzolással (afl) és a valgrind-del tervezzük tesztelni. A backend-et Postmannal fogjuk ellenőrizni.