HF1 Tervezési fázis - Sa2x/FiukSzGHomework GitHub Wiki
Az online áruházunk számára megvalósítandó követelmények listáját szigorúan a feladatkiírásban található funkcionalitás (funkcionális követelmények) alapján gyűjtöttük össze. Az egyes követelményekhez az alábbi használati eseteket társítottuk.
|
Felhasználó kezeléshez kapcsolódó követelmények
(User management) |
|
| Use-case azonosító | Use case leírás |
| USR01 | A felhasználónak legyen lehetősége a rendszerbe való regisztrálásra. |
| USR02 | A felhasználónak legyen lehetősége a rendszerbe való belépésre. |
| USR03 | Az adminisztrátor jogosultságú felhasználónak legyen lehetősége más felhasználói adatok módosítására. |
| USR04 | Az adminisztrátor jogosultságú felhasználónak legyen lehetősége más felhasználói adatok törlésére. |
|
CAFF támogatással kapcsolatos követelmények
(CAFF funkcionalitás) |
|
| Use-case azonosító | Use case leírás |
| CAF01 | A felhasználónak legyen lehetősége CAFF fájl feltöltésére. |
| CAF02 | A felhasználónak legyen lehetősége CAFF fájl letöltésére. |
| CAF03 | A felhasználónak legyen lehetősége CAFF fájl keresésére. |
| CAF04 | A felhasználónak legyen lehetősége CAFF fájlokhoz megjegyzés fűzésére. |
1.1 Use-Case diagram: A felhasználó és az adminisztrátor
- Userek/Adminok spoofolása
- Userek/Adminok nem megfelelően használják a rendszert
- Szándékosan elrontott/Hibás CAFF fájl feltöltése
- Tranzakció teljesítéséhez tartozó kötelességeit nem teljesíti a vásárló/eladó
- Szerver és kliens kommunikáció közbeni adatok jogtalan megszerzése
- Kliens/Szerver terheléses megtámadása
- Admin jogosultság megszerzése a támadó által
- Admin által szándékos kártétel az adatbázisban
- Rossz fájlformátum feltöltése
- Hibás fájl feltöltése
- illegálisan megszerzett CAFF fájl eladása
| Biztonsági követelmény | Biztonsági mechanizmus | |
| Confidentiality | Személyes adatokat kötelező megvédeni külső entitásoktól | Adattitkosítás, Hozzáférés korlátozás |
| Integrity | Felhasználók csak azon CAFF fájlokhoz férhetnek hozzá, amiket ők töltöttek fel vagy vettek meg. | Hozzáférés korlátozás |
| Availability | Nagy százalékban használt böngésző verziók támogatása. | Platformfüggetlen fejlesztés |
| Authentication | Csak Admin típusú felhasználó módosíthat adatokat. | Felhasználó authentikáció |
| Authorization | A CAFF fájlokat ne lehessen fizetés előtt birtokba venni. | Biztonságos fizetés megvalósítása. |
| Auditing | Bejelentkezési próbálkozások rögzítése szükséges. | Loggolási megoldások használata |
1.2. Assetek megjelenítése adatfolyam diagramon
2.1. Komponens diagram
A szekvenciadiagramokat egy online diagramszerkesztő eszköz, a Mermaid segítségével készítettük el. Mivel a követelményeket atomi részekre vagyis use-case-kre bontottuk, ezért minden egyes használati esethez csupán egy szekvenciadiagram tartozik. A használati esetek hiba nélküli és hibás lefutásait egy szekvencián ábrázoltuk, alternatív blokkok használatával.
Egy szekvencia diagram Mermaid leírása:
sequenceDiagram
autonumber
User->>+Webshop: Signin (username, password)
alt matching credentials
Webshop->>+Authenticator: Signin (username, password)
Authenticator->>+UserData: ManageUserData (username, password)
UserData->>-Authenticator: success
Authenticator->>-Webshop: token
Webshop->>User: success
else non-matching credentials
Webshop->>+Authenticator: Signin (username, password)
Authenticator->>+UserData: ManageUserData (username, password)
UserData->>-Authenticator: fail
Authenticator->>-Webshop: fail
Webshop->>-User: fail
end
USR01 - Regisztrálás
USR02 - Bejelentkezés
USR03 - Adminisztrátori módosítás
USR04 - Adminisztrátori törlés
CAF01 - CAFF fájl feltöltés
CAF02 - CAFF fájl letöltés
CAF03 - CAFF fájl keresés
CAF04 - CAFF fájl megjegyzés
A tesztelés határait a következőképpen határoztuk meg:
A rendszerünk komponenseit külön-külön teszteljük, hogy megbizonyosodjunk hogy azok önálló működése helyes, ezután pedig a komponensek együttes működését egy integrált tesztelésnek is alávetjük hogy azok együttes működése is helyes legyen. A funkcionális tesztelés során a komponensek működésén túl a rendszer egyéb elemeit nem teszteljük.
A funkcionális tesztelésünket White-box alapú teszteléssel fogjuk elvégezni, a komponensek szempontjából pedig a statikus és a dinamikus működést is tesztek alá vetjük majd.
Az előadáson tanult módszerek alapján a SEI CERT Coding Standards-okat vizsgáltuk meg, amiket a következő oldalon találtunk meg:
https://wiki.sei.cmu.edu/confluence/display/seccode/SEI+CERT+Coding+Standards
Mivel Spring Java alapú backendet tervezünk a rendszer backendjének, ezért a Java Coding Standards listájából válogattunk.
Több elemzőt is kiválasztottunk az általunk használt coding standard teszteléséhez. Ezek a Sonarsource, Findbugs és az Infer. Ezeket mind kipróbáljuk a fejlesztés során és a legmegfelelőbbet fogjuk használni hosszútávon.
A Sonarsource-ról bővebben: https://www.sonarsource.com/java/
A Findbugs -ról bővebben: http://findbugs.sourceforge.net/
A Infer-ről bővebben: https://infer.netlify.app/
A CAFF parser dinamikus tesztelésére a Valgrind-et néztük ki, ami egy dinamikus memory leak detektáló komponens. A Valgrind-ról bővebben: https://valgrind.org/
Fontosnak tartjuk, hogy dinamikus tesztelést a fuzzing módszerrel is megközelítsük. Ez azt jelenti, hogy véletlenszerű bemeneteket generálunk egy programmal és ezeket végig futtatjuk a teszteseteinken.
A dinamikus tesztelésre az AFL fuzzer-t szeretnénk használni. Az AFL jelentése American Fuzzy lop, ez egy brute force megközelítése a fuzzer módszernek. Konkrét implementációja a google által lett kifejlesztve: https://github.com/google/AFL . Az algoritmus részletes működéséről a github oldalon lehet olvasni. A munkánk során mi ezt az implementációt fogjuk használni.