Pe scurt: Un site static constă din fișiere HTML, CSS și imagini gata făcute, pe care serverul web doar le livrează. Deoarece pe server nu rulează PHP și nici bază de date, breșe precum PHP2Shell, injecția SQL sau webshell-urile introduse dispar în mare parte ca risc. Pentru securitatea unui site static contează în schimb alte lucruri: accese protejate la hosting, domeniu și uneltele de build, dependențe întreținute și servicii terțe alese cu grijă. Se potrivește mai ales site-urilor care se modifică rar și nu au nevoie de conturi de clienți.
De ce se pune întrebarea tocmai acum
PHP2Shell a arătat multor companii cât de mult depinde de o singură componentă. Un site de firmă cu zece pagini, actualizat o dată pe trimestru, rula pe același PHP ca un mare magazin online și era astfel expus aceleiași breșe critice. Potrivit presei, chiar și autorități și comune au oprit preventiv site-uri.
Întrebarea se pune de la sine: avem nevoie deloc de PHP pe server pentru site-ul nostru? La multe întreprinderi mici și mijlocii, răspunsul sincer este: pentru livrare adesea nu. PHP generează pagina din nou la fiecare accesare, deși conținutul nu s-a schimbat de săptămâni. Cum decurge acest lucru tehnic descrie Cum generează PHP o pagină web. Ce înseamnă breșa în sine explică Ce este PHP2Shell?.
Cum funcționează un site static
La un site static, pagina nu este generată la vizită, ci dinainte. Un generator de pagini statice, de exemplu Hugo, Jekyll sau Eleventy, preia texte, imagini și șabloane și construiește din ele fișiere gata făcute. Aceste fișiere sunt încărcate pe un server web simplu sau într-o rețea de livrare de conținut, adică o rețea distribuită de livrare.
Pentru redactori poate sta în față o unealtă de editare, care primește modificările și declanșează reconstruirea. Uneori se folosește pentru aceasta un așa-numit CMS headless, care administrează doar conținutul și nu trebuie să fie el însuși accesibil public. Vizitatorul nu vede nimic din toate acestea; el primește doar fișierele gata făcute.
Site static și securitate în comparație
| Criteriu | CMS PHP dinamic | Site static |
|---|---|---|
| Logică de program pe serverul public | Da, la fiecare accesare | Nu |
| Risc din cauza breșelor din interpretorul PHP | Da, ca la PHP2Shell | Dispare pe serverul de livrare |
| Bază de date conectată public | Da | Nu |
| Căi tipice de pătrundere | Pluginuri, autentificare admin, upload-uri, server | Accese la hosting, domeniu, sistem de build, servicii terțe |
| Formulare, căutare, cont de client | Integrate | Doar prin servicii externe sau funcții separate |
| Efort de întreținere pentru redactori | Redus, interfață familiară | Depinde de unealta editorială |
| Mentenanță | Actualizări regulate ale CMS-ului, pluginurilor și PHP | Actualizări ale uneltelor de build și ale dependențelor |
| Potrivire | Magazine online, portaluri, mulți redactori, modificări frecvente | Site-uri de firmă, pagini de destinație, documentație |
Tabelul arată: suprafața de atac se mută, nu dispare. În loc de un server PHP accesibil public trebuie să protejați contul de la furnizorul de hosting, domeniul, pipeline-ul de build și, la nevoie, unealta editorială.
Ce riscuri rămân la site-urile statice
În primul rând accesele. Cine preia contul de hosting, accesul la domeniu sau depozitul de cod poate modifica site-ul, chiar fără PHP. Autentificarea în doi factori și conturile personale sunt de aceea obligatorii.
În al doilea rând dependențele. Generatoarele și șabloanele aduc adesea multe pachete, de exemplu din npm. Acestea trebuie menținute la zi, deoarece o dependență compromisă poate scrie cod malițios în fișierele gata făcute la construire. Cum organizați acest lucru descrie Menținerea dependențelor la zi.
În al treilea rând serviciile terțe. Serviciile de formulare, funcțiile de căutare, uneltele de analiză și scripturile integrate rulează în browserul vizitatorilor sau pe servere străine. Fiecare dintre aceste servicii este o relație de încredere, inclusiv din punct de vedere al protecției datelor.
În al patrulea rând partea de browser. Și o pagină statică ar trebui să seteze antete de securitate, de exemplu o Content-Security-Policy, care stabilește ce scripturi au voie să fie încărcate. Bazele se află la Antete de securitate pentru site-uri.
Verificați înainte de o trecere ce funcții folosește cu adevărat site-ul dumneavoastră. Adesea sunt mai puține decât se crede: pagini, imagini, un formular de contact. Atunci drumul spre un site static este mai scurt decât pare la început.
Pentru cine merită trecerea și pentru cine nu
Un site static este foarte potrivit pentru pagini de companie de amploare redusă, pagini de destinație pentru campanii, documentații de produs și pagini de cariere. Trecerea merită mai ales dacă actualul site rulează pe o versiune PHP veche, iar un upgrade ar fi oricum necesar.
Este mai puțin potrivit pentru magazine online, portaluri pentru clienți, sisteme de rezervări și site-uri cu mulți redactori care publică zilnic. Aici un sistem dinamic rămâne sensibil. O formă mixtă poate ajuta: magazinul rămâne dinamic și este bine consolidat, ghidurile și paginile companiei sunt livrate static.
Un avantaj adesea subestimat apare în caz de urgență. Deoarece fișierele gata făcute pot fi reconstruite oricând din șabloane și conținut, un site manipulat poate fi readus rapid la o stare cunoscută, curată. Condiția este ca conținutul și șabloanele să se afle într-un depozit protejat, modificările să fie înregistrate verificabil, iar nimeni să nu editeze fișierele direct pe server.
Nu aveți neapărat nevoie de un furnizor de servicii de securitate pentru trecere; o poate prelua o agenție sau un dezvoltator. Dacă site-ul de până acum a fost compromis, conținutul ar trebui totuși verificat înainte de preluare. Aceasta o tratează Schimbăm CMS-ul după atac?.
Cum ajută PHP SOS concret?
- Verificăm ce funcții are cu adevărat nevoie site-ul dumneavoastră și spunem deschis dacă o soluție statică se potrivește.
- La o trecere, securizăm accesele la hosting, domeniu și sistemul de build cu autentificare în doi factori și conturi personale.
- Verificăm serviciile terțe și setăm antete de securitate, pentru ca noul site să fie bine protejat și în browser.
- Pentru sistemele PHP rămase preluăm actualizările și monitorizarea în contractul de mentenanță de securitate.
Concluzie
Un site static nu este un panaceu, dar pentru multe pagini de companie este cea mai simplă cale de a scăpa de o întreagă clasă de riscuri. Acolo unde nu rulează PHP, PHP2Shell nu poate face nimic. Securitatea câștigată rezistă însă doar dacă accesele, dependențele și serviciile terțe sunt luate la fel de în serios cum era înainte serverul.
Întrebări frecvente
Poate fi spart totuși un site static?
Da. Dispare logica de program de pe partea serverului și, odată cu ea, o clasă mare de atacuri. Rămân însă vulnerabile accesele la hosting, domeniu și sistemul de build, serviciile terțe integrate și uneltele cu care este generat site-ul.
Poate un site static să aibă formulare de contact?
Da, printr-un serviciu extern de formulare sau o mică funcție operată separat. Atunci prelucrarea datelor revine acelui serviciu. Clarificați protecția datelor și prelucrarea în numele operatorului înainte de a-l integra.
Pot redactorii să întrețină singuri un site static?
Cu o unealtă editorială potrivită, da. Multe soluții oferă o interfață de editare din care site-ul este apoi regenerat. Pentru echipele care modifică zilnic mult conținut, un CMS clasic este însă adesea mai comod.
Merită trecerea pentru un magazin online?
De obicei nu integral. Coșul de cumpărături, contul de client și plata necesită logică pe partea serverului. Este posibil ca părți precum ghidurile sau paginile companiei să fie livrate static, iar magazinul să fie operat separat.