Ajankohtainen tilanne: PHP2Shell. Kaksi kriittistä PHP-haavoittuvuutta (CVSS 9.2) sallii haittakoodin suorittamisen ilman kirjautumista. Korjaukset 21.10.2026 alkaen.Mitä nyt on tehtävä →
113 artikkelia

Blogi: PHP2Shell, palvelimen tietoturva ja hätäapu

Tilannearviot, ohjeet ylläpitäjille ja päätöksenteon tuki johdolle. Järjestetty aiheittain, jokaisessa artikkelissa on lähteet.

Tilanne ja arviointi

17 artikkelia

001

PHP2Shell: mikä on todennettu ja mikä ei

PHP2Shellin faktantarkistus: mitkä väitteet tulevat ensisijaisista lähteistä, mitkä mediaraporteista ja mitkä väitteet eivät kestä tarkastelua.

Lue lisää →
002

Miksi PHP-aukko tuli tietoon ennen korjausta

Raporttien mukaan PHP2Shellin yksityiskohdat tulivat julkisiksi ennen embargon päättymistä. Selitämme tapahtumien kulun ja mitä se tarkoittaa päivityssuunnittelullenne.

Lue lisää →
003

Viranomaiset ottavat verkkosivuja pois verkosta: mitä yritykset voivat oppia

Mainz, Hessenin osavaltion hallitus ja BKA ottivat verkkosivuja varotoimena pois verkosta. Mitä yritykset voivat oppia omaa päätöstään varten.

Lue lisää →
004

BSI:n oranssi varoitustaso: mitä luokitus tarkoittaa

BSI luokittelee PHP2Shellin tasolle 3 / oranssi. Mitä asteikko kertoo ja mitä ei, ja miten yritykset muuttavat luokituksen päätöksiksi.

Lue lisää →
005

Mitä CERT-EU ja CERT-Bund suosittelevat PHP2Shellistä

Viralliset tahot ovat yhtä mieltä: päivittäkää heti, muuten eristäkää. Vertaamme suosituksia ja näytämme, miltä eristäminen käytännössä näyttää.

Lue lisää →
006

Cloudflaren suojasäännöt PHP2Shelliä vastaan: mitä ne tekevät ja mitä eivät

Cloudflare otti käyttöön suojasäännöt PHP2Shelliä vastaan jo varhain. Miksi se auttaa, miksi se ei silti korvaa PHP-päivitystä ja mitä asetuksia kannattaa tarkistaa.

Lue lisää →
007

22,6 miljoonaa altistunutta instanssia: lukujen oikea tulkinta

Unit 42, CybelAngel ja muut mainitsevat PHP2Shellistä hyvin erilaisia lukuja. Selitämme, mitä on laskettu ja mikä luku merkitsee teille todella.

Lue lisää →
008

PHP2Shell viidessä minuutissa: tiivistelmä johdolle

PHP-tietoturva-aukko PHP2Shell yhdellä sivulla päättäjille: tilanne, riski, viisi kysymystä IT:lle ja tämän päivän päätökset.

Lue lisää →
009

PHP-tietoturva-aukko selkeästi selitettynä

PHP2Shell ei-teknisille: arkisin vertauksin, pienen sanaston ja kolmen tyypillisen lähtötilanteen avulla, mitä verkkosivuston ylläpitäjän kannattaa tehdä.

Lue lisää →
010

PHP2Shell: 15 kysymystä hosting-asiakkailta

Verkkosivustonne on hosting-yrityksellä ja haluatte tietää, mitä teidän on itse tehtävä PHP2Shellin vuoksi? Tässä 15 yleisintä kysymystä lyhyin vastauksin.

Lue lisää →
011

Miksi WordPress-päivitys ei auta PHP2Shelliä vastaan

Moni ylläpitäjä päivitti WordPressin otsikoiden jälkeen ja tuntee olonsa turvalliseksi. Miksi se ei PHP2Shellin kohdalla riitä ja mikä ratkaisee.

Lue lisää →
012

PHP2Shell ja Log4Shell: mitä aukoilla on yhteistä

Moni vertaa PHP2Shelliä vuoden 2021 Log4Shelliin. Mitä vertailu kestää, missä se ontuu ja mitkä silloiset opit auttavat nyt.

Lue lisää →
013

Massaskannaukset päivittämättömän PHP:n perässä: näin automaattiset hyökkäykset etenevät

PHP2Shellin jälkeen hyökkääjät etsivät internetistä automaattisesti haavoittuvia palvelimia. Miten se etenee, miksi koolla ei ole merkitystä ja mikä suojaa.

Lue lisää →
014

Päivityksen ja hyökkäyksen välinen aikaikkuna

PHP2Shellin kohdalla hyökkäysyrityksiä oli jo ennen korjausta. Selitämme aikaikkunan vaiheet, miten mittaatte omanne ja miten lyhennätte sitä.

Lue lisää →
015

PHP2Shellin jälkeen: miksi lisäilmoitukset ovat todennäköisiä

