A funkcionális követelmények a feladat szövege által voltak meghatározva.

Általános követelmények:

• A felhasználóknak kell tudni regisztrálni és belépni
• A felhasználóknak kell tudni CAFF fájlt feltölteni, letölteni, keresni
• A felhasználóknak kell tudni CAFF fájlhoz megjegyzést hozzáfűzni
• A rendszerben legyen adminisztrátori felhasználó, aki tud adatokat törölni és módosítani

Szerver oldali funkciókövetelmények:

• CAFF feldolgozási képesség
• Teljesítménymegfontolásokból C/C++ nyelven kell implementálni
• A CAFF fájlból egy előnézet generálása a webshopban megjelenítéshez

Kliens oldali követelmények

• Webes kliens implementálása

Az általános felhasználókat érintő funkcionális követelményeket az alábbi use-case diagrammal vizualizálhatjuk:

Az adminisztrátorokkal kapcsolatos funkcionális követelményeket pedig az alábbi diagrammal szemléltetjük:

A funkcionális követelmények ismeretében nagy vonalakban fel tudjuk vázolni a rendszert és annak környezetét, ezt az alábbi ábra mutatja:

A webshop rendszer biztonsági követelményeit 6 kategóriába sorolhatjuk: CIA és AAA. Az egyes kategóriákhoz további követelményeket határozhatunk meg.

• A felhasználók bizalmas adatait (pl. e-mail cím, jelszó) más felhasználók nem ismerhetik meg.
• A felhasználók vásárlási adatait más felhasználók nem ismerhetik meg (ki mit vett meg).

• A felhasználók által feltöltött animációkat más felhasználók nem módosíthatják
• A regisztrációkor megadott bejelentkezési adatoknak egyedieknek kell lenniük (felhasználónév, e-mail cím)
• A felhasználók minden képet egyszer vásárolhatnak meg
• A felhasználók nem vásárolhatnak meg saját maguk által feltöltött képet
• A felhasználók által feltölthető fájlok mérete és formátuma (CAFF) limitált
• Egy felhasználó egyszerre csak limitált számú feltöltést indíthat el

• A felhasználók bármikor vásárolhatnak, tölthetnek le, és tölthetnek fel képeket
• A felhasználók bármikor kommentelhetnek
• A felhasználók bármikor bejelentkezhetnek, kijelentkezhetnek és regisztrálhatnak

• Csak bejelentkezett felhasználók tölthetnek fel animációkat
• Kommentelni csak bejelentkezés után lehetséges
• A felhasználói fiókokat a felhasználók hozhatják létre egy regisztrációs oldalon

• Csak olyan felhasználó tölthet le animációt, aki megvásárolta
• A sima felhasználók csak jóváhagyott animációkat láthatnak

• A felhasználók minden tevékenységét naplózni kell

• Fizikai assetek

  A fizikai assetek a rendszer megvalósításához szükséges hardver eszközök, ezek jelen rendszer esetében az alábbiak lehetnek:

  • Számítógépek, amik szerverekként funkcionálnak, a pontos számuk méretezési kérdés, aminél a felhasználók számát figyelembe kell vennünk.
  • Hálózati eszközök, a rendszer interneten keresztül történő elérhetőségének biztosításához.

• Emberi asstek

  Az emberi assetek az alkalmazás felhasználói, őket két kategóriába sorolhatjuk:

  • Vásárlók/eladók
  • Adminisztrátorok

