SWA – Predavanje 2

Kako funkcionira web aplikacija? Arhitekture web aplikacija.

Da bismo identificirali anomaliju, prvo bismo trebali razumjeti kako tehnologija funkcionira. Aplikacije koriste posebne protokole za međusobnu komunikaciju.

HTTP protokol nalazi se na sloju 7 OSI modela. To znači da se protokoli kao što su Ethernet, IP, TCP i SSL koriste prije HTTP protokola.

HTTP (Hypertext Transfer Protocol) je osnovni protokol koji omogućava prijenos podataka na webu. Funkcionira na klijent-server modelu, pri čemu klijent (obično web preglednik) šalje zahtjeve serveru, a server odgovara sa željenim podacima.

Kako HTTP protokol funkcionira:

  1. Klijentov zahtjev (Request):
    • Kada korisnik unese URL u preglednik, preglednik započinje HTTP komunikaciju tako što šalje HTTP zahtjev serveru.
    • HTTP zahtjev obično sadrži nekoliko komponenti:
      • Metoda: Najčešće metode su GET (zahtjev za dohvaćanjem resursa) i POST (za slanje podataka serveru).
      • URL: Adresa resursa koji se traži.
      • HTTP verzija: Verzija protokola, npr. HTTP/1.1.
      • Zaglavlja: Dodatne informacije kao što su vrsta sadržaja koji klijent može prihvatiti ili autentifikacijski podaci.
      • Tijelo zahtjeva: Koristi se kod metoda poput POST, gdje klijent šalje podatke na server.
  2. Serverov odgovor (Response):
    • Kada server primi zahtjev, obrađuje ga i vraća HTTP odgovor klijentu.
    • HTTP odgovor također ima nekoliko komponenti:
      • Statusni kod: Označava uspjeh ili neuspjeh zahtjeva, npr. 200 OK (za uspješan zahtjev) ili 404 Not Found (ako traženi resurs ne postoji).
      • Zaglavlja: Informacije kao što su vrsta sadržaja (Content-Type) i veličina podataka (Content-Length).
      • Tijelo odgovora: Sadrži stvarne podatke koje klijent traži, poput HTML stranice, slike ili drugog resursa.
  3. Prikaz rezultata:
    • Nakon što klijent primi odgovor od servera, web preglednik prikazuje podatke korisniku. Ako je odgovor HTML stranica, preglednik će je prikazati kao web stranicu.

Primjer:

  • Ako unesete URL “http://example.com“, vaš preglednik šalje GET zahtjev serveru koji hosta “example.com”. Server odgovara s HTML dokumentom koji preglednik zatim prikazuje korisniku.

Arhitekture web aplikacija

Odabir arhitekture ovisi o proizvodu / usluzi web aplikacije.

Arhitektura web aplikacija ima značajan utjecaj na sigurnost tih aplikacija. Način na koji je aplikacija strukturirana, uključujući izbor arhitektonskog stila i uzoraka, može utjecati na to kako su podaci zaštićeni, kako se upravlja pristupom i kako se potencijalni napadi detektiraju i neutraliziraju.

Razlika između uzoraka (engl. patterns) i stilova (engl. styles) u arhitekturi web aplikacija leži u njihovoj razini apstrakcije i specifičnosti primjene.

Arhitektonski stilovi

  • Definicija: Arhitektonski stilovi predstavljaju visoku razinu apstrakcije u dizajnu softvera. Oni određuju globalne karakteristike sustava, kao što su organizacija komponenti, način interakcije između tih komponenti, te opća struktura sustava.
  • Primjeri:
    • Monolitna arhitektura: Aplikacija je izgrađena kao jedinstvena jedinica, u kojoj su svi dijelovi sustava usko povezani.
    • Mikroservisi: Aplikacija je podijeljena na niz manjih, samostalnih servisa koji mogu raditi neovisno jedan o drugom.
    • Event-driven arhitektura: Sustav reagira na događaje (evente) koje generiraju različite komponente.
    • Layered (slojna) arhitektura: Aplikacija je podijeljena na slojeve (npr. prezentacijski sloj, poslovni sloj, sloj podataka), pri čemu svaki sloj ima specifičnu funkciju.

