9 съвета за сигурност, за да защитите уебсайта си от хакери

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

Хакерството се извършва редовно чрез автоматизирани скриптове, написани за търсене в интернет в опит да се използват известни проблеми със сигурността на уебсайта в софтуера. Ето нашите девет най-добри съвета, които ще ви помогнат да запазите сигурността си онлайн и вашия сайт.

01. Поддържайте софтуера актуален

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



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

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

Много разработчици използват инструменти като Composer, npm или RubyGems, за да управляват своите софтуерни зависимости, а уязвимостите в сигурността, които се появяват в пакет, от който разчитате, но не обръщате внимание, е един от най-лесните начини да ви хванат навън. Уверете се, че актуализирате зависимостите си и използвайте инструменти като Гимназия за да получавате автоматични известия, когато е обявена уязвимост в един от вашите компоненти.

02. Внимавайте за SQL инжектиране

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

Помислете за тази заявка:

'SELECT * FROM table WHERE column = '' + parameter + '';'

Ако нападателят промени параметъра на URL, за да премине в 'или' 1 '=' 1, това ще доведе до това, че заявката ще изглежда така:

'SELECT * FROM table WHERE column = '' OR '1'='1';'

Тъй като „1“ е равно на „1“, това ще позволи на нападателя да добави допълнителна заявка в края на SQL израза, която също ще бъде изпълнена.

Можете да поправите тази заявка, като я параметризирате изрично. Например, ако използвате MySQLi в PHP, това трябва да стане:

$stmt = $pdo->prepare('SELECT * FROM table WHERE column = :value'); $stmt->execute(array('value' => $parameter));

03. Защита срещу XSS атаки

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

Това е особено притеснително в съвременните уеб приложения, където страниците сега се изграждат предимно от потребителско съдържание и които в много случаи генерират HTML, който след това се интерпретира и от предни рамки като Angular и Ember. Тези рамки осигуряват много XSS защити, но смесването на сървърно и клиентско изобразяване създава и нови и по-сложни пътища за атака: не само е ефективно инжектирането на JavaScript в HTML, но можете също да инжектирате съдържание, което ще изпълнява код, като вмъкнете Angular директиви или използвате Ember помощници.

Ключът тук е да се съсредоточите върху това как вашето генерирано от потребителите съдържание може да излезе от границите, които очаквате, и да бъде интерпретирано от браузъра като нещо различно от това, което сте планирали. Това е подобно на защитата срещу SQL инжекция. Когато динамично генерирате HTML, използвайте функции, които изрично правят промените, които търсите (например използвайте element.setAttribute и element.textContent, които ще бъдат автоматично избягани от браузъра, вместо да задавате element.innerHTML на ръка), или използвайте функции в инструмента за шаблониране, който автоматично прави подходящо избягване, вместо да обединява низове или да задава сурово HTML съдържание.

Друг мощен инструмент в инструментариума на XSS защитника е Политика за защита на съдържанието (CSP). CSP е заглавие, което сървърът ви може да върне, което казва на браузъра да ограничи как и какво се изпълнява JavaScript на страницата, например да забрани изпълнението на скриптове, които не са хоствани във вашия домейн, да забрани вградения JavaScript или да деактивира eval (). Mozilla има отличен водач с някои примерни конфигурации. Това затруднява работата на скриптове на нападателя, дори ако те могат да ги вкарат в страницата ви.

04. Пазете се от съобщения за грешки

Бъдете внимателни с това колко информация давате в съобщенията си за грешка. Предоставяйте само минимални грешки на вашите потребители, за да сте сигурни, че те не изпускат тайни, присъстващи на вашия сървър (напр. API ключове или пароли за база данни). Не предоставяйте и пълни подробности за изключения, тъй като те могат да направят сложните атаки като SQL инжектиране далеч по-лесни. Запазете подробни грешки в регистрационните файлове на сървъра си и показвайте на потребителите само информацията, от която се нуждаят.

05. Валидирайте от двете страни

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

06. Проверете паролите си

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

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

Паролите винаги трябва да се съхраняват като криптирани стойности, за предпочитане като се използва еднопосочен алгоритъм за хеширане като SHA. Използването на този метод означава, че когато удостоверявате потребителите, сравнявате само криптирани стойности. За допълнителна сигурност на уебсайта е добра идея да посолите паролите, като използвате нова сол на парола.

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

За щастие, много CMS осигуряват управление на потребителите от кутията с много от тези вградени функции за защита на уебсайта, въпреки че може да са необходими някои конфигурации или допълнителни модули, за да се използват солени пароли (преди Drupal 7) или да се зададе минималната сила на паролата. Ако използвате .NET, тогава си струва да използвате доставчици на членство, тъй като те са много конфигурируеми, осигуряват вградена защита на уебсайта и включват готови контроли за влизане и нулиране на паролата.

07. Избягвайте качването на файлове

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

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

И така, какво можете да направите, за да предотвратите това? В крайна сметка искате да спрете потребителите да могат да изпълняват всеки файл, който качват. По подразбиране уеб сървърите няма да се опитват да изпълняват файлове с разширения на изображения, но не разчитайте само на проверка на разширението на файла, тъй като е известно, че файл с името image.jpg.php преминава.

Някои опции са да преименувате файла при качване, за да осигурите правилното разширение на файла, или да промените разрешенията на файла, например chmod 0666, така че да не може да бъде изпълнен. Ако използвате * nix, можете да създадете .htaccess файл (вижте по-долу), който ще позволи само достъп до зададени файлове, предотвратяващи споменатите по-рано атаки с двойно разширение.

deny from all order deny,allow allow from all

В крайна сметка препоръчителното решение е да се предотврати изцяло директния достъп до качените файлове. По този начин всички файлове, качени на вашия уеб сайт, се съхраняват в папка извън webroot или в базата данни като blob. Ако вашите файлове не са директно достъпни, ще трябва да създадете скрипт за извличане на файловете от частната папка (или HTTP манипулатор в .NET) и да ги доставите на браузъра. Таговете за изображения поддържат атрибут src, който не е директен URL адрес на изображение, така че атрибутът ви src може да сочи към вашия скрипт за доставка на файлове, като ви предоставя правилния тип съдържание в заглавката на HTTP. Например:

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

Уверете се, че имате настройка на защитна стена и блокирате всички несъществени портове. По възможност създаване на DMZ (демилитаризирана зона), позволяваща достъп до портове 80 и 443 от външния свят. Въпреки че това може да не е възможно, ако нямате достъп до сървъра си от вътрешна мрежа, тъй като ще трябва да отворите портове, за да позволите качване на файлове и да влезете дистанционно на сървъра си чрез SSH или RDP.

Ако разрешавате качването на файлове от Интернет, използвайте само защитени транспортни методи на вашия сървър като SFTP или SSH.

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

И накрая, не забравяйте за ограничаване на физическия достъп до вашия сървър.

08. Използвайте HTTPS

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

Ако имате нещо, което вашите потребители биха искали да са частни, е силно препоръчително да използвате само HTTPS, за да го доставите. Това разбира се означава кредитни карти и страници за вход (и URL адресите, на които се подават), но обикновено и много повече от вашия сайт. Формата за вход често задава например бисквитка, която се изпраща с всяка друга заявка до вашия сайт, която прави влязъл потребител, и се използва за удостоверяване на тези заявки. Нападателят, който открадне това, би могъл перфектно да имитира потребител и да поеме сесията му за вход. За да победите този вид атаки, почти винаги искате да използвате HTTPS за целия си сайт.

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

По-специално Google обявиха, че ще ви повишат в класацията за търсене, ако използвате HTTPS, което също дава SEO предимство. Несигурният HTTP е на път да излезе и сега е моментът да надстроите.

Вече използвате HTTPS навсякъде? Отидете по-нататък и вижте настройката на HTTP Strict Transport Security (HSTS), лесен заглавие, което можете да добавите към отговорите на вашия сървър, за да забраните несигурния HTTP за целия ви домейн.

09. Вземете инструменти за сигурност на уебсайта

След като си мислите, че сте направили всичко, което можете, тогава е време да тествате сигурността на уебсайта си. Най-ефективният начин да направите това е чрез използването на някои инструменти за сигурност на уебсайтове, често наричани тестване за проникване или кратко писане.

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

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

  • Netsparker (Предлага се безплатно издание на общността и пробна версия). Добър за тестване на SQL инжектиране и XSS
  • OpenVAS Твърди, че е най-модерният скенер за сигурност с отворен код. Добре за тестване на известни уязвимости, в момента сканира над 25 000. Но настройването може да бъде трудно и изисква инсталиране на сървър OpenVAS, който работи само на * nix. OpenVAS е вилица на Nessus, преди да се превърне в търговски продукт с затворен код.
  • SecurityHeaders.io (безплатна онлайн проверка). Инструмент за бързо отчитане на кои заглавки на защитата, споменати по-горе (като CSP и HSTS), е активиран и конфигуриран правилно домейн.
  • Xenotix XSS Exploit Framework Инструмент от OWASP (Open Web Application Security Project), който включва огромен избор от примери за XSS атаки, които можете да стартирате, за да потвърдите бързо дали данните на вашия сайт са уязвими в Chrome, Firefox и IE.

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

Има някои допълнителни стъпки, които можете да предприемете, за да опитате ръчно да компрометирате сайта си, като промените стойностите на POST / GET. Прокси за отстраняване на грешки може да ви помогне тук, тъй като ви позволява да прихващате стойностите на HTTP заявка между вашия браузър и сървъра. Популярно безплатно приложение, наречено Скрипач е добра отправна точка.

И така, какво трябва да се опитвате да промените в заявката? Ако имате страници, които трябва да се виждат само от влязъл потребител, опитайте да промените параметрите на URL като потребителски идентификатор или стойности на бисквитки в опит да видите подробности за друг потребител. Друга област, която си струва да бъдат тествани, са формуляри, промяна на стойностите на POST за опит за подаване на код за извършване на XSS или качване на скрипт от страна на сървъра.

Свързани статии: