Около година назад стартирахме в DataLine за търсене и анализ на уязвимости в ИТ-приложенията. В основата на услугата стои облачното решение Qualys, за което . За една година работа с решението проведохме 291 сканиране за различни сайтове и натрупахме статистика за разпространените уязвимости в уеб-приложенията.
В статията по-долу ще покажа какви точно дупки в сигурността на сайтовете се крият зад различни нива на критичност. Нека видим кои уязвимости скенерът намира особено често, защо могат да възникнат и как да се защитим.
Всички уязвимости на уеб-приложенията Qualys дели на три нива на критичност: ниско, средно и високо. При поглед към разпределението по 'тежест' изглежда, че всъщност не е толкова зле. Уязвимостите с високо ниво на критичност са малко, основно всичко е некритично:
Но некритичните не означават безобидни. Те също могат да причинят сериозни щети.
Топ 'некритични' уязвимости
- Уязвимости, свързани с комбинирано съдържание.
Стандартът за сигурност на сайтове е предаване на данни между клиента и сървъра по протокола HTTPS, който поддържа криптиране и защитава информацията от прихващане.
Някои сайтове използват комбинирано съдържание: предават част от данните чрез незашифрован протокол HTTP. Често по този начин предават пасивно съдържание – информация, която влияе само на визуализацията на сайта: изображения, css-стили. Но понякога така се предава и активно съдържание: скриптове, които управляват поведението на сайта. В този случай с помощта на специален софтуер може да се анализира идващата от сървъра информация с активно съдържание, да се модифицират на лето отговорите и да се накара машината да работи така, както не е била замислена от създателите си.
Браузерите на новите версии предупреждават потребителите, че сайтовете с комбинирано съдържание не са безопасни и блокират съдържанието. Разработчиците на сайтове също получават предупреждения от браузера в консолата. Например, така изглежда в :
Опасността е:Злоумишленици използват незашифрован протокол за прихващане на информация за потребителя, подмяна на скриптове и изпращане на заявки на сайта от негово име. Дори ако посетителят на сайта не е въвел данни, това не го предпазва от фишинг – извлечения конфиденциальна информация по мошенническим методам. Например, с помощью скрипта можно пренаправить потребителя на небезопасен сайт, който се маскира под познат за потребителя. В отделни случаи злонамереният сайт изглежда дори по-добре от оригинала, и потребителят може сам да попълни формуляра и да предостави конфиденциални данни.Какво трябва да запомни уеб разработчикът: Дори ако администраторът на сайта е инсталирал и конфигурирал SSL/TLS сертификат, уязвимост може да възникне поради човешкия фактор. Например, ако на някоя от страниците се е поставила не относителна връзка, а абсолютна с http, и освен това не са конфигурирани пренасочвания от http на https.
Намирането на смесено съдържание на сайта може да се извърши с помощта на браузър: да се потърси в изходния код на страницата, да се прочетат уведомленията в конзолата на разработчика. Но на разработчика ще му отнеме дълго и скучно да търси в кода. Процесът може да се ускори с автоматизирани средства за анализ, например: , свободен софтуер Lighthouse или платен софтуер Screaming Frog SEO Spider.
Също така уязвимост може да възникне поради проблеми с legacy-code – код, който е наследен. Например, ако част от страниците се генерират по стар шаблон, където не се отчита преходът на сайтовете към https.
- Бисквитки без флаговете „HTTPOnly“ и „secure“.
Атрибутът „HTTPOnly“ защитава файловете с бисквитки от обработка от скриптове, които злоумышлениците използват за кражба на потребителски данни. Флагът „secure“ не позволява предаване на бисквитки в открит вид. Обменът на данни ще бъде разрешен само ако за изпращане на бисквитките се използва защитен протокол HTTPS.
И двата атрибута се записват в свойствата на бисквитките:
Set-Cookie: Secure; HttpOnlyОпасността е:: Ако разработчикът на сайта не е посочил тези атрибути, злоумышленикът може да перехване информацията на потребителя от бисквитките и да я използва. Ако бисквитките се използват за удостоверяване и авторизация, той ще може да открадне сесията на потребителя и да извърши действия на сайта от негово име.
Какво трябва да запомни уеб разработчикът: Обикновено в популярни рамки тези атрибути се задават автоматично. Но все пак проверете конфигурацията на уеб сървъра и задайте флага: Set-Cookie HttpOnly; Secure.
При това атрибутът „HTTPOnly“ ще направи бисквитките невидими и за вашия собствен JavaScript.
- Path-Based Vulnerabilities („пътеви“ уязвимости).
Сканиращото устройство съобщава за такава уязвимост, ако открие публично достъпен файл или директория на сайта с потенциално конфиденциална информация. Например, открива отделни файлове с конфигурация на системата или достъп до файловата система в цялост. Такава ситуация е възможна, ако на сайта неправилно са зададени права на достъп.
Опасността е:: Ако файловата система е "изложена навън", злоумышленникът може да проникне в интерфейса на операционната система и да се опита да намери папки с пароли, ако те са съхранени в открит вид (не го правете!). Или може да открадне хешове на пароли и да опита да подбере паролата, а също така да се опита да увеличи привилегиите в системата и да задълбочи навлизането в инфраструктурата.
Какво трябва да запомни уеб разработчикът: Не забравяйте за правата на достъп и конфигурирайте платформата, уебсервера, уеб приложението, така че да не може да "избяга" от уеб директорията.
- Форми за въвеждане на конфиденциални данни с активирана функция за автоматично попълване.
Ако потребителят често попълва форми на сайтове, неговият браузър съхранява тази информация с помощта на функцията за автоматично попълване.
Формите на сайтовете могат да включват полета с конфиденциална информация, например пароли или номера на кредитни карти. За такива полета е добре да се деактивира функцията за автоматично попълване на формуляри на самия сайт.
Опасността е:: Ако браузърът на потребителя съхрани конфиденциална информация, злоумышленникът може да я прихване по-късно, например чрез фишинг. По същността, уеб разработчик, който е забравил за този нюанс, поставя своите потребители в риск.
Какво трябва да запомни уеб разработчикът: В този случай имаме класически конфликт: удобство срещу сигурност. Ако уеб разработчикът мисли за комфорта на потребителя, той може съзнателно да избере автоматичното попълване. Например, ако е важно да се следва – препоръки за достъпност на съдържанието за потребители с ограничени възможности.
За повечето браузъри деактивирането на автоматичното попълване може да стане чрез атрибута autocomplete="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, а вариант на рецептата може да бъде намерен .
- В кода на сайта не е зададен заглавие X-Frame-Options.
Тази заглавна част влияе на таговете frame, iframe, embed или object. Чрез нея можете напълно да забраните вграждането на вашия сайт в frame. За целта трябва да зададете стойността X-Frame-Options: deny. Или можете да зададете X-Frame-Options: sameorigin, тогава вграждането в iframe ще бъде достъпно само на вашия домейн.
Опасността е:: Липсата на такава заглавна част може да се използва на злонамерени сайтове за кликджекинг. За такова нападение злонамереният извършител създава прозрачен frame над бутоните и заблуждава потребителя. Например: измамниците вграждат страници на социални мрежи във frame на сайта. Потребителят мисли, че кликва на бутон на този сайт. Вместо това кликът се прихваща и изпраща заявка от потребителя в социалната мрежа, където има активна сесия. Така злонамерени лица разпространяват спам от името на потребителя или увеличават последователите и лайковете.
Ако не се забрани такава възможност, злонамереният може да постави бутона на вашето приложение на злонамерен сайт. Той може да се интересува от вашата референтна програма или от вашите потребители.
Какво трябва да запомни уеб разработчикът: Уязвимост може да се появи, ако 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; ... } - Уязвимости PRSSI (Path-relative stylesheet import).
Това е уязвимост в стиловете на сайта. Тя възниква, ако за достъп до файловете със стилове се използват относителни линкове от вида href="/somefolder/styles.css/". Злонамереният ще се възползва от това, ако намери начин да пренасочи потребителя на злонамерена страница. Страницата ще постави относителния линк в своя url и ще имитира достъпа до стилове. Получава се заявка подобна на badsite.ru/.../somefolder/styles.css/, която под предлог на стил може да извършва злонамерени действия.
Опасността е:: Злодей може да се възползва от тази уязвимост, ако намери друга дупка в сигурността. В резултат на това могат да бъдат откраднати потребителски данни от бисквити или токени.
Какво трябва да запомни уеб разработчикът: Задайте заглавие X-Content-Type-Options: nosniff. В този случай браузърът ще провери типа на съдържанието за стиловете. Ако типът се различава от text/css, браузърът ще блокира заявката.
Критични уязвимости
- Страница с поле за парола се предава на сървъра по неподвижен канал (HTML форма, съдържаща поле за парола, се предоставя през HTTP).
Отговорът от сървъра по нешифрован канал е уязвим за атаки от тип 'Човек в средата'. Злоумышленик може да прихване трафика и да се вмъкне между клиента и сървъра, когато страницата върви от сървъра към клиента.
Опасността е:: Злодей може да замени страницата и да изпрати на потребителя форма за конфиденциални данни, които ще отидат на сървъра на злоумышленика.
Какво трябва да запомни уеб разработчикът: Някои сайтове вместо парола изпращат на потребителите еднократен код на имейл/телефон. В този случай уязвимостта не е толкова критична, но механизмът ще затрудни живота на потребителите.
- Изпращане на форма с логин и парола по незащитен канал (Формуляр за вход не се изпраща чрез HTTPS).
В този случай от потребителя на сървъра по нешифрован канал се изпраща форма с логин и парола.
Опасността е:: За разлика от предишния случай, това вече е критична уязвимост. По-лесно е да се прихванат конфиденциални данни, тъй като дори не е необходимо да се пише код за това.
- Използване на JavaScript библиотеки с известни уязвимости.
По време на сканирането най-използваната библиотека стана jQuery с обширен набор от версии. Във всяка от версиите има поне една, а понякога и повече известни уязвимости. Влиянието може да бъде разнообразно – зависи от природата на уязвимостта.
Опасността е:: За известни уязвимости съществуват експлойти, например:
Какво трябва да запомни уеб разработчикът: Редовно се връщайте към цикъла: търсене на известни уязвимости – премахване – проверка. Ако съзнателно използвате остарели библиотеки, например за подкрепа на стари браузъри или за спестяване на бюджет, търсете възможности за отстраняване на известни уязвимости. - Междусайтови скриптове (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 и наблюдавайте опитите за внедряване в сайта.
- 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.
Следете за актуализации от доставчика и ги обновявайте редовно. Уязвимостта ще бъде открита, след това ще бъде написан експлойт, публикуван в публичен достъп и всичко ще започне отново. Абонирайте се за актуализации до стабилни версии от доставчика на софтуер.
Проверявайте правата за достъп. От страна на сървъра винаги се отнасяйте към кода си, сякаш той целият, от първата до последната буква, е написан от вашия най-ненавистен враг, който иска да разбие сайта ви, да наруши целостта на данните ви. Още повече, че понякога това наистина е така.
Използвайте клони, тестови среди, а след това вече прилагайте на продуктивната среда. Това ще помогне, първо, да избегнете грешки и несъответствия в продуктивната среда: продуктивната среда носи печалба, просто неработещата продуктивна среда е критична. При добавяне, поправяне или закриване на някакъв проблем е важно да се работи в тестова среда, след това да се провери функционалността и откритите уязвимости, а след това да се планират работите в продуктивната среда.
Защитавайте уеб приложението с помощта на и интегрирайте с него отчети от скенера за уязвимости. Например, в DataLine се използват Qualys и FortiWeb като свързващи услуги.
Източник: habr.com