PHP2Shell ei ole ohi 21. lokakuuta tulleella päivityksellä. Miksi jatkoilmoituksia on odotettavissa ja miten valmistatte tiiminne niihin.

Lue lisää →
016

PHP2Shell: ensimmäisen viikon tilannekuva

Viikko ensimmäisen havaitun hyökkäysyrityksen jälkeen: päivitysten, viranomaisvaroitusten, hyökkäysten ja sulkemisten tilanne lähteittäin eroteltuna.

Lue lisää →
017

Vaaralliset vääränlaiset vinkit PHP2Shellistä, jotka kiertävät juuri nyt

Evästeiden estäminen, virheilmoitusten piilottaminen, vain CMS:n päivitys: yhdeksän PHP2Shell-neuvoa, jotka luovat väärää turvallisuutta, ja mikä todella merkitsee.

Lue lisää →

Hosting ja jakelut

18 artikkelia

018

PHP-version vaihtaminen hosting-asiakasalueella

Miten vaihdatte PHP-version hosting-yrityksenne asiakasalueella, minkä version valitsette ja mitä tarkistatte ennen ja jälkeen.

Lue lisää →
019

Debian ja Ubuntu: onko PHP-pakettini päivitetty?

Mitkä PHP-paketit Debian ja Ubuntu ovat korjanneet PHP2Shelliä vastaan, miten vertaatte asennetun tilan tarkasti ja mihin todistaminen kaatuu.

Lue lisää →
020

RHEL, AlmaLinux ja Rocky Linux: PHP-päivityksen tarkistaminen

Mitä Red Hat on julkaissut PHP2Shellistä, miten todistatte pakettitilan RHELillä ja sen jäljennöksillä ja miksi uudelleenlataus ei riitä.

Lue lisää →
021

sury.org-repositorio: PHP-paketit kolmannelta osapuolelta

Monet Debian- ja Ubuntu-palvelimet hankkivat PHP:n sury-repositoriosta. Mitä se tarkoittaa päivityksille, todisteille ja vanhoille PHP-versioille PHP2Shellin jälkeen.

Lue lisää →
022

Remi-repositorio: PHP ajan tasalla RHEL-järjestelmissä

Remi toimittaa ajantasaisia PHP-versioita RHEL-perheelle, moduulina tai rinnakkain asennettavina. Näin tarkistatte tilan PHP2Shellin jälkeen ja vältätte unohtuneet haarat.

Lue lisää →
023

Miksi php -v näyttää päivityksen jälkeen saman numeron

Päivitys onnistui, mutta php -v ilmoittaa vanhan version. Yleensä kyse on backportista eikä virheestä. Näin erotatte harmittoman todellisista ongelmista.

Lue lisää →
024

CVE-numeroiden todistaminen paketin muutoslokista

Jos PHP-korjaus on todistettava johdolle, tarkastajille tai vakuutusyhtiölle, versionumero ei riitä. Näin muutoslokin merkinnästä tulee todiste.

Lue lisää →
025

Hosting-yrityksen vaihto tietoturvatapauksen jälkeen: mihin kiinnittää huomiota?

Tapauksen jälkeen halu vaihtaa hosting-yritystä on ymmärrettävä. Jotta hyökkääjä ei muuta mukana, väliä on järjestyksellä ja valinnalla.

Lue lisää →
026

Useita PHP-versioita yhdellä palvelimella: korjatkaa jokainen erikseen

Monella palvelimella toimii rinnakkain kolme, neljä tai useampia PHP-asennuksia. PHP2Shellin jälkeen jokainen on löydettävä, päivitettävä ja käynnistettävä uudelleen.

Lue lisää →
027

Vanhojen PHP-versioiden poistaminen käytöstä hosting-paneelissa

PHP2Shell on hyvä syy luopua vanhoista PHP-versioista. Näin etenette kolmessa vaiheessa, jotta mikään verkkosivusto tai cron-työ ei lakkaa toimimasta huomaamatta.

Lue lisää →
028

Plesk: PHP-handlerien ymmärtäminen (FPM, FastCGI, Apache-moduuli)

Se, mitä PHP-handleria Plesk käyttää verkkosivustolle, ratkaisee erottelun, asetukset ja riskin. Vertailu PHP2Shellin näkökulmasta.

Lue lisää →
029

CloudLinux ja alt-php: mitä hosting-asiakkaiden pitäisi tietää

CloudLinux-palvelimilla verkkosivustot toimivat usein omilla alt-php-paketeillaan. Jokainen versio tarvitsee oman korjauksensa, ja sen voi asentaa vain palvelimen ylläpitäjä.

Lue lisää →
030

PHP NAS-laitteilla, palomuureilla ja appliance-laitteilla: unohdetut järjestelmät

PHP:tä eivät käytä vain verkkopalvelimet. Myös NAS-järjestelmät, palomuurit ja erikoislaitteet, joissa on verkkokäyttöliittymä, voivat olla haavoittuvia. Korjauksen voi yleensä tehdä vain valmistaja, saavutettavuudesta päätätte itse.

