Смъртоносни грехове в безопасността на сайта: какво узнахме от статистика на скенера за уязвимости за годината

Преди около година в DataLine стартирахме услуга за търсене и анализ на уязвимости в ИТ приложения. В основата на услугата е облачното решение Qualys, за работата на което вече говорихме. През годината на работа с решението направихме 291 сканиране за различни сайтове и натрупахме статистика за разпространените уязвимости в уеб приложенията. 

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

Всички уязвимости в уеб приложенията Qualys разделя на три нива на критичност: ниско, средно и високо. Ако погледнем разпределението по „тежест“, изглежда, че всичко не е толкова лошо. Уязвимостите с високо ниво на критичност са малко, основно всичко е некритично: 

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

Топ „некритични“ уязвимости

1. Уязвимости, свързани с редувано съдържание.

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

   Някои сайтове използват редувано съдържание: предават част от данните през незабореен протокол HTTP. Често така предават пассивно съдържание – информация, която влияе само на визуализацията на сайта: снимки, CSS стилове. Но понякога така предават и активно съдържание: скриптове, които управляват поведението на сайта. В този случай с помощта на специален софтуер може да се анализира информацията, идваща от сървъра с активно съдържание, да се модифицират отговорите в реално време и да се накара машината да работи така, както не е била замислена от създателите си. 

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

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

   Какво трябва да помни уеб разработчикът: Дори ако администраторът на сайта е инсталирал и конфигурирал SSL/TLS сертификат, уязвимост може да се появи заради човешкия фактор. Например, ако на някоя от страниците е поставена не относителна връзка, а абсолютна с http, и освен това не са настроени пренасочвания от http на https. 

   Може да се открие смесено съдържание на сайта с помощта на браузъра: да се потърси по изходния код на страницата, да се прегледат известията в конзолата на разработчика. Въпреки това, разработчикът ще трябва да се потруди дълго и упорито в кода. Процесът може да бъде ускорен с автоматизирани средства за анализ, например: SSL Check, безплатен софтуер Lighthouse или платен софтуер Screaming Frog SEO Spider.

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

2. Бисквитки без флагове «HTTPOnly» и «secure».

   Атрибутът «HTTPOnly» защитава файловете с бисквитки от обработка от скриптове, които злоумышлениците използват за кражба на потребителски данни. Флагът «secure» не позволява предаването на бисквитки в отворен вид. Обменът на данни ще бъде разрешен само ако за изпращане на бисквитките се използва защитен протокол HTTPS. 

   И двата атрибута се записват в свойствата на бисквитките:

   Set-Cookie: Secure; HttpOnly

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

   Какво трябва да помни уеб разработчикът: Обикновено в популярни фреймуъркове тези атрибути се задават автоматично. Но все пак проверете конфигурацията на уеб сървъра и задайте флага: Set-Cookie HttpOnly; Secure.

   При това атрибутът «HTTPOnly» ще направи бисквитките невидими и за вашия собствен JavaScript.  

3. Path-Based Vulnerabilities («пътеви» уязвимости).

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

   Каква е опасността: Ако файловата система е "изложена навън", злонамерен потребител може да навлезе в интерфейса на операционната система и да опита да намери папки с пароли, ако те се съхраняват в открит вид (не трябва да се прави така!). Или може да се откраднат хешовете на паролите и да се подбере паролата чрез подбиране, както и да се опита повишаване на правата в системата и да се движи навътре в инфраструктурата.  

   Какво трябва да помни уеб разработчикът: Не забравяйте за правата за достъп и конфигурирайте платформата, уеб сървъра, уеб приложението, така че да не може да „избяга“ от уеб директорията.

4. Форми за въвеждане на конфиденциални данни с включена функция за автоматично попълване.

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

   Формите на сайтовете могат да включват полета с конфиденциална информация, например пароли или номера на кредитни карти. За такива полета е препоръчително на самия сайт да се деактивира функцията за автоматично попълване на формите. 

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

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

   За повечето браузъри функцията за автоматично попълване може да бъде деактивирана с атрибута autocompete="off", например:

    <body>
       <form action="/bg/form/submit/" method="get" autocomplete="off" data-trp-original-action="/form/submit">
         <div>
           <input type="text" placeholder="Първо име">
         </div>
         <div>
           <input type="text" id="lname" placeholder="Последно име" autocomplete="on">
         </div>
         <div>
           <input type="number" placeholder="Номер на кредитна карта">
         </div>
         <input type="submit">
       <input type="hidden" name="trp-form-language" value="bg"/></form>
     </body>

   Но за Chrome той няма да работи. Това се заобикаля с помощта на JavaScript, вариант на рецепта можете да намерите тук. 

5. В кода на сайта не е зададен заглавие X-Frame-Options. 

   Този заглавие влияе на таговете frame, iframe, embed или object. Чрез него можете напълно да забраните вграждането на вашия сайт в рамка. За това трябва да зададете стойност X-Frame-Options: deny. Или можете да зададете X-Frame-Options: sameorigin, така вграждането в iframe ще бъде достъпно само на вашия домейн.

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

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

   Какво трябва да помни уеб разработчикът: Уязвимост може да се появи, ако X-Frame-Options с конфликтна стойност е зададена на уеб сървъра или балансировчика на натоварване. В този случай сървърът и балансировчикът просто ще презапишат заглавието, тъй като имат по-висок приоритет в сравнение с кода на бекенда.  

   Стойностите deny и sameorigin на заглавието X-Frame-Options ще пречат на работата на уебвизора на Яндекс. За да разрешите използването на iframe за уебвизора, трябва да напишете отделно правило в настройките. Например, за nginx можете да настроите по следния начин:

   http{
   ...
    map $http_referer $frame_options {
    "~webvisor.com" "ALLOW-FROM http://webvisor.com";
    default "SAMEORIGIN";
    }
    add_header X-Frame-Options $frame_options;
   ...
   }
   
   

