Lekcija 11

Sigurni protokoli i aplikacijska sigurnost

HTTPS/TLS, cipher suites, LDAPS, SNMP v3, SPF/DKIM/DMARC, DNS filtriranje, input validation, sandboxing i ostale ključne tehnike zaštite protokola i aplikacija.

Obj 2.2.8 — Unsecure networks Obj 4.4.3 — Monitoring tools Obj 4.5.5 — Secure protocols Obj 4.6.9 — MFA

1. Pregled — sigurni protokoli

Mnogi mrežni protokoli nastali su desetljećima ranije kada su funkcionalnost i dostupnost bili prioritet, a ne sigurnost. Insecure protokoli prenose podatke u čistom tekstu — svaki tko presretne paket može ga pročitati. Sigurni protokoli koriste enkripciju, autentifikaciju i provjeru integriteta.

Cleartext / Plaintext protokoli

HTTP, Telnet, FTP, LDAP (basic), SNMPv1/v2, POP3, IMAP (bez TLS) — svi prenose podatke bez enkripcije. Napadač koji presretne promet (sniffing, on-path) vidi sve.

Sigurni ekvivalenti

HTTPS (HTTP + TLS), SSH (umjesto Telnet), SFTP/FTPS (umjesto FTP), LDAPS (umjesto LDAP), SNMPv3, SMTPS, IMAPS, POP3S, DNSSEC.

Načelo: sigurno ako nije opravdano drugačije

Svaki protokol treba biti siguran ako ne postoji specifičan i dokumentiran razlog za korištenje nesigurnog. Iznimke moraju biti procijenjene, odobrene i kompenzirane alternativnim kontrolama.

Ispit

Ispit redovito pita koji sigurni protokol zamjenjuje koji nesigurni. Uči kombinacije: HTTP→HTTPS, Telnet→SSH, FTP→SFTP ili FTPS, LDAP→LDAPS, SNMPv1/v2→SNMPv3.

2. Nesigurni vs sigurni protokoli — pregled

Najčešći parovi nesigurnih i sigurnih protokola s odgovarajućim portovima

Zašto sigurni protokoli zahtijevaju više napora?

Certifikati i upravljanje ključevima

HTTPS zahtijeva SSL/TLS certifikat od trusted CA-a. Certifikat mora biti točno instaliran, konfiguriran i obnavljan. Kriptografski ključevi moraju se sigurno generirati, pohraniti i distribuirati.

Troubleshooting kompleksnost

Administrators ne mogu lako čitati šifrirani promet pri dijagnozi problema. Konfiguracija je složenija i sklonija pogreškama.

Downgrade napadi

On-path napadač može pokušati natjerati client i server da se "dogovore" na starijoj, ranjivoj verziji protokola. TLS 1.3 eksplicitno onemogućuje downgrade.

3. HTTPS, TLS i cipher suites

SSL je razvio Netscape 1990-ih kao odgovor na nesigurnost HTTP-a. Industrija ga je standardizirala pod imenom TLS (Transport Layer Security). Danas samo TLS verzije smiju biti u upotrebi — SSL je zastario i nesiguran.

Verzija	Status	Ključne napomene
SSL 2.0 / 3.0	Zastarjelo — ne koristiti	Višestruke kritične ranjivosti (POODLE, BEAST)
TLS 1.0 / 1.1	Zastarjelo — ne koristiti	Ranjivi na downgrade napade, deprecated od 2020.
TLS 1.2	Prihvatljivo (min standard)	Podržava legacy klijente; moguće downgrade na slabije cipher suites
TLS 1.3	Preporučeno	Uklonjen downgrade, kraći handshake, samo forward-secret key exchange

TLS handshake — kako funkcionira

TLS handshake — klijent i server dogovaraju cipher suite i razmjenjuju ključeve prije enkripcije

Cipher suites

Cipher suite je skup algoritama koji klijent i server koriste za TLS vezu. TLS 1.2 i stariji imaju duži format; TLS 1.3 koristi pojednostavljen skup.

TLS 1.2 cipher suite format

ECDHE-RSA-AES128-GCM-SHA256

ECDHE = Elliptic Curve Diffie-Hellman Ephemeral (key exchange)
RSA = algoritam potpisa (autentifikacija servera)
AES128-GCM = bulk enkripcija (128-bit, Galois Counter Mode)
SHA256 = HMAC hash funkcija

TLS 1.3 cipher suite format

TLS_AES_256_GCM_SHA384

TLS 1.3 koristi samo ephemeral key exchange → PFS je obavezan.
Tip potpisa dolazi iz certifikata, pa nije u cipher suiteu.
AES_256_GCM = bulk enkripcija · SHA384 = u HKDF funkciji

Downgrade napad

On-path napadač može ubaciti poruke i pregovarati "u ime" klijenta ili servera da koriste stariji, ranjiviji protokol ili slabiji cipher suite. TLS 1.3 eksplicitno sprječava downgrade na TLS 1.2 ili niže.

4. LDAP i LDAPS

LDAP (Lightweight Directory Access Protocol) omogućuje pristup mrežnom direktoriju (korisnici, računala, grupe, dozvole). Pokreće se na portu 389 — bez ikakve enkripcije u defaultnoj konfiguraciji.

No Authentication (anonimni pristup)

Direktorij dostupan bez ikakve autentifikacije. Nije prihvatljivo za produkcijska okruženja.

Simple Bind

Klijent šalje Distinguished Name (DN) i lozinku — u čistom tekstu. Ranjivo na sniffing i on-path napade.

SASL (Simple Authentication and Security Layer)

Klijent i server pregovaraju mehanizam (npr. Kerberos). STARTTLS naredba dodaje enkripciju i provjeru integriteta. Preferiran pristup za Active Directory (Microsoft AD).

LDAPS — LDAP Secure

Server ima digitalni certifikat koji uspostavlja TLS tunel prije svake komunikacije. Port: 636. Sigurnija alternativa, ali SASL+STARTTLS je fleksibilniji u AD okruženjima.

Ispit

LDAP = port 389, cleartext. LDAPS = port 636, TLS tunel. U AD okruženjima: SASL + STARTTLS je preferiran. Anonimni i Simple Bind moraju biti onemogućeni ako se zahtijeva sigurnost.

5. SNMP — upravljanje i monitoring mrežnih uređaja

SNMP (Simple Network Management Protocol) koriste administratori za nadzor i upravljanje mrežnim uređajima. Sastoji se od monitora (NMS) i agenata koji trče na upravljanim uređajima.

SNMP arhitektura — NMS pola agente (port 161); agenti šalju TRAP obavijesti (port 162)

Verzija	Autentifikacija	Enkripcija	Preporuka
SNMPv1	Community string (cleartext)	Nema	Ne koristiti
SNMPv2c	Community string (cleartext)	Nema	Ne koristiti
SNMPv3	Korisničko ime + lozinka (hashirana)	AES / DES	Koristiti uvijek

Community string (v1/v2)

Funkcionira kao shared password, ali se šalje u čistom tekstu. Nikad ga ne ostavljati na defaultu ("public", "private"). Koristiti access liste za ograničenje na poznate IP adrese.

SNMPv3 sigurnosni model

Agenti imaju popis korisnika i dozvola. Poruke se potpisuju hashom korisničke lozinke → agent verificira potpis i autentificira korisnika. Enkripcija poruka: AES (preporučeno) ili DES (zastarjelo).

Ako SNMP nije korišten

Onemogućiti na svim uređajima. Ako je potreban — koristiti SNMPv3, ACL za pristup, komplikovana community stringa (v1/v2 samo ako je legacy zahtjev), ne eksponirati prema internetu.

6. Email sigurnosni protokoli — SPF, DKIM, DMARC

Phishing i spam emailovi lažno predstavljaju poznate pošiljatelje. SPF, DKIM i DMARC su DNS-bazirani mehanizmi koji autentificiraju identitet pošiljatelja i štite od spoofinga.

SPF, DKIM i DMARC — troslojni email autentifikacijski sustav

SPF (Sender Policy Framework)

DNS TXT zapis koji navodi koji mail serveri smiju slati email u ime domene. Prijemni server provjerava IP adresu pošiljatelja s SPF listom → ako nije na listi, email je sumnjiv. Primjer: v=spf1 include:_spf.google.com ~all

DKIM (DomainKeys Identified Mail)

Pošiljateljev mail server digitalno potpisuje dijelove emaila (header, body) privatnim ključem. Javni ključ je objavljen u DNS-u. Prijemni server verificira potpis → jamstvo integriteta poruke i identiteta domene.

DMARC (Domain-based Message Authentication, Reporting & Conformance)

Politika koja govori prijemnom serveru što učiniti kada SPF ili DKIM provjera ne prođe: none (samo bilježi), quarantine (spam mapa), reject (odbaci poruku). Uključuje i mehanizam izvještavanja — vlasnik domene prima izvještaje o pokušajima spoofinga.

Ispit

SPF = koji serveri smiju slati. DKIM = digitalni potpis poruke. DMARC = politika što učiniti ako SPF/DKIM ne prođe + izvještavanje. Sve tri su DNS-bazirane. DMARC se oslanja na SPF i DKIM.

7. DNS filtriranje

DNS filtriranje blokira pristup malicioznim, zabranjenim ili neprikladnim domenama na razini DNS upita — prije nego korisnik uopće uspostavi TCP vezu s ciljanim serverom.

Kako funkcionira

Organizacijski DNS resolver uspoređuje svaki upit s listom zabranjenih ili kategorija. Ako domena odgovara pravilima, resolver vraća NXDOMAIN ili preusmjerava na "block page" umjesto stvarne IP adrese.

Prednosti DNS filtriranja

Blokira malware, phishing, C2 (Command and Control) komunikaciju, neprihvatljiv sadržaj. Radi na svim protokolima (HTTP, HTTPS, FTP) jer sve ovisi o DNS-u. Centralno upravljanje za cijelu mrežu.

DNSSEC (DNS Security Extensions)

Digitalni potpisi DNS zapisa koji sprječavaju DNS spoofing i cache poisoning. Resolver verificira potpis odgovora. Ne pruža enkripciju DNS prometa — samo integritet.

DoH (DNS over HTTPS)

Šifrira DNS upite unutar HTTPS-a (port 443). Sprječava praćenje i man-in-the-middle napade na DNS. Problem: zaobilazi korporativno DNS filtriranje jer promet izgleda kao normalni web promet.

DoT (DNS over TLS)

Šifrira DNS upite koristeći TLS (port 853). Lakše identificirati i filtrirati od DoH-a jer koristi dedicirani port.