• Logikai assetek

  A logikai asseteket a rendszerben tárolt információk és azokkal interakcióba lépő komponensek alkotják.

  A megrendelő szeretne távoli elérést az alkalmazáshoz, ezért a rendszer felületét böngészőben fogjuk megjeleníteni a felhasználók számára.

  Mivel minden tevékenység bejelentkezéshez kötött, szükségünk lesz egy authentikációs komponensre, amely kezeli a bejelentkezési kéréseket és a regisztrációkat is. Ennek a komponensnek szüksége van a felhasználók adataira, ezt egy adatbázisban fogjuk tárolni.

  Az alkalmazás bizonyos funkcióihoz (kommentek törlése, felhasználók tiltása/engedélyezése/feltölések jóváhagyása, stb.) csak adminisztrátorok férhetnek hozzá, ezért szükségünk lesz egy authorizációs komponensre is. Ez a komponens fogja kezelni annak eldöntését is, hogy egy felhasználó jogosult-e egy-egy adott animáció letöltésére.

  A rendszer egy webshop alkalmazás lesz, így az alapvető webshop funkciókat (vásárlás, vásárolt animációk megtekintése, illetve kommentelés) is meg kell valósítanunk, erre egy webshop-komponenst hozunk létre. A webshopban elérhető animációkat valahol nyilván kell tartanunk, az animációk nyilvántartását egy adatbázisban fogjuk tárolni a hozzájuk tartozó metaadatokkal együtt. Az animációkhoz tartozó metaadatok közé tartoznak olyan információk, mint pl. az adott animáció ára, az előnézetéhez tartozó útvonal, vagy az, hogy az adott animáció elfogadásra került-e már az adminisztrátorok által; amíg egy animációt az adminisztrátorok nem fogadnak el, addig az nem jelenhet meg a webshopban.

  A webshop komponens csak az alapvető webshop funkciókért felel, de nekünk gondoskodnunk kell a feltöltött animációk tárolásáról is, ennek menedzselésére külön egy animáció-kezelő komponenst hozunk létre. A frissen feltöltött animációkkal ez a komponens fogja meghívni az animáció feldolgozó komponenst, amelynek feladata, hogy beparse-olja a feltöltött animációkat és azokból egy előnézetet állítson elő. Az animáció-kezelő komponens a feltöltött animációkat és a hozzájuk tartozó előnézeteket közvetlenül háttértáron fogja tárolni.

  Azt is tárolnunk kell, hogy a felhasználók milyen animációkat vásároltak már meg, ezeket szintén adbatbázisban fogjuk tárolni.

  A fentieken felül minden tevékenységet naplózunk, ebből következik, hogy a naplót is tárolnunk kell. Annak érdekében, hogy a naplóban később könnyedén tudjuk keresni, a napló tárolásához speciális logolási technológiát, Elasticsearch-öt fogunk használni.

  Az asseteket összefoglaló adatfolyam diagram:

A támadó modell kidolgozásához számba kell vennünk az egyes assetek potenciális gyengeségeit és az azokra leselkedő veszélyeket. A veszélyforrások rendszerezéséhez a STRIDE keretrendszert használtuk fel, amely az alábbi elemekkel rendelkezik:

• Spoofing (megszemélyesítés)
• Tampering (hamisítás)
• Repudiation (tevékenységek letagadása)
• Information disclosure (információ szivárgás)
• Denial of service (szolgáltatás-megtagadás)
• Elevation of privilege (jogosultsági szint emelése)

A megszemélyesítéssel kapcsolatos veszélyek forrása olyan külső szereplő, aki interakcióba lép a rendszerrel. A támadó megpróbálhatja magát felhasználónak vagy adminisztrátornak kiadni, és az ő nevükben megkísérelhet valamilyen tevékenységet végrehajtani. A lehetséges támadások:

• Felhasználó más nevében kísérel meg kommentelni
• Felhasználó más nevében, saját maga által még ki nem fizetett animációt próbál meg letölteni
• Felhasználó az adminisztrátor nevében próbál meg hozzáférni az el nem érhető funkciókhoz (komment törlés, felhasználó letiltás/feloldás, jóváhagyás)
• Felhasználó megpróbál más felhasználó személyes adataihoz hozzáférni

A hamisítással kapcsolatos veszélyekre a belső folyamatok, adattárak és adatfolyamok implementációja során kell felkészülni. A belső folyamatok támadását megkísérelhetik implementációs sérülékenységek kihasználásával, így megváltoztatva a komponensek működését. Az adattárak kompromittálása esetén hamis adatok kerülhetnek az adatbázisba, például megváltoztatott szerepkörök vagy fals fizetési adatok.

A tevékenységek letagadásának megakadályozása érdekében naplózási rendszer kerül megvalósításra. Ennek segítségével mindenképpen nyoma marad a megkísérelt sikeres vagy sikertelen támadásoknak, így ezek könnyebben és még időben felderíthetők. Ide tartozik például a sikertelen bejelentkezések naplózása, amivel az esetleges brute force támadások felderíthetők.

Az információ szivárgás során a felhasználók védett személyes adatai kerülhetnek illetéktelenek kezébe. Ez érinthet egy felhasználót vagy a teljes felhasználói adatbázist.

