PHP-kehykset yleiskatsauksena

Lyhyesti: PHP-kehys on uudelleenkäytettävästä koodista koostuva perusrakenne, joka ratkaisee valmiiksi verkkosovelluksen tyypillisiä tehtäviä: pyyntöjen ohjaus oikealle koodille, lomaketietojen käsittely, tietokantojen käyttö, tulosteiden tuottaminen. Tunnettuja PHP-kehyksiä ovat Laravel, Symfony, Laminas, CodeIgniter, Yii, CakePHP ja Slim. Kehys tuo mukanaan tietoturvan rakennuspalikoita, mutta ei suojaa PHP-tulkin aukoilta kuten PHP2Shell.

Mikä PHP-kehys on?

Ilman kehystä jokainen tiimi kirjoittaa reitityksen, lomaketarkistuksen, istunnot ja virheenkäsittelyn uudelleen. Kehys antaa niihin kiinteät rakennuspalikat ja käytännöt. Se säästää aikaa, tekee koodista luettavaa uusille kehittäjille ja kokoaa tietoturvatoiminnot yhteen paikkaan sen sijaan, että ne olisi hajautettu satoihin tiedostoihin.

Johdolle tärkein seuraus on tämä: kehystä valitessanne sitoudutte vuosiksi sen julkaisusykliin. Jos kehys ei enää tue jotakin PHP-versiota tai sitä ei enää ylläpidetä, jokainen päivitys käy kalliimmaksi.

Useimmat modernit kehykset asennetaan Composerilla ja ne noudattavat PHP-FIG:n standardeja, esimerkiksi PSR-4:ää automaattiseen lataukseen tai PSR-7:ää HTTP-viesteille.

Tunnetut PHP-kehykset vertailussa

Seuraava yleiskatsaus käyttää projektien omia kuvauksia niiden etusivuilta. Suosioon tai markkinaosuuteen perustuvat arviot jätämme tietoisesti pois, koska niille ei ole luotettavaa yhteistä lähdettä.

Symfony mainitsee etusivullaan Drupalin, Laravelin, API Platformin ja Composerin projekteina, jotka käyttävät Symfony-komponentteja. Kehys on siis usein mukana myös siellä, missä sitä ei suoraan näe. Miltä se näyttää CMS- ja verkkokauppajärjestelmissä, näyttää sivu CMS- ja verkkokauppajärjestelmät PHP:llä.

Lähes kaikkien kehysten yhteiset osat

Erilaisista filosofioista huolimatta useimmilla kehyksillä on yhteinen rakenne. Kaikki pyynnöt kulkevat yhden sisääntulopisteen, front controllerin, kautta, yleensä public/index.php. Verkkopalvelin välittää sille jokaisen osoitteen, jolle ei ole todellista tiedostoa.

# Esimerkki: Nginx ohjaa tuntemattomat polut front controllerille
root /var/www/app/public;

location / {
    try_files $uri /index.php$is_args$args;
}

Apachessa tämän tehtävän hoitaa yleensä uudelleenkirjoitussääntö julkisessa kansiossa, muissa verkkopalvelimissa vastaava sääntö. Kaikissa tapauksissa on tärkeää, että verkkopalvelin osoittaa kansioon public eikä projektin pääkansioon. Väärin asetettu dokumenttihakemisto kuuluu yleisimpiin syihin siihen, että asetustiedostot yhtäkkiä ovat julkisesti haettavissa.

Tietoturvan etu: vain kansio public on verkkojuuressa. Konfiguraatio, lähdekoodi ja vendor ovat yhtä tasoa ylempänä eivätkä ole URL:n kautta tavoitettavissa. Sen jälkeen reititin yhdistää pyynnön kontrolleriin, middleware tarkistaa kirjautumisen tai CSRF-tokenin, ja mallipohjamoottori tuottaa tulosteen automaattisella merkkien suojauksella.

Miten kehyksen valitsee?

Uudessa kehityksessä tai olemassa olevan projektin haltuunotossa auttavat nämä kysymykset:

1. Ylläpito ja julkaisusykli: Kuinka kauan versioille toimitetaan tietoturvapäivityksiä, ja onko versioita pidennetyllä tuella?
2. PHP-tuki: Toimiiko käytetty kehysversio PHP-versiolla, joka itse saa vielä tietoturvapäivityksiä? Se selviää projektin vaatimuksista.
3. Tiimi ja palveluntarjoaja: Tunteeko tiimi kehyksen, ja löytyykö hätätilanteessa sen osaajia?
4. Ekosysteemi: Onko vaatimuksiinne ylläpidettyjä paketteja, vai pitäisikö paljon rakentaa itse?
5. Standardit: Jos kehys noudattaa PSR-rajapintoja, rakennuspalikat on myöhemmin helpompi vaihtaa.

Laravel- ja Symfony-projekteille meillä on omat suojaussivunsa: Laravel-sovellusten suojaus ja Symfony-sovellusten suojaus.

Mitä kehys tekee tietoturvan hyväksi ja mitä ei

Kehykset vievät kehittäjiltä monta virhelähdettä: valmistellut tietokantakyselyt SQL-injektiota vastaan, automaattinen merkkien suojaus cross-site scriptingiä vastaan, lomakkeiden CSRF-suoja, turvalliset salasanatiivisteet. Se toimii kuitenkin vain, jos tiimi käyttää näitä rakennuspalikoita eikä kierrä niitä.

PHP2Shelliä vastaan mikään tästä ei auta. CVE-2026-109618 ja CVE-2026-109619 ovat PHP-tulkissa. PHP-tiimi arvioi riskin korkeimmaksi mod_php:ssä; siinä on esitetty hyökkäys, joka toimii ennen kuin sovelluskoodia ajetaan. Kehys ei siis pääse lainkaan vaikuttamaan. Apua tuo vain päivitys versioon PHP 8.5.12, 8.4.27, 8.3.36 tai 8.2.35 ja kaikkien PHP-prosessien uudelleenkäynnistys.

Vanhemmissa projekteissa tulee vielä yksi riski: jos sovellus roikkuu vanhassa kehysversiossa, se roikkuu usein myös vanhassa PHP-versiossa. PHP 8.1:lle ja sitä vanhemmille PHP-projekti ei enää tarjoa virallisia päivityksiä.

Miten PHP SOS auttaa konkreettisesti?

• Selvitämme sovelluksenne kehyksen, version ja PHP-vaatimukset ja toteamme, saavatko molemmat vielä tietoturvapäivityksiä.
• Tarkistamme rakenteen: onko vain public verkkojuuressa, ovatko konfiguraatio ja vendor suojattuja?
• Suunnittelemme kehys- ja PHP-päivitykset erikseen, testaamme ne ja asennamme ne käynnistämällä kaikki workerit uudelleen.
• Omille kehitystöille tarjoamme tietoturvatarkastuksen ja tunkeutumistestin, joka tarkistaa kohdennetusti kehyksen suojatoimintojen käytön.

Usein kysytyt kysymykset

Lähteet

• Symfony
• Laravel
• Laminas Project
• Slim Framework