Komercijalni DNS filteri

Cisco Umbrella, Cloudflare Gateway, Palo Alto DNS Security, OpenDNS. Koriste threat intelligence feed za automatsko ažuriranje lista malicioznih domena.

8. Ostali sigurni protokoli

SSH (Secure Shell) — port 22

Zamjenjuje Telnet (port 23). Pruža šifrirani remote shell pristup, tunneling i SCP/SFTP prijenos datoteka. Autentifikacija: lozinka ili SSH key pair (preporučeno). SSH ključevi moraju se upravljati kao osjetljivi materijal.

SFTP vs FTPS

SFTP = SSH File Transfer Protocol (port 22, unutar SSH tunela). FTPS = FTP over TLS (port 990 za implicit, 21 za explicit s STARTTLS). Oba zamjenjuju nesigurni FTP. SFTP je jednostavniji za firewall konfiguraciju (jedan port).

SMTPS / STARTTLS — port 465/587

Email slanje: SMTPS (port 465) = implicit TLS od početka. STARTTLS (port 587) = počinje nešifriranom vezom, nadograđuje na TLS. IMAPS (port 993) i POP3S (port 995) za čitanje emaila.

HTTPS — port 443

HTTP unutar TLS tunela. Označeno s https:// i ikonom lokota u pregledniku. Certifikat mora biti izdan od trusted CA-a, pravilno instaliran i redovito obnavljan. Mutual TLS (mTLS) = i server i klijent imaju certifikat.

9. Aplikacijska sigurnost — tehnike

Aplikacijska sigurnost obuhvaća prakse u dizajnu, razvoju, testiranju i deploymentu softvera s ciljem smanjivanja ranjivosti i otpora prema napadima.

Input validation

Provjera svega što korisnik unese ili API prima — duljina, format, tip podatka, dozvoljeni znakovi. Primjenjuje se na svakoj granici sustava (korisnik → aplikacija, API pozivi, datoteke).

SQL injection prevencija

Koristiti parameterized queries (prepared statements) umjesto string konkatenacije. Nikad ne unositi neobrađeni korisnički input direktno u SQL upit. ORM alati pomažu ali ne eliminiraju rizik.

XSS (Cross-Site Scripting) prevencija

Escapati sve korisnički generirane podatke pri ispisivanju u HTML-u. Koristiti Content Security Policy (CSP) header. Validirati da unos ne sadrži HTML/JS oznake osim ako su eksplicitno dozvoljene.

Allowlist vs denylist za input

Allowlist (whitelist) = definiraj što je dozvoljeno, odbij sve ostalo. Denylist = definiraj što je zabranjeno, propusti ostalo. Allowlist je sigurniji jer novi vektori napada automatski padaju.

Principle of Least Privilege u aplikacijama

Minimalni DB privilegiji

Aplikacijski korisnički račun za bazu podataka smije imati samo SELECT, INSERT, UPDATE na tablicama koje treba — ne DROP, ALTER, CREATE. Smanjuje impakt SQL injection napada.

Minimalni OS privilegiji

Web server i aplikacijski server trebaju se pokretati pod dedicated service accountom s minimalnim dozvolama — ne kao root/Administrator. Kompromis servera → ograničen scope.

Sigurno upravljanje sesijama

Session token sigurnost

Koristiti kriptografski slučajne tokene visoke entropije. Postaviti razumno kratko trajanje sesije. Invalidirati sesiju pri odjavi i pri promjeni privilegija. Rotirati token pri privilegiranim operacijama.

Secure i HttpOnly cookie flags

Secure flag = cookie se šalje samo HTTPS vezom. HttpOnly flag = JavaScript ne može pristupiti kolačiću (štiti od XSS krađe sesijskog tokena). SameSite = zaštita od CSRF napada.

MFA za osjetljive operacije

Čak i unutar aktivne sesije, visoko rizične operacije (promjena lozinke, veliki transfer, admin action) trebaju ponovnu autentifikaciju ili drugi faktor.

Sigurno logiranje i monitoring

Structured logging

Logovi trebaju biti strukturirani (JSON, syslog), vremenski žigosani i centralizirano pohranjeni. Svaki security-relevantni događaj mora se zabilježiti: autentifikacija, autorizacijski fail, promjene konfiguracije, neobične operacije.

Ne logirati osjetljive podatke

Lozinke, session tokeni, PII, kreditne kartice nikad ne smiju završiti u logovima. Logovi moraju biti zaštićeni od neovlaštenog pristupa i imati definirano trajanje pohrane.

Monitoring i alerting

Logovi moraju biti integrirani sa SIEM sustavom za korelaciju i detekciju anomalija. Definiraj prag za alerting — previše lažnih alarma vodi na alarm fatigue.

Redovito ažuriranje i patching

Sve komponente (framework, library, runtime, OS) moraju biti redovito ažurirane. Software Composition Analysis (SCA) alati automatski otkrivaju ranjive dependencies (npm audit, OWASP Dependency-Check).

10. Sandboxing

Sandboxing izolira aplikaciju, proces ili kod unutar kontroliranog okruženja s ograničenim pristupom resursima hosta i mreže. Malware ili ranjivi kod ne može izaći iz sandboxa i oštetiti ostatak sustava.

Sandboxing — nepouzdani kod radi unutar izoliranog okruženja bez pristupa resursima hosta

Use cases sandboxinga

Analiza malwarea (dynamička analiza u kontroliranom okruženju). Pokretanje nepouzdanih aplikacija (preuzeti software, email attachment). Testiranje novih koda/patcha bez rizika za produkcijski sustav. Preglednici izoliraju svaki tab u sandbox. Mobilni OS-ovi izoliraju svaku aplikaciju.

Tehnologije sandboxinga

OS-level: chroot, Linux namespaces, cgroups, seccomp. Virtualizacija: VM kao sandbox (VMware, Hyper-V, KVM). Kontejneri: Docker (ograničenija izolacija od VM-a). Komercijalni sandbox alati: Cuckoo Sandbox, Any.run, FireEye, Palo Alto WildFire.

Sandbox evasion

Napredniji malware otkriva da se izvršava u sandboxu (provjera CPU broja, RAM-a, korisničke aktivnosti, vremena izvođenja) i ne pokazuje maliciozno ponašanje dok je u njemu. Moderni sandbox alati simuliraju realnu korisničku aktivnost.

Email sandbox (attachment sandbox)

Email security gateway otvara attachmente u sandboxu i analizira ponašanje prije dostave korisniku. Detectira zero-day malware koji ne odgovara poznatim signaturama.

11. FTP, SFTP i FTPS

FTP (File Transfer Protocol) je popularan protokol za prijenos datoteka zbog učinkovitosti i široke podrške, ali ne nudi nikakvu sigurnost — sve se prenosi cleartext-om, uključujući vjerodajnice.

Rogue FTP server

Windows IIS uključuje HTTP, FTP i SMTP servere koji mogu biti instalirani i omogućeni bez znanja administratora. Korisnici koji instaliraju neovlaštene servere na PC-jeve (rogue serveri) stvaraju sigurnosni rizik.

SFTP — SSH File Transfer Protocol

Koristi SSH tunel (port 22) za sigurni prijenos. Enkripcija autentifikacije i podataka. Zahtijeva SSH server s SFTP podrškom i SFTP klijent. Jednostavno za vatrozid — samo jedan port.

FTPS — FTP over SSL/TLS

Dvije varijante: FTPES (Explicit TLS) = koristi AUTH TLS naredbu na portu 21 za nadogradnju na TLS; FTPS (Implicit TLS) = TLS tunel uspostavljen odmah na portu 990. FTPES je preferiran jer je lakše proći kroz vatrozid.

Protokol	Port	Sigurnost	Napomena
FTP	20/21 (TCP)	Cleartext	Ne koristiti za osjetljive podatke
SFTP	22 (TCP)	SSH enkripcija	Preporučeno — jednostavno za firewall
FTPES (Explicit TLS)	21 (TCP)	TLS (nadogradnja)	Preferiran nad Implicit FTPS
FTPS (Implicit TLS)	990 (TCP)	TLS (od početka)	Kompliciraniji s vatrozidom

12. Email protokoli — portovi i sigurnost

Email infrastruktura koristi dvije vrste protokola: SMTP za slanje i mailbox protokoli (POP3/IMAP) za preuzimanje poruka.

SMTP i SMTPS — portovi

Port	Namjena	Sigurnost
25	SMTP relay između mail servera (MTA↔MTA)	STARTTLS opcijalan ako oba servera podržavaju
587	Mail submission — klijent → SMTP server (MSA)	STARTTLS obavezan + autentifikacija — preporučeni port za klijente
465	SMTPS — implicit TLS (deprecated standard)	TLS od samog početka veze — neki provideri i dalje koriste

STARTTLS vs Implicit TLS (SMTPS)

STARTTLS naredba nadograđuje postojeću nešifriranu vezu na TLS (oportunistički TLS, explicit TLS). SMTPS uspostavlja TLS tunel prije bilo koje SMTP naredbe (HELO i sl.). STARTTLS je šire implementiran od SMTPS.

POP3 i POP3S

POP3 — Post Office Protocol v3

Port 110 (cleartext). Klijent se spaja, autenticira, preuzima sve poruke na lokalni PC i tipično ih briše s servera. Jednostavan — nema sync između uređaja.

POP3S

POP3 unutar TLS tunela. Port 995. Štiti vjerodajnice i sadržaj poruka od sniffinga.

IMAP i IMAPS

IMAP — Internet Message Access Protocol

Port 143 (cleartext). Za razliku od POP3: podržava trajne veze, upravljanje mapama na serveru, više klijenata istovremeno na istom mailboxu. Poruke ostaju na serveru — sinhronizirano između uređaja.

IMAPS

IMAP unutar TLS tunela. Port 993. Standard za moderan siguran pristup emailu s više uređaja.

Ispit — portovi napamet

SMTP=25 · Submission=587 · SMTPS=465 · POP3=110 · POP3S=995 · IMAP=143 · IMAPS=993

13. Email gateway, S/MIME i DLP

Email gateway

Email gateway je kontrolna točka za sav dolazni i odlazni email promet. Pregledava sve emailove i uklanja prijetnje prije dostave u inbox.

Što gateway radi

Anti-spam filtriranje, antivirus skeniranje, detekcija phishinga i malicioznih URL-ova, skeniranje attachmenta (sandbox), provjera SPF/DKIM/DMARC, DLP enforcement, content filtering, attachment blocking.

Policy enforcement