Lue lisää →
031

PHP pilvi- ja PaaS-palveluissa: kuka korjaa ajoympäristön?

Alustapalveluissa PHP-korjaus riippuu toimintamallista. Ratkaisevaa on ajoympäristö, joka todella palvelee pyyntöjä, ei paikallinen ympäristö eikä sovelluskoodi.

Lue lisää →
032

Viralliset PHP Docker -kuvat: tagit, digestit ja uudelleenrakennus

Virallisen PHP-kuvan tag on osoitin, joka siirtyy ajan myötä uusiin tiloihin. Kun tiedätte, mitä tag, variantti ja digest tarkoittavat, valitsette oikean kuvan ja voitte todistaa korjaustilan.

Lue lisää →
033

CI/CD: PHP-kuvien automaattinen uudelleenrakennus

Kuva vanhenee ilman koodimuutostakin. Ajastetuilla buildeilla, versiotarkistuksella ja digestiin perustuvalla käyttöönotolla PHP-korjaukset pääsevät luotettavasti tuotantoon.

Lue lisää →
034

Pitkäaikaistuki vanhoille PHP-versioille: vaihtoehdot ja rajat

Jos ette voi heti siirtyä pois PHP 8.1:stä tai vanhemmasta, pitkäaikaistukea tarjoavat jakelut, kolmannet osapuolet ja kaupalliset palvelut. Mitä nämä tiet tarjoavat, mitä tarvitsette kirjallisena ja missä rajat ovat.

Lue lisää →
035

PHP:n päivittäminen Windowsissa

Windowsissa ei ole automaattista PHP-päivitystä. Kun valitsette oikean variantin, tarkistatte latauksen ja käynnistätte kaikki prosessit uudelleen, PHP2Shell-korjaus saadaan siististi jokaiselle koneelle.

Lue lisää →

Havaitseminen ja forensiikka

18 artikkelia

036

Varoitusmerkki: verkkopalvelin käynnistää shellin

Jos PHP-FPM- tai verkkopalvelinprosessi käynnistää shellin, se on yksi vahvimmista murron varoitusmerkeistä. Näin tarkistatte prosessipuun, arvioitte poikkeukset ja seuraatte kaavaa pysyvästi.

Lue lisää →
037

Epäilyttävien prosessien löytäminen Linux-palvelimilta

Haitalliset prosessit naamioituvat harmittomilla nimillä, toimivat väliaikaisista kansioista tai poistetuista tiedostoista. Muutamalla lukevalla komennolla löydätte poikkeamat ja arvioitte ne.

Lue lisää →
038

Piilotettujen cron-töiden tunnistaminen takaovena

Hyökkääjät käyttävät ajastettuja tehtäviä palatakseen siivouksen jälkeen. Näin tarkistatte crontabit, cron-hakemistot, systemd-ajastimet ja at-työt kokonaan ja tunnistatte epäilyttävät merkinnät.

Lue lisää →
039

Äskettäin muuttuneiden tiedostojen etsintä verkkopalvelimelta

Mahdollisen murron jälkeen ratkaisevaa on, mikä palvelimella on muuttunut. Näin etsitte aikaikkunoilla, käytätte mtimea ja ctimea oikein ja vertaatte paketteihin, Gitiin ja varmuuskopioihin.

Lue lisää →
040

PHP-tiedostot upload-kansiossa: löytöjen oikea tulkinta

PHP-tiedosto upload-kansiossa on lähes aina hälytysmerkki, mutta kaikki eivät ole haittakoodia. Näin arvioitte löydön tuhoamatta jälkiä ja selvitätte, onko joku kutsunut tiedostoa.

Lue lisää →
041

Hämärretyn PHP-koodin tunnistaminen

Lukukelvoton PHP-koodi, jossa on eval ja base64_decode, on klassinen merkki lisätystä haittakoodista. Mitä kaavoja etsitte, miten löydätte ne vaarattomasti ja milloin hämärrys on oikeutettua.

Lue lisää →
042

Palvelimen lähtevien yhteyksien tarkistus

Verkkopalvelin vastaa pääasiassa pyyntöihin. Jos se itse muodostaa yhteyksiä tuntemattomiin kohteisiin, se voi tarkoittaa hyökkääjän ohjausta tai tietovuotoa. Näin tarkistatte ja rajaatte lähtevää liikennettä.

Lue lisää →
043

Vieraiden ylläpitäjätilien löytäminen CMS:stä ja palvelimelta

Tuntematon ylläpitäjä on usein yksinkertaisin takaovi. Näin etsitte vieraita tilejä tasolta tasolle, myös sellaisia, jotka käyttöliittymä piilottaa.

Lue lisää →
044

Tuntemattomien SSH-avainten löytäminen ja poistaminen

Lisätty SSH-avain avaa hyökkääjille oven, vaikka kaikki salasanat olisi vaihdettu. Näin löydätte jokaisen authorized_keys-tiedoston ja tarkistatte jokaisen merkinnän.

