Sigurnosni audit: ranjivosti, pentest i skeniranje

Sigurnosni audit pokazuje koje slabosti web stranice, API-ja ili servera napadač zaista može iskoristiti, i koje od njih zaslužuju ispravku ove sedmice, a ne red u zaboravljenoj tabeli. Ocjena skenera nije taj odgovor. Većina stvarnih incidenata počinje od zastarjelog plugina, zaboravljene admin putanje, tokena u repozitoriju ili endpointa koji klijentu vjeruje malo više nego što treba.

Sadržaj

U CodeWizu procjenjujemo i ojačavamo sisteme koje znamo i da gradimo: WordPress i WooCommerce, Laravel i običan PHP, Node.js API-je, online prodavnice i servere na kojima rade. Spajamo procjenu ranjivosti, usmjeren penetration testing na pisanom obimu, ponovljivo sigurnosno skeniranje i pregled usklađenosti tamo gdje to traži payment provider, kupac ili propis. Ne ostavljamo PDF koji niko ne otvori. Rezultat je lista nalaza poredana po prioritetu, sa uticajem na poslovanje i konkretnom ispravkom, a kad to želite, tu ispravku unosimo u kod, CMS i konfiguraciju servera.

Ovo je za timove koji isporučuju proizvod u kojem su podaci kupaca, prodavnice pred uključivanjem kartičnog plaćanja, agencije koje nasljeđuju sajt koji nisu gradile, i firme koje su prerastle stav “hosting brine o sigurnosti”. Testiramo samo sisteme koje posjedujete ili koje smijete dati na testiranje. Ništa ne počinje bez dogovorenog obima.

Audit: Izbliza zamućen izvorni kod na tamnom ekranu

Procjena ranjivosti: srž sigurnosnog audita

Procjena ranjivosti je uređen pregled poznatih i uočljivih slabosti aplikacije, njenih zavisnosti i servera. Šira je od penetration testa i promišljenija od jednog automatskog skena. Tu mapiramo napadačku površinu: javne URL-ove, admin panele, API-je, upload fajlova, autentikaciju, skripte trećih strana, otvorene portove i put kojim tajne prolaze kroz deployment.

Pregled aplikacije – autentikacija, autorizacija, sesije, obrada ulaza, upload fajlova i ponašanje pri greškama, prema OWASP Top 10 kao polaznoj tački, a ne kao plafonu.
Pregled zavisnosti i platforme – WordPress core, pluginovi i teme, Composer i npm paketi, kontejnerske slike i operativni sistem.
Pregled konfiguracije – TLS, sigurnosna zaglavlja, oznake kolačića, CORS, listanje direktorijuma, izloženi debug alati i podrazumijevane lozinke.
Tok podataka: gdje se čuvaju lični podaci, narudžbe i tokeni, ko ih može čitati, i jesu li backupi šifrovani i obnovljivi.
Rangiranje ozbiljnosti koje uzima u obzir izvodljivost i uticaj na poslovanje, tako da nedostajuće zaglavlje na statičkoj stranici ne prestigne nesiguran direktan pristup tuđoj narudžbi.

Dobijate pogođenu komponentu, šta bi napadač dobio i konkretnu ispravku. Izvještaj ne punimo informativnom bukom iz skenera koji niko nije pregledao.

Penetration testing u dogovorenom obimu

Penetration testing postavlja oštrije pitanje od procjene: u pravilima koja smo dogovorili, može li neko doći do podataka ili radnji koje mu ne pripadaju? Nalaze potvrđujemo ručno, korak po korak, u okviru dozvole koju ste dali. Automatsko upozorenje koje se ne može ponoviti ne ulazi u izvještaj kao dokazan problem. Nalaz koji se može ponoviti opisan je dovoljno jasno da ga vaši programeri provjere nakon ispravke, bez javnog objavljivanja detalja koje bi neko mogao iskoristiti protiv vas.