Organizacije mogu definirati pravila za sadržaj i attachmente temeljem internih politika ili regulatornih zahtjeva (GDPR, HIPAA, PCI DSS). Gateway automatski primjenjuje te politike.

S/MIME — Secure/Multipurpose Internet Mail Extensions

Što je S/MIME

Protokol za enkripciju i digitalno potpisivanje email poruka (body emaila). Koristi PKI — javni ključ primatelja za enkripciju, privatni ključ pošiljatelja za potpis. Certifikat mora biti izdan od trusted CA-a.

Što S/MIME pruža

Enkripcija = povjerljivost sadržaja (samo primatelj može dešifrirati). Digitalni potpis = autentifikacija pošiljatelja + integritet (poruka nije modificirana). Štiti body emaila — ne metapodatke (From, To, Subject su vidljivi).

Ograničenja S/MIME

Implementacija je kompleksna i sklona pogreškama. Zahtijeva da oba korisnika imaju S/MIME certifikate i razmijene javne ključeve. Teško skalirati u velikim organizacijama. Nije zamjena za SPF/DKIM/DMARC.

DLP — Data Loss Prevention

Što je DLP

Tehnologije koje sprječavaju neovlašteno dijeljenje ili širenje osjetljivih informacija. DLP skenira emailove i attachmente na osjetljive podatke (brojevi kreditnih kartica, OIB/SSN, povjerljivi poslovni podaci, IP).

Akcije DLP sustava

Blokiranje emaila, alert administratoru ili pošiljatelju, automatska enkripcija prije slanja, quarantine za pregled. Politike se definiraju temeljem regex obrazaca, ključnih riječi, klasifikacijskih labela.

Regulatorna usklađenost

GDPR, HIPAA, PCI DSS zahtijevaju zaštitu specifičnih kategorija podataka. DLP je ključan mehanizam za dokazivanje usklađenosti i sprječavanje kršenja koja vode do kazni. Implementira se kroz email gateway i endpoint protection alate.

Insider threat zaštita

DLP štiti od internih prijetnji — zaposlenika koji slučajno ili namjerno šalju povjerljive podatke prema vanjskim adresama. Kombinira se s UEBA za detekciju anomalnih obrazaca slanja.

14. DNSSEC, zone transfer i DNS footprinting

DNS sigurnost na privatnoj mreži

Rekurzivni upiti

Lokalni DNS serveri trebaju prihvaćati rekurzivne upite samo od lokalnih hostova — ne s interneta. Autentificirani lokalni hostovi su preferiran pristup. Otvoren rekurzivni resolver je potencijalna žrtva DNS amplification DoS napada.

Access control

Implementirati kontrole pristupa na DNS serveru koje sprječavaju malicioznog korisnika od ručnog mijenjanja DNS zapisa. Klijenti trebaju biti ograničeni na korištenje ovlaštenih resolvera.

Patchiranje DNS softvera

BIND (Berkeley Internet Name Domain) — najčešći DNS server — ima poznate ranjivosti u pojedinim verzijama. Kritično je pratiti security announcements ISC-a (isc.org) i redovito patchirati. Isto vrijedi za Microsoft DNS.

DNS footprinting i zone transfer napadi

DNS footprinting

Napadač koristi DNS server privatne mreže za prikupljanje informacija: nazivi servera, IP adrese, topologija mreže. Alati: nslookup, dig. Otkriva arhitekturu unutarnje mreže bez aktivnog skeniranja.

Zone transfer

DNS mehanizam za replikaciju svih zapisa domene (RRset) između primarnog i sekundarnog DNS servera. Ako je dostupan bez autentifikacije, napadač može preuzeti sve DNS zapise domene odjednom — potpuna mapa mreže.

Zaštita zone transfera

ACL koji dozvoljava zone transfer samo na ovlaštene sekundarne DNS servere po IP adresi. Sprječava eksternog napadača od preuzimanja svih informacija o internoj mreži.

DNSSEC — detalji

Kako DNSSEC funkcionira

Autoritativni server za zonu kreira RRset (skup DNS zapisa) potpisan Zone Signing Key (ZSK) privatnim ključem. Resolver verificira potpis koristeći javni ZSK. Zaštita od cache poisoninga i spoofinga.

Zone Signing Key (ZSK) vs Key Signing Key (KSK)

ZSK potpisuje DNS zapise. KSK potpisuje sam ZSK. Razdvajanje: ako je ZSK kompromitiran, može se opozvati i zamijeniti bez mijenjanja KSK-a — domena ostaje operativna. KSK validira parent domena ili ISP.

Chain of trust

KSK za domenu validira parent domena → top-level domena (TLD) validiraju Regional Internet Registries → DNS root serveri su self-validated (M-of-N kontrolna grupa za potpisivanje). Lanac povjerenja od root servera do bilo koje subdomene.

15. Secure Development Lifecycle (SDL) i OWASP

Tradicionalni softverski razvoj fokusiran je na funkcionalnost i performanse uz sigurnost kao naknadnu misao. Moderni pristup integrira sigurnost kroz cijeli razvojni ciklus.

Microsoft SDL

Formalni proces koji integrira sigurnosne prakse u svaku fazu razvoja softvera: dizajn (threat modeling), implementacija (secure coding standards), verifikacija (code review, SAST/DAST), release (final security review), response (patch management). Dostupan na microsoft.com/en-us/securityengineering/sdl.

OWASP SAMM

Software Assurance Maturity Model — okvir za mjerenje i poboljšanje sigurnosnih praksi u razvoju softvera. Ocjenjuje zrelost kroz domene: governance, design, implementation, verification, operations.

OWASP Top 10

Popis 10 najkritičnijih sigurnosnih rizika web aplikacija, redovito ažuriran. Uključuje: injection (SQL, LDAP, XSS), broken authentication, sensitive data exposure, XXE, broken access control, security misconfiguration, insecure deserialization, vulnerable components, insufficient logging.

Injection napadi

Napadač ubacuje maliciozne naredbe ili skripte kroz input mehanizme aplikacije. Kategorije: SQL injection, LDAP injection, XML injection, code injection, XSS (Cross-Site Scripting). Svi se sprječavaju ispravnom input validacijom.

16. Input validation — metode

Input validation je esencijalna tehnika zaštite od injection napada. Svaki input od korisnika ili eksternih sustava mora biti validiran. Bez validacije, aplikacija je ranjiva na SQL injection, XSS, code injection i mnoge druge napade.

Metoda	Opis	Primjer
Allowlisting	Dozvoljava samo unaprijed definirane vrijednosti ili obrasce	Email polje prima samo znakove a-z, 0-9, @, . — sve ostalo odbija
Blocklisting	Eksplicitno blokira poznate štetne inpute (posebni znakovi, SQL ključne riječi)	Blokira `'; DROP TABLE`, `<script>`
Data Type Checks	Provjerava je li input očekivanog tipa (string, integer, datum)	Dob mora biti integer, ne string
Range Checks	Validira da numerički input pada unutar očekivanog raspona	Ocjena mora biti 1–5, ne 999
Regular Expressions (Regex)	Uspoređuje input s očekivanim obrascem ili znakovima maliciozne aktivnosti	Telefon: `^\+?[0-9]15$`
Encoding	Pretvara posebne znakove da se ne interpretiraju kao kod ili naredbe	HTML encoding: `<` → `<`

  Client-side vs server-side validation
Client-side validacija informira korisnika o greškama prije slanja na server — bolja UX. Ali klijent je uvijek ranjiviji na malware i manipulaciju. Server-side validacija je obavezna — svaki input mora biti ponovo validiran na serveru čak i ako je prošao client-side provjeru. Oslanjati se isključivo na client-side je loša praksa.
 Allowlist > Blocklist
Blocklist mora eksplicitno pokriti sve poznate napade — nova varijanta prolazi dok se ne doda. Allowlist automatski blokira nepoznate napade jer sve što nije na listi je odbijeno. Allowlist je sigurniji ali zahtijeva pažljivo definiranje dozvoljenih ulaza.
 
  17. SAST, DAST i code signing
 Static Code Analysis (SAST)
  Što je SAST
Static Application Security Testing — analiza izvornog koda bez izvođenja programa. Identificira ranjivosti, greške i nesigurne prakse rano u razvojnom ciklusu. Alati: SonarQube, Coverity, Fortify (OpenText). Integrira se u IDE i CI/CD pipeline.
 Prednosti SAST
Rana detekcija bugova i sigurnosnih ranjivosti, ušteda troškova (jeftinije popraviti rano). Poboljšava kvalitetu koda provođenjem standarda. Educira developere o uobičajenim greškama i sigurnosnim rizicima.
 
 Dynamic Application Security Testing (DAST)
  Što je DAST
Testiranje aplikacije u runtime okruženju — "black box" pristup bez pristupa izvornom kodu. Simulira napade kao pravi napadač. Otkriva ranjivosti koje se pojavljuju samo u izvođenju (race conditions, runtime injection). Alati: OWASP ZAP, Burp Suite.
 SAST vs DAST
SAST = analiza koda (rano u ciklusu, pristup kodu). DAST = analiza pokrenute aplikacije (kasno u ciklusu, bez koda). Kombinirani pristup (SAST + DAST) pokriva širi spektar ranjivosti.
 
 Code signing
  Što je code signing
Digitalni potpis software-a koji verificira integritet i autentičnost koda. Razvijač koristi privatni ključ za potpisivanje hasha koda. Javni ključ (u certifikatu od trusted CA-a) omogućuje provjeru potpisa i identiteta publishera.
 Što code signing pruža i što NE pruža
Pruža: dokaz o porijeklu (tko je potpisao), integritet (kod nije modificiran od potpisa). NE pruža: garanciju da je kod siguran ili bez buga. Potpisani kod može sadržavati malware koji je ubacio originalni autor. Code signing ne evaluira kvalitetu ni sigurnost koda.
 Primjena
OS i endpoint alati blokiraju nepotpisani ili nepouzdano potpisani softver (Windows SmartScreen, macOS Gatekeeper). Administratori mogu konfigurirati allow liste za certifikate pouzdanih publishera.
 
  18. Error handling, memory management i data exposure
 Error handling
  Structured Exception Handler (SEH)
Svaka procedura treba imati handlere za predvidive greške i "catchall" handler za neočekivane situacije. Cilj: aplikacija ne smije "pasti" na način koji napadaču omogućuje izvršavanje koda ili injection napad.
 Custom error messages
Defaultni error handleri (npr. framework error page) otkrivaju platformu, stack trace i interno funkcioniranje koda — korisne informacije za napadača. Custom error handleri prikazuju samo ono što developer namjerno odabere — ne tehničke detalje.
 Error vs Exception