Arhitektonski uzorci

  • Definicija: Arhitektonski uzorci su specifične implementacije ili dizajnerska rješenja unutar zadanog arhitektonskog stila. Oni su općenito niže razine od stilova i usredotočeni su na rješavanje određenih problema unutar aplikacije.
  • Primjeri:
    • MVC (Model-View-Controller): Uzorak koji se često koristi unutar slojne arhitekture za organiziranje koda u tri glavne komponente: model (logika podataka), view (korisničko sučelje) i controller (posrednik između modela i viewa).
    • Repository Pattern: Uzorak koji se koristi za upravljanje pristupom podacima, omogućavajući da logika za pristup podacima bude odvojena od poslovne logike.
    • Singleton: Uzorak koji osigurava da postoji samo jedna instanca određene klase tijekom trajanja aplikacije.

Primjeri arhitektura i primjena

3-tier arhitektura
Stil: Arhitektonski stil
Opis: 3-tier arhitektura je stil dizajna koji dijeli aplikaciju na tri sloja: prezentacijski sloj (UI), poslovni sloj (logika) i sloj podataka (baza podataka). Ova podjela omogućava bolje upravljanje, skalabilnost i održavanje aplikacije.
Primjena: Često se koristi u poslovnim aplikacijama, gdje svaki sloj može biti razvijen i održavan neovisno.


Klijent-poslužitelj (Client-Server)
Stil: Arhitektonski stil
Opis: Klijent-poslužitelj arhitektura je model gdje su aplikacija i resursi podijeljeni između klijentske strane (koja šalje zahtjeve) i poslužiteljske strane (koja obrađuje te zahtjeve i šalje odgovore). Klasičan primjer je web preglednik (klijent) koji komunicira s web serverom.
Primjena: Osnova za mnoge mrežne aplikacije i web usluge.


SOA (Service-Oriented Architecture)
Stil: Arhitektonski stil
Opis: SOA je stil arhitekture gdje se funkcionalnosti aplikacije razbijaju na neovisne usluge koje komuniciraju međusobno preko mreže. Svaka usluga obavlja određenu poslovnu funkciju i može biti ponovno upotrebljiva u različitim aplikacijama.
Primjena: Pogodna za velike, kompleksne sustave gdje različiti dijelovi aplikacije moraju komunicirati na distribuiran način.


Objavi-pretplati (Publish-Subscribe)
Stil: Arhitektonski stil / Uzorak dizajna
Opis: U objavi-pretplati modelu, emitenti (publishers) šalju poruke određenim temama ili kanalima bez znanja tko će primiti te poruke, dok se pretplatnici (subscribers) prijavljuju za primanje poruka od određenih emitenta. Ovaj model omogućuje asinkronu komunikaciju između različitih dijelova sustava.
Primjena: Koristi se u distribuiranim sustavima, npr. za obavještavanje korisnika o događajima ili promjenama stanja, često implementirano putem posredničkih sustava kao što su MQTT, Apache Kafka ili RabbitMQ.

3 slojna arhitektura

Web aplikacija obično se sastoji od tri glavna sloja: prezentacijski slojposlovni sloj i sloj podataka. Ovi slojevi zajedno omogućuju funkcionalnost i skalabilnost aplikacije.

1. Prezentacijski sloj (Presentation Layer)

  • Opis: Ovo je sloj s kojim korisnici izravno stupaju u interakciju. On predstavlja korisničko sučelje (UI) i prikazuje podatke koje aplikacija obrađuje.
  • Funkcija: Prezentacijski sloj je odgovoran za prikupljanje podataka od korisnika putem obrazaca, prikazivanje podataka u obliku tekstova, slika, tablica itd., te za komunikaciju s poslovnim slojem kako bi prikazao odgovarajuće informacije.
  • Tehnologije: HTML, CSS, JavaScript, Angular, React, Vue.js.

