Накратко: Статичният уебсайт се състои от готови HTML, CSS и файлове с изображения, които уеб сървърът само обслужва. Тъй като на сървъра не работят нито PHP, нито база данни, уязвимости като PHP2Shell, SQL инжекция или внесени webshell-ове отпадат като риск до голяма степен. За сигурността на статичния уебсайт имат значение други неща: защитени достъпи до хостинга, домейна и build инструментите, поддържани зависимости и грижливо подбрани външни услуги. Той е подходящ най-вече за уебсайтове, които рядко се променят и не изискват клиентски акаунти.
Защо въпросът се задава именно сега
PHP2Shell показа на много фирми колко много зависи от един-единствен компонент. Фирмен уебсайт с десет страници, обновяван веднъж на тримесечие, работеше на същия PHP като голям онлайн магазин и беше изложен на същата критична уязвимост. Според медийни съобщения дори институции и общини изключиха предпазно уебсайтове.
Тогава се налага въпросът: имаме ли изобщо нужда от PHP на сървъра за нашия уебсайт? При много малки и средни предприятия честният отговор е: за обслужването често не. PHP създава страницата наново при всяко отваряне, въпреки че съдържанието не се е променяло със седмици. Как става това технически, описва Как PHP създава уеб страница. Какво означава самата уязвимост, обяснява Какво е PHP2Shell?.
Как работи статичният уебсайт
При статичния уебсайт страницата не се създава при посещението, а предварително. Генератор за статични страници, например Hugo, Jekyll или Eleventy, взема текстове, изображения и шаблони и изгражда от тях готови файлове. Тези файлове се качват на прост уеб сървър или на Content Delivery Network, тоест разпределена мрежа за доставка.
За редакторите пред това може да стои инструмент за редактиране, който приема промените и задейства ново изграждане. Понякога за целта се ползва така нареченото Headless CMS, което само управлява съдържанието и не е нужно да е публично достъпно. Посетителят не вижда нищо от това; той получава само готовите файлове.
Статичен уебсайт и сигурност в сравнение
| Критерий | Динамично PHP CMS | Статичен уебсайт |
|---|---|---|
| Програмна логика на публичния сървър | Да, при всяко отваряне | Не |
| Риск от уязвимости в интерпретатора на PHP | Да, както при PHP2Shell | Отпада на сървъра за обслужване |
| Публично свързана база данни | Да | Не |
| Типични входни врати | Добавки, администраторски вход, качвания, сървър | Достъпи до хостинга, домейна, build системата, външни услуги |
| Формуляри, търсене, клиентски акаунт | Вградени | Само чрез външни услуги или отделни функции |
| Усилия за поддръжка от редакторите | Малки, позната среда | Зависи от редакторския инструмент |
| Поддръжка | Редовни ъпдейти на CMS, добавки и PHP | Ъпдейти на build инструментите и зависимостите |
| Пригодност | Магазини, портали, много редактори, чести промени | Фирмени уебсайтове, целеви страници, документация |
Таблицата показва: повърхността за атака се измества, но не изчезва. Вместо публично достъпен PHP сървър трябва да защитавате акаунта при хостинг доставчика, домейна, build pipeline-а и евентуално редакторския инструмент.
Какви рискове остават при статичните уебсайтове
Първо достъпите. Който поеме хостинг акаунта, достъпа до домейна или хранилището с код, може да промени уебсайта, изцяло без PHP. Двуфакторното удостоверяване и личните акаунти затова са задължителни.
Второ зависимостите. Генераторите и шаблоните често носят много пакети, например от npm. Те трябва да се поддържат актуални, защото компрометирана зависимост при изграждането може да запише зловреден код в готовите файлове. Как да го организирате, описва Как да поддържате зависимостите актуални.
Трето външните услуги. Услугите за формуляри, функциите за търсене, аналитичните инструменти и вградените скриптове работят в браузъра на посетителите или на чужди сървъри. Всяка от тези услуги е отношение на доверие, и от гледна точка на защитата на данните.
Четвърто страната на браузъра. И статичната страница трябва да задава Security Headers, например Content-Security-Policy, която определя кои скриптове могат да се зареждат. Основите са в Security Headers за уебсайтове.
Преди прехода проверете кои функции Вашият уебсайт наистина ползва. Често са по-малко, отколкото се мисли: страници, изображения, контактен формуляр. Тогава пътят към статичния уебсайт е по-кратък, отколкото изглежда първоначално.
За кого преходът си струва и за кого не
Статичният уебсайт е добре подходящ за фирмени страници с обозрим обем, целеви страници за кампании, документации на продукти и страници за кариера. Преходът си струва особено когато досегашният уебсайт работи на стара версия на PHP и ъпгрейд така или иначе предстои.
По-малко подходящ е за онлайн магазини, клиентски портали, системи за резервации и уебсайтове с много редактори, които публикуват ежедневно. Тук динамичната система остава разумна. Смесена форма може да помогне: магазинът остава динамичен и добре заздравен, ръководствата и фирмените страници се обслужват статично.
Често подценявано предимство се проявява в критичен момент. Тъй като готовите файлове могат по всяко време да се изградят наново от шаблони и съдържание, манипулиран уебсайт може бързо да се върне към известно, чисто състояние. Предпоставка е съдържанието и шаблоните да са в защитено хранилище, промените да се протоколират проследимо и никой да не редактира файловете директно на сървъра.
Доставчик на услуги по сигурност за прехода не Ви трябва задължително; това може да поеме агенция или разработчик. Ако досегашният уебсайт е бил компрометиран, съдържанието все пак трябва да се провери преди прехвърляне. За това се занимава Да сменим ли CMS след хака?.
Как помага PHP SOS конкретно?
- Проверяваме кои функции Вашият уебсайт действително изисква и казваме открито дали статичното решение е подходящо.
- При прехода обезопасяваме достъпите до хостинга, домейна и build системата с двуфакторно удостоверяване и лични акаунти.
- Проверяваме външните услуги и задаваме Security Headers, за да е новият уебсайт добре защитен и в браузъра.
- За оставащите PHP системи поемаме ъпдейти и наблюдение в договор за поддръжка на сигурността.
Извод
Статичният уебсайт не е универсално лекарство, но за много фирмени страници е най-простият начин да се освободите от цял клас рискове. Където не работи PHP, PHP2Shell не може да направи нищо. Постигнатата сигурност обаче се задържа само ако достъпите, зависимостите и външните услуги се приемат толкова сериозно, колкото преди сървърът.
Често задавани въпроси
Може ли статичен уебсайт все пак да бъде хакнат?
Да. Отпада сървърната програмна логика и с нея голям клас атаки. Остават обаче уязвими достъпите до хостинга, домейна и build системата, вградените външни услуги и инструментите, с които се създава страницата.
Може ли статичен уебсайт да има контактни формуляри?
Да, чрез външна услуга за формуляри или малка, отделно поддържана функция. Тогава обработката на данните е при тази услуга. Изяснете защитата на данните и обработването по поръчка, преди да я вградите.
Могат ли редакторите сами да поддържат статичен уебсайт?
С подходящ редакторски инструмент да. Много решения предлагат интерфейс за редактиране, от който страницата след това се генерира наново. За екипи, които ежедневно променят много съдържание, класическото CMS обаче често е по-удобно.
Има ли смисъл от прехода за онлайн магазин?
Обикновено не изцяло. Количката, клиентският акаунт и плащането изискват сървърна логика. Възможно е части като ръководства или фирмени страници да се обслужват статично, а магазинът да се поддържа отделно.