Blog: PHP2Shell, sigurnost poslužitelja i hitna pomoć
Procjena stanja, upute za administratore i pomoć pri odlučivanju za upravu. Razvrstano po temama, svaki članak s izvorima.
Stanje i procjena
17 članaka
PHP2Shell: što je dokazano, a što nije
Provjera činjenica o PHP2Shellu: koje tvrdnje potječu iz primarnih izvora, koje iz medijskih izvješća i koje se tvrdnje ne mogu održati.
Čitajte dalje →002Zašto je PHP ranjivost postala poznata prije zakrpe
Prema izvješćima detalji o PHP2Shellu postali su javni prije isteka embarga. Objašnjavamo tijek događaja i što on znači za Vaše planiranje zakrpa.
Čitajte dalje →003Tijela vlasti isključuju web-stranice: što tvrtke iz toga uče
Mainz, hesenska zemaljska vlada i BKA preventivno su isključili web-stranice. Što tvrtke iz toga mogu naučiti za vlastitu odluku.
Čitajte dalje →004BSI razina upozorenja narančasta: što razvrstavanje znači
BSI razvrstava PHP2Shell u 3 / narančasto. Što ljestvica govori, što ne govori i kako tvrtke razvrstavanje pretvaraju u odluke.
Čitajte dalje →005Što CERT-EU i CERT-Bund savjetuju o PHP2Shellu
Službena tijela su složna: odmah zakrpati, inače izolirati. Uspoređujemo preporuke i pokazujemo kako izolacija izgleda u praksi.
Čitajte dalje →006Cloudflare zaštitna pravila protiv PHP2Shella: što postižu, a što ne
Cloudflare je rano uveo zaštitna pravila protiv PHP2Shella. Zašto pomažu, zašto ipak ne zamjenjuju PHP ažuriranje i koje postavke biste trebali provjeriti.
Čitajte dalje →00722,6 milijuna izloženih instanci: kako ispravno razumjeti brojke
Unit 42, CybelAngel i drugi navode vrlo različite brojke o PHP2Shellu. Objašnjavamo što je brojano i koja brojka za Vas doista vrijedi.
Čitajte dalje →008PHP2Shell u pet minuta: brifing za upravu
PHP sigurnosna ranjivost PHP2Shell na jednoj stranici za donositelje odluka: stanje, rizik, pet pitanja za IT i odluke za danas.
Čitajte dalje →009PHP sigurnosna ranjivost jednostavno objašnjena
PHP2Shell za one koji nisu tehničari: sa slikama iz svakodnevice, malim pojmovnikom i tri tipična polazišta, što kao operater web-stranice trebate učiniti.
Čitajte dalje →010PHP2Shell: 15 pitanja korisnika hostinga
Vaša web-stranica je kod pružatelja hostinga, a želite znati što kod PHP2Shella morate učiniti sami? Evo 15 najčešćih pitanja s kratkim odgovorima.
Čitajte dalje →011Zašto ažuriranje WordPressa ne pomaže protiv PHP2Shella
Mnogi su operateri nakon naslova ažurirali WordPress i osjećaju se sigurno. Zašto to kod PHP2Shella ne vodi nikamo i što umjesto toga vrijedi.
Čitajte dalje →012PHP2Shell i Log4Shell: što ranjivosti imaju zajedničko
Mnogi PHP2Shell uspoređuju s Log4Shellom iz 2021. godine. Što usporedba nosi, gdje šepa i koje pouke iz tog vremena danas pomažu.
Čitajte dalje →013Masovna skeniranja nezakrpanog PHP-a: kako teku automatizirani napadi
Nakon PHP2Shella napadači automatizirano pretražuju internet u potrazi za ranjivim poslužiteljima. Kako to teče, zašto veličina nije važna i što Vas štiti.
Čitajte dalje →014Vremenski prozor između zakrpe i napada
Kod PHP2Shella pokušaji napada postojali su već prije zakrpe. Objašnjavamo faze vremenskog prozora, kako izmjeriti vlastiti i kako ga skratiti.
Čitajte dalje →015Nakon PHP2Shella: zašto su daljnje objave vjerojatne
PHP2Shell zakrpom od 21. listopada nije zaključen. Zašto se mogu očekivati naknadne objave i kako svoj tim pripremiti na njih.
Čitajte dalje →016PHP2Shell: pregled stanja nakon prvog tjedna
Tjedan dana nakon prvog uočenog pokušaja napada: stanje zakrpa, upozorenja tijela vlasti, napada i isključenja, uredno razdvojeno po izvorima.
Čitajte dalje →017Opasni pogrešni savjeti o PHP2Shellu koji trenutačno kruže
Blokirati kolačiće, sakriti poruke o pogreškama, ažurirati samo CMS: devet savjeta o PHP2Shellu koji stvaraju lažnu sigurnost i što doista vrijedi.
Čitajte dalje →Hosting i distribucije
18 članaka
Promjena PHP verzije u korisničkom području hostinga
Kako u korisničkom području svog pružatelja hostinga promijeniti PHP verziju, koju verziju odabrati i što provjeriti prije i poslije.
Čitajte dalje →019Debian i Ubuntu: je li moj PHP paket zakrpan?
Koje su PHP pakete Debian i Ubuntu ispravili protiv PHP2Shella, kako točno usporediti instalirano stanje i na čemu dokaz zapinje.
Čitajte dalje →020RHEL, AlmaLinux i Rocky Linux: provjera PHP zakrpe
Što je Red Hat objavio o PHP2Shellu, kako na RHEL-u i njegovim derivatima dokazati stanje paketa i zašto reload nije dovoljan.
Čitajte dalje →021Repozitorij sury.org: PHP paketi iz izvora treće strane
Mnogi Debian i Ubuntu poslužitelji PHP dobivaju iz sury repozitorija. Što to znači za ažuriranja, dokaze i stare PHP verzije nakon PHP2Shella.
Čitajte dalje →022Repozitorij Remi: održavati PHP na RHEL sustavima aktualnim
Remi isporučuje aktualne PHP verzije za RHEL obitelj, kao modul ili za uporednu instalaciju. Kako provjeriti stanje nakon PHP2Shella i izbjeći zaboravljene grane.
Čitajte dalje →023Zašto php -v nakon ažuriranja prikazuje isti broj
Ažuriranje je prošlo, a php -v javlja staru verziju. Najčešće je to backport, a ne pogreška. Kako razlikovati bezopasno od stvarnih problema.
Čitajte dalje →024Dokazati CVE brojeve u changelogu paketa
Tko upravi, revizorima ili osigurateljima mora dokazati PHP zakrpu, treba više od broja verzije. Evo kako unos u changelogu postaje dokaz.
Čitajte dalje →025Promjena hostera nakon sigurnosnog incidenta: na što paziti?
Nakon incidenta želja za novim hosterom je razumljiva. Da selidba ne povuče napadača sa sobom, važni su redoslijed i izbor.
Čitajte dalje →026Više PHP verzija na jednom poslužitelju: zakrpati svaku zasebno
Na mnogim poslužiteljima paralelno radi tri, četiri ili više PHP instalacija. Nakon PHP2Shella svaku treba pronaći, ažurirati i ponovno pokrenuti.
Čitajte dalje →027Isključiti stare PHP verzije u hosting panelu
PHP2Shell je dobar povod da se riješite starih PHP verzija. Postupajte u tri faze kako nijedna web-stranica ni cron posao ne bi neprimijećeno ispali.
Čitajte dalje →028Plesk: razumjeti PHP handlere (FPM, FastCGI, Apache modul)
Koji PHP handler Plesk koristi za web-stranicu, odlučuje o izolaciji, konfiguraciji i riziku. Usporedba s obzirom na PHP2Shell.
Čitajte dalje →029CloudLinux i alt-php: što trebaju znati korisnici hostinga
Na CloudLinux poslužiteljima web-stranice često rade s vlastitim alt-php paketima. Svaka od tih verzija treba svoju zakrpu, a može je instalirati samo operater poslužitelja.
Čitajte dalje →030PHP na NAS-u, vatrozidima i uređajima: zaboravljeni sustavi
PHP ne koriste samo web-poslužitelji. Mogu biti pogođeni i NAS sustavi, vatrozidi i stručni uređaji s web-sučeljem. Zakrpati ih većinom može samo proizvođač, a dostupnost uređujete Vi.
Čitajte dalje →031PHP kod cloud i PaaS pružatelja: tko zakrpava runtime?
Na platformskim uslugama PHP zakrpa ovisi o modelu poslovanja. Odlučujući je runtime koji se doista isporučuje, a ne lokalno okruženje ni kod aplikacije.
Čitajte dalje →032Službeni PHP Docker image-i: tagovi, digesti i ponovna izgradnja
Tag službenog PHP image-a pokazivač je koji s vremenom prelazi na nova stanja. Tko zna što znače tag, varijanta i digest, bira pravi image i može dokazati stanje zakrpe.
Čitajte dalje →033CI/CD: automatski ponovno graditi PHP image-e
Image zastarijeva i bez izmjene koda. Uz vremenski upravljane izgradnje, provjeru verzije i isporuku putem digesta PHP zakrpe pouzdano stižu u produkciju.
Čitajte dalje →034Dugoročna podrška za stare PHP verzije: opcije i granice
Tko ne može odmah prijeći s PHP-a 8.1 ili starijeg, dugoročnu podršku nalazi kod distribucija, trećih pružatelja i komercijalnih usluga. Što ti putovi pružaju, što trebate imati pisano i gdje su granice.
Čitajte dalje →035Ažurirati PHP na Windowsu
Na Windowsu nema automatskog PHP ažuriranja. Tko odabere pravu varijantu, provjeri preuzimanje i ponovno pokrene sve procese, uredno donosi PHP2Shell zakrpu na svako računalo.
Čitajte dalje →Otkrivanje i forenzika
18 članaka
Znak upozorenja: web-poslužitelj pokreće ljusku
Ako PHP-FPM ili proces web-poslužitelja pokrene ljusku, to je jedan od najjačih znakova upozorenja na provalu. Kako provjeriti stablo procesa, razvrstati iznimke i trajno nadzirati obrazac.
Čitajte dalje →037Pronaći sumnjive procese na Linux poslužiteljima
Zlonamjerni procesi maskiraju se bezazlenim imenima, rade iz privremenih direktorija ili s izbrisanih datoteka. S nekoliko naredbi koje samo čitaju pronaći ćete neobičnosti i razvrstati ih.
Čitajte dalje →038Prepoznati skrivene cron poslove kao stražnja vrata
Napadači koriste planirane zadatke kako bi se vratili nakon čišćenja. Kako potpuno provjeriti crontabove, cron direktorije, systemd timere i at zadatke i prepoznati sumnjive unose.
Čitajte dalje →039Pronaći nedavno izmijenjene datoteke na web-poslužitelju
Nakon moguće provale važno je što se na poslužitelju promijenilo. Kako tražiti po vremenskim prozorima, ispravno koristiti mtime i ctime te usporediti s paketima, Gitom i sigurnosnim kopijama.
Čitajte dalje →040PHP datoteke u direktoriju za prijenose: ispravno protumačiti nalaze
PHP datoteka u direktoriju za prijenose gotovo je uvijek znak upozorenja, ali nije svaka zlonamjeran kod. Kako procijeniti nalaz bez uništavanja tragova i razjasniti je li je netko pozvao.
Čitajte dalje →041Prepoznati zamagljeni PHP kod
Nečitljiv PHP kod s eval i base64_decode klasičan je znak ubačenog zlonamjernog koda. Koje obrasce tražiti, kako ih bezopasno pronaći i kada je zamagljivanje legitimno.
Čitajte dalje →042Provjeriti odlazne veze poslužitelja
Web-poslužitelj uglavnom odgovara na zahtjeve. Ako sam uspostavlja veze prema nepoznatim odredištima, to može značiti upravljanje od strane napadača ili odljev podataka. Kako provjeriti i ograničiti odlazni promet.
Čitajte dalje →043Pronaći tuđe administratorske račune u CMS-u i na poslužitelju
Nepoznati administrator često su najjednostavnija stražnja vrata. Kako razinu po razinu tražiti tuđe račune, i one koje sučelje skriva.
Čitajte dalje →044Pronaći i ukloniti nepoznate SSH ključeve
Ubačeni SSH ključ napadačima otvara vrata čak i kad su sve lozinke promijenjene. Kako pronaći svaku datoteku authorized_keys i provjeriti svaki unos.
Čitajte dalje →045Kriptorudar na web-poslužitelju: znakovi i postupak
Procesor stalno pun, a posjetitelja nije više: to može biti kriptorudar. Kako provjeriti opterećenje, pronaći proces i mehanizme njegova ponovnog pokretanja te postupati uredno.
Čitajte dalje →046Poslužitelj šalje spam: pronaći uzroke
Nedostavljive poruke, crne liste, pritužbe: kad vlastiti poslužitelj šalje spam, iza toga uglavnom stoji skripta ili preuzet sandučić. Kako pronaći izvor.
Čitajte dalje →047SEO spam i tuđe stranice u Google indeksu
Odjednom se pod Vašom domenom rangiraju stranice o lijekovima ili robi poznatih marki. Saznajte odakle dolazi SEO spam i kako ga ukloniti iz indeksa.
Čitajte dalje →048Web-stranica preusmjerava na tuđe stranice
Posjetitelji završe na nagradnim igrama ili sumnjivim shopovima, a Vi sami ništa ne vidite? Saznajte u kojem je sloju preusmjeravanje i kako ga ukloniti.
Čitajte dalje →049Osigurajte dokaze prije nego ponovno postavite poslužitelj
Ponovna izgradnja uklanja napadača, ali i sve tragove. Tko prije toga uloži sat vremena u osiguranje dokaza, kasnije može reći što se dogodilo.
Čitajte dalje →050Izrada vremenske crte incidenta
Kada je napadač došao, što je učinio, kada je to primijećeno? Uredna vremenska crta odgovara na ta pitanja i temelj je za prijave, osiguranje i izvješće.
Čitajte dalje →051Usporedba jezgrenih datoteka CMS-a s originalom
Usporedba s čistim originalom pokazuje svaku izmijenjenu datoteku, neovisno o tome poznaje li je skener. Evo kako postaviti usporedbu za WordPress, Composer projekte i sistemske pakete.
Čitajte dalje →052Provjera baze podataka na ubačeni kod
Tko provjerava samo datoteke, previđa polovicu. Evo kako pretražiti sadržaje, postavke, okidače i račune baze podataka na ubačeni kod, samo čitanjem i na kopiji.
Čitajte dalje →053Skeneri zlonamjernog softvera za web-stranice: što pronalaze, a što ne
Skener ne javlja ništa, pa je sve u redu? Ne nužno. Koje vrste skenera web-stranica postoje, što svaki vidi i što u načelu ne može vidjeti.
Čitajte dalje →Ojačavanje i konfiguracija
20 članaka
Izolacija PHP-FPM poolova po web-stranici
Zaseban pool za svaku web-stranicu početak je, a ne kraj. Evo kako provjeriti postojeće poolove i ojačati socketove, ekstenzije, status stranice, resurse i zapisnike.
Čitajte dalje →055Pravilno postaviti memory_limit
memory_limit ograničava memoriju po PHP zahtjevu. Nakon PHP2Shella php.net privremeno savjetuje suprotno. Što vrijedi u redovitom radu, u prijelazu i nakon ažuriranja.
Čitajte dalje →056Smisleno ograničiti post_max_size i upload_max_filesize
Granice prijenosa djeluju na tri mjesta: u web-poslužitelju, u PHP-u i u aplikaciji. Evo kako uskladiti vrijednosti, i s prijelaznim vrijednostima php.net-a za PHP2Shell.
Čitajte dalje →057Isključiti session.upload_progress: ispravno i trajno
Zaštita od CVE-2026-115560 i jedna od prijelaznih mjera za PHP2Shell postavlja se brzo. Da bi držala, mora biti na pravom mjestu, zaključana i provjeravana nakon svakog ažuriranja.
Čitajte dalje →058expose_php i Server zaglavlje: sakriti podatke o verziji
PHP, Nginx i Apache zadano navode broj verzije u svakom odgovoru. To ne štiti od napada, ali skenerima daje zgodan popis meta. Evo kako to isključiti, a ipak zadržati pregled.
Čitajte dalje →059display_errors off: isključiti ispis pogrešaka u produkciji
Vidljive PHP poruke o pogreškama odaju putove, nazive baza podataka i verzije. Evo kako ih isključiti u PHP-u, frameworku i web-poslužitelju, a pogreške ne ispustiti iz vida.
Čitajte dalje →060php_admin_value: zaključati postavke od nadjačavanja
Sigurnosna postavka malo vrijedi ako je aplikacija jednim retkom koda ponovno promijeni. Pomoću php_admin_value i php_admin_flag vrijednosti za PHP-FPM i Apache određujete obvezujuće.
Čitajte dalje →061Postaviti granice memorije pomoću systemd-a i cgroupa
php.net kao prijelaznu mjeru za PHP2Shell preporučuje memory_limit=-1 i granicu memorije izvan PHP-a. Evo kako tu granicu postaviti pomoću systemd-a i cgroupa, a da jedan worker ne povuče cijelu uslugu.
Čitajte dalje →062Sigurno konfigurirati Nginx za PHP
Većina slabosti u Nginx postavkama za PHP nije u Nginxu, nego u nekoliko redaka PHP lokacije. Evo kako predaju PHP-FPM-u konfigurirati tako da se izvršavaju samo željene skripte.
Čitajte dalje →063Sigurno konfigurirati Apache za PHP
Apache je fleksibilan, a upravo ga to čini podložnim pogrešnoj konfiguraciji. Evo kako PHP povezati putem PHP-FPM-a, zatvoriti .htaccess kao stražnja vrata i sigurno postaviti najvažnije temeljne opcije.
Čitajte dalje →064Zabraniti izvršavanje PHP-a u mapama za prijenose
Web shell treba dvije stvari: mapu u koju se može zapisati i poslužitelj koji je izvršava. Evo kako joj oduzeti ovo drugo, i to u svakoj zapisivoj mapi, a ne samo u uploads.
Čitajte dalje →065Filtrirati zahtjeve za prijenos na rubu: prilike i rizici
Stručni autori predlažu da se zahtjevi za prijenos izvan pravih putova za prijenos blokiraju na proxyju dok PHP nije zakrpan. To može pomoći, ali i paralizirati obrasce i narudžbe. Evo kako postupiti kontrolirano.
Čitajte dalje →066Primijeniti ModSecurity i OWASP Core Rule Set
Vlastiti Web Application Firewall s ModSecurityjem i OWASP Core Rule Setom besplatan je i moćan, ali ne ide sam od sebe. Evo kako odabrati engine, krenuti bez ispada i uskladiti pravila.
Čitajte dalje →067Postaviti Fail2ban za web-poslužitelje
Fail2ban blokira adrese koje se u zapisnicima više puta ističu. Za web-poslužitelje donosi gotove filtre, a s nekoliko redaka dodaju se vlastiti. Evo kako ga postaviti a da ne zaključate sebe ili svoje kupce.
Čitajte dalje →068Vatrozid za web-poslužitelje: otvoriti samo nužne portove
Web-poslužitelju prema van obično trebaju samo dva porta. Ipak na mnogim poslužiteljima na internetu slušaju baze podataka, PHP-FPM ili administratorska sučelja. Evo kako pronaći otvorene usluge i zatvoriti ono što se ne treba.
Čitajte dalje →069Automatska sigurnosna ažuriranja na Linux poslužiteljima
Prema izvješćima distribucije su PHP backportove dijelom isporučile još 21. listopada 2026., na dan zakrpa. Tko koristi automatska sigurnosna ažuriranja, imao ih je brzo na poslužitelju. Da bi i djelovala, trebaju ponovna pokretanja, izvori trećih strana i kontrola.
Čitajte dalje →070Najmanje ovlasti: prava korisnika web-poslužitelja
Ubačeni kod izvršava se s pravima korisnika web-poslužitelja. Što taj račun smije, određuje koliko daleko napadač može doći. Kako ljusku, sudo, cron, bazu podataka i datotečni sustav ograničiti na nužno.
Čitajte dalje →071Odvojiti admin područja pomoću IP-a, VPN-a ili dodatne zaštite
Zašto backend web-stranice ne mora biti dostupan cijelom svijetu i kako ga odvojiti pomoću IP popisa, VPN-a ili prethodne prijave, a da pritom sami sebe ne isključite.
Čitajte dalje →072Ispravno konfigurirati TLS i HTTPS
Koje TLS verzije i cipher suites web-poslužitelj danas treba nuditi, na što se preporuke oslanjaju i kako provjeriti Nginx, Apache i odlazne PHP veze.
Čitajte dalje →073CIS Benchmarks i BSI moduli za web-poslužitelje
Koji standardi ojačavanja postoje za Linux web-poslužitelje, po čemu se razlikuju CIS Benchmarks i moduli IT-Grundschutza te kako od njih napraviti provjerljivu osnovu za Vaše PHP poslužitelje.
Čitajte dalje →Siguran razvoj
16 članaka
Sigurno spremati lozinke u PHP-u: ispravna primjena password_hash
Kako razvojni inženjeri u PHP-u spremaju lozinke pomoću password_hash i password_verify, biraju odgovarajući postupak i zamjenjuju stare MD5 ili SHA-1 hashove bez resetiranja lozinke svim korisnicima.
Čitajte dalje →075CSRF zaštita u PHP aplikacijama
Kako razvojni inženjeri u PHP aplikacijama sprječavaju Cross-Site Request Forgery: tokeni za svaki zahtjev koji mijenja podatke, provjera podrijetla u zaglavlju i SameSite kolačići kao dodatni sloj.
Čitajte dalje →076Validirati i filtrirati unos u PHP-u pomoću filter_var
Kako razvojni inženjeri provjeravaju unos u PHP-u pomoću filter_var, filter_input_array i popisa dopuštenog, koji su filtri zastarjeli i zašto validacija ne zamjenjuje Prepared Statements i kodiranje izlaza.
Čitajte dalje →077Spriječiti Command Injection u PHP-u
Kako razvojni inženjeri izbjegavaju Command Injection u PHP-u: sistemske naredbe zamijeniti PHP funkcijama, koristiti proc_open bez ljuske, provjeravati argumente i pronaći opasna mjesta u postojećem kodu.
Čitajte dalje →078Spriječiti Server-Side Request Forgery (SSRF) u PHP-u
Kako razvojni inženjeri sprječavaju da PHP aplikacija u tuđe ime ispituje interne sustave: popisi dopuštenog, ograničenje protokola, provjera razriješene adrese i granice u mreži.
Čitajte dalje →079Spriječiti XML External Entities (XXE) u PHP-u
Kako razvojni inženjeri sigurno obrađuju XML u PHP-u: zadano ponašanje libxml-a, rizične opcije poput LIBXML_NOENT, zaštita pomoću Entity Loadera i LIBXML_NO_XXE te tipični skriveni XML ulazi.
Čitajte dalje →080Type Juggling u PHP-u: labave usporedbe kao sigurnosni rizik
Zašto labave usporedbe pomoću == u PHP-u mogu dovesti do sigurnosnih ranjivosti, što se promijenilo s PHP-om 8.0 i kako robusno pisati usporedbe u prijavama, tokenima i ovlastima.
Čitajte dalje →081Sigurni slučajni brojevi i tokeni u PHP-u pomoću random_bytes
Kako razvojni inženjeri u PHP-u stvaraju tokene za poveznice za lozinke, API ključeve i jednokratne kodove: kriptografski sigurni izvori, dovoljna duljina, spremanje kao hash i ograničena valjanost.
Čitajte dalje →082Ispravno zaštititi pristupne podatke i .env datoteke
Kako u PHP projektima zaštititi lozinke baza podataka, API ključeve i druge tajne: .env datoteke izvan webroota, blokade u web-poslužitelju, uska prava i uredna zamjena nakon incidenta.
Čitajte dalje →083Javni .git direktorij: podcijenjeno curenje podataka
Zašto webroot isporučen putem Gita može otkriti cijeli izvorni kod zajedno s poviješću, kako to provjeriti, odmah blokirati i trajno izgraditi isporuku bez .git direktorija.
Čitajte dalje →084Sigurnosne kopije u webrootu: .zip, .sql i .bak
Zašto dumpovi baza podataka, arhive i sigurnosne kopije u javnom direktoriju spadaju među najčešća curenja podataka, kako ih pronaći, blokirati i razjasniti jesu li dohvaćene.
Čitajte dalje →085phpinfo() datoteke: zašto moraju nestati
Nakon PHP2Shella mnogi administratori brzo stvore info.php. Zašto su takve datoteke curenje podataka, kako ih pronaći i koji su bolji putovi provjere.
Čitajte dalje →086Održavati ovisnosti ažurnima: Composer, npm i dodaci
Projekt se sastoji od triju svjetova paketa: Composera, npm-a i CMS dodataka. Kako sve tri održavati ažurnima s fiksnim ritmom, jasnom odgovornošću i testovima.
Čitajte dalje →087Sigurnosni code review za PHP projekte
Kako timovi ciljano pregledavaju vlastiti PHP kod u potrazi za sigurnosnim ranjivostima: vrste reviewa, kritične funkcije, smisleni alati i kontrolni popis.
Čitajte dalje →088Sigurno logirati: bilježiti pogreške bez curenja podataka
Zapisnici pomažu pri traženju pogrešaka i forenzici, ali brzo i sami postaju curenje podataka. Što PHP aplikacije trebaju bilježiti, što nikad i kako zaštititi zapisnike.
Čitajte dalje →089Osigurati REST API-je u PHP-u
Sučelja su često slabije zaštićena od web-stranice ispred njih. Najvažnija pravila za REST API-je u PHP-u, od ovlasti po objektu do ograničenja stope.
Čitajte dalje →Upravljanje i pravo
14 članaka
Ugovori s IT pružateljima usluga: jasno urediti sigurnosne obveze
PHP2Shell je pokazao koliko je često nejasno tko mora zakrpati. Koje sigurnosne obveze pripadaju u ugovore s agencijom, hosterom i IT pružateljem usluga.
Čitajte dalje →091Obrada podataka u ime voditelja kad pružatelji pristupaju poslužitelju
Tko vanjske osobe pušta na poslužitelje s podacima kupaca, obično treba ugovor o obradi (AVV). Što traži čl. 28. GDPR-a i kako pristupe u hitnom slučaju organizirati u skladu sa zaštitom podataka.
Čitajte dalje →092Upravljanje ranjivostima za srednje tvrtke
Nijedna srednja tvrtka ne može odmah obraditi svaku obavijest. Uredan krug od evidentiranja, procjene, odluke i dokaza osigurava da se najvažnije napravi prvo.
Čitajte dalje →093Znati što radi: popis svih web-stranica i poslužitelja
Kod PHP2Shella mnogi nisu zapeli na zakrpi, nego na pitanju gdje se uopće izvodi PHP. Ovako izgradite popis svih web-stranica i poslužitelja.
Čitajte dalje →094Upravljanje zakrpama kao proces umjesto gašenja požara
Tko zakrpe instalira tek kad gori, u kritičnom trenutku gubi vrijeme. Kako proces s čvrstim klasama, prozorima i dokazima povezuje rutinu i hitni slučaj.
Čitajte dalje →095Kontakti za hitne slučajeve: tko se i kada mora obavijestiti?
U kritičnom trenutku važno je koga dosegnete i kada. Kako izgraditi popis IT kontakata za hitne slučajeve s okidačima, zamjenama i podacima koje svaki poziv treba.
Čitajte dalje →096Koliko košta hakirani poslužitelj: stavke troškova
Hakirani web-poslužitelj uzrokuje više troškova od samog popravka. Koje se stavke javljaju i kako vlastitim brojkama obrazložiti proračun za prevenciju.
Čitajte dalje →097Obavještavanje klijenata nakon incidenta
Bilo obveza ili dobrovoljno: kako nakon incidenta odlučiti koga obavijestiti, koji su kanali sigurni i kako pripremiti korisničku službu.
Čitajte dalje →098Lanac opskrbe na webu: agencija, pružatelj hostinga, proizvođač dodataka
PHP2Shell je pokazao koliko karika leži između zakrpe i Vaše web-stranice. Kako upoznati lanac opskrbe svoje web-stranice, osigurati ga i amortizirati ispad pojedinih karika.
Čitajte dalje →099Sigurnosna svijest administratora i urednika: security awareness u web timu
Tko održava web-stranice, svaki dan odlučuje o sigurnosti, često a da to ne primijeti. Kako obučiti administratore i urednike prema ulozi i bez bitke prezentacijama.
Čitajte dalje →100Vježba hitnog slučaja za stolom: proći incident web-poslužitelja
Vježba za stolom košta jedno poslijepodne i pokazuje drži li Vaš plan za hitne slučajeve. Ovdje je gotov scenarij za incident na PHP web-poslužitelju.
Čitajte dalje →101ISO 27001 i TISAX: što se tiče web-poslužitelja
Tko vodi ISMS prema ISO 27001 ili ima TISAX oznaku, mora misliti i na web-poslužitelje. Ovdje stoji koje zahtjeve dotiču i koji dokazi nakon PHP2Shella vrijede.
Čitajte dalje →102VdS 10000: informacijska sigurnost za mala i srednja poduzeća
VdS 10000 je vitak okvir za informacijsku sigurnost u srednjim tvrtkama. Što traži, što je novo 2025. i što to znači za web-stranice i web-poslužitelje.
Čitajte dalje →103Lessons learned: postati bolji nakon incidenta
Nakon incidenta je prije sljedećeg. Strukturiran razgovor bez traženja krivaca od lošeg tjedna čini mjerljiv napredak.
Čitajte dalje →Pomoć pri odlučivanju
10 članaka
Zakrpati, isključiti ili čekati? Pomoć pri odlučivanju kod PHP ranjivosti
Kod kritične PHP ranjivosti odgovorni moraju brzo odlučiti. Ova pomoć razvrstava tri opcije, navodi kriterije i pokazuje kada je čekanje opravdano.
Čitajte dalje →105WAF ili ažuriranje: zašto Vam treba oboje
Web aplikacijski vatrozid može zaustaviti napade, ali ne zatvara ranjivost u PHP interpreteru. Kada WAF pomaže, gdje završava i kako ih smisleno kombinirati.
Čitajte dalje →106Ponovno postaviti poslužitelj ili očistiti? Odluka nakon zaraze
Nakon provale otvorena su dva puta: poslužitelj očistiti ili ga iznova izgraditi. Koji kriteriji odlučuju i zašto je redoslijed važniji od izbora.
Čitajte dalje →107Riješiti sami ili dovesti pružatelja usluga? Iskreno odvagivanje
Ne treba svaka sigurnosna situacija vanjsku pomoć. S ovim kriterijima i kratkim samotestom odlučujete hoće li Vaš tim PHP2Shell svladati sam ili treba podršku.
Čitajte dalje →108Odabir pružatelja usluga IT sigurnosti: 12 pitanja prije narudžbe
Pod vremenskim pritiskom teško je pronaći dobrog pružatelja usluga sigurnosti. Ovih dvanaest pitanja pomaže stvarno usporediti ponude, a da ne nasjednete na reklamna obećanja.
Čitajte dalje →109Upravljani hosting ili vlastiti poslužitelj? Usporedba sigurnosti
PHP2Shell je bio test izdržljivosti za svaki model rada. Usporedba pokazuje kada je upravljani hosting sigurniji, kada vlastiti poslužitelj i koji se mješoviti oblici pokazuju dobrima.
Čitajte dalje →110PHP nadogradnja ili backport? Odluka za stare sustave
Za stare verzije PHP-a nakon PHP2Shella postoji više putova: backport distribucije, izvor treće strane, zakrpa izvornog koda, dugoročna podrška ili nadogradnja. Što vrijedi svaki put i koliko dugo drži.
Čitajte dalje →111Promijeniti CMS nakon hakiranja? Kada pomaže, a kada ne
Nakon provale povjerenje u CMS je često nestalo. No novi sustav rijetko rješava stvarni uzrok. Kada je promjena smislena i kako uredno uspijeva.
Čitajte dalje →112Statične web-stranice: manje PHP-a, manja napadna površina
Statična web-stranica isporučuje gotove HTML datoteke i ne treba PHP na poslužitelju. To znatno smanjuje napadnu površinu, ali donosi vlastite granice i obveze.
Čitajte dalje →113Pentest, bug bounty ili skeniranje ranjivosti? Odabir prikladnog postupka provjere
Skeniranje, penetracijski test i bug bounty provjeravaju web-stranice na posve različite načine. Što svaki postupak može, gdje zakazuje i koji redoslijed odgovara Vašoj tvrtki.
Čitajte dalje →Svaki sat se računa. Pišite nam odmah.
Ukratko opišite sustav, verziju PHP-a i opažanje. Javit ćemo Vam se, razjasniti situaciju i raditi na daljinu dok incident nije zaključen i dokumentiran.