Szolgáltatás-megtagadás esetén a teljes szolgáltatás elérhetetlennél válhat. Ehhez elegendő a rendszer valamely erőforrását elérhetetlenné tenni. Egy ügyesen legyártott CAFF-állomány segítségével egy hibásan implementált animáció feldolgozó egységet elérhetetlenné lehet tenni, ezáltal a rendszer egésze nem lesz megfelelően működőképes. Lehetséges oly módon is elérhetetlenné tenni a szolgáltatást, hogy tömeges kérésekkel árasztják el. Ennek megelőzésére megoldás lehet a felhasználók általa feltölthető képek méretének, illetve mennyiségének korlátozása.

Jogosultsági szint emelése során nem adminisztrátori szerepben levő felhasználó kerülhet adminisztrátori szerepbe. Ezt követően az eredeti jogosultságaival elérhetetlen funkciókat is elérhet, például tilthat vagy engedélyezhet más felhasználókat.

A fentebb megállapított követelmények ismeretében elkészítettük a rendszer architekturális tervét. A struktúrát komponens diagramon, a viselkedést szekvencia diagramokon keresztül mutatjuk be.

A rendszer négy fő komponensből áll, ezek felelősek a 12 interfészen érkező kérés kezeléséért:

• Bejelentkezés: a felhasználók és adminisztrátorok ezen az interfészen keresztül tudnak bejelentkezni a rendszerbe.
• Kijelentkezés: a felhasználók és adminisztrátorok ezen az interfészen keresztül tudnak kijelentkezni a rendszerből.
• Regisztráció: a felhasználók és adminisztrátorok ezen az interfészen keresztül tudnak regisztrálni a rendszerbe.
• Felhasználó engedélyezése és tiltása: az adminisztrátorok ezen az interfészen keresztül tudnak felhasználói fiókokat letiltani, illetve a tiltást feloldani.
• Komment törlése: az adminisztrátorok ezen az interfészen keresztül tudnak bizonyos kommenteket törölni.
• Feltöltés jóváhagyása: az adminisztrátorok ezen az interfészen keresztül tudják a feltöltött animációkat jóváhagyni.
• Vásárlás: a felhasználók ezen az interfészen keresztül tudják megvásárolni a kiválasztott animációt.
• Előnézetek megtekintése: a felhasználók ezen az interfészen keresztül érik el a kiválasztott animáció előnézetét.
• Kommentelés: a felhasználók ezen az interfészen keresztül hagyhatnak megyjegyzést a kiválaszott animáció alatt.
• Animáció keresése: a felhasználók ezen az interfészen keresztül tudnak keresni a feltöltött animációk között.
• Animáció feltöltése: a felhasználók ezen az interfészen keresztül tudnak új animációt feltölteni a rendszerbe.
• Animáció letöltése: a felhasználók ezen az interfészen keresztül tudnak megvásárolt animációt letölteni a rendszerből.

A felhasználói és személyes adatokat felhasználói adatbázisban tároljuk. Az adatok kezeléséhez egy különálló logikai komponenst fogunk megvalósítani. A webshop adatai (vásárlások ténye, kommentek), valamint az animációk és előnézetük tárolása azonos séma szerint kerül megvalósításra. Mivel számos interfész esetén szükség van több kezelő komponensből is, ezek között interfészek segítségével tesszük lehetővé az összeköttetést. Minden komponens naplózza az elvégzett tevékenységeket.

A rendszer komponens diagramján az UMLsec segítségével jelenítettük meg a biztonsági követelményeket. A kritikus fontosságú erőforrásokat <> sztereotípiával láttuk el. Mindhárom adatbázis esetén tagged value-kkal tüntettük fel a kritikus fontosságú aspektusokat. A komponensek közötti dependenciákon is feltüntettük a biztonsági követelményeket. Végül az interfészeken is feltüntetésre kerültek a védendő aspektusok.

Megjegyzés: az authorizációs szolgáltatást a felhasznált keretrendszer beépítetten biztosítja implicit middleware formájában, ezért a szekvenciadiagramokon e szolgáltatás feltüntetését mellőztük.