Lue lisää →
045

Kryptolouhija verkkopalvelimella: merkit ja toimintatapa

Suoritin jatkuvasti täynnä, vaikka kävijöitä ei ole enempää: se voi olla kryptolouhija. Näin tarkistatte kuorman, löydätte prosessin ja sen uudelleenkäynnistysmekanismit ja etenette järjestyksessä.

Lue lisää →
046

Palvelin lähettää roskapostia: syiden löytäminen

Toimittamattomia viestejä, estolistoja, valituksia: kun oma palvelin lähettää roskapostia, taustalla on yleensä skripti tai kaapattu postilaatikko. Näin löydätte lähteen.

Lue lisää →
047

SEO-roska ja vieraat sivut Googlen hakemistossa

Yhtäkkiä lääkkeitä tai merkkituotteita esitteleviä sivuja ilmestyy hakutuloksiin teidän verkkotunnuksenne alla. Näin selvitätte, mistä SEO-roska tulee, ja saatte sen pois hakemistosta.

Lue lisää →
048

Verkkosivusto ohjaa kävijät vieraille sivuille

Kävijät päätyvät arvontasivuille tai epäilyttäviin verkkokauppoihin, mutta te itse ette näe mitään? Näin löydätte kerroksen, jossa uudelleenohjaus piilee, ja poistatte sen.

Lue lisää →
049

Varmistakaa todisteet ennen palvelimen uudelleenasennusta

Uudelleenrakennus poistaa hyökkääjän mutta myös kaikki jäljet. Kun käytätte tuntiin todisteiden varmistamiseen ensin, voitte myöhemmin kertoa, mitä tapahtui.

Lue lisää →
050

Tapauksen aikajanan laatiminen

Milloin hyökkääjä tuli, mitä hän teki ja milloin se huomattiin? Selkeä aikajana vastaa näihin kysymyksiin ja on ilmoitusten, vakuutuksen ja raportin perusta.

Lue lisää →
051

CMS-ydintiedostojen vertailu alkuperäiseen

Vertailu puhtaaseen alkuperäiseen paljastaa jokaisen muuttuneen tiedoston riippumatta siitä, tunteeko skanneri sen. Näin rakennatte vertailun WordPressille, Composer-projekteille ja järjestelmäpaketeille.

Lue lisää →
052

Tietokannan tarkistus sisäänajetun koodin varalta

Joka tarkistaa vain tiedostot, ohittaa puolet. Näin käytte läpi tietokannan sisällöt, asetukset, triggerit ja tilit sisäänajetun koodin varalta, lukien ja kopiolla.

Lue lisää →
053

Verkkosivustojen haittaohjelmaskannerit: mitä ne löytävät ja mitä eivät

Skanneri ei ilmoita mitään, joten kaikki on hyvin? Ei välttämättä. Millaisia verkkosivuskannereita on, mitä kukin näkee ja mitä se ei voi periaatteessa nähdä.

Lue lisää →

Koventaminen ja asetukset

20 artikkelia

054

PHP-FPM-poolien eristys sivustoittain

Oma pooli jokaiselle sivustolle on alku, ei loppu. Näin tarkistatte nykyiset poolit ja koventatte socketit, päätteet, tilasivut, resurssit ja lokit.

Lue lisää →
055

memory_limit-asetuksen määrittäminen oikein

memory_limit rajaa muistin PHP-pyyntöä kohden. PHP2Shellin jälkeen php.net suosittelee tilapäisesti päinvastaista. Mikä on voimassa normaalikäytössä, siirtymäaikana ja päivityksen jälkeen.

Lue lisää →
056

post_max_size- ja upload_max_filesize-rajojen järkevä asettaminen

Upload-rajat vaikuttavat kolmessa paikassa: verkkopalvelimessa, PHP:ssä ja sovelluksessa. Näin asetatte arvot yhteensopiviksi, myös php.netin PHP2Shellin siirtymäarvojen kanssa.

Lue lisää →
057

session.upload_progress pois käytöstä: oikein ja pysyvästi

Keino aukkoa CVE-2026-115560 vastaan ja yksi PHP2Shellin siirtymäajan toimenpiteistä asetetaan nopeasti. Jotta se pitää, sen on oltava oikeassa paikassa, lukittuna ja tarkistettava jokaisen päivityksen jälkeen.

Lue lisää →
058

expose_php ja Server-otsakkeet: versiotietojen piilotus

PHP, Nginx ja Apache kertovat versionumeronsa oletuksena jokaisessa vastauksessa. Se ei suojaa hyökkäyksiltä, mutta antaa skannereille kätevän osumalistan. Näin estätte sen ja säilytätte silti yleiskuvan.

Lue lisää →
059

display_errors off: virhetulosteiden poisto tuotannosta

Näkyvät PHP-virheilmoitukset paljastavat polkuja, tietokantojen nimiä ja versioita. Näin kytkette ne pois PHP:ssä, kehyksessä ja verkkopalvelimessa menettämättä virheitä näkyvistä.