Rad prati duh OWASP Web Security Testing Guide: autentikacija, upravljanje sesijom, kontrola pristupa, validacija ulaza i poslovna logika, plus ono što je posebno za vašu aplikaciju. Poslovna logika je mjesto na kojem generički skeneri najslabije stoje – kupon koji se može iskoristiti više puta, ID u URL-u koji otvara tuđi račun, webhook koji vjeruje pošiljaocu.

Obim, vrijeme i zabranjene radnje zapisuju se prije bilo kakvog testiranja. Provjere na produkciji zakazuju se i drže u dogovorenim granicama opterećenja.
Radije koristimo staging kopiju sa realističnim podacima iz kojih su tajne uklonjene. Test na živom sajtu radimo samo kad staging ne može pokazati ponašanje, i nikad tako da uništi narudžbe ili podatke kupaca.
Pristupni podaci za svaku ulogu (gost, kupac, osoblje, admin) omogućavaju da kontrolu pristupa testiramo kako treba. Mnogi ozbiljni problemi vide se tek nakon prijave.
Izvještaj odvaja potvrđene probleme od preostalog rizika, a svaki potvrđeni problem ima preporučenu ispravku i ponovni test.

Sigurnosno skeniranje na svakom izdanju

Sigurnosno skeniranje je sloj koji se ponavlja. Jednokratni pregled zastari sedmicu nakon što izađe zavisnost sa poznatom ranjivošću. Provjere vežemo za pipeline i za server, tako da nazadovanje padne u CI-u, a ne u browseru kupca.

Provjera	Šta hvata	Gdje radi	Šta ne zamjenjuje
Audit zavisnosti (npm, Composer, pip)	Poznate ranjivosti u bibliotekama	Svaki pull request	Greške u vašoj poslovnoj logici
Skeniranje tajni	Tokene i ključeve commitovane u Git	Pre-commit i CI	Tajne već zalijepljene u wiki ili chat
Sken slike i servera (Trivy i slično)	Ranjive pakete u kontejnerima i OS-u	Build slike i sedmični posao na serveru	Pogrešno firewall pravilo koje ste juče napisali
DAST osnova (OWASP ZAP ili Nuclei)	Nedostajuća zaglavlja, izložene fajlove, poznate CMS probleme	Staging, po rasporedu	Prijavljenu, višekoračnu zloupotrebu checkouta

Kod Node.js projekata rizik lanca nabavke traži svoju naviku: zaključane lock fajlove, pregled novih paketa i install skripte koje ne rade sa većim privilegijama nego što im trebaju. Posebno smo pisali o sandboxu koji ograničava šta zlonamjerni npm paket može dirnuti tokom razvoja. Dio o skeniranju kaže koje od ovih provjera već imate, a koje nedostaju.

Otvorena čelična vrata sefa na ulazu u zaštićenu prostoriju

Audit usklađenosti prema stvarnim obavezama

Audit usklađenosti poredi vaše kontrole sa navedenim zahtjevom. Ne izdajemo certifikate i nećemo se pretvarati da je upitnik penetration test. Čitamo obavezu onako kako je napisana, gledamo da li je sistem zaista ispunjava na produkciji, a ne samo u politici na papiru, i zatvaramo rupe u kodu, hostingu i procesu. Ako dokaz već postoji, ne izmišljamo novu proceduru samo da bi upitnik izgledao duži.

Plaćanja. Podaci o kartici treba da ostanu kod payment providera. Hosted polja ili preusmjeravanje drže broj kartice van vašeg servera i smanjuju obim PCI DSS-a. Naše bilješke o integraciji payment gatewaya pokrivaju arhitekturu; audit provjerava da živi sajt i dalje odgovara toj slici.
Lični podaci. HTTPS svuda, kontrola pristupa na izvozima, čuvanje podataka u skladu sa onim što kažete kupcima, i backupi koji nisu javno čitljivi.
Upitnici kupaca i većih firmi. Pomažemo da odgovore date iz dokaza – zaglavlja, pristupni logovi, izvještaji o zavisnostima – umjesto iz optimističnog teksta.
Zaglavlja i TLS kao minimum. HSTS, savremen lanac certifikata i Content-Security-Policy koju možete objasniti. Politika koja zauvijek ostane samo u report-only režimu nije kontrola.

Ako se neki zahtjev na vas ne odnosi, reći ćemo to. Sajt od pet stranica ne treba isti skup kontrola kao prodavnica koja čuva kartice, a prodati vam veći paket bio bi teatar.

Hardening WordPressa, Laravela i Node.js-a

Hardening je dio koji mijenja sistem. Zakrpimo, uklonimo ono što se ne koristi i postavimo podrazumijevano ponašanje koje se zatvara kad nešto nije u redu. Tipičan web stack dobija istu kratku listu HTTP zaglavlja, podešenu tako da ne polomi legitimne ugradnje:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Content-Security-Policy "default-src 'self'; frame-ancestors 'none'" always;

Content-Security-Policy traži stvaran popis vaših skripti i stilova. OWASP CSP Cheat Sheet je referenca koju koristimo kad oznaka treće strane otežava strogu politiku. Uz zaglavlja, praktičan rad izgleda ovako:

WordPress: ukloniti nekorištene pluginove i teme, blokirati XML-RPC i nabrajanje korisnika ako vam ne trebaju, isključiti uređivač fajlova i držati admin na jakoj jedinstvenoj lozinci uz dvofaktorsku autentikaciju.
Laravel i PHP: APP_DEBUG isključen u produkciji, kolačići sesije sa Secure, HttpOnly i SameSite, mass assignment ograničen na navedena polja, a uploadovani fajlovi van web roota ili na object storageu.
Node.js: bez stack tracea prema klijentu, zaglavlja u stilu helmeta gdje pristaju, zavisnosti instalirane iz lock fajla, i proces koji radi kao korisnik koji ne može pisati u vlastiti kod.
Server: SSH ključevi umjesto lozinki, automatska sigurnosna ažuriranja, firewall na kojem su otvoreni samo 80, 443 i ograničen admin port, i portovi baze koji nisu objavljeni na internet.

Sesije, tajne i zloupotreba API-ja

Nalozi i API-ji su mjesto na kojem ovi pregledi obično nađu probleme koji nešto znače. Nedostajući rate limit na prijavi, JWT koji nikad ne ističe ili .env fajl kopiran u Docker sliku pretvaraju malu grešku u preuzimanje naloga.

Lozinke heširane savremenim algoritmom (Argon2id ili bcrypt), linkovi za reset koji ističu, i ID-jevi sesije koji se rotiraju pri prijavi.
Tajne u manageru ili u CI varijablama, nikad commitovane u Git. Ako je ključ već procurio, rotiramo ga, pa ga uklonimo iz stabla.
Autorizacija provjerena na serveru za svaki objekat, a ne samo sakrivena u interfejsu. Dugme koje korisnik ne vidi nije kontrola pristupa.
Webhookovi provjereni potpisom i vremenskom oznakom, tako da ponovljeni zahtjev ne napravi drugu narudžbu.
Rate limiting i zaključavanje na prijavi, resetu lozinke i skupim API rutama. Obrasci su opisani u našem vodiču za API rate limiting; ovdje provjeravamo da vaše rute to zaista koriste.

Logovanje ide u istom prolazu. Neuspjela autentikacija, promjene privilegija i događaji plaćanja treba da se bilježe bez čuvanja lozinki, brojeva kartica ili cijelih tokena sesije.

Najčešći nalazi sigurnosnog audita koje ispravljamo

Admin ili phpMyAdmin putanja izložena internetu, zaštićena samo dijeljenom lozinkom.
Upload fajla koji prihvata ekstenziju koju aplikacija kasnije izvršava, ili koji upload servira sa istog origin-a kao aplikaciju.
CORS podešen da odražava bilo koji origin, uz credentials.
Debug režim, listanje direktorijuma ili .git folder ostavljen na produkcijskom serveru.
Pluginovi i paketi godinama iza, uključujući one koje sajt više ne koristi.
Backupi u javnom bucketu, ili backup koji nikad nije probno vraćen.
Sigurnosna zaglavlja prepisana sa bloga, pa isključena jer su polomila jednu stranicu, i ništa nije vraćeno na njihovo mjesto.

