Welcome to the PictoGraphy wiki!

• A felhasználóknak kell tudni regisztrálni és belépni
• A felhasználó jelszó emlékeztetőt kérhet a megadott e-mail címére
• A felhasználóknak kell tudni CAFF fájlt feltölteni, letölteni és törölni
• A felhasználóknak kell tudni CAFF fájlokat keresni a CAFF fájlban lévő CIFF képek tag-ei, caption-je alapján
• A felhasználóknak kell tudni CAFF fájlhoz megjegyzést hozzáfűzni
• A rendszerben legyen adminisztrátor felhasználó, aki tud adatokat módosítani, törölni
• Minden felhasználói interakció webes felületen zajlik

Továbbiakban felhasználó alatt a felhasználói jogosultságokkal rendelkező felhasználót, adminisztrátor alatt az adminisztrátori jogosultságokkal rendelkező felhasználót értjük.

• Bizalmasság
  • A felhasználó személyes adataihoz csak a felhasználó és az adminisztrátor férhet hozzá
  • Az adminisztrátor adataihoz csak adminisztrátor férhet hozzá
• Integritás
  • Felhasználó csak a saját képeit törölheti
  • Adminisztrátor bármilyen képet törölhet
• Elérhetőség
  • Ha a weboldal elérhető, akkor minden funkció használható
• Autentikáció
  • A webshopot csak regisztrált, bejelentkezett felhasználó vagy adminisztrátor használhatja
• Autorizáció
  • Csak a képet feltöltő felhasználó törölheti a képet
  • Adminisztrátor bármelyik képet törölheti
  • Megjegyzést bármelyik felhasználó vagy adminisztrátor írhat bármelyik képhez
• Auditálás
  • A felhasználók és az adminisztrátorok tevékenységét naplózni kell.

• Megszemélyesítés
  • Egy felhasználó egy másik felhasználónak adja ki magát - jelszóra vonatkozó követelmények (legalább 8 karakter, tartalmazzon legalább egy kisbetűt, legalább egy nagybetűt, legalább egy számot és legalább egy speciális karaktert); session control
    • Explicit kijelentkezik, akkor vége a session-nek
    • Ha becsukja az oldalt, vége a session-nek, de ez nem triviális, ezért időlimitet adunk: ha 5 percig nem aktív, akkor kijelentkeztetjük
    • Minden session új random session id-t kap
• Hamisítás
  • Képfeltöltésnél (megjegyzésnél, letöltésnél, törlésnél...) a feltöltést a támadó elkapja és módosítva küldi tovább a szervernek - SSL kapcsolat
  • Regisztrációnál módosított adatok beküldése - SSL kapcsolat
  • Adminisztrátor tevékenységét elkapják és módosítják - SSL kapcsolat
  • Regisztrációnál lehetséges olyan e-mailt megadni, ami nem az övé - e-mail verifikáció ezt megoldaná, de ettől eltekintünk a megvalósítás során
• Tevékenységek letagadása
  • Adminisztrátor indokolatlanul letöröl valakit - naplózás (read only)
  • "Nem én írtam azt a megjegyzést", "nem én töltöttem fel az a képet", "nem én töltöttem le"... - naplózás (időbélyeg, IP cím, tevékenység); naplózott tevékenységek:
    • Regisztráció
    • Bejelentkezés
    • Tranzakció
    • CAFF letöltés
    • CAFF feltöltés
    • CAFF törlés
    • Felhasználó törlés
    • Felhasználó adat módosítás/törlés
    • Megjegyzés írása
    • Megjegyzés törlése
• Információ szivárgás
  • Jelszavakhoz hozzáférés, ha valaki feltöri az adatbázist - jelszavakat nem tárolunk (csak hash + salt, salt kriptográfiailag biztonságos random szám generátorral előállítva és mentve az adatbázisba)
  • Képekhez való hozzáférés, ha valaki feltöri az adatbázist - titkosítás (egy master kulccsal, pl AES használatával)
• Szolgáltatás megtagadás
  • DDoS támadás az egyes komponensek ellen - túl sok kérés egységnyi időn belül, azonos IP címről -> captcha, de a router beállításaival és a szerver konfigurálásával nem foglalkozunk
• Jogosultsági szint emelése
  • Felhasználó adminisztrátori jogosultságokhoz jut - authorizáció minden kérés előtt + session control (lásd feljebb) + újabb adminisztrátort nem lehet létrehozni

A követelmények értelmezését követően két use case-t tudunk megkülönböztetni a rendszerben. Az első, amikor egy sima felhasználó lehetséges tevékenységeit vesszük szemügyre. A második esetben pedig egy adminisztrátor tevékenyégeit vizsgáljuk. Úgy véljük, hogy az adminisztrátor igazából egy többletfunkciókkal rendelkező felhasználó, így közel azonos lehetőségei vannak. Lényegi eltérés, hogy adminisztrátor felhasználót nyilván nem lehet regisztrálni, és az adminisztrátor tud adatokat módosítani, törölni, valamint hogy "mezei" felhasználó csak a saját képét törölheti, másét nem. Ezen funkcióktól eltekintve a két use case lényegében megegyezik, hisz szemléletünk szerint az adminisztrátor ugyanúgy véleményezhet képeket, és feltölthet saját képeket, vagy akár másokét letöltheti (mint ahogy ez a valóságban is nagy fórumokon szokás). Mindezek alapján a két elkészült use case-ünk az alábbiak szerint néz ki:

Felhasználó use case Adminisztrátor use case Adatfolyam ábra

A kérések az interneten keresztül érkeznek a webszerver felé. Ez az első számú veszélyzóna, mivel itt a rendszer határán átmenő kérések érkeznek. Ezért, minden kérést, még a feldolgozás előtt authentikálni kell, hogy a kérő megfelelő jogosultsággal rendelkezik-e a kérés végrehajtására, a kérés tárgya létezik-e, stb.

A kérések közül a legkomplexebb a CAFF fájl feltöltése, mivel ott egy összetett bemenetről van szó, ami korrupt lehet, ezért először teljes vizsgálat szükséges, hogy a feltölteni kívánt bájtsorozat megfelel-e a CAFF fájl specifikációjának. Amennyiben megfelel, előnézetet kell generálni hozzá, ami megjeleníthető lesz a webes interfészen. Mindezek után, az előnézettel együtt le kell tárolni a CAFF adatbázisban.

Az adatbázis-kérések között is határvonal húzódik, bár a terveink szerint az adatbázis a rendszer része lesz, viszont az adatbázis kéréseket, mivel felhasználói inputok is szereplnek bennük, mindenképpen ellenőrizni kell. Ezért ezt is kritikus résznek ítéltük meg.

Bejelentkezés admin és user fiókkal

A továbbiakban mind a felhasználót, mind az adminisztrátort bejelentkezettnek tekintjük, így a fenti szekvenciát nem másoltuk be az összes többi szekvencia elejére.

Adatok módosítása és törlése CAFF fájl feltöltése CAFF fájl letöltése CAFF fájl törlése CAFF fájl keresése Megjegyzés fűzése egy CAFF fájlhoz

Komponens diagram:

Az interface-ek leírása:

• Felhasználói fiók létrehozása: ezen az interface-n hozunk létre felhasználói fiókokat, amelyek segítségével a felhasználó késobb be tud jelentkezni a webáruházba.
• Bejelentkezés: itt tud a felhasználónév és jelszó megadása után bejelentkezni a webáruházba a felhasználó, ezek megadása után a rendszer ellenőrzi, hogy jogosult-e a felhasználó a belépésre.
• Felhasználói adatok módosítása: ezen keresztül lehet változtatni a felhasználói adatokat.
• Felhasználói fiók törlése: ezen az interface-n keresztül lehet egy felhasználói fiókot annak minden adatával együtt törölni, a rendszer integritása érdekében (mivel van aki az adott felhasználó képeit megvásárolta) az általa feltöltött képek megmaradnak.
• Kijelentkezés: a bejelentkezett felhasználó ezen az interface-n keresztül tud kijelentkezni a rendszerből.
• CAFF állomány feltöltése: a felhasználó vagy az adminisztrátor ezen az interface-n keresztül tud CAFF állományokat feltöltetni. A feltöltendő állományokat minden esetben a Caff Parser ellenőrzi.
• CAFF állomány keresése: ezen keresztül lehet egy konkrét CAFF állományt név szerint keresni.
• CAFF állomány törlése: a felhasználó (amennyiben ő töltötte fel) vagy az adminisztrátor törölhet a rendszerből a kiválasztott CAFF állományt.
• CAFF állomány letöltése: ezen az interface-n keresztül lehet CAFF állományt vásárolni, és letölteni.
• CAFF állományok listázása: ezen keresztül érhetik el és böngészhetik a felhasználók a CAFF állományok előnézeti képeit.
• megjegyzés írása CAFF állományokhoz: a kiválasztott CAFF állományhoz a felhasználó és az adminisztrátor megjegyzéseket írhat.
• CAFF állományhoz írt megjegyzés törlése: a CAFF állományhoz írt bármelyik megjegyzést csak az admin törölheti.