Lue lisää →
060

php_admin_value: asetusten lukitseminen ylikirjoitukselta

Tietoturva-asetuksesta on vähän hyötyä, jos sovellus muuttaa sen takaisin yhdellä koodirivillä. Komennoilla php_admin_value ja php_admin_flag määritätte arvot sitovasti PHP-FPM:lle ja Apachelle.

Lue lisää →
061

Muistirajojen asettaminen systemd:llä ja cgroupeilla

php.net suosittelee PHP2Shellin siirtymäajan toimenpiteenä asetusta memory_limit=-1 ja PHP:n ulkopuolista muistirajaa. Näin asetatte rajan systemd:llä ja cgroupeilla niin, ettei yksittäinen worker vedä koko palvelua mukanaan.

Lue lisää →
062

Nginxin turvallinen asetus PHP:lle

Useimmat Nginx-PHP-asennusten heikkoudet eivät ole Nginxissä vaan PHP-locationin muutamalla rivillä. Näin asetatte PHP-FPM:lle välityksen niin, että vain halutut skriptit suoritetaan.

Lue lisää →
063

Apachen turvallinen asetus PHP:lle

Apache on joustava, ja juuri se tekee siitä alttiin virhekonfiguraatiolle. Näin liitätte PHP:n PHP-FPM:n kautta, suljette .htaccess-takaoven ja asetatte tärkeimmät ydinvalinnat turvallisiksi.

Lue lisää →
064

PHP:n suorituksen kielto upload-kansioissa

Web shell tarvitsee kaksi asiaa: kansion, johon se voidaan kirjoittaa, ja palvelimen, joka suorittaa sen. Näin viette siltä jälkimmäisen, ja jokaisessa kirjoitettavassa kansiossa, ei vain uploads-kansiossa.

Lue lisää →
065

Upload-pyyntöjen suodatus reunalla: mahdollisuudet ja riskit

Asiantuntijakirjoittajat ehdottavat, että upload-pyynnöt todellisten upload-polkujen ulkopuolella estetään välityspalvelimessa, kunnes PHP on päivitetty. Se voi auttaa, mutta myös lamauttaa lomakkeet ja tilaukset. Näin etenette hallitusti.

Lue lisää →
066

ModSecurityn ja OWASP Core Rule Setin käyttöönotto

Oma Web Application Firewall ModSecurityllä ja OWASP Core Rule Setillä on ilmainen ja tehokas, mutta ei itsestään toimiva. Näin valitsette moottorin, aloitatte ilman katkoksia ja hienosäädätte säännöt.

Lue lisää →
067

Fail2banin käyttöönotto verkkopalvelimille

Fail2ban estää osoitteet, jotka herättävät lokeissa toistuvasti huomiota. Verkkopalvelimille se tuo valmiit suodattimet, ja muutamalla rivillä lisäätte omia. Näin otatte sen käyttöön sulkematta ulos itseänne tai asiakkaitanne.

Lue lisää →
068

Palomuuri verkkopalvelimelle: avatkaa vain tarvittavat portit

Verkkopalvelin tarvitsee ulospäin yleensä vain kaksi porttia. Silti monella palvelimella tietokannat, PHP-FPM tai hallintakäyttöliittymät kuuntelevat internetissä. Näin löydätte avoimet palvelut ja suljette sen, mitä ei tarvita.

Lue lisää →
069

Automaattiset tietoturvapäivitykset Linux-palvelimilla

Raporttien mukaan jakelut toimittivat PHP-backportteja osin jo 21. lokakuuta 2026, korjausten julkaisupäivänä. Joka käyttää automaattisia tietoturvapäivityksiä, sai ne nopeasti palvelimelleen. Jotta ne tehoavat, tarvitaan uudelleenkäynnistyksiä, kolmannen osapuolen lähteitä ja valvontaa.

Lue lisää →
070

Vähimmän oikeuden periaate: verkkopalvelinkäyttäjän oikeudet

Ujutettu koodi toimii verkkopalvelinkäyttäjän oikeuksilla. Se, mitä tämä tili saa tehdä, ratkaisee, kuinka pitkälle hyökkääjä pääsee. Näin rajaatte shellin, sudon, cronin, tietokannan ja tiedostojärjestelmän vain välttämättömään.

Lue lisää →
071

Hallintaosien suojaus IP-osoitteella, VPN:llä tai lisäsuojalla

Miksi verkkosivuston hallintaosan ei tarvitse olla koko maailman saavutettavissa ja miten suojaatte sen IP-rajauksella, VPN:llä tai ennakkotunnistautumisella lukitsematta itseänne ulos.

Lue lisää →
072

TLS ja HTTPS oikein asetettuna

Mitä TLS-versioita ja salausjoukkoja (cipher suites) verkkopalvelimen tulisi nykyään tarjota, mihin suositukset perustuvat ja miten tarkistatte Nginxin, Apachen ja PHP:n lähtevät yhteydet.

Lue lisää →
073

CIS-benchmarkit ja BSI-moduulit verkkopalvelimille

Mitä koventamisstandardeja Linux-verkkopalvelimille on, miten CIS-benchmarkit ja IT-Grundschutz-moduulit eroavat toisistaan ja miten niistä tehdään tarkistettava vaatimus PHP-palvelimillenne.

Lue lisää →

Turvallinen kehitys

16 artikkelia

074

Salasanojen turvallinen tallennus PHP:ssä: password_hashin oikea käyttö

Miten kehittäjät tallentavat salasanat PHP:ssä password_hashilla ja password_verifylla, valitsevat sopivan menetelmän ja korvaavat vanhat MD5- tai SHA-1-tiivisteet ilman, että kaikkien käyttäjien salasana nollataan.

Lue lisää →
075

CSRF-suoja PHP-sovelluksissa

Miten kehittäjät estävät Cross-Site Request Forgeryn PHP-sovelluksissa: token jokaiselle muuttavalle pyynnölle, alkuperän tarkistus otsikosta ja SameSite-evästeet lisäkerroksena.

Lue lisää →
076

Syötteiden validointi ja suodatus PHP:ssä filter_varilla

Miten kehittäjät tarkistavat syötteet PHP:ssä filter_varilla, filter_input_arraylla ja sallittujen luetteloilla, mitkä suodattimet ovat vanhentuneita ja miksi validointi ei korvaa valmisteltuja lauseita eikä tulosteen koodausta.

Lue lisää →
077

Command Injectionin estäminen PHP:ssä

Miten kehittäjät välttävät Command Injectionin PHP:ssä: järjestelmäkomentojen korvaaminen PHP-funktioilla, proc_openin käyttö ilman shelliä, argumenttien tarkistus ja vaarallisten kohtien löytäminen vanhasta koodista.

Lue lisää →
078

Server-Side Request Forgeryn (SSRF) estäminen PHP:ssä

Miten kehittäjät estävät PHP-sovellusta kysymästä sisäisiä järjestelmiä vieraiden puolesta: sallittujen luettelot, protokollarajoitus, ratkaistun osoitteen tarkistus ja verkon rajat.

Lue lisää →
079

XML External Entitiesin (XXE) estäminen PHP:ssä

Miten kehittäjät käsittelevät XML:ää PHP:ssä turvallisesti: libxmlin oletuskäyttäytyminen, riskialttiit asetukset kuten LIBXML_NOENT, suoja entity-loaderilla ja LIBXML_NO_XXE:lla sekä tyypilliset piilotetut XML-syötteet.

Lue lisää →
080

Type Juggling PHP:ssä: löyhät vertailut tietoturvariskinä

Miksi löyhät vertailut operaattorilla == voivat PHP:ssä johtaa tietoturva-aukkoihin, mitä PHP 8.0 muutti ja miten kirjoitatte vertailut kirjautumisissa, tokeneissa ja käyttöoikeuksissa kestävästi.

Lue lisää →
081

Turvalliset satunnaisluvut ja tokenit PHP:ssä random_bytesilla

Miten kehittäjät luovat PHP:ssä tokeneita salasanalinkeille, API-avaimille ja kertakoodeille: kryptografisesti turvalliset lähteet, riittävä pituus, tallennus tiivisteenä ja rajattu voimassaolo.

Lue lisää →
082

Tunnusten ja .env-tiedostojen oikea suojaus

Miten suojaatte tietokannan salasanat, API-avaimet ja muut salaisuudet PHP-projekteissa: .env-tiedostot verkkojuuren ulkopuolella, verkkopalvelimen estot, tiukat oikeudet ja hallittu vaihto tapahtuman jälkeen.

Lue lisää →
083

Julkinen .git-kansio: aliarvioitu tietovuoto

Miksi Gitillä toimitettu verkkojuuri voi paljastaa koko lähdekoodin historioineen, miten tarkistatte asian, estätte pääsyn heti ja rakennatte käyttöönoton pysyvästi ilman .git-kansiota.

Lue lisää →
084

Varmuuskopiotiedostot verkkojuuressa: .zip, .sql ja .bak

Miksi tietokantavedokset, arkistot ja varmuuskopiot julkisessa hakemistossa kuuluvat yleisimpiin tietovuotoihin, miten ne löydetään ja estetään ja miten selvitetään, onko niitä haettu.

Lue lisää →
085

phpinfo()-tiedostot: miksi niiden on poistuttava

PHP2Shellin jälkeen moni ylläpitäjä luo nopeasti tiedoston info.php. Miksi tällaiset tiedostot ovat tietovuoto, miten ne löydetään ja mitkä tarkistustavat ovat parempia.

Lue lisää →
086

Riippuvuudet ajan tasalla: Composer, npm ja laajennukset

Projekti koostuu kolmesta pakettimaailmasta: Composer, npm ja CMS-laajennukset. Miten pidätte kaikki kolme ajan tasalla kiinteällä rytmillä, selkeällä vastuulla ja testeillä.

Lue lisää →
087

Tietoturvakoodikatselmointi PHP-projekteille

Miten tiimit käyvät omaa PHP-koodiaan läpi kohdennetusti tietoturva-aukkojen varalta: katselmointityypit, kriittiset funktiot, järkevät työkalut ja tarkistuslista.

Lue lisää →
088

Turvallinen lokitus: virheiden kirjaus ilman tietovuotoa

Lokit auttavat vianhaussa ja forensiikassa, mutta niistä tulee helposti itse tietovuoto. Mitä PHP-sovellusten tulisi kirjata, mitä ei koskaan ja miten lokit suojataan.

Lue lisää →
089

REST-API:iden suojaus PHP:ssä

Rajapinnat on usein suojattu huonommin kuin niiden edessä oleva verkkosivusto. Tärkeimmät säännöt PHP:n REST-API:ille olion käyttöoikeudesta nopeusrajoitukseen.

Lue lisää →

Johtaminen ja lainsäädäntö

14 artikkelia

090

IT-palveluntarjoajasopimukset: tietoturvavelvoitteet selkeiksi

PHP2Shell osoitti, kuinka usein on epäselvää, kenen pitää päivittää. Mitkä tietoturvavelvoitteet kuuluvat sopimuksiin toimiston, hosting-palveluntarjoajan ja IT-palveluntarjoajan kanssa.

Lue lisää →
091

Henkilötietojen käsittely, kun palveluntarjoajat pääsevät palvelimelle

Joka päästää ulkopuoliset asiakastietoja sisältäville palvelimille, tarvitsee yleensä käsittelijäsopimuksen (DPA). Mitä GDPR:n 28 artikla edellyttää ja miten järjestätte pääsyt hätätilanteessa tietosuojan mukaisesti.

Lue lisää →
092

Haavoittuvuuksien hallinta pk-yrityksessä

Yksikään keskisuuri yritys ei voi käsitellä jokaista tiedotetta heti. Kevyt kierto, jossa haavoittuvuudet kirjataan, arvioidaan, ratkaistaan ja todennetaan, varmistaa, että tärkein hoidetaan ensin.

Lue lisää →
093

Tietäkää, mitä käytössä on: kaikkien verkkosivustojen ja palvelinten luettelo

PHP2Shellin kohdalla monet eivät kompastuneet korjaukseen vaan kysymykseen, missä PHP ylipäätään toimii. Näin rakennatte luettelon kaikista verkkosivustoista ja palvelimista.

Lue lisää →
094

Päivitysten hallinta prosessina palokunta-toiminnan sijaan

Joka päivittää vasta kun palaa, menettää aikaa hätätilanteessa. Miten päivitysten hallinnan prosessi, jossa on kiinteät luokat, ikkunat ja todisteet, yhdistää rutiinin ja hätätilanteen.

Lue lisää →
095

Hätäyhteystiedot: kenelle ilmoitetaan ja milloin?

Hätätilanteessa ratkaisee, ketkä tavoitetaan ja milloin. Näin rakennatte IT-hätäyhteystietojen listan, jossa on laukaisevat tilanteet, sijaiset ja tiedot, joita jokainen puhelu tarvitsee.

Lue lisää →
096

Mitä murrettu palvelin maksaa: kuluerät

Murrettu verkkopalvelin aiheuttaa enemmän kuluja kuin korjaus. Mitä kulueriä syntyy ja miten perustelette ennaltaehkäisyn budjetin omilla luvuillanne.

Lue lisää →
097

Asiakkaiden tiedottaminen häiriön jälkeen

Velvollisuus tai vapaaehtoinen: miten päätätte häiriön jälkeen, ketä tiedotatte, mitkä kanavat ovat turvallisia ja miten asiakaspalvelunne on valmisteltu.

Lue lisää →
098

Verkon toimitusketju: toimisto, hosting-yritys, lisäosien toimittaja

PHP2Shell osoitti, kuinka monta lenkkiä korjauksen ja verkkosivustonne välissä on. Näin tunnette verkkosivustonne toimitusketjun, turvaatte sen ja pehmennätte yksittäisten lenkkien vikaantumista.

Lue lisää →
099

Tietoturvatietoisuus ylläpitäjille ja toimittajille: tietoturvatietoisuus verkkotiimissä

Joka ylläpitää verkkosivustoja, päättää päivittäin tietoturvasta, usein huomaamattaan. Näin koulutatte ylläpitäjät ja toimittajat rooleittain ja ilman kalvosulkeisia.

Lue lisää →
100

Hätäharjoitus pöydän ääressä: verkkopalvelinhäiriön läpikäynti

Pöytäharjoitus vie iltapäivän ja osoittaa, kantaako hätäsuunnitelmanne. Tästä löydätte valmiin käsikirjoituksen PHP-verkkopalvelimen häiriölle.

Lue lisää →
101

ISO 27001 ja TISAX: mitä verkkopalvelimet koskee

Joka ylläpitää ISO 27001 -mukaista tietoturvajohtamisjärjestelmää tai omistaa TISAX-tunnuksen, joutuu ottamaan verkkopalvelimet huomioon. Tässä kerrotaan, mitä vaatimuksia ne koskettavat ja mitkä todisteet merkitsevät PHP2Shellin jälkeen.

Lue lisää →
102

VdS 10000: tietoturva pienille ja keskisuurille yrityksille

VdS 10000 on kevyt kehys keskisuurten yritysten tietoturvalle. Mitä se vaatii, mikä tuli uutena 2025 ja mitä se tarkoittaa verkkosivustoille ja verkkopalvelimille.

Lue lisää →
103

Lessons Learned: paremmaksi häiriön jälkeen

Häiriön jälkeen on ennen seuraavaa. Jäsennelty jälkipuinti ilman syyllistämistä muuttaa huonon viikon mitattavaksi edistykseksi.

Lue lisää →

Päätöksenteon tuki

10 artikkelia

104

Päivitys, sulkeminen vai odottaminen? Päätöksentekoapu PHP-aukossa

Kriittisen PHP-aukon kohdalla vastuuhenkilöiden on päätettävä nopeasti. Tämä apu jäsentää kolme vaihtoehtoa, nimeää perusteet ja näyttää, milloin odottaminen on perusteltua.

Lue lisää →
105

WAF vai päivitys: miksi tarvitsette molempia

Web Application Firewall voi torjua hyökkäyksiä mutta ei sulje aukkoa PHP-tulkissa. Milloin WAF auttaa, mihin sen teho päättyy ja miten yhdistätte molemmat järkevästi.

Lue lisää →
106

Palvelimen uudelleenasennus vai puhdistus? Päätös tartunnan jälkeen

Tunkeutumisen jälkeen on kaksi tietä: palvelin puhdistetaan tai rakennetaan uudelleen. Mitkä perusteet ratkaisevat, ja miksi järjestys on tärkeämpi kuin valinta.

Lue lisää →
107

Korjaatteko itse vai kutsutteko palveluntarjoajan? Rehellinen punninta

Kaikki tietoturvatilanteet eivät vaadi ulkopuolista apua. Näillä perusteilla ja lyhyellä itsearvioinnilla ratkaisette, selviääkö tiiminne PHP2Shellistä yksin vai tarvitsetteko tukea.

Lue lisää →
108

IT-tietoturvapalveluntarjoajan valinta: 12 kysymystä ennen toimeksiantoa

Hyvän tietoturvapalveluntarjoajan löytäminen aikapaineessa on vaikeaa. Nämä kaksitoista kysymystä auttavat vertailemaan tarjouksia asiallisesti lankeamatta markkinointilupauksiin.

Lue lisää →
109

Hallinnoitu hosting vai oma palvelin? Tietoturvavertailu

PHP2Shell oli stressitesti jokaiselle toimintamallille. Vertailu näyttää, milloin hallinnoitu hosting on turvallisempi, milloin oma palvelin ja mitkä sekamuodot ovat osoittautuneet hyviksi.

Lue lisää →
110

PHP-päivitys vai backport? Päätös vanhoille järjestelmille

Vanhoille PHP-versioille on PHP2Shellin jälkeen useita teitä: jakelun backport, kolmannen osapuolen lähde, lähdekoodikorjaus, pitkäaikainen tuki tai päivitys. Mihin kukin tie kelpaa ja kuinka kauan se kantaa.

Lue lisää →
111

Vaihdetaanko CMS hakkeroinnin jälkeen? Milloin se auttaa ja milloin ei

Tunkeutumisen jälkeen luottamus CMS:ään on usein mennyt. Uusi järjestelmä ratkaisee kuitenkin harvoin varsinaisen syyn. Milloin vaihto on järkevä ja miten se onnistuu siististi.

Lue lisää →
112

Staattiset verkkosivustot: vähemmän PHP:tä, vähemmän hyökkäyspinta-alaa

Staattinen verkkosivusto toimittaa valmiita HTML-tiedostoja eikä tarvitse PHP:tä palvelimella. Se pienentää hyökkäyspinta-alaa selvästi, mutta tuo mukanaan omat rajansa ja velvoitteensa.

Lue lisää →
113

Tunkeutumistesti, Bug Bounty vai haavoittuvuusskannaus? Valitkaa sopiva tarkastusmenetelmä

Skannaus, tunkeutumistesti ja Bug Bounty tarkastavat verkkosivustoja aivan eri tavoin. Mitä kukin menetelmä tekee, missä se epäonnistuu ja mikä järjestys sopii yrityksellenne.

Lue lisää →
Pikayhteys

Jokainen tunti on tärkeä. Kirjoittakaa meille nyt.

Kuvatkaa lyhyesti järjestelmä, PHP-versio ja havainnot. Otamme yhteyttä, selvitämme tilanteen ja työskentelemme etänä, kunnes tapaus on käsitelty loppuun ja dokumentoitu.

Pikaapu