Zeleni znakovi koji se slijevaju niz crni ekran poput izvornog koda

Kako radimo

Obim: popisujemo sisteme, uloge, podatke koji su važni i pravila rada, i prije testiranja dobijamo pisanu dozvolu.
Procjena: pregledamo aplikaciju, zavisnosti, zaglavlja, hosting i tajne, i pokrećemo skenove koje zatim ručno trijažiramo.
Test: potvrđujemo probleme koji nose stvaran uticaj, na stagingu gdje je moguće, u dogovorenim granicama.
Izvještaj: dobijate nalaze poredane po ozbiljnosti, svaki sa uticajem, dokazom i ispravkom koju programeri mogu primijeniti.
Ispravka: možemo sami zakrpiti kod, CMS i server, ili podržati vaš tim dok to radi.
Ponovni test: provjeravamo zatvorene stavke i ostavljamo rutinu skeniranja i ažuriranja, da sljedeće izdanje ne poništi rad.

Zašto CodeWiz

Gradimo iste stackove koje auditiramo. WordPress, Laravel, Node.js, API-ji i hosting su svakodnevni posao, pa nalaz dolazi sa ispravkom koja odgovara kodu, a ne sa generičkim pasusom.
Open-source alati na prvom mjestu. OWASP ZAP, Nuclei, Trivy, Dependabot i fail2ban drže trajne provjere bez licence koju ne možete napustiti.
U skladu sa rizikom. Mali sajt dobija usmjeren sigurnosni audit. Ne prodajemo višesedmični zahvat kad su pažljiv pregled i hardening dovoljni.
Performanse i sigurnost zajedno. Keširanje, Cloudflare i podešavanje servera ostaju u istim rukama, pa sigurnosno zaglavlje ne nestane u sljedećem zahvatu na brzini.
Fer cijene, iz Banje Luke. Vrhunski razvoj bez vrhunskih cijena, na daljinu, sa klijentima lokalno i međunarodno. Više o CodeWizu.

Često postavljana pitanja

Koliko košta sigurnosni audit?

Zavisi od broja aplikacija, od toga treba li testiranje sa prijavom, i koliko ispravki želite u obimu. Pregled jednog sajta i njegovog servera je kompaktan posao; nekoliko API-ja uz ponovni test traje duže. Procjenu dajemo nakon kratkog pogleda na obim, prije početka rada.

Koliko traje penetration test?

Jedna web aplikacija sa staging okruženjem često staje u nekoliko dana, uključujući izvještaj. Veći obim, sa više uloga i ciklusom ispravke i ponovnog testa, obično traje nekoliko sedmica. Podešavanje skeniranja ide brže kad prvi audit pokaže šta treba automatizovati.

Hoće li testiranje srušiti sajt?

Ne bi trebalo. Pravila dogovorimo unaprijed, radije radimo na stagingu, a provjere na produkciji držimo u granicama koje neće iscrpiti server niti kreirati narudžbe. Destruktivne provjere nisu dio standardnog angažmana.

Koja je razlika između procjene ranjivosti i penetration testinga?

Procjena široko traži slabosti i rangira ih. Penetration testing na dogovorenom obimu provjerava mogu li se te slabosti iskoristiti da se dođe do nečega vrijednog. Skeniranje zatim prati iste klase problema na kasnijim izdanjima. Koristan sigurnosni audit koristi sva tri, tim redom.

Treba li vam izvorni kod?

Izvorni kod ubrzava pregled i hvata probleme koje test s vanjske strane propušta, pa ga tražimo kad ga možete podijeliti. Sajt možemo procijeniti i spolja, sa test nalozima, kad kod pripada platformi kojom ne upravljate.

Spremni za sigurnosni audit koji se završava ispravkama?

Recite nam šta pokrećete, koje podatke to drži i imate li već rok od kupca ili payment providera. Kontaktirajte nas da dogovorimo obim, ili pogledajte naše usluge sigurnosnog audita.

Sigurnosni audit: ranjivosti, pentest i skeniranje