RBS/Januar 2026

Izvor: SI Wiki
< РБС
Datum izmene: 25. februar 2026. u 23:32; autor: Aleksa (razgovor | doprinosi) (→‎4. zadatak)
Pređi na navigaciju Pređi na pretragu

Ispit u januarskom ispitnom roku 2026. godine održan je 18. februara, trajao je sat vremena i radio se preko platforme Moodle u Secure browser.

  • За питања са више одговора, тачни одговори су подебљани и уоквирени
  • За питања за које се одговори уносе, тачни одговори су подвучени и сакривени, тако да се прикажу када изаберете тај текст (пример: овако)
  • Притисните лево дугме испод за сакривање и откривање свих одговора, или десно дугме за укључивање и искључивање интерактивног режима:

1. zadatak

U Heartbeat protokolu koristi se bibliotečka funkcija memcpy iz jezika C i njeno korišćenje je dovelo do ranjivosti Heartblead. Objasniti kako je ova funkcija dovela do toga i kako se ovo može prevazići.

Odgovor:

Funkcija ima potpis memcpy(bp, pl, payload) koja kopira payload bajtova iz bafera pl u bp. Ovo se koristi u Heartbeat za proveru da li je server aktivan. Klijent šalje poruku i dužinu poruke serveru, i server odgovara istom porukom. Ranjivost nastaje jer se ne radi provera da li je payload veći od veličine pl, pa klijent može da pošalje poruku veličine 4B, a payload da postavi na 128KB, i samim tim da pročita osetljive informacije - lozinke, podatke o brojevima kreditnih kartica i slično - buffer overread. Ovo se može prevazići jednostavnom proverom da li je payload veći od veličine pl, i ako da da se prijavi greška.

2. zadatak

Šta od navedenog ne spada u principe bezbednog dizajna:

  1. Razdvojiti odgovornosti
  2. Osigurati najslabiju kariku
  3. Dodeliti najveće potrebne privilegije
  4. Koristiti jednostavna rešenja
  5. Beležiti osetljive događaje
  6. Ne oslanjati se na nejasnost
  7. Implementirati odbranu u dubinu
  8. Ne izmišljati bezbednosnu tehnologiju
  9. Oprezno dodeljivati poverenje:

3. zadatak

Postoje eksplicitni i kvalitativni sigurnosni zahtevi. Odakle potiču eksplicitni sigurnosni zahtevi. Navesti primer eksplicitnog zahteva i objasniti kako je dobijen.

Odgovor:

Eksplicitni zahtevi potiči iz regulativa i standarda. Regulative propisuju zaštitu IKT i zaštitu od napada (zakoni). Moraju se ispoštovati. Standardni su dokumenta odobrena od strane prepoznatih ili priznatih tela za standardizaciju. Ne moraju se ispoštivati. Primer eksplicitnog zahteva - zakon propisuje da nalozi na eUpravi moraju imati lozinku od najmanje 10 karaktera, i to bar 1 veliko slovo, bar 1 broj i bar 1 specijalni karakter iz određenog skupa. Ovo je dobijeno jer je pokazano da se primenom ovih kriterijuma otežava provaljivanje lozinke poznatim tehnikama.

4. zadatak

Ako u sistemu imamo 5 objekata i 5000 subjekata, koju kontrolu pristupa je bolje koristiti?

  1. Kontrola pristupa zasnovana na ulogama
  2. Liste za kontrolu pristupa

5. zadatak

U NIST SSDF da li se koristi statičko testiranje i ako da, u kojoj fazi?

  1. Priprema organizacije
  2. Zaštita softvera
  3. Produkcija dobro zaštićenog softvera
  4. Odgovor na ranjivosti
  5. Ne primenjuje se

6. zadatak

U STRIDE metodologiji, šta predstavlja pretnju Autorizaciji?

  1. Skrivanje identiteta
  2. Neautorizovana izmena podataka
  3. Osporavanje
  4. Neautorizovan pristup podacima
  5. Onemogućavanje pristupa
  6. Podizanje privilegija

7. zadatak

U OSSTMM, šta predstavlja slepo testiranje?

  1. Analitičar nema predznanje o sistemu, a meta je spremna i unapred upoznata sa testiranjem.
  2. Analitičar nema predznanje o sistemu, a meta nije spremna niti upoznata sa testiranjem.
  3. Analitičar poznaje kanale napada i delimično odbrane, a meta je spremna i unapred upoznata sa svim detaljima.
  4. Analitičar poznaje kanale napada i delimično odbrane, a meta je upoznata sa okvirom testiranja, ali ne i sa kanalima i vektorima napada.
  5. Analitičar poznaje sve detalje o mogućim napadima, a meta je spremna i unapred upoznata sa svim detaljima.
  6. Analitičar poznaje sve detalje o mogućim napadima, a meta nije spremna niti upoznata sa testiranjem.

8. zadatak

Šta predstavlja deljenje rizika?

  1. Promena dizajna modula, dodavanje novih radnih zadataka, kupovina dodatnih alata?
  2. Uklanjanje modula koji uvodi rizik
  3. Angažovanje treće strane da se izbegne pretnja ili informisanje klijenta da je njegova obavaza da se pozabavi pretnjom
  4. Prihvatanje rizika

9. zadatak

LOG_FILE_LIST = ["data_log", "system", "access"]
def read_logs(log_file_name):
	if log_file_name not in LOG_FILE_LIST:
		return "Invalid log file name"
	result = subprocess.run(["cat", f"/var/log/{log_file_name}.log"], capture_output=True, text=True)
    return result.stdout

Koja tehnika je primenjena?

  1. Blackisting
  2. Whitelisting
  3. Bezbedan poziv API
  4. Beleženje korisničkih akcija

10. zadatak

Za isti kod iz prethodnog zadatka unosi se

system; rm -rf /

Objasniti kako će biti obrađen ovaj unos.

LOG_FILE_LIST = ["data_log", "system", "access"]
def read_logs(log_file_name):
	if log_file_name not in LOG_FILE_LIST:
		return "Invalid log file name"
	result = subprocess.run(["cat", f"/var/log/{log_file_name}.log"], capture_output=True, text=True)
    return result.stdout

Dodatno ukratko objasniti ovaj mehanizam zaštite.

Odgovor:

Unos pored dozvoljene niske sadrži i nedozvoljene karaktere, pa će program vratiti Invalid log file name. Ovde se koristi tehnika whitelisting, za sprečavanje Command injection napada - do kog dolazi usled Improper input validation. Postoji lista dozvoljenih unosa, ako naš unos nije među njima, on se odbacuje i prijavljuje se greška. Ovo je proaktivan pristup, smanjuje značajno mogućnost za napad i samim tim je bolja tehnika od blackistinga.

Napomene

  • Ovaj rok je napisan isključivo po sećanju studenata.
  • U određenim zadacima eksplicitne vrednosti ili ponuđeni odgovori možda nisu isti kao u originalnoj postavci, međutim u svim zadacima gde je to slučaj, očuvana je suština zadatka.