Error = uvjet iz kojeg se proces ne može oporaviti (nema memorije). Exception = greška koju blok koda može obraditi bez rušenja procesa. Exception handling je ključan za stabilnost i sigurnost aplikacije.
 
 Memory management
  Buffer overflow
Napadač ubacuje više podataka nego što buffer može primiti → prepisuje susjedna memorijska područja. Može rezultirati izvršavanjem arbitrary koda napadača. Sprječava se: bounds checking, safe funkcijama (strncpy umjesto strcpy), stack canaries, ASLR.
 Nesigurne prakse
Poznate nesigurne funkcije (gets(), strcpy() u C/C++) ne provjeravaju veličinu buffera. Nepouzdani input (korisničke stringovi) mora biti provjeren i sanitiziran prije obrade. Moderni jezici (Java, Python, C#) upravljaju memorijom automatski što smanjuje ove rizike.
 
 Data exposure
  Što je data exposure
Ranjivost koja omogućuje čitanje privilegiranih informacija (token, lozinka, osobni podaci) bez odgovarajućih access kontrola. Aplikacija mora prenositi osjetljive podatke samo između autenticiranih hostova, koristeći enkripciju za zaštitu sesije.
 Kriptografske biblioteke
Koristiti industrijske standardne enkripcijske biblioteke s dokazanom čvrstoćom (OpenSSL, BouncyCastle, libsodium) — ne interno razvijene. Vlastita implementacija kriptografije je gotovo uvijek ranjiva.
 
  19. Sandboxing u security operacijama
 Sandbox alati su ključni u security operacijama za detekciju i razumijevanje malware aktivnosti kroz forenzičku inspekciju — detonacija potencijalno štetnog softvera u kontroliranom okruženju.
   Cuckoo Sandbox
 Open-source sandbox alat. Izvodi datoteke u izoliranom okruženju i analizira ponašanje: system calls, mrežni promet, promjene datotečnog sustava, Registry aktivnost. Generira detaljne izvještaje o ponašanju malwarea.
 
  Joe Sandbox
 Ne zahtijeva setup u organizacijinom okruženju — dostupan kroz web preglednik (cloud-based). Koristi machine learning i višestruke analitičke tehnike. Pruža detaljnu analizu: network, file system, memory, screenshot aktivnosti.
 
  ANY.RUN
 Interaktivni online sandbox — analitičar može sam komunicirati sa sandboxiranim malwareom u realnom vremenu. Vizualni prikaz mrežnih konekcija, procesa i artefakata.
 
  Palo Alto WildFire / FireEye
 Komercijalni sandbox integrirani s gateway sustavima (email, web proxy, vatrozid). Automatski šalju sumnjive datoteke u sandbox i primjenjuju zaštitu u realnom vremenu kada se otkrije prijetnja.
 
 
  Detonacija malwarea
Kontrolirano pokretanje (detonacija) sumnjivog koda unutar sandboxa. Analiza: mrežne konekcije (C2 promet), datoteke koje se kreiraju/modificiraju, Registry promjene, procesi koji se spawnjaju, izlučeni stringovi, C2 adrese. Rezultat je IOC (Indicators of Compromise) lista.
 Sandbox u email gatewayju
Attachmenti se automatski šalju u sandbox za analizu. Ako sandbox detektira maliciozno ponašanje, email se zadržava ili briše. Štiti od zero-day malwarea koji nema poznatog signaturea za antivirus.
 
  Flashcards
 Klikni karticu za okretanje — prednja strana je pitanje, zadnja odgovor.
  HTTPS koristi koji port i što ga čini sigurnim?
Port 443 (TCP). Siguran jer HTTP radi unutar TLS tunela koji pruža enkripciju, autentifikaciju servera (certifikat) i integritet podataka.
 Razlika TLS 1.2 vs TLS 1.3?
TLS 1.3 uklanja mogućnost downgrade napada, uklanja ranjive algoritme (RC4, DES, SHA-1 za potpise), skraćuje handshake i zahtijeva ephemeral key exchange (PFS obavezan).
 Što je cipher suite?
Skup kriptografskih algoritama dogovorenih između klijenta i servera: key exchange (ECDHE), autentifikacija (RSA), bulk enkripcija (AES-GCM), hash (SHA). TLS 1.3 koristi skraćeni format.
 LDAP vs LDAPS — portovi i sigurnost?
LDAP = port 389, cleartext. LDAPS = port 636, TLS tunel od početka veze. SASL + STARTTLS je alternativa unutar LDAP-a (koristi ga Active Directory). Anonimni i Simple Bind trebaju biti onemogućeni.
 Zašto SNMPv1/v2 nije siguran?
Koristi community string (shared password) koji se šalje u čistom tekstu. Nema enkripcije poruka. SNMPv3 donosi korisničku autentifikaciju (hash lozinke) i enkripciju (AES).
 Što je SPF i kako funkcionira?
Sender Policy Framework — DNS TXT zapis koji navodi koji mail serveri (IP adrese) smiju slati email u ime domene. Prijemni server provjerava IP pošiljatelja s SPF listom. Štiti od email spoofinga.
 Što je DKIM i što garantira?
DomainKeys Identified Mail — pošiljateljev server digitalno potpisuje email privatnim ključem. Javni ključ je u DNS-u. Prijemni server verificira potpis. Garantira identitet domene i integritet poruke (nije modificirana u prijenosu).
 Što je DMARC i koje su tri moguće akcije?
Domain-based Message Authentication — politika što učiniti kada SPF/DKIM ne prođe. Tri akcije: none (samo prati i izvještava), quarantine (spam mapa), reject (odbaci poruku). Uključuje mehanizam izvještavanja vlasniku domene.
 Razlika DNSSEC vs DoH vs DoT?
DNSSEC = digitalni potpisi DNS zapisa (integritet, ne enkripcija). DoH = DNS upiti unutar HTTPS (port 443, enkripcija, teže filtrirati). DoT = DNS upiti unutar TLS (port 853, enkripcija, lakše identificirati i filtrirati).
 Što je DNS filtriranje i kako blokira malware?
Organizacijski DNS resolver uspoređuje svaki DNS upit s listom malicioznih/zabranjenih domena. Ako domena odgovara, vraca NXDOMAIN ili preusmjerava na block page — klijent nikad ne dobiva pravu IP adresu i ne uspostavlja vezu.
 Razlika SFTP vs FTPS?
SFTP = SSH File Transfer Protocol (port 22, unutar SSH tunela). FTPS = FTP over TLS (port 990 implicit ili 21+STARTTLS). Oba zamjenjuju nesigurni FTP. SFTP je jednostavniji za firewall jer koristi samo port 22.
 HttpOnly i Secure flag na cookieju — čemu služe?
Secure = cookie ide samo HTTPS vezom (ne HTTP). HttpOnly = JavaScript ne može pročitati kolačić (štiti od XSS krađe session tokena). SameSite = zaštita od CSRF. Sva tri trebaju biti postavljena na session cookieju.
 Zašto input validation treba biti na allowlist principu?
Denylist (blacklist) mora pokriti sve poznate napade — nova varijanta prolazi dok se ne doda. Allowlist definira što je dozvoljeno i odbija sve ostalo → automatski blokira nepoznate napade. Sigurniji, ali zahtijeva pažljiviju definiciju dozvoljenih ulaza.
 Sandboxing — koje su ključne use cases?
1. Dinamička analiza malwarea u sigurnom okruženju. 2. Pokretanje nepouzdanih aplikacija/attachmenta. 3. Testiranje koda/patcha prije deploymenta. 4. Izolacija browser tabova. 5. Email gateway sandbox za attachment analizu.
 Što je sandbox evasion?
Tehnika naprednog malwarea koji detektira da se izvršava u sandboxu (niski broj CPU jezgri, malo RAM-a, nema korisničke aktivnosti) i skriva maliciozno ponašanje. Moderni sandbox alati simuliraju realnu korisničku aktivnost da prevare malware.
 Koji email port se koristi za slanje s TLS-om?
Port 587 (SMTP + STARTTLS) za mail submission s TLS-om. Port 465 (SMTPS) = implicit TLS od početka. Port 25 = standardni SMTP između mail servera (obično bez enkripcije krajnjih klijenata). IMAPS = 993, POP3S = 995.
 Što je parameterized query i zašto sprječava SQL injection?
Prepared statement gdje je struktura SQL upita odvojena od korisničkih podataka. DB engine tretira korisnički input isključivo kao podatak, nikad kao SQL kod. String konkatenacija je ranjiva jer napadač može ubaciti SQL kod unutar unosa.
 SNMP MIB i Trap — što su?
MIB (Management Information Base) = baza statistika na SNMP agentu (broj frejmova, iskorištenost CPU, status portova). TRAP = agent inicijativno šalje alert NMS-u bez čekanja na poll (npr. port failure, threshold prekoračen). Trap ide na port 162 UDP.
 Mutual TLS (mTLS) — što je i čemu služi?
Obostrana TLS autentifikacija — i server i klijent imaju certifikat koji verificiraju jedan drugome. Koristi se u API komunikaciji između servisa, zero-trust arhitekturama i enterprise okruženjima gdje se ne smije vjerovati klijentu samo na temelju sesije.
 Zašto DoH može biti problem u enterprise okruženju?
DNS over HTTPS koristi port 443 — isti kao normalni web promet. Korporativni DNS filter ne može presresti i filtrirati DoH upite jer izgledaju kao HTTPS. Napadač ili malware može koristiti DoH za zaobilaženje DNS-baziranih sigurnosnih kontrola.
 FTPES vs FTPS — razlika?
FTPES (Explicit TLS) = koristi AUTH TLS naredbu na portu 21 za nadogradnju nesigurne veze na TLS. FTPS (Implicit TLS) = TLS tunel se odmah uspostavlja na portu 990. FTPES je preferiran jer lakše prolazi kroz vatrozid.
 Koji port koristi SMTP za mail submission od klijenta prema serveru s TLS-om?
Port 587 (MSA — Mail Submission Agent). Zahtijeva STARTTLS i autentifikaciju. Port 25 = relay između MTA servera. Port 465 = SMTPS implicit TLS (deprecated). Port 587 je preporučeni port za email klijente.
 POP3 vs IMAP — ključna razlika?
POP3 (port 110/995s): preuzima poruke na lokalni PC, tipično briše s servera — nema sync. IMAP (port 143/993s): trajne veze, poruke ostaju na serveru, više klijenata istovremeno, upravljanje mapama — sinhronizirano između uređaja.
 Što je S/MIME i što pruža?
Secure/Multipurpose Internet Mail Extensions — protokol za enkripciju (javni ključ primatelja) i digitalno potpisivanje (privatni ključ pošiljatelja) email poruka (body). Pruža povjerljivost, integritet i autentifikaciju pošiljatelja. Zahtijeva PKI certifikate od trusted CA-a za oba korisnika.
 Što je DLP i koje akcije može poduzeti?
Data Loss Prevention — sprječava neovlašteno dijeljenje osjetljivih podataka. Skenira emailove i attachmente. Akcije: blokiranje emaila, alert adminu/pošiljatelju, automatska enkripcija, quarantine za pregled. Ključno za GDPR, HIPAA, PCI DSS usklađenost.
 Što je zone transfer i zašto je sigurnosni rizik?
DNS mehanizam za replikaciju svih zapisa domene između DNS servera. Ako je dostupan bez autentifikacije, napadač može preuzeti sve DNS zapise odjednom — potpuna mapa interne mreže (nazivi servera, IP adrese). Zaštita: ACL koji dozvoljava zone transfer samo ovlaštenim sekundarnim DNS serverima.
 DNSSEC Zone Signing Key (ZSK) vs Key Signing Key (KSK)?
ZSK potpisuje DNS zapise u zoni. KSK potpisuje sam ZSK. Razdvajanje svrhe: ako je ZSK kompromitiran, može se zamijeniti bez mijenjanja KSK-a. KSK validira parent domena ili ISP. Chain of trust ide od root servera do subdomene.
 SAST vs DAST — ključna razlika?
SAST (Static Application Security Testing) = analiza izvornog koda bez pokretanja programa — rano u razvojnom ciklusu, pristup kodu (SonarQube, Fortify). DAST (Dynamic) = testiranje pokrenute aplikacije bez koda — black box, simulira napade kao napadač (OWASP ZAP, Burp Suite).
 Što code signing garantira, a što NE garantira?
Garantira: porijeklo (tko je potpisao), integritet (kod nije modificiran od potpisa). NE garantira: da je kod siguran, bez buga ili bez malwarea kojeg je ubacio originalni autor. Code signing je o autentičnosti — ne o kvaliteti koda.
 Zašto custom error messages poboljšavaju sigurnost?
Defaultni error handleri (framework/OS error pages) otkrivaju platformu, verziju, stack trace i unutarnju logiku — korisne informacije za napadača (fingerprinting). Custom handleri prikazuju samo što developer namjerno odabere, bez tehničkih detalja o sustavu.
 
  Kviz — 60 pitanja
 Mješavina tipova kao na pravom ispitu. Traži se najbolji odgovor.
  0 / 60
 Riješi kviz da vidiš rezultat.
 
   1Koji port standardno koristi HTTPS?jedan odgovor
  80 (TCP)  8080 (TCP)  443 (TCP)  8443 (TCP) HTTPS = HTTP unutar TLS tunela. Standardni port je 443/TCP. Port 80 je HTTP (cleartext). Port 8080 često koriste development serveri ili proxy. Port 8443 alternativni HTTPS za dev okruženja.
  
 
   2TLS 1.3 u odnosu na TLS 1.2 uvodi koje ključno poboljšanje?jedan odgovor
  Dodaje podršku za RC4 enkripciju  Onemogućuje downgrade napade i zahtijeva ephemeral key exchange (PFS obavezan)  Povećava maksimalnu veličinu certifikata  Uvodi podršku za SHA-1 potpise TLS 1.3 uklanja mogućnost downgrade napada, uklanja zastarjele algoritme (RC4, DES, MD5, SHA-1 za potpise) i zahtijeva ephemeral key exchange → PFS je obavezan za sve veze. Handshake je i brži (manje round-tripova).
  
 
   3LDAPS (LDAP Secure) koristi koji port?jedan odgovor
  389  443  636  3268 LDAP = port 389 (cleartext). LDAPS = port 636 (TLS tunel uspostavlja se odmah pri spajanju). Port 3268 koristi Global Catalog u Active Directory okruženjima.
  
 
   4SNMPv3 nadmašuje SNMPv1/v2c u sigurnosti jer?jedan odgovor
  SNMPv3 koristi TCP umjesto UDP  SNMPv3 ne koristi MIB bazu podataka  SNMPv3 uvodi korisničku autentifikaciju (hash lozinke) i enkripciju poruka (AES)  SNMPv3 eliminira potrebu za community stringovima i koristi OAuth SNMPv1/v2c koriste community string u čistom tekstu. SNMPv3 uvodi usm (user-based security model): korisnici s hashiranim lozinkama, digitalni potpisi poruka i opcionalna AES enkripcija. Community string koncept je zamijenjen korisničkim računima.
  
 
   5SPF DNS zapis govori prijemnom mail serveru što?jedan odgovor
  Koje akcije poduzeti kada email ne prođe provjeru  Javni ključ za verifikaciju DKIM potpisa  Koji mail serveri (IP adrese) smiju slati email u ime domene  Koji SMTP portovi su dozvoljeni za domenu SPF (Sender Policy Framework) je DNS TXT zapis koji sadrži listu ovlaštenih mail servera (IP rasponi ili hostname) za domenu. Prijemni server provjerava IP pošiljatelja s SPF listom. Ako nije na listi → email je suspektan (SPF fail).
  
 
   6DKIM mehanizam štiti od čega?jedan odgovor
  Spam emailova s poznatih IP adresa  DDoS napada na mail server  Modificiranja emaila u prijenosu i spoofinga domene pošiljatelja  Phishinga putem attachmenta DKIM potpisuje email privatnim ključem. Primatelj verificira potpis javnim ključem iz DNS-a. Ako se email modificira u prijenosu (on-path napad, relay) ili domena lažno predstavlja drugu, DKIM provjera ne prođe. Garantira autentičnost i integritet.
  
 
   7DMARC politika "quarantine" znači što?jedan odgovor
  Email se odmah briše  Email se isporučuje normalno ali se prati  Email koji ne prođe SPF/DKIM provjeru se preusmjerava u spam/junk mapu  Email se šalje na administratorski pregled DMARC ima tri politike: none (isporuči, samo izvještavaj), quarantine (premjesti u spam), reject (odbaci poruku). "Quarantine" je srednji korak — korisnik može provjeriti spam mapu, ali email nije u inboxu.
  
 
   8DNS filtriranje blokira maliciozne domene na kojoj razini?jedan odgovor
  Aplikacijskoj (Layer 7) — analizira HTTP sadržaj  Transportnoj (Layer 4) — blokira TCP portove  DNS razoluciji — vraća NXDOMAIN ili redirect umjesto IP adrese maliciozne domene  Fizičkoj (Layer 1) — onemogućuje mrežno sučelje DNS filtriranje intercepts DNS upite i za maliciozne domene vraća NXDOMAIN ili preusmjerava na block page. Klijent nikad ne dobiva pravu IP adresu → TCP veza se ne uspostavlja. Radi neovisno o protokolu (HTTP, HTTPS, FTP…).
  
 
   9DNSSEC pruža što, a što NE pruža?jedan odgovor
  Pruža enkripciju DNS prometa; ne pruža autentifikaciju  Pruža integritet i autentičnost DNS odgovora; NE šifrira DNS promet  Pruža enkripciju i integritet DNS prometa  Pruža filtriranje malicioznih domena; ne pruža enkripciju DNSSEC digitalno potpisuje DNS zapise → resolver može verificirati da odgovor dolazi od ovlaštenog servera i nije modificiran (sprječava cache poisoning i spoofing). ALI ne šifrira DNS promet — upiti i odgovori su vidljivi na mreži. DoH/DoT šifriraju promet.
  
 
   10Koji cipher suite format odgovara TLS 1.3 standardu?jedan odgovor
  ECDHE-RSA-AES128-GCM-SHA256  TLS_AES_256_GCM_SHA384  RSA-AES256-SHA512  DHE-DSS-AES128-SHA TLS 1.3 koristi skraćeni format: TLS_{enkripcija}_{hash}. Key exchange je uvijek ephemeral (ECDHE ili DHE), a tip potpisa dolazi iz certifikata → ne navode se u cipher suiteu. Format s 4+ komponenti (ECDHE-RSA-AES128-GCM-SHA256) je TLS 1.2 format.
  
 
   11Što je downgrade napad u kontekstu TLS protokola?jedan odgovor
  Napadač preuzima TLS certifikat i koristi ga za vlastite domene  Napadač smanji bandwidth TLS veze da izazove DoS  On-path napadač manipulira handshakeom da prisiljenjem ugovori stariju, ranjiviju verziju protokola ili slabiji cipher suite  Napadač dešifrira TLS promet bruteforceom Downgrade napad (npr. POODLE) prisiljava klijenta i server da "padnu" na TLS 1.0 ili SSL 3.0 gdje postoje poznate ranjivosti. TLS 1.3 eksplicitno onemogućuje downgrade ugrađivanjem verzije u kriptografski materijal handshakea.
  
 
   12U Active Directory okruženju, koji je preferirani mehanizam sigurnog LDAP bindinga?jedan odgovor
  Simple Bind s LDAPS  Anonimni pristup s SSL-om  SASL + STARTTLS (Kerberos autentifikacija s enkripcijom)  No Authentication + VPN Microsoft preporučuje SASL (Simple Authentication and Security Layer) s STARTTLS za AD LDAP. SASL podržava Kerberos → jaka autentifikacija. STARTTLS dodaje enkripciju i integritet. Simple Bind šalje lozinku cleartext čak i s LDAPS.
  
 
   13Zašto DoH može biti sigurnosni problem u enterprise okruženju?jedan odgovor
  DoH ne šifrira DNS promet pa je ranjiv na sniffing  DoH zahtijeva poseban hardware  DoH koristi port 443 pa DNS filtar ne može razlikovati DoH od normalnog HTTPS prometa i ne može ga filtrirati  DoH ne podržava DNSSEC DNS over HTTPS šalje DNS upite unutar HTTPS na portu 443. Korporativni DNS filter koji radi na razini DNS-a (port 53) ne vidi DoH promet. Malware ili korisnik može zaobići DNS filtriranje korištenjem DoH servera. DoT (port 853) je lakše identificirati i blokirati.
  
 
   14SFTP (SSH File Transfer Protocol) za razliku od FTPS koristi koji port?jedan odgovor
  21 (TCP)  990 (TCP)  22 (TCP) — unutar SSH tunela  443 (TCP) SFTP radi unutar SSH tunela na portu 22. FTPS (FTP over TLS) koristi port 990 (implicit TLS) ili 21 + STARTTLS (explicit TLS). Prednost SFTP-a: firewall konfiguracija je jednostavnija jer je samo jedan port.
  
 
   15HttpOnly flag na session cookieju sprječava što?jedan odgovor
  Cookie se šalje HTTP vezom (ne samo HTTPS)  Cookie ističe nakon 30 minuta  JavaScript kôd (uključujući injektirani XSS payload) ne može čitati vrijednost kolačića  Cookie se šifrira AES-256 algoritmom HttpOnly flag sprječava JavaScript API (document.cookie) da čita kolačić. XSS napad koji injektira JS kôd ne može ukrasti session token. Secure flag dodatno osigurava da se cookie šalje samo HTTPS vezom. SameSite sprječava CSRF.
  
 
   16Parameterized query (prepared statement) sprječava SQL injection jer?jedan odgovor
  Šifrira sve SQL upite AES-om  Ograničuje duljinu korisničkog unosa  Struktura SQL upita je fiksirana unaprijed; korisnički unos tretira se isključivo kao podatak, nikad kao SQL kôd  Blokira sve posebne znakove u unosu Prepared statement odvaja SQL logiku od podataka. DB engine "zna" strukturu upita prije nego dobije parametre. Korisnički input ' OR '1'='1 tretira se kao string koji treba naći u bazi — ne kao SQL logika. String konkatenacija je ranjiva jer input postaje dio SQL koda.
  
 
   17Email sandbox na mail gatewayju služi za što?jedan odgovor
  Enkripciju emailova u prijenosu  Provjeru SPF i DKIM zapisa  Dinamičku analizu attachmenta izvršavanjem u izoliranom okruženju prije dostave korisniku  Blokiranje spam emailova po sadržaju poruke Email sandbox otvara attachment (PDF, Word, exe) u izoliranom virtualnom okruženju i promatra ponašanje — mrežne konekcije, promjene datotečnog sustava, registry, procese. Može otkriti zero-day malware koji nema poznatog signaturea. Tek potom isporučuje email korisniku.
  
 
   18SNMP Trap poruka se šalje na koji port i tko je inicira?jedan odgovor
  Port 161 UDP; NMS inicira poll  Port 443 TCP; agent šalje svake minute  Port 162 UDP; agent inicijativno šalje NMS-u kada se dogodi određeni događaj  Port 514 UDP; syslog server inicira zahtjev SNMP poll (GET request) od NMS-a prema agentu ide na port 161 UDP. SNMP Trap od agenta prema NMS-u ide na port 162 UDP. Agent sam inicira Trap kada se dogodi threshold event (pad porta, prekoračenje CPU-a itd.) bez čekanja da ga NMS pita.
  
 
   19Koji od navedenih protokola zamjenjuje Telnet za siguran remote shell pristup?jedan odgovor
  FTPS  HTTPS  SSH (Secure Shell)  LDAPS Telnet (port 23) prenosi sve u cleartext — uključujući lozinke i naredbe. SSH (port 22) pruža šifrirani remote shell, SCP i SFTP prijenos datoteka. Autentifikacija ključem (SSH key pair) je sigurnija od lozinke. SSH je standard za upravljanje serverima i mrežnom opremom.
  
 
   20Aplikacijski korisnički račun za bazu podataka prema principu least privilege smije imati?jedan odgovor
  DBA (Database Administrator) privilegije za sve operacije  Root pristup bazi podataka  Samo SELECT/INSERT/UPDATE na tablicama koje aplikacija stvarno koristi — ne DROP, ALTER, CREATE  Pristup svim tablicama ali samo za čitanje Least privilege u DB kontekstu: web aplikacija treba čitati i pisati podatke — ne treba modificirati shemu (ALTER, DROP), kreirati tablice ili imati admin pristup. SQL injection napad kompromitira samo ono što račun smije raditi. DBA privilegije = napadač može sve.
  
 
   21Koji od navedenih je primjer "sandbox evasion" tehnike?jedan odgovor
  Malware šifrira sve datoteke na disku  Malware šalje podatke na C2 server  Malware provjerava broj CPU jezgri i RAM — ako je < 2 jezgre i < 2GB RAM, zaključuje da je u sandboxu i ne pokazuje maliciozno ponašanje  Malware briše event logove Sandbox okruženja često imaju minimalan hardware (1-2 CPU jezgre, 1-2 GB RAM, nema korisničkih datoteka, kratko uptime). Napredniji malware ove indikatore koristi da detektira sandbox i "spava" dok ne bude pokrenut na pravom sustavu. Rješenje: sandbox s realnim hardwareom i simuliranom korisničkom aktivnošću.
  
 
   22Content Security Policy (CSP) HTTP header služi za zaštitu od?jedan odgovor
  SQL injection napada  Brute force napada na lozinke  XSS (Cross-Site Scripting) napada — definira koje izvore skripti, stilova i medija preglednik smije učitati  DDoS napada CSP header govori pregledniku s kojih domena smije učitavati JavaScript, CSS, slike i druge resurse. Ograničavanjem na trust-liste domena, čak i ako napadač injektira <script src="evil.com/xss.js">, preglednik ga odbija izvršiti jer evil.com nije na CSP listi.
  
 
   23Koji port koristi SMTPS za slanje emaila s implicit TLS-om?jedan odgovor
  25  587  465  993 Port 25 = standardni SMTP između mail servera (bez enkripcije). Port 465 = SMTPS (SMTP s implicit TLS — TLS odmah pri spajanju). Port 587 = SMTP mail submission s STARTTLS (nadogradnja na TLS). Port 993 = IMAPS (čitanje emaila s TLS-om).
  
 
   24Structural logging u aplikacijama doprinosi sigurnosti na koji način?jedan odgovor
  Šifrira sve log datoteke AES algoritmom  Sprječava SQL injection napade  Pruža strukturirane, strojno čitljive podatke koji se mogu integrirati u SIEM za korelaciju, detekciju anomalija i forenziku  Automatski patchira ranjivosti u kodu Structured logging (JSON, syslog) omogućuje SIEM sustavu da parsira i korelira logove bez kompleksnog string parsinga. Svaki security event (failed login, privilege escalation, unusual data access) mora biti zabilježen s timestamp-om, korisničkim ID-om i kontekstom za forenziku i alerting.
  
 
   25Mutual TLS (mTLS) razlikuje se od standardnog TLS-a jer?jedan odgovor
  mTLS šifrira promet jačim algoritmima  mTLS ne zahtijeva certifikat  I klijent i server moraju imati certifikat — obostrana autentifikacija, ne samo serverova  mTLS koristi lozinku umjesto certifikata Standardni TLS: samo server ima certifikat → klijent verificira server. mTLS: i server verificira klijenta (klijent ima certifikat). Koristi se za API komunikaciju između servisa, zero-trust okruženjima i VPN-ovima gdje se mora autenticirati i klijent.
  
 
   26Koji od navedenih alata pruža komercijalno DNS filtriranje temeljeno na threat intelligence feedu?jedan odgovor
  Wireshark  Metasploit  Cisco Umbrella (OpenDNS)  Nmap Cisco Umbrella (bivši OpenDNS) je cloud-based DNS resolver s threat intelligence. Automatski blokira maliciozne, phishing i C2 domene. Cloudflare Gateway i Palo Alto DNS Security su alternativni komercijalni DNS filteri. Wireshark = packet analyzer, Metasploit = exploitation framework, Nmap = port scanner.
  
 
   27Organizacija želi implementirati najstrožu DMARC politiku. Koja je to?jedan odgovor
  p=none  p=quarantine  p=reject  p=monitor DMARC politike od najliberalnije do najstrože: none → samo izvještava, email prolazi. quarantine → email ide u spam. reject → email se potpuno odbacuje (ne isporučuje se). Organizacije počinju s "none" da vide izvještaje, zatim prelaze na "quarantine" i konačno "reject".
  
 
   28Što je HKDF (Hash Key Derivation Function) u TLS 1.3 kontekstu?jedan odgovor
  Algoritam za šifriranje poruka  Metoda za generiranje certifikata  Mehanizam kojim se Diffie-Hellman dijeljeni tajni ključ koristi za derivaciju simetričnih session ključeva  Protokol za razmjenu certifikata između CA i servera TLS 1.3 koristi HKDF (HMAC-based Extract-and-Expand Key Derivation Function) za derivaciju simetričnih ključeva iz DH dijeljene tajne. HKDF "razvlači" jedan dijeljeni tajni u više zasebnih ključeva za različite namjene (server write key, client write key, itd.).
  
 
   29Aplikacija loggira korisničke lozinke u error logove. Koji je sigurnosni problem?jedan odgovor
  Logovi zauzimaju previše diskovnog prostora  Logovi se ne mogu čitati sa SIEM sustavom  Lozinke u logovima su dostupne svakome tko ima pristup log datotekama — direktna kompromitacija korisničkih računa  Log rotacija brisati će logove prebrzo Logovi se često pohranjuju na više sustava (log aggregator, SIEM, backup) i pristupačni su širem krugu administratora nego sama aplikacija. Lozinke, API ključevi, tokeni i PII nikad ne smiju biti u logovima. Minimalna sanacija: maskirati/redaktirati osjetljive podatke (npr. password=***) ili ih uopće ne logirati.
  
 
   30Koja tehnologija sandboxinga pruža najsnažniju izolaciju između sandbox okruženja i host sustava?jedan odgovor
  Docker kontejner  chroot jail  Hardverska virtualizacija (VM — VMware, Hyper-V, KVM)  Linux namespaces VM je najjača izolacija jer svaka VM ima vlastiti virtualni hardware, kernel i OS. Docker kontejneri dijele host kernel → kontejner escape napadi su mogući. chroot samo ograničava vidljivi filesystem. VM izolacija se oslanja na hypervisor — VM kompromis ne kompromitira host direktno.
  
 
   31DoT (DNS over TLS) u usporedbi s DoH (DNS over HTTPS) je lakši za korporativno filtriranje jer?jedan odgovor
  DoT ne šifrira DNS promet  DoT je sporiji od DoH  DoT koristi dedicirani port 853 koji se lako može blokirati ili nadzirati — DoH koristi port 443 koji se ne može lako odvojiti od normalnog HTTPS  DoT zahtijeva poseban DNS server DoT koristi port 853 koji organizacije mogu blokirati ili preusmjeriti na vlastiti DNS resolver. DoH koristi port 443 — isti kao sav HTTPS promet — pa ga nije moguće jednostavno blokirati a da se ne pokvari normalno web pregledavanje. Organizacije moraju koristiti DPI ili blokirati poznate DoH servere po IP-u.
  
 
   32IMAPS koristi koji port?jedan odgovor
  143  110  993  995 IMAP (cleartext) = port 143. IMAPS (IMAP over TLS) = port 993. POP3 (cleartext) = port 110. POP3S (POP3 over TLS) = port 995. Uvijek preferirajte S (Secure) verziju pri konfiguraciji email klijenata.
  
 
   33Telnet je posebno rizičan u usporedbi s SSH jer?jedan odgovor
  Telnet je sporiji od SSH-a  Telnet ne podržava UDP promet  Telnet sve prenosi u cleartext — korisničko ime, lozinka i sve naredbe vidljive su svakome tko prisluškuje mrežni promet  Telnet podržava samo Windows sustave Telnet (port 23) ne koristi nikakvu enkripciju. Svaki paket u sniffer alatu (Wireshark) prikazuje puno login ime, lozinku i sve unijete naredbe. Na nesigurnim mrežama (Wi-Fi, shared network) ovo je kritična ranjivost. SSH (port 22) šifrira čitavu sesiju.
  
 
   34Organizacija prima DMARC izvještaje koji pokazuju da napadači pokušavaju lažno predstaviti njenu domenu. DMARC politika je "none". Koji je sljedeći korak?jedan odgovor
  Nema akcije — "none" je najjača politika  Onemogućiti DMARC i koristiti samo SPF  Promijeniti DMARC politiku na "quarantine" ili "reject" da se aktivno blokiraju spoofed emailovi  Promijeniti SPF da blokira sve pošiljatelje DMARC "none" = samo prati i izvještava, ne blokira ništa. Organizacija sada ima vidljivost (zna tko pokušava spoofat) i treba preći na "quarantine" (sumnjivi u spam) ili direktno na "reject" (odbaci sve koji ne prođu SPF/DKIM). "Reject" je najjača zaštita.
  
 
   35SameSite flag na session cookieju štiti od kojeg napada?jedan odgovor
  SQL injection  XSS (Cross-Site Scripting)  CSRF (Cross-Site Request Forgery)  Session hijacking putem sniffinga SameSite=Strict ili Lax sprječava da preglednik šalje session cookie u cross-site zahtjevima (npr. kada napadačeva stranica "pozove" legitimnu stranicu u pozadini koristeći korisnikovu sesiju). HttpOnly štiti od XSS krađe tokena. Secure štiti od HTTP sniffinga.
  
 
   36Organizacija mora osigurati da se na mrežnim uređajima ne koriste defaultne SNMP community stringove "public" i "private". Koji je razlog?jedan odgovor
  Defaultni stringovi su predugi i usporavaju SNMP  Defaultni stringovi podržavaju samo read-only pristup  Defaultni stringovi su javno poznati i prenose se u cleartext — svaki napadač na mreži može ih koristiti za čitanje ili modifikaciju MIB podataka  Defaultni stringovi nisu kompatibilni s SNMPv3 Community stringovi "public" (read-only) i "private" (read-write) su defaulti na gotovo svim SNMP uređajima — poznati svima. Prenose se u cleartext → pasivni sniffer ih vidi. Napadač može čitati topologiju mreže, konfiguraciju i potencijalno modificirati uređaj. Promijeniti, koristiti ACL i preferirati SNMPv3.
  
 
   37Software Composition Analysis (SCA) alati kao što su npm audit ili OWASP Dependency-Check koriste se za što?jedan odgovor
  Skeniranje mreže za otvorene portove  Dinamičku analizu runtime ponašanja aplikacije  Otkrivanje poznatih ranjivosti u third-party bibliotekama i dependencyima aplikacije  Statičku analizu vlastitog kôda za SQL injection SCA alati analiziraju popis dependencija (package.json, pom.xml, requirements.txt) i uspoređuju s bazom poznatih ranjivosti (CVE, NVD, Snyk). Otkrivaju da npr. koristite zastarjelu verziju log4j ili jQuery s poznatim XSS ranjivostima — bez da ručno pratite sve CVE-ove.
  
 
   38Koji scenarij opisuje korištenje sandboxinga unutar modernog web preglednika?jedan odgovor
  Preglednik šifrira sve cookies AES-256  Preglednik blokira HTTPS stranice s isteklim certifikatom  Svaki browser tab izvršava se u izoliranom procesu — kompromis jednog taba ne može direktno čitati podatke drugog taba  Preglednik provjerava SPF zapise za sve domene Moderni preglednici (Chrome, Firefox, Edge) izoliraju svaki tab i iframe u zaseban sandbox proces. Ranjivost u web stranici može kompromitirati taj tab, ali ne može direktno pristupiti sadržaju drugog taba, sessionu druge domene ili OS datotekama (bez dodatne exploit razine).
  
 
   39Adminstrator želi osigurati da SNMP nije iskorišten za napad na mrežnu infrastrukturu. Koji skup mjera je najefikasniji?jedan odgovor
  Promijeniti community string i koristiti SNMPv1  Onemogućiti SNMP trap funkcionalnost  Koristiti SNMPv3 s enkripcijom, ACL koji ograničuje pristup na NMS IP adrese, onemogućiti SNMPv1/v2, ne eksponirati SNMP prema internetu  Promijeniti SNMP na nestandardni port Sveobuhvatan pristup: SNMPv3 za autentifikaciju i enkripciju + ACL za ograničenje na specifične IP adrese NMS sustava + onemogućiti stare verzije + firewall blokada SNMP portova (161/162) prema internetu. Samo promjena community stringa bez enkripcije je nedovoljno za SNMPv1/v2.
  
 
   40Organizacija implementira email autentifikacijske protokole. Koji je ispravan redoslijed implementacije?jedan odgovor
  Prvo DMARC, zatim SPF, na kraju DKIM  DKIM je dovoljan bez SPF i DMARC  Prvo SPF i DKIM (temelj), zatim DMARC koji se oslanja na njima — početi s p=none za monitoring, zatim quarantine, pa reject  SPF je dovoljan — DKIM i DMARC su opcijski DMARC se oslanja na SPF i DKIM — bez barem jednog od njih, DMARC nema baze za provjeru. Ispravni redoslijed: 1) Implementirati SPF DNS zapis, 2) Implementirati DKIM potpisivanje, 3) Implementirati DMARC počevši s p=none (monitor) → p=quarantine → p=reject. Ovaj postepeni pristup sprječava legitimne emailove da budu blokirani.
  
 
   41FTPES (Explicit TLS) za FTP razlikuje se od FTPS (Implicit TLS) jer?jedan odgovor
  FTPES koristi port 990, FTPS koristi port 21  FTPES koristi AUTH TLS naredbu na portu 21 za nadogradnju veze; FTPS odmah uspostavlja TLS na portu 990  FTPES šifrira samo autentifikaciju, FTPS i podatke  FTPES i FTPS su identični osim naziva FTPES (Explicit) = spaja se na port 21, šalje AUTH TLS naredbu za nadogradnju na TLS. FTPS (Implicit) = TLS tunel se uspostavlja odmah pri spajanju na port 990. FTPES je preferiran jer je lakše konfigurirati vatrozid (jedan poznati port). Implicit FTPS zahtijeva da obje strane znaju koristiti port 990.
  
 
   42SFTP koristi koji port i koji protokol kao temelj?jedan odgovor
  Port 21, FTP protokol  Port 990, SSL/TLS protokol  Port 22, SSH protokol — SFTP radi unutar SSH tunela  Port 443, HTTPS protokol SFTP (SSH File Transfer Protocol) nije FTP s enkripciom — to je potpuno drugačiji protokol koji radi unutar SSH sesije na portu 22. Prednost: samo jedan port za firewall konfiguraciju. FTPS je FTP s TLS-om i zahtijeva složeniju firewall konfiguraciju zbog aktivnog/pasivnog FTP načina rada.
  
 
   43Koji SMTP port je preporučen za email klijente koji šalju poruke prema mail serveru?jedan odgovor
  Port 25  Port 110  Port 587 (mail submission s STARTTLS i autentifikacijom)  Port 143 Port 587 je standardni mail submission port za klijente. Zahtijeva STARTTLS (nadogradnju na TLS) i autentifikaciju. Port 25 je za relay između MTA mail servera i tipično blokiran ISP-om za krajnje korisnike. Port 465 (implicit TLS/SMTPS) je deprecated. Portovi 110 i 143 su za čitanje emaila (POP3/IMAP).
  
 
   44IMAP ima prednost nad POP3 za organizacije s korisnicima koji pristupaju emailu s više uređaja jer?jedan odgovor
  IMAP je brži od POP3  IMAP automatski šifrira sve emailove  IMAP ostavlja poruke na serveru, podržava više klijenata istovremeno i sinkronizira stanje između svih uređaja  IMAP koristi manje bandwidth-a od POP3 POP3 preuzima poruke na lokalni uređaj i tipično ih briše s servera → pristupaš mailboxu s jednog uređaja. IMAP (port 143, IMAPS port 993) ostavlja poruke na serveru, podržava trajne veze, više klijenata simultano i upravljanje mapama na serveru → sinkronizirano stanje (pročitano/nepročitano) na svim uređajima.
  
 
   45S/MIME digitalni potpis emaila omogućuje primatelju što?jedan odgovor
  Dešifriranje poruke bez ikakve lozinke  Blokiranje budućih poruka od istog pošiljatelja  Verifikaciju identiteta pošiljatelja i potvrdu da poruka nije modificirana u prijenosu  Automatsko prosljeđivanje poruke na sigurniji kanal S/MIME digitalni potpis koristi pošiljateljev privatni ključ za potpisivanje. Primatelj verificira potpis pošiljateljevim javnim ključem (iz S/MIME certifikata). Uspješna verifikacija potvrđuje: 1) poruka dolazi od potpisanog pošiljatelja (autentičnost), 2) poruka nije modificirana u prijenosu (integritet).
  
 
   46Email gateway kombinira koji skup funkcija?jedan odgovor
  Samo anti-spam filtriranje i antivirus  Samo SPF/DKIM/DMARC provjere  Anti-spam, antivirus, phishing/URL detekcija, attachment sandbox, SPF/DKIM/DMARC, DLP, content filtering i policy enforcement  Samo enkripciju emailova Email gateway je sveobuhvatna kontrolna točka za email promet. Kombinira: anti-spam/antivirus skeniranje, detekciju phishinga i malicioznih URL-ova, sandbox za attachmente (zero-day detekcija), SPF/DKIM/DMARC autentifikaciju, DLP za sprječavanje curenja podataka, content filtering i policy enforcement prema regulatornim zahtjevima.
  
 
   47DLP sustav detektira da zaposlenik pokušava emailom poslati 500 dokumenata s oznakom "Povjerljivo". Koja DLP akcija je najrestriktivnija?jedan odgovor
  Alert administratoru ali propusti email  Quarantine — zadržati email za pregled  Blokirati email i automatski obavijestiti pošiljatelja i administratora  Automatski šifrirati i propustiti DLP može poduzeti različite akcije od najmanje do najrestriktivnije: alert → automatska enkripcija → quarantine → blokiranje. Za masu dokumenata klasificiranih kao povjerljivi koji idu van organizacije, blokiranje uz obavijest pošiljatelju i administratoru je najrestriktivnija i najefikasnija zaštita od data exfiltration.
  
 
   48Napadač koristi dig alat prema DNS serveru organizacije i dobiva listu svih hostname-ova, IP adresa i MX zapisa. Što se dogodilo?jedan odgovor
  Uspješan DNS cache poisoning napad  Napadač je iskoristio DNSSEC ranjivost  Napadač je izveo DNS zone transfer jer ACL nije ograničio zone transfer samo na ovlaštene sekundarne servere  Napadač je kompromitirao DNS server direktnim pristupom Zone transfer (AXFR upit) replicira sve DNS zapise domene. Ako DNS server nema ACL koji ograničuje zone transfer na specifične IP adrese sekundarnih servera, svaki može zatražiti transfer — napadač dobiva kompletnu mapu mreže (DNS footprinting). Zaštita: ACL koji blokira zone transfer svima osim ovlaštenim sekundarnim serverima.
  
 
   49DNSSEC chain of trust počinje od?jedan odgovor
  Organizacijskog DNS servera  TLD (Top Level Domain) registara  DNS root servera koji su self-validated (M-of-N kontrolna grupa)  ISP DNS resolvera DNSSEC chain of trust: DNS root serveri (self-validated, M-of-N kontrolna grupa) → Regional Internet Registries koji validiraju TLD → TLD validira parent domenu → parent domena validira KSK organizacije → KSK potpisuje ZSK → ZSK potpisuje DNS zapise. Svaki karika verificira idući nivo niže.
  
 
   50Što je OWASP Top 10?jedan odgovor
  Lista 10 najpopularnijih web frameworka  Certifikacija za web developere  Redovito ažurirana lista 10 najkritičnijih sigurnosnih rizika web aplikacija s opisima i mitigacijama  Popis 10 najčešćih DDoS napada OWASP (Open Web Application Security Project) Top 10 je konsenzualni dokument koji opisuje 10 najkritičnijih sigurnosnih rizika web aplikacija. Uključuje: injection napade (SQL, XSS, LDAP), broken authentication, sensitive data exposure, broken access control, security misconfiguration, vulnerable components itd. Standardna referenca za web application security.
  
 
   51Aplikacija prihvaća korisničko ime kao input i ubacuje ga direktno u SQL upit string konkatenacijom. Napadač unosi: admin'--. Koji je rezultat?jedan odgovor
  Input je blokiran jer sadrži apostrof  Input je automatski enkodiran u HTML  SQL injection — apostrof zatvara string, -- komentira ostatak upita i napadač se možda prijavljuje bez lozinke  Baza podataka odbija upit jer je sintaksa neispravna String konkatenacija: SELECT * FROM users WHERE username='admin'--' AND password='...'. Apostrof zatvara username string, -- komentira AND password dio → upit provjerava samo username. Rješenje: parameterized queries (prepared statements) koji tretiraju input isključivo kao podatak, ne kao SQL kod.
  
 
   52Allowlist metoda validacije inputa je sigurnija od blockliste jer?jedan odgovor
  Allowlist je brža za procesiranje  Allowlist dopušta više tipova inputa  Allowlist automatski odbija sve što nije eksplicitno dozvoljeno — uključujući nepoznate buduće napade; blocklist mora ažurirati svaki novi napadački vektor  Allowlist ne zahtijeva održavanje Blocklist pristup: mora pokriti sve poznate napade. Nova varijanta (zero-day injection) prolazi dok se ne doda u listu. Allowlist pristup: definiraj točno što je dozvoljeno (samo slova, samo brojevi u određenom rasponu itd.) i odbaci sve ostalo — uključujući nove, neviđene napade. Allowlist je "deny by default" pristup.
  
 
   53SAST (Static Application Security Testing) se razlikuje od DAST (Dynamic) jer?jedan odgovor
  SAST testira samo web aplikacije; DAST testira mobile aplikacije  SAST je skuplji od DAST  SAST analizira izvorni kod bez pokretanja programa (white-box); DAST testira pokrenutu aplikaciju bez pristupa kodu (black-box)  SAST otkriva samo runtime greške; DAST otkriva samo logičke greške u kodu SAST (white-box/static): ima pristup izvornom kodu, analizira ga statički — radi rano u razvojnom ciklusu, integrira se u IDE. Alati: SonarQube, Fortify, Coverity. DAST (black-box/dynamic): testira pokrenutu aplikaciju izvan — simulira napade kao pravi napadač. Alati: OWASP ZAP, Burp Suite. Oba zajedno pokrivaju širi spektar ranjivosti.
  
 
   54Code signing certifikat garantira koje dvije stvari?jedan odgovor
  Da je kod siguran i da ne sadrži bugove  Da je kod testiran i da prošao DAST analizu  Identitet publishera (tko je potpisao) i integritet koda (nije modificiran od potpisa)  Da je kod odobren od strane CA za distribuciju Code signing pruža: 1) Autentičnost — certifikat od trusted CA-a dokazuje identitet developera/organizacije. 2) Integritet — hash koda koji je enkriptiran privatnim ključem dokazuje da kod nije modificiran nakon potpisivanja. NE garantira da kod nema ranjivosti, bugova ili namjerno ubačenog malwarea od strane originalnog autora.
  
 
   55Aplikacija prikazuje detaljni stack trace i verziju frameworka kada dođe do greške. Koji je sigurnosni rizik?jedan odgovor
  Nema rizika — stack trace pomaže korisnicima da prijave greške  Rizik je gubitak performansi zbog generiranja stack tracea  Napadač dobiva informacije o platformi, verzijama komponenti i unutarnjoj logici — korisno za targeted napade i iskorištavanje poznatih ranjivosti  Stack trace može srušiti preglednik korisnika Detaljne error poruke (stack trace, verzija frameworka, putanje datoteka, SQL greške) su goldmine za napadača — information disclosure ranjivost. Napadač zna točno koji framework i verziju koristiš → traži poznate CVE-ove. Custom error handleri trebaju prikazivati generičku poruku korisniku i logirati detalje interno.
  
 
   56Buffer overflow napad cilja što?jedan odgovor
  Preopterećenje mreže velikim brojem paketa  Krađu session tokena iz memorije preglednika  Pisanje više podataka nego što buffer može primiti — prepisivanje susjednih memorijskih područja radi izvršavanja arbitrary koda  SQL injection kroz memorijski cache Buffer overflow: aplikacija rezervira buffer fiksne veličine (npr. 256 bajtova). Napadač šalje 512 bajtova → prepisuje return address na stacku → CPU skaće na napadačev shellcode. Prevencija: bounds checking, safe funkcije (strncpy umjesto strcpy), stack canaries, ASLR (Address Space Layout Randomization), DEP/NX bit.
  
 
   57Zašto se kriptografske biblioteke trebaju birati iz industrijskih standarda (OpenSSL, libsodium) umjesto internog razvoja?jedan odgovor
  Standardne biblioteke su uvijek brže  Interne biblioteke zahtijevaju više licenci  Vlastita implementacija kriptografije je gotovo uvijek ranjiva — kriptografija je iznimno složena i standardne biblioteke su testirane i auditrane od strane stotina stručnjaka  Standardne biblioteke ne zahtijevaju ažuriranja "Don't roll your own crypto" — zlatno pravilo sigurnosti. Kriptografija je matematički iznimno složena, a suptilne implementacijske greške (timing napadi, nonce reuse, improper padding) čine i naizgled ispravno izgledajući algoritam ranjivim. Standardne biblioteke su god peer-reviewed, testirane milijunima korisnika i kontinuirano auditrane. Interne implementacije nemaju tu razinu provjere.
  
 
   58Što je "detonacija" u kontekstu sandbox security alata?jedan odgovor
  Fizičko uništavanje zaraženih uređaja  Brisanje malware datoteka s inficiranog sustava  Kontrolirano pokretanje (izvršavanje) potencijalno štetnog softvera unutar sandbox okruženja radi analize ponašanja  Pokretanje exploit koda na napadačevom sustavu Detonacija = sigurno pokretanje sumnjive datoteke/koda u sandboxu. Analitičar ili automatski sustav promatra što se događa: koje procese spawna, koje datoteke kreira/mijenja, koje mrežne konekcije uspostavlja (C2 promet), koje Registry ključeve mijenja. Rezultat = IOC lista i klasifikacija malwarea. Ime dolazi iz analogije s kontroliranom detonacijom eksploziva.
  
 
   59Client-side validacija inputa u web aplikaciji?jedan odgovor
  Dovoljna je za sigurnost jer preglednik je pouzdano okruženje  Treba zamijeniti server-side validaciju zbog performansi  Korisna za UX (brza povratna informacija korisniku) ali uvijek mora biti praćena server-side validacijom — klijent nije pouzdano okruženje  Sigurnija od server-side validacije jer se ne prenosi do servera Client-side validacija (JavaScript) = napadač može je zaobići modificiranjem koda u pregledniku, Burp Suiteom ili direktnim API pozivima. Pruža korisnu UX povratnu informaciju ali nije sigurnosna kontrola. Server-side validacija je obavezna sigurnosna mjera — server ne smije nikad vjerovati inputu koji dolazi s klijenta bez vlastite provjere.
  
 
   60Organizacija koristi Microsoft SDL (Secure Development Lifecycle). Koja aktivnost u fazi implementacije direktno smanjuje SQL injection ranjivosti?jedan odgovor
  Penetration testing produkcijskog sustava  DMARC konfiguracija za email domenu  Secure coding standards koji zahtijevaju parameterized queries i input validation za sve korisničke inpute  Implementacija content security policy (CSP) headera U SDL fazi implementacije, secure coding standards propisuju specifične tehnike za poznate klase ranjivosti. SQL injection se sprječava: parameterized queries (prepared statements), ORM korištenjem, input validacijom i least privilege DB računima. Pentest je u fazi verifikacije/release. DMARC je email zaštita. CSP sprječava XSS, ne SQL injection.