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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   Атрибутът "HTTPOnly" защитава бисквитките от обработка от скриптове, които атакуващите използват за кражба на потребителски данни. Флагът "сигурно" не позволява бисквитките да бъдат изпращани в ясен текст. Комуникацията ще бъде разрешена само ако за изпращане на бисквитки се използва защитен HTTPS протокол. 

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

   Set-Cookie: Secure; HttpOnly

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

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

   В този случай атрибутът „HTTPOnly“ ще направи бисквитките невидими за вашия собствен JavaScript.  

3. Базирани на пътя уязвимости.

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

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

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

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

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

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

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

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

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

    <body>
       <form action="/bg/form/submit" method="get" autocomplete="off">
         <div>
           <input type="text" placeholder="First Name">
         </div>
         <div>
           <input type="text" id="lname" placeholder="Last Name" autocomplete="on">
         </div>
         <div>
           <input type="number" placeholder="Credit card number">
         </div>
         <input type="submit">
       </form>
     </body>

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

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

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

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

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

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

   Стойностите deny и sameorigin на заглавката X-Frame-Options ще попречат на работата на уеб визуализатора на Yandex. За да разрешите използването на iframes за уеб визуализатора, трябва да напишете отделно правило в настройките. Например за 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="/bg/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 по-опасно, тъй като скриптът е вграден в сървъра и се изпълнява всеки път, когато атакуваната страница се отвори в браузъра.

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

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

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

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

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

   Не забравяйте да регистрирате всичко с помощта на report-uri и да разгледате опитите за внедряването му в сайта.

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

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

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

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

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

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

   Взаимодействието възниква, когато получим някаква информация: заявка с идентификатор (промяна на идентификатор), създаване на нов потребител, нов коментар или нови записи в базата данни. Това е мястото, където могат да възникнат 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 - Пролетен MVC.

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

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

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

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

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