A komponensek leírása:

• Felhasználó menedzsment: a felhasználói adatbázist kezeli.
• Felhasználói adatbázis: a regisztrált felhasználók és adminok adatait tárolja.
• CAFF állomány menedzsment: az összes CAFF állománnyal kapcsolatos műveletet (beleéertve a CAFF állomány validálását és feldolgozását a CAFF Parser segítségével) hajtja végre.
• CAFF Parser: feltöltéskor a CAFF állományokat dolgozza fel, validálja őket, kiszedi a META adatokat, előnézeti képet generál.
• Naplózás: egy központi naplózást valósít meg, amelybe a rendszerben történt eseményeket menti.
• CAFF adatbázis: a rendszerben megtalálható CAFF állományokat tárolja.

A tesztjeink az általunk megírt kódra fognak vonatkozni, a használt kriptográfiai könyvtárakat (pl. openssl), szervetechnológiát (nodejs és dependenciái) adottnak tekintjük.

• Minden megírt kódot 2 olyan csapattag is ellenőriz, akik nem vettek részt a megírásában (az egyes részek külön branchek-ben, pull request-ben két review-er elfogadása szükséges).
• A kritikus részek átfogó tesztelése (lásd lejjebb).
• Funkcionális tesztek a webes interfészre vonatkozóan.
• A NodeJS statikus vizsgálathoz nodejsscan-t fogjuk használni.

• Unit tesztek - minden függvényt ellenőrizni, 100% code coverage a mi általunk megírt kódra (3rd party-k mockolva)
• Blackbox tesztek (előre kreált valid és különböző módon korrupt CAFF fájlokkal) - minden validot el kell fogadnia, minden korruptat el kell utasítania
• valgrind a memóriaszivárgás kiszűrésére (mivel a képeket titkosítani is kell, ezért használni fogunk 3rd party kriptográfiai könyvtárat, amikben szokott lenni memóriaszivárgás, ezért külön a saját kódunkat is ellenőrizzük, mockolva a 3rd party-t és élesben is, mock nélkül) - nem maradhat memóriaszivárgás a mi általunk megírt kódban
• Statikus analízis tool-lal - nem maradhat egy error/warning sem
• Fuzzing valid és invalid CAFF fájlokból kiindulva - minden talált hibát javítani kell

• Jelszó követelmények meglétének tesztelése - rossz és jó jelszavak használatára vonatkozó tesztek
• Naplózás tesztelése - minden naplózott tevékenységre teszt, hogy bekerül-e a megfelelő napló bejegyzés
• CAFF Adatbázis ellenőrzése, hogy titkosítva vannak a CAFF fájlok (pl. dekódolás nélkül beadni a CAFF parsernek és ellenőrizni, hogy nem fogadja el)
• Captcha tesztelése - rossz captcha beütésekor az adoott kérés nem megy végbe
• Megpróbálunk nem megfelelő jogosultsággal minden tevékenységet végrehajtani - minden ilyennek sikertelennek kell lennie
• Megpróbálunk megfelelő jogosultsággal minden tevékenységet végrehajtani - minden ilyennek sikeresnek kell lennie
• Jelszó hashelés + saltolás ellenőrzése -> kétszer regisztrálva ugyanazzal a jelszóval, a hasheknek különböznie kell

CAFF állományok feldolgozását több szempont miatt (teljesítmény, biztonság és memóriakezelés) C++ nyelven implementáljuk. Az adatbázis MySql adatbázis-kezelő rendszerrel lesz megvalósítva, mivel ez a jól ismert SQL nyelvet és relációs sémát használ. A backend NodeJS segítségével lesz megvalósítva, a kliens oldal pedig egy webes megoldás lesz, Bootstrap használatával.