Az animáció feltöltésekor mutatott viselkedést az alábbi ábra mutatja be. Amikor beérkezik egy feltöltési kérés, a webshop-kezelő továbbítja a beérkező CAFF animációs fájlt az animáció-kezelőnek, mely egyrészt átadja a kapott fájl egy másolatát az animáció-feldolgozó komponensnek előnézet generálására, majd az animációs fájlt és az előnézetét fájlrendszerben eltárolja, és visszaadja a webshop-kezelőnek az előnézet elérési útvonalát. Ezt követően a webshop-kezelő eltárolja a webshop adatbázisában az animációhoz tartozó metaadatokat, és visszajelzést küld a feltöltési kérés sikerességéről.

Egy feltöltés adminisztrátori jóváhagyásakor mutatott viselkedést az alábbi ábra mutatja be. Egy feltöltés jóváhagyási kérését a webshop-kezelő kapja meg, mely az adminisztrátor kérésének megfelelően rögzíti egy animáció elfogadásának vagy elutasításának tényét, illetve elutasítás esetén törli az animációt a fájlrendszerből. (Így a metaadatok pedig a webshop-adatbázisban megmaradnak, rögzítve ezzel az elutasítás tényét a kérdéses animációval kapcsolatban.)

Egy vásárlás során mutatott viselkedést az alábbi ábra mutatja be. Vásárlás kezdeményezésekor a webshop-kezelő először ellenőrzi, hogy az adott animációt a kérés kezdeményezője korábban már megvásárolta-e. Ha igen, akkor a felhasználót átirányítja a letöltésre, ha nem, akkor feldolgozza a vásárlási kérést.

Egy animáció letöltésekor mutatott viselkedést az alábbi ábra mutatja be. Egy letöltés kezdeményezésének az animáció-kezelőbe történő beérkezésekor az animáció-kezelő lekérdezi, hogy a kért animációt a kezdeményező felhasználó már megvásárolta-e. Amennyiben igen, az animáció-kezelő elküldi a kért animációt a felhasználónak, ha nem, akkor a kérés elutasításra kerül, és a felhasználó át lesz irányítva a vásárlási felületre.

Egy animáció előnézetének lekérésekor mutatott viselkedést az alábbi ábra mutatja be. Előnézet kérésekor a webshop-kezelőhöz beérkező kérést az animáció-kezelőnek továbbítja, mely visszaadja a kért előnézetet, melyet aztán a webshop-kezelő elküldi a felhasználónak.

• A CAFF parsert C++-ban implementáljuk, mivel a követelmények ezt írják elő.
• A szervert C# nyelven az ASP.NET Core keretrendszer segítségével implementáljuk, amely segítséget fog nyújtani a felhasználókezelésben, authorizációban.
• Adatbázisként a Microsoft SQL Server ingyenes verzióját fogjuk használni. (Nyilván production környezetben ezt ki kell cserélni rendes SQL Server adatbázisra, a méretkorlátozás miatt)
• A CAFF fájlok és előnézetek tárolását a szerver fájlrendszerében fogjuk végezni.
• Az alkalmazás kliensoldalaként szerver oldalon renderelt nézeteket fogunk használni, amelyhez a Razor Pages nevű technológiát használjuk.
• A naplók tárolásához Elasticsearch-öt használunk, amelyeket Kibana segítségével tekinthetünk meg.

A natív komponens teszteléséhez az alábbi módszereket használjuk:

• Fuzzing: az AFL fuzzer segítségével megkísérlünk minél több kritikus hibát feltárni a parserben
• Leak detection: a Valgrind eszköz felhasználásával kielemezzük a komponens memóriahasználatát, potenciális szivárgásokat keresve
• Static code analysis: egy választott eszköz segítségével (Cppcheck, SonarQube) statikus kódelemzést hajtunk végre, az így talált potenciális hibákat megvizsgáljuk és kijavítjuk

A webalkalmazás teszteléséhez az alábbi módszereket használjuk:

• CI pipeline: bekonfigurálunk egy automatikus build pipeline-t, amely az alább említett teszt lépéseket is végrehajtja
• Static code analysis: egy választott eszköz segítségével (SonarQube) statikus kódelemzést hajtunk végre, az így talált potenciális hibákat megvizsgáljuk és kijavítjuk
• Unit testing: a kritikusnak vélt alkalmazáskomponensekhez egységteszteket készítünk, melyek automatikus végrehajtásra kerülnek a CI pipeline build fázisában.
• Integration testing: a legfontosabbnak vélt workflow-khoz integrációs teszteket készítünk, melyek szintén automatikus kiértékelésre kerülnek