Какво е сигурност на сайт?
Сигурността на уебсайта изисква бдителност във всички аспекти на дизайна и използването на уебсайта. Тази уводна статия няма да ви направи гуру по сигурността на уебсайтове, но ще ви помогне да разберете откъде идват заплахите и какво можете да направите, за да защитите уеб приложението си срещу най-честите атаки.
Интернет е опасно място! С голяма редовност чуваме за уебсайтове, които стават недостъпни поради атаки за отказ на услуга или показват модифицирана (и често вредна) информация на началните си страници. В други нашумели случаи милиони пароли, имейл адреси и данни за кредитни карти са изтекли в публичното пространство, излагайки потребителите на уебсайта както на личен срам, така и на финансов риск.
Целта на сигурността на уебсайта е да предотврати тези (или всякакви) видове атаки. По-официалната дефиниция на сигурността на уебсайта е действие/практика за защита на уебсайтове от неоторизиран достъп, използване, модификация, унищожаване или прекъсване .
Ефективната сигурност на уебсайта изисква усилия за проектиране в целия уебсайт: във вашето уеб приложение, конфигурацията на уеб сървъра, вашите политики за създаване и подновяване на пароли и кода от страна на клиента. Въпреки че всичко това звучи много зловещо, добрата новина е, че ако използвате уеб рамка от страна на сървъра, тя почти сигурно ще активира „по подразбиране“ стабилни и добре обмислени защитни механизми срещу редица по-често срещани атаки . Други атаки могат да бъдат смекчени чрез конфигурацията на вашия уеб сървър, например чрез активиране на HTTPS. И накрая, има публично достъпни инструменти за сканиране на уязвимости, които могат да ви помогнат да разберете дали сте направили очевидни грешки или имате уязвимости.
Останалата част от тази статия ви дава повече подробности за няколко често срещани заплахи и някои от простите стъпки, които можете да предприемете, за да защитите сайта си.
11 ПОЛЕЗНИ СЪВЕТА СРЕЩУ КРИПТОВИРУСИ
Заплахи за сигурността на уебсайта
Този раздел изброява само няколко от най-често срещаните заплахи за уебсайтове и как те се смекчават.
Междусайтови скриптове (XSS)
XSS е термин, използван за описване на клас атаки, които позволяват на атакуващ да инжектира скриптове от страна на клиента през уебсайта в браузърите на други потребители. Тъй като инжектираният код идва в браузъра от сайта, кодът се доверява и може да прави неща като изпращане на бисквитка за оторизация на сайта на потребителя до нападателя. Когато атакуващият разполага с бисквитката, той може да влезе в сайт, сякаш е потребител, и да направи всичко, което потребителят може, като например достъп до данните на кредитната си карта, преглед на данните за контакт или промяна на пароли.
XSS уязвимостите се разделят на отразени и постоянни въз основа на начина, по който сайтът връща инжектираните скриптове на браузър.
- Отразена XSS уязвимост възниква, когато потребителското съдържание, което се предава на сървъра, се връща незабавно и непроменено за показване в браузъра. Всички скриптове в оригиналното потребителско съдържание ще бъдат изпълнени, когато се зареди новата страница. Например, помислете за функция за търсене в сайта, където думите за търсене са кодирани като URL параметри и тези думи се показват заедно с резултатите. Нападателят може да създаде връзка за търсене, която съдържа злонамерен скрипт като параметър (напр.http://developer.mozilla.org?q=beer<script%20src=“https://example.com/tricky.js“></script>) и го изпрати по имейл до друг потребител. Ако целевият потребител щракне върху тази „интересна връзка“, скриптът ще се изпълни, когато се покажат резултатите от търсенето. Както беше обсъдено по-рано, това дава на атакуващия цялата информация, от която се нуждае, за да влезе в сайта като целеви потребител, потенциално да прави покупки като потребител или да споделя своята информация за контакт.
- Постоянна XSS уязвимост възниква, когато злонамереният скрипт се съхранява на уебсайта и след това се показва отново непроменен, за да могат други потребители да го изпълнят неволно. Например, дискусионна дъска, която приема коментари, които съдържат немодифициран HTML, може да съхранява злонамерен скрипт от нападател. Когато коментарите се показват, скриптът се изпълнява и може да изпрати на атакуващия информацията, необходима за достъп до акаунта на потребителя. Този вид атака е изключително популярна и мощна, тъй като нападателят може дори да няма пряк контакт с жертвите.
Въпреки че данните от POST или GET заявките са най-често срещаният източник на XSS уязвимости, всички данни от браузъра са потенциално уязвими, като например данни за бисквитки, изобразени от браузъра, или потребителски файлове, които се качват и показват.
Най-добрата защита срещу XSS уязвимости е да премахнете или деактивирате всяко маркиране, което потенциално може да съдържа инструкции за изпълнение на кода. За HTML това включва елементи като <script>, <object>, <embed>и <link>.
Процесът на модифициране на потребителските данни, така че да не могат да се използват за изпълнение на скриптове или по друг начин да повлияят на изпълнението на сървърния код, е известен като саниране на входа. Много уеб рамки автоматично дезинфекцират въвеждането на потребителя от HTML формуляри по подразбиране.
SQL инжекция
Уязвимостите при SQL инжектиране позволяват на злонамерени потребители да изпълняват произволен SQL код в база данни, позволявайки достъп до данни, модифициране или изтриване, независимо от разрешенията на потребителя. Една успешна инжектираща атака може да подмени самоличности, да създаде нови самоличности с административни права, да получи достъп до всички данни на сървъра или да унищожи/модифицира данните, за да ги направи неизползваеми.
Типовете SQL инжектиране включват базирано на грешки SQL инжектиране, SQL инжектиране въз основа на булеви грешки и базирано на време SQL инжектиране.
Тази уязвимост е налице, ако потребителското въвеждане, което се предава на основен SQL оператор, може да промени значението на израза. Например, следният код има за цел да изброи всички потребители с определено име ( userName), което е предоставено от HTML формуляр:
statement = „SELECT * FROM users WHERE name = ‘“ + userName + „‘;“
Ако потребителят посочи истинско име, изразът ще работи по предназначение. Въпреки това, злонамерен потребител може напълно да промени поведението на този SQL израз към новия оператор в следния пример, като посочи текста с получер шрифт за userName.
SELECT * FROM users WHERE name = ‘a’;DROP TABLE users; SELECT * FROM userinfo WHERE ‘t’ = ‘t’;
Модифицираният оператор създава валиден SQL оператор, който изтрива users таблицата и избира всички данни от userinfo таблицата (което разкрива информацията за всеки потребител). Това работи, защото първата част от инжектирания текст ( a’;) допълва оригиналния израз.
За да избегнете този вид атака, трябва да сте сигурни, че всички потребителски данни, които се предават на SQL заявка, не могат да променят естеството на заявката. Един от начините да направите това е да избегнете всички знаци във въведеното от потребителя, които имат специално значение в SQL.
Забележка: SQL изразът третира символа ‘ като начало и край на низов литерал. Като поставим обратна наклонена черта пред този знак ( \’ ), ние избягваме символа и казваме на SQL вместо това да го третира като символ (само част от низа).
В следния оператор избягваме знака ‘ . Сега SQL ще интерпретира името като целия низ в удебелен шрифт (което наистина е много странно име, но не е вредно).
SELECT * FROM users WHERE name = ‘a\’;DROP TABLE users; SELECT * FROM userinfo WHERE \’t\’ = \’t’;
Уеб рамките често ще се погрижат за избягването на героя вместо вас. Django, например, гарантира, че всички потребителски данни, предадени на набори от заявки (моделни заявки), са екранирани.
Фалшифициране на заявки между сайтове (CSRF)
CSRF атаките позволяват на злонамерен потребител да изпълнява действия, използвайки идентификационните данни на друг потребител без знанието или съгласието на този потребител.
Този тип атака се обяснява най-добре с пример. Иван е злонамерен потребител, който знае, че конкретен сайт позволява на влезли потребители да изпращат пари към определен акаунт, използвайки HTTP POST заявка, която включва името на акаунта и парична сума. Иван създава формуляр, който включва неговите банкови данни и парична сума като скрити полета, и го изпраща по имейл на други потребители на сайта (с бутона Изпращане, маскиран като връзка към сайт за бързо забогатяване, примерно).
Ако потребител щракне върху бутона за POST изпращане, до сървъра ще бъде изпратена HTTP заявка, съдържаща подробностите за транзакцията и всички бисквитки от страна на клиента, които браузърът е асоцирал със сайта (добавянето на асоцирани бисквитки на сайта към заявките е нормално поведение на браузъра). Сървърът ще провери бисквитките и ще ги използва, за да определи дали потребителят е влязъл или не и има разрешение да извърши транзакцията.
Резултатът е, че всеки потребител, който щракне върху бутона Изпрати , докато е влязъл в сайта за търговия, ще направи транзакцията. Иван забогатява.
Забележка: Номерът тук е, че Иван не трябва да има достъп до бисквитките на потребителя (или идентификационни данни за достъп). Браузърът на потребителя съхранява тази информация и автоматично я включва във всички заявки към свързания сървър.
13 ОБЕЗПОКОИТЕЛНИ ФАКТИ И СТАТИСТИКИ В КИБЕРСИГУРНОСТА
Един от начините за предотвратяване на този тип атака е сървърът да изисква POST заявките да включват специфична за потребителя тайна, генерирана от сайта. Тайната ще бъде предоставена от сървъра при изпращане на уеб формуляра, използван за извършване на трансфери. Този подход не позволява на Иван да създаде свой собствен формуляр, защото той би трябвало да знае тайната, която сървърът предоставя на потребителя. Дори ако открие тайната и създаде формуляр за определен потребител, той вече няма да може да използва същия формуляр, за да атакува всеки потребител.
Уеб рамките често включват такива механизми за предотвратяване на CSRF.
Други заплахи
Други често срещани атаки/уязвимости включват:
- Clickjacking. При тази атака злонамерен потребител отвлича кликванията, предназначени за видим сайт от първо ниво, и ги насочва към скрита страница отдолу. Тази техника може да се използва, например, за показване на легитимен банков сайт, но за улавяне на идентификационните данни за вход в невидим <iframe>, контролиран от нападателя. Clickjacking може също да се използва, за да накара потребителя да щракне върху бутон на видим сайт, но при това всъщност неволно да щракне върху напълно различен бутон. Като защита вашият сайт може да предотврати вграждането си във вградена рамка на друг сайт, като зададе подходящите HTTP заглавки.
- Отказ от услуга (DoS). DoS обикновено се постига чрез наводняване на целеви сайт с фалшиви заявки, така че достъпът до сайт да бъде прекъснат за законни потребители. Заявките може да са многобройни или могат поотделно да консумират големи количества ресурс (напр. бавно четене или качване на големи файлове). Защитите срещу DoS обикновено работят, като идентифицират и блокират „лош“ трафик, като същевременно позволяват легитимни съобщения. Тези защити обикновено се намират преди или в уеб сървъра (те не са част от самото уеб приложение).
- Обхождане на директория (файл и разкриване). При тази атака злонамерен потребител се опитва да получи достъп до части от файловата система на уеб сървъра, до които не би трябвало да има достъп. Тази уязвимост възниква, когато потребителят може да предаде имена на файлове, които включват знаци за навигация на файловата система (например ../../). Решението е да дезинфекцирате входа, преди да го използвате.
- Включване на файл. При тази атака потребителят може да посочи „нежелан“ файл за показване или изпълнение в данните, предадени на сървъра. Когато се зареди, този файл може да бъде изпълнен на уеб сървъра или от страната на клиента (което води до XSS атака). Решението е да дезинфекцирате входа, преди да го използвате.
- Инжектиране на команди. Атаките с инжектиране на команди позволяват на злонамерен потребител да изпълнява произволни системни команди на хост операционната система. Решението е да се дезинфекцира въведеното от потребителя, преди да може да се използва в системни повиквания.
Няколко ключови послания
Почти всички експлойти за сигурност в предишните раздели са успешни, когато уеб приложението се доверява на данни от браузъра. Каквото и друго да правите, за да подобрите сигурността на уебсайта си, трябва да дезинфекцирате всички данни, произхождащи от потребителя, преди да бъдат показани в браузъра, използвани в SQL заявки или предадени на извикване на операционна система или файлова система.
Предупреждение: Единственият най-важен урок, който можете да научите за сигурността на уебсайта, е никога да не се доверявате на данни от браузъра. Това включва, но не се ограничава до данни в URL параметри на GET заявки, POST заявки, HTTP заглавки и бисквитки и качени от потребители файлове. Винаги проверявайте и дезинфекцирайте всички входящи данни. Винаги се съмнявайте в най-лошото.
Редица други конкретни стъпки, които можете да предприемете, са:
Използвайте по-ефективно управлението на пароли. Насърчавайте използването на силни пароли. Помислете за двуфакторно удостоверяване за вашия сайт, така че в допълнение към парола потребителят трябва да въведе друг код за удостоверяване (обикновено такъв, който се доставя чрез някакъв физически хардуер, който само потребителят ще има, като например код в SMS, изпратен до телефон).
Защо паролите са лесна плячка за кибер престъпниците и защо трябва да ги сменяте често
Конфигурирайте вашия уеб сървър да използва HTTPS и HTTP Strict Transport Security (HSTS). HTTPS криптира данните, изпратени между вашия клиент и сървър. Това гарантира, че идентификационните данни за вход, бисквитките, POST данните за заявките и информацията в заглавката не са лесно достъпни за нападателите.
Следете най-популярните заплахи (текущият списък на OWASP е тук) и първо адресирайте най-често срещаните уязвимости.
Използвайте инструменти за сканиране на уязвимости, за да извършите автоматизирани тестове за сигурност на вашия сайт.
Съхранявайте и показвайте само необходимите ви данни. Например, ако вашите потребители трябва да съхраняват чувствителна информация като данни за кредитна карта, покажете достатъчно от номера на картата, за да може да бъде идентифициран от потребителя, и не достатъчно, за да може да бъде копиран от нападател и използван на друг сайт. Най-често срещаният модел в момента е да се показват само последните 4 цифри от номера на кредитна карта.
Уеб рамките могат да помогнат за смекчаване на много от по-често срещаните уязвимости.
Тази статия обяснява концепцията за уеб сигурност и някои от по-често срещаните заплахи, срещу които вашият уебсайт трябва да се опита да защити. Най-важното е, че трябва да разберете, че уеб приложението не може да има доверие на никакви данни от уеб браузъра. Всички потребителски данни трябва да бъдат дезинфекцирани, преди да бъдат показани или използвани в SQL заявки и извиквания на файловата система.
От екип на „ЛИП Трейд“ ООД