2. Sloj poslovne logike

  • Opis: Ovaj sloj sadrži poslovnu logiku aplikacije, tj. pravila prema kojima se podaci obrađuju.
  • Funkcija: Poslovni sloj obrađuje podatke dobivene iz sloja podataka, primjenjuje poslovna pravila i odlučuje kako ti podaci trebaju biti prikazani korisniku. Također, može uključivati logiku za autentifikaciju i autorizaciju korisnika.
  • Tehnologije: Programski jezici poput Java, C#, Python, Ruby, te frameworks kao što su Spring, Django, ASP.NET.

3. Sloj podataka (Data Layer)

  • Opis: Ovaj sloj je odgovoran za upravljanje pohranom i pristupom podacima aplikacije.
  • Funkcija: Sloj podataka komunicira s bazama podataka i drugim spremištima podataka kako bi dohvaćao, pohranjivao ili ažurirao podatke potrebne za aplikaciju. Ovaj sloj također osigurava integritet i sigurnost podataka.
  • Tehnologije: Relacijske baze podataka (npr. MySQL, PostgreSQL), NoSQL baze podataka (npr. MongoDB), ORM alati (npr. Hibernate, Entity Framework).

Ovi slojevi rade zajedno kako bi omogućili funkcionalnu i učinkovitu web aplikaciju. Prezentacijski sloj osigurava da korisnik ima intuitivno sučelje, poslovni sloj obrađuje podatke prema poslovnim pravilima, a sloj podataka osigurava sigurno i učinkovito pohranjivanje i dohvaćanje podataka.

Veza između arhitekture i sigurnosti:

  1. Izolacija slojeva:
    • 3-tier arhitektura i slojna arhitektura (Layered Architecture) omogućuju bolju izolaciju između različitih dijelova aplikacije. Na primjer, poslovni sloj može biti zaštićen od izravnog pristupa vanjskim korisnicima, dok se sigurnosne kontrole mogu primijeniti između slojeva kako bi se smanjio rizik od neovlaštenog pristupa podacima ili poslovnoj logici.
  2. Kontrola pristupa:
    • Arhitekture poput SOA (Service-Oriented Architecture) omogućuju definiranje detaljnih sigurnosnih politika na razini svake usluge. Ovo može uključivati autentifikaciju, autorizaciju i šifriranje komunikacije između usluga, čime se povećava sigurnost cijelog sustava.
    • Klijent-poslužitelj arhitektura često uključuje centraliziranu kontrolu pristupa putem poslužitelja, koji može provoditi sigurnosne politike i zaštitu podataka.
  3. Distribucija odgovornosti i rizika:
    • mikroservisnoj arhitekturi, svaki mikroservis može imati vlastite sigurnosne kontrole, čime se smanjuje rizik da napad na jedan dio sustava ugrozi cijelu aplikaciju. Međutim, ovo također uvodi kompleksnost u sigurnosno upravljanje, jer svaki mikroservis mora biti pojedinačno zaštićen.
  4. Reaktivna sigurnost:
    • Objavi-pretplati (Publish-Subscribe) model može poboljšati sigurnost omogućujući asinkronu komunikaciju između komponenti, što može otežati napadačima da predvide ili presretnu poruke. Također, ovaj model omogućava brzu distribuciju sigurnosnih ažuriranja ili obavijesti o prijetnjama kroz cijeli sustav.
  5. Rukovanje podacima:
    • Arhitekture koje uključuju centralizirane baze podataka moraju implementirati jake sigurnosne mehanizme za zaštitu podataka, kao što su šifriranje i stroge kontrole pristupa. Nasuprot tome, distribuirane baze podataka u mikroservisnim arhitekturama mogu povećati izazove u održavanju sigurnosti i integriteta podataka.

Arhitektura web aplikacija direktno utječe na sigurnosni profil te aplikacije. Pravilno dizajnirana arhitektura može smanjiti rizike i omogućiti implementaciju sigurnosnih mjera koje su ključne za zaštitu podataka i korisnika. S druge strane, loše dizajnirana arhitektura može otvoriti vrata mnogim sigurnosnim prijetnjama i učiniti aplikaciju ranjivom na napade. Stoga je ključno da sigurnosni aspekti budu integrirani u arhitektonski dizajn od samog početka.