6. Уязвимости PRSSI (Импорт на стилове относително към пътя).  

   Тази уязвимост се появява в стиловете на сайта. Тя възниква, ако се използват относителни линкове от вида href="/somefolder/styles.css/" за достъп до файлове със стилове. Злонамеренецът ще се възползва от това, ако намери начина да пренасочи потребителя на злонамерена страница. Страницата ще подмени относителния линк в своя url и ще имитира достъп до стиловете. Получава се заявка от типа badsite.ru/…/somefolder/styles.css/, която под прикритието на стил може да извършва злонамерени действия. 

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

   Какво трябва да помни уеб разработчикът: Задайте заглавие X-Content-Type-Options: nosniff. В този случай браузърът ще провери типа на съдържанието за стиловете. Ако типът се различава от text/css, браузърът ще блокира заявката.

Критични уязвимости

1. Страницата с полето за парола се предава от сървъра по незашифрован канал (HTML форма, съдържаща поле за парола, се подава чрез HTTP).

   Отговорът от сървъра по нешифрован канал е уязвим към атаки от типа "Човек в средата". Злоумишленикът може да прихване трафика и да се намеси между клиента и сървъра, когато страницата преминава от сървъра към клиента. 

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

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

2. Изпращане на форма с логин и парола по незашифрован канал (Формата за вход не се подава чрез HTTPS).

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

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

3. Използване на библиотеки на JavaScript с известни уязвимости.

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

   Каква е опасността: За известни уязвимости има експлойти, например такива:

   
   
   Какво трябва да помни уеб разработчикът: Редовно се връщайте към цикъла: търсене на известни уязвимости – отстраняване – проверка. Ако умишлено използвате остарели библиотеки, например за поддръжка на стари браузъри или за икономия на бюджет, търсете начин да отстраните известна уязвимост. 

4. Междусайтови скриптове (XSS). 
   Cross-Site Scripting (XSS), или межсайтови скриптове, е атака на уеб приложение, при която в базата данни се появява злонамерен код. Ако Qualys открие такава уязвимост, потенциалният злонамерен потребител може да вградили или вече е вградил свой js скрипт в кода на сайта за извършване на вредни действия.

   Съхранени XSS (Stored XSS) са по-опасни, тъй като скриптът се вгражда на сървъра и се изпълнява всеки път, когато атакуваната страница бъде отворена в браузъра.

   Отразени XSS (Reflected XSS) са по-лесни за извършване, тъй като злонамереният скрипт може да се вгради в HTTP заявка. Приложението ще получи HTTP заявка, няма да провери данните, ще ги опакова и незабавно ще ги изпрати. Ако атакуващият прихване трафика и вмъкне скрипт от вида

   <script>/*+что+то+плохое+*/</script> 

   тогава ще излезе злонамерена заявка от името на клиента.

   Ясен пример за XSS: js-снифери, които имитират страници за въвеждане на CVC, срок на валидност на картата и така нататък. 

   Какво трябва да помни уеб разработчикът: В заглавката Content-Security-Policy използвайте атрибута script-src, за да позволите на браузъра на клиента да зарежда и изпълнява само код от доверен източник. Например, script-src ‘self’ добавя в бял списък само скриптове от нашия сайт. 
   Най-добра практика е използването на Inline code: разрешавайте само inline javascript с помощта на стойността unsafe-inline. Тази стойност позволява използването на inline js/css, но не забранява включването на js файлове. В комбинация със script-src ‘self’ забраняваме изпълнението на външни скриптове.

   Задължително логирайте всичко с помощта на report-uri и следете опитите за вграждане в сайта.

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

   Каква е опасността: Ако злонамереният потребител въведе SQL заявка в такава форма, може да срине базата данни или да издаде конфиденциална информация. 

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

   На страната на клиента напишете проверка на полета с помощта на JavaScript. 

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

   Определете точно къде става взаимодействието с базата данни в уеб-приложението. 

   Взаимодействието настъпва, когато получаваме някаква информация: заявка с id (смяна на id), създаване на нов потребител, нов коментар – нови записи в базата. Тук могат да възникнат sql инжекции. Дори и да изтрием запис от базата, sql инжекция все пак е възможна.

Общи препоръки

Не изобретявайте колелото – използвайте проверени фреймуорки.. Обикновено популярните фреймуорки са по-сигурни. За .NET – това са ASP.NET MVC и ASP.NET Core, за Python – Django или Flask, за Ruby – Ruby on Rails, за PHP – Symfony, Laravel, Yii, за JavaScript – Node.JS-Express.js, за Java – Spring MVC.

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

Проверявайте правата на достъп.. От страна на сървъра винаги се отнасяйте към вашия код така, сякаш той е написан от вашия най-непоносим враг, който желае да срине вашия сайт и да наруши целостта на данните ви. Особено, тъй като понякога наистина е така.

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

Защитете уеб приложението с помощта на Web Application Firewall и интегрирайте с него докладите от скенера за уязвимости.. Например, в DataLine за свързване на услуги се използват Qualys и FortiWeb.

Източник: habr.com