10 най-често срещани заплахи за сигурността на сайта (Част 2)

Продължаваме списъка с най-често срещаните заплахи за сигурността на сайта (и съветите за защита). 

Както видяхме, сигурността и защитата на сайта е споделена отговорност, за която полагат грижи както разработчиците и потребителите, така и хостинг доставчикът.

В първата част видяхме 4 от заплахите, вижте и останалите 6:

5. Distributed Denial of Service (DDoS) атаки

DDoS (Distributed Denial of Service) атаката е вид кибератака, при която множество компрометирани компютри, често наричани ботнет, се използват за заливане на жертвата (уебсайт или онлайн услуга) с огромен обем трафик, който превишава капацитета на ресурсите им и води до недостъпност за легитимните потребители. Основната цел на DDoS атаката е да наруши нормалното функциониране на сайта, като го направи недостъпен за потребителите.

DDoS атаките могат да варират по мащаб и сложност, като някои включват множество вектори на атака, насочени към различни части от инфраструктурата на сайта. Често са използвани от хакерите с цел изнудване за пари от целевите организации, да получат конкурентно предимство или просто да нарушат онлайн услугите по различни причини.

Вижте още: Какво е DDoS? | Help

Пример

Представете си онлайн магазин, който разчита в голяма степен на своето онлайн присъствие за осъществяване на дейността си. Конкурент или злонамерено лице решава да започне DDoS атака срещу този уебсайт.

Нападателят използва мрежа от компрометирани компютри, често контролирани дистанционно чрез зловреден софтуер, за да създаде ботнет. Този ботнет може да се състои от хиляди или дори стотици хиляди устройства като компютри, сървъри, устройства от интернет на нещата (IoT) или дори смартфони.

Злонамереният хакер инструктира мрежата да изпрати огромен обем трафик към сървъра на целевия онлайн магазин, за да надхвърли капацитета му за обработка на входящите заявки. Трафикът може да се състои от различни видове заявки като HTTP заявки, DNS заявки или друг мрежов трафик.

В резултат на огромната вълна от трафик сървърът на сайта се претоварва и се затруднява да отговори на легитимните заявки на потребителите. Зареждането на сайта може да се забави значително, с прекъсвания или да спре да се зарежда изобщо.

Легитимните потребители, които се опитват да получат достъп до магазина по време на атаката, изкачват дълго време за зареждане или изобщо не могат да получат достъп до уебсайта. Това води до прекъсване на бизнес операциите и потенциални финансови загуби за онлайн магазина.

Атаката продължава за определен период от време, като причинява неудобство на потребителите и вреди на репутацията на бизнеса.

Как да се предпазите?

В случай че сайтът се намира на Ваша инфраструктура, може да се обърнете към системните администратори, които се грижат за нея. Друго решение е да активирате CDN услуга (мрежа за доставка на съдържание) за разпределяне на трафика и филтрирането му.

Вижте още: Настройки за защита в Cloudflare при нежелан трафик към сайта | Help

Ако сайтът Ви е при нас, то той е защитен денонощно от подобни атаки. 

Как защитаваме клиентските сайтове?

Системата за защита от DDoS, която е част от глобалната ни система за сигурност SH Protect, предпазва хостинг услугите на цялата ни инфраструктура (уеб хостинг, WordPress хостинг, Managed VPS, VPS). Тя запазва нормалната работа на сайтовете, като неутрализира 95% от познатите типове DDoS атаки.

Хостинг сървърите на СуперХостинг.БГ са разположени в центъра за данни на Equinix. А за да се гарантира добрата свързаност, използваме два доставчика на интернет – Evolink и Neterra. За защита от DDoS атаки използваме услугите на компанията Voxility. Тази защита следи трафика на мрежово ниво и при необходимост се активира, като филтрира злонамерената част от трафика. 

При засичане на атака към даден сайт при нас, нашият експертен екип извършва проверка. В случай че атаката е комплексна, може да активираме и допълнителна защита от Cloudflare. Ако атаката е от IP адреси извън България, трафикът може да се ограничи за останалите държави, докато се преустанови атаката.

Заплахи за сигурността на сайта, свързани с кода му

Следващите 5 заплахи за сигурността на сайтовете са свързани предимно с уеб приложението и неговия код, тъй като включват уязвимости в начина, по който то е проектирано, реализирано и функционира. Например начина, по който обработва потребителските входни данни, управлява сесиите, конструира заявките и налага контрол на достъпа.

Тези заплахи често са резултат от неподходящи практики за сигурност при разработването на уеб приложенията.

6. Обхождане на директории/пътища

Directory Traversal (или Path Traversal) се отнася до различни пропуски в сигурността на сайта, при които нападателят може да манипулира пътищата към файлове или директории, за да получи достъп до ресурси извън предвидения обхват на приложението. 

Най-често засичаният тип уязвимост от тази категория заплахи е Local File Inclusion (LFI). Тя позволява на потребителя да достъпва локални файлове на сървъра, чрез манипулация на параметрите в URL адресите. Това е възможно, когато приложението използва необезопасени входни данни, с които изгражда файловите пътища. Така нападателят може да се движи през файловата система и потенциално да получи достъп до чувствителни файлове или да изпълни произволен код на сървъра.

Пример

Ето един пример за LFI. Да предположим, че имате уебсайт със страница, която приема параметър, например page, за да зареди различно съдържание. URL адресът може да изглежда по следния начин:

https://example.com/index.php?page=about

В този случай, когато параметърът page е зададен на about, приложението зарежда и показва съдържанието на файла about.php. Ако приложението не валидира и не обработи правилно входните данни, атакуващият може да манипулира параметъра, за да получи достъп до файлове, до които не би трябвало да има достъп като например чувствителни конфигурационни файлове. Потенциалният нападател може да създаде URL адрес по следния начин:

https://example.com/index.php?page=../../../../dir/config.php

Ако приложението не ограничава правилно обхождането на файловите пътища, този URL адрес може да позволи на нападателя да получи достъп до файла /dir/config.php на сървъра, който може да съдържа чувствителна информация, като например данни за потребителски акаунти.

Как да се предпазите?

Уеб разработчиците може да предприемат следните действия, за да предотвратят Directory Traversal атаки:

• Имплементиране на стриктна валидация и „почистване“ на входните данни, за да се предотврати възможността за преглеждане на директории;
• Предотвратяване на възможността да се конструират директно пътищата на файловете от въведени от потребителя данни;
• Използване на бял списък за позволените файлове и директории и валидиране на входните данни с него;
• Прилагане на добри практики при разработката на кода и извършването на тестове за сигурността, с които да се засичат уязвимости.

7. Cross-Site Scripting (XSS)

Това е вид уязвимост в сигурността на сайта, която позволява на злонамерения хакер да инжектира зловредни скриптове в уеб страниците, докато те се преглеждат от посетителите. Тези зловредни скриптове могат да бъдат изпълнени в контекста на браузъра на жертвата, което потенциално води до различни рискове за сигурността, включително кражба на данни, отвличане на сесия или обезобразяване на уебсайта. 

XSS атаките са възможни, когато уеб приложението не валидира или „почиства“ правилно въведените от потребителя данни, преди да ги изобрази в уеб страницата.

Пример 

Хакерът публикува зловреден скрипт в коментар във форума/блога. Когато други потребители видят коментара, скриптът се изпълнява в техния браузър, като потенциално може да открадне сесийните им бисквитки или да извърши други злонамерени действия.

Как да се предпазите?

Предотвратяването на XSS атаки включва правилно валидиране на входните данни и кодиране на изходните. Уеб разработчиците трябва да гарантират, че въведените данни от потребителя са изчистени от специални елементи (символи, думи, команди) и че данните са правилно кодирани, преди да бъдат изобразени в уеб страниците. Освен това механизми за сигурност на уеб приложенията, като Content Security Policy (CSP), могат да се използват за смекчаване на въздействието на XSS атаките чрез ограничаване на изпълнението на скриптове.

8. Cross-Site Request Forgery (CSRF)

Тази уязвимост позволява на киберпрестъпника да подмами потребителя да извърши неволни или неоторизирани действия на различен уебсайт или уеб приложение, където потребителят се е логнал. Атаката използва доверието, което уебсайтът има в браузъра на потребителя и може да доведе до действия като промяна на паролата за акаунта, осъществяване на финансови транзакции или промяна на данни в уебсайта без съгласието на потребителя.

Пример 

Да предположим, че сте влезли в профила си в някоя социална мрежа. Вие имате възможност да променяте настройките на профила си, включително профилната си снимка. Злонамереният хакер създава зловредна уебстраница, която в кода си има таг за изображение, насочващ към URL адрес като този:

<img src="https://mysocialnetwork.com/account-settings?action=change-profile-picture&url=malicious-image-url">

Нападателят Ви подмамва да посетите неговата уебстраница или да кликнете на линк, водещ към нея. Браузърът Ви зарежда изображението от URL адреса, посочен в тага за изображението. Без да знаете, URL адресът също съдържа заявка за промяна на профилната Ви снимка с изображение, разположено на сървъра на нападателя. Тъй като вече сте удостоверени в платформата на социалната мрежа, заявката се изпълнява и профилната Ви снимка се променя с изображението на нападателя.

Тази CSRF атака разчита на факта, че сте влезли с данните си (вече сте логнати) в дадената платформа и че нападателят може да заблуди браузъра Ви да прави заявки от Ваше име без Ваше знание. 

Как да се предпазите?

За да предотвратят CSRF атаките, уеб разработчиците могат да приложат няколко мерки за сигурност:

1. Използвайте Anti-CSRF токени. Уеб приложенията могат да генерират уникални токени за всяка потребителска сесия и тези токени трябва да се включват във всички заявки за промяна на състоянието. Наличието на тези токени гарантира, че заявката е легитимна;
2. Обърнете внимание на произхода на заявките. Уеб приложенията трябва да проверяват източника на входящите заявки, за да се уверят, че те произхождат от същия домейн. Техники като SameSite бисквитки и хедъра „Origin“ могат да се използват за проверка на произхода на заявката;
3. Имплементирайте функцията за споделяне на ресурси с различен произход (Cross-Origin Resource Sharing, CORS). За API-та и cross-origin заявки могат да се конфигурират CORS хедъри, за да се ограничи кои домейни могат да правят заявки;
4. Проверявайте действията на потребителя. Винаги изисквайте допълнително удостоверяване, например повторно въвеждане на парола, преди да извършите чувствителни действия, дори ако потребителят вече е удостоверен.

9. SQL Injection

SQL инжектирането е вид уязвимост в сигурността на сайта, при която злонамереният хакер може да вмъкне зловреден SQL код в полетата за попълване в сайта. Тази уязвимост обикновено възниква, когато уеб приложението не валидира правилно или не обработва правилно потребителските входни данни, преди да ги включи в SQL заявките. SQL инжектирането може да позволи на нападателя да получи неоторизиран достъп до базата данни на сайта и да извлече, промени или изтрие данни.

Пример

Да вземем за пример една обикновена страница за логин в уебсайт, в която потребителите въвеждат своето потребителско име и парола. Приложението използва следната SQL заявка, за да провери дали идентификационните данни на потребителя са валидни:

SELECT * FROM users WHERE username = 'input_username' AND password = 'input_password';

В тази заявка input_username и input_password трябва да бъдат заменени със стойностите, предоставени от потребителя. Ако обаче уеб приложението не валидира правилно потребителските входни данни, атакуващият може да въведе нещо подобно за потребителско име:

' OR '1' = '1

Модифицираната SQL заявка ще изглежда по този начин:

SELECT * FROM users WHERE username = '' OR '1' = '1' AND password = 'input_password';

В този случай, тъй като 1 винаги е равно на 1, заявката връща всички записи от таблицата 'users', което на практика позволява на нападателя да влезе в системата без валидна парола. Това е само един пример от многото видове атаки тип SQL Injection, които могат да бъдат извършени.

Как да се предпазите?

За да се предотврати SQL Injection атака, разработчиците на уебсайтове трябва да използват prepared statements или параметризирани заявки при взаимодействие с базата данни. Тези техники отделят потребителските входни данни от SQL заявката, което прави невъзможно за нападателите да инжектират злонамерен SQL код. Правилното валидиране на входните данни, обработката им и достъпът с най-малки привилегии до базите данни също са важни мерки за сигурност за защита от SQL Injection.

10. Неадекватна оторизация (authorization)

Заплахата от липсваща или неадекватна оторизация е вид недостатък в сигурността на сайта, който се появява, когато уеб приложението не успява да провери и наложи правилно контрол на достъпа до обекти, като например файлове или записи в бази данни. 

Тази уязвимост позволява на атакуващия да получи достъп, да промени или да изтрие чувствителни данни или да извърши действия, за които не би трябвало да има разрешение/права.

Пример

Представете си плъгин за електронна търговия за WordPress, който се използва за обработка на онлайн поръчки. Този плъгин включва функция, която позволява на администраторите на сайта да управляват поръчки, да ги отбелязват като изпратени или завършени, както и да преглеждат данните на клиентите.

Плъгинът обаче има уязвимост „липсваща оторизация“ (missing authorisation). Той не прилага правилно контрол на достъпа и не проверява дали потребителят, който извършва тези действия, има необходимите разрешения.

Потребителите с малко права и ограничен достъп (например клиентът на магазина) трябва да може да преглежда подробностите само за собствените си поръчки, но не и тези на други клиенти. Въпреки това, поради уязвимостта, този потребител може да манипулира URL адреса или да направи директна заявка за достъп и да прегледа данните за поръчката на всеки друг клиент в сайта.

Например уязвимият URL адрес за разглеждане на подробностите на поръчката може да изглежда по следния начин:

https://example.com/wp-admin/admin.php?page=ecommerce-plugin&order_id=123

При сигурна конфигурация плъгинът трябва да провери дали влезлият в момента потребител има съответните разрешения за преглед на поръчка с номер 123. В този случай обаче плъгинът не извършва тази проверка. Така че нападателят, който е потребител с малко права, може да промени параметъра order_id в URL адреса, за да прегледа данните за поръчките на други клиенти, което потенциално може да включва чувствителна информация като имена, адреси и история на поръчките.

Как да се предпазите?

За да се смекчи обхвата или предотврати уязвимостта от липсваща оторизация, както разработчиците на плъгини, така и администраторите на уебсайтове, трябва да следват най-добрите практики.

Разработчиците на плъгини:

• Прилагайте подходящ контрол на достъпа и проверки за оторизация;
• Разрешавайте само на привилегировани потребители да извършват действия, които изискват повишени разрешения;
• Извършвайте прегледи и тестове на сигурността, за да идентифицирате и отстраните уязвимостите.

Администратори на уебсайтове:

• Редовно актуализирайте плъгините, за да сте сигурни, че разполагате с най-новите и най-сигурни версии;
• Следете препоръките и съобщенията за сигурност, свързани с използваните от Вас приставки;
• Обмислете използването на плъгини за сигурност или услуги, които осигуряват допълнителни нива на сигурност и мониторинг.

Как защитаваме клиентските сайтове от тези 5 заплахи?

Защитата на сайтовете от тези 5 заплахи включва преодоляване на уязвимостите чрез практики за създаване на сигурен код, правилно валидиране на входните данни, управление на сесиите и прилагане на контрол на достъпа. Изключително важно е разработчиците да са наясно с тези заплахи и да следват най-добрите практики, за да сведат до минимум риска от инциденти със сигурността.

Сигурността на сайтовете обаче е споделена отговорност между доставчика на хостинг услуга и уеб разработчика. Докато хостингът играе ключова роля в осигуряването на базовата инфраструктура и предоставянето на определени мерки за сигурност, разработчиците на уеб приложения са основно отговорни за гарантиране на сигурността на кода на уеб приложението и неговата функционалност.

Ето как системата SH Protect на СуперХостинг.БГ защитава сайтовете от тези заплахи:

• Защита от известни уязвимости в сигурността на приложенията. Тези 5 заплахи за сигурността на сайта, свързани с кода му, често се крият в уязвимостите на необновените теми/плъгини.
• Защитна стена за уеб приложения (WAF). WAF помага за защита на уеб приложенията от често срещани заплахи за сигурността, като XSS, CSRF и SQL Injection, чрез филтриране и наблюдение на HTTP трафика между уеб приложението и интернет. Защитната стена за уеб приложенията е част от хостинг услугата. 
• Мрежова сигурност. Осигуряване на правилно сегментиране и изолиране на мрежата, за да се предотврати неоторизиран достъп до чувствителни данни.
• Сигурност на инфраструктурата, включително сървъри, мрежи и центрове за данни. Прилагане на мерки за сигурност на ниво мрежа и сървър – защитна стена, система за откриване на проникване и редовни актуализации на софтуера.
• Редовни одити на сигурността. Извършване на одити на сигурността и оценки на уязвимостта на хостинг инфраструктурата с цел идентифициране и отстраняване на потенциални слабости. 

---

В защитата на сайтовете се включва и трета страна – администраторът на сайта. След като разработчиците са приложили корекции в кода и са „закърпили“ пролуката в сигурността му, администраторът трябва да се погрижи и да приложи обновление на приложението. Чрез новата му версия се нанасят и подобренията в кода.

Вижте още: Как да повишим сигурността на сайта в 10 стъпки! | Blog