Политики за сигурност на съдържанието: Какво представляват и как работят?

by Dec 21, 2017Инструменти0 comments

Активното съдържание на уебсайтовете (в т.ч. JavaScript, CSS, ActiveX) могат да бъдат риск по отношение на сигурността за интернет потребителите и уебсайт операторите, тъй катоте могат да бъдат манипулирани чрез крос-сайт скриптове. Политиката за сигурност на съдържанието (Content Security Policy (CSP) беше представена, за да сме уверени в сигурността на сайтовете, които ползваме и правим, както и да ги ползваме в пълния им капацитет. Този стандарт по сигурността е създаден да защитава от зловредни атаки и вече се поддържа от повечето уеб-браузъри. CSP защитава както сайтовете, така и потребителите. Но какво стои зад тази политика?

CSP може да бъде проследена до 2004г, когато е по-известна като “Ограничение на съдържанието” (“Content Restriction”). Причината за тази мярка са повишеният брой слаби места в интернет скриптовете. Крос-сайт скриптирането (XSS) е криминален метод за внедряване на зловреден код в даден уебсайт, което поставя потребителите в голям риск. Те влизат в доверен сайт, но в него има скрипт, който зарежда зловредни данни от друг външен източник. Кибер престъпниците се възползват от слабости в сигурността на сайта. По този начин те могат да проникнат в чужди компютри без знанието на техните собственици. Операторите на уебсайта дори няма да забележат промяната в кода на сайта.

За да разреши този проблем, фондация Mozilla инвестира в развитието на CSP. Предимството на този стандарт е, че в браузъра могат да бъдат вградени правила, които да казват на софтуера кои скриптове са безопасни да бъдат заредни и кои – не. За да се случи това CSP ползва HTTP.

Факт: Фондация Mozilla стои зад разработката на браузъра Firefox. Организацията с нестопанска цел е отговорна за ориентирането на проектите на Mozilla към интернет. Тя е основана от бивши служители на Netscape, които разработват един от първите уеб-браузъри.

Как работи CSP? 

Когато общуваме онлайн, клиенти и сървъри обменят данни чрез Hypertext Transfer Protocol (HTTP). HTTP полетата са важна част от рикуестите и отговорите: параметри и аргументи се предават чрез тези полета и те са важни за обмен на информация между двама участници (клиенти и сървъри). Протоколите са разделени на полета за анкета и полета за отговор и могат да съдържат информация като брой символи, език и бисквитки. CSP е интегриран като поле за отговор. Това значи, че сървърът доставя информацията, а браузърът я обработва.

CSP полето е създадено от оператора на уебсайта и интегрирано във всяка подстраница на сайта, в която искате стандартът за сигурност да бъде приложен. Като операторт на сайта, имате възможността да определяте различни мерки за сигурност за всяка отделна страница. Можете да интегрирате цонцептът за сигурност по-лесно, създавайки .htaccess файлове, които се намират на същия (или йерархически по-високи) папки от кореспондиращите уеб-страници, или чрез внедряване на CSP директно в настройките на сървъра.

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

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

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

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

  • base-uri: Ограничава URL-ите които могат да бъдат използвани в <base> елементите на сайта;
  • child-src: Определя валидни източници за уеб разработчиците и гнездови контексти, използващи елемнти като <frame> и <iframe>;
  • connect-src: Ограничава източниците, към които сайтът може да се свърже (т. нар. линкове);
  • font-src: Определя работещите източници за шрифтове;
  • form-action: Определя валидни източници, които могат да бъдат ползвани като HTML <form> действие;
  • frame-ancestors: Определя валидни източници за вграждане на ресурси, използващи кода <frame> и <iframes>;
  • img-src: Определя валидни източници на изображения;
  • media-src: Определя валидни аудио и видео източници;
  • object-src: Определя валидни източници за плъгини;
  • plugin-types: Определя валидни плъгин типове;
  • report-uri: Позволява на браузъра да разбере кога един URL (към който се пращат доклади) нарушава мерките за сигурност;
  • script-src: Определя валидни източници на JavaScript;
  • style-src: Определя валидни стилови източници;
  • upgrade-insecure-requests: Определя кои несигурни HTTP сайтове трябва да бъдат третирани като HTTPS сайтове;
  • sandbox: Мести подозрителния сайт в т. нар. сандбокс (Sandbox – кутия с пясък), където формуляри, изскачащи прозорци и скриптове са забранени;

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

Можете да въведете какъвто и да е брой заповеди в полето на браузъра. Ако искате да включите няколко заповеди, разделете ги с точка и запетая. Освен това, Вие, като оператор на сайта трябва да определите всички източници в рамките на заповедта. Няколко въвеждания на една и съща заповед с допълнителни източници не са разрешени (както е в следващия пример):

script-src example1.local; script-src example2.local

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

script-src example1.local example2.local

Ако не желаете определени типове съдържание за определена страница или за целия уебсайт, можете да въведете стойност „none” в хедъра, за да уточните, че не желаете да бъдат зареждани каквито и да е източници. Можете да използвате и стойността „self” – това значи, че браузъра може зарежда съдържание от същия източник. И двете стойности трябва да бъдат обградени с единични кавички, иначе двете команди ще бъдат интерпретирани като домейни.

Има различни възможности за определяне на Политиката за сигурност на съдържанието в хедъра:

  • Content-Security-Policy
  • X-Webkit-CSP
  • X-Content-Security-Policy

Не всички браузъри поддържат всяко условие. Все пак W3C (тялото, отговорно за определянето на уеб стандарти) предполага CSP. Следователно всички модерни браузъри са адаптирани към този стандарт за сигурност (останалите 2 версии се считат за остарели). За да сте сигурни, че ще достигнете възможно най-много интернет потребители (дори тези с остарели браузъри) с Вашето CSP, препоръчително е да включите всички полета в хедъра. Ако някой уеб браузър не може да се справи с хедъра за Политиката, просто ще игнорира и ще покаже сайта без проблеми – все пак, обаче, сайтът няма да има допълнителна защита.

Би трябвало да сложите HTTP хедъри в целия Ви домейн. За поддиректориите можете да използвате файла „.htaccess“.  След това ползвате CSP за да зададете специални правила за отделните подстраници. Например, ако сте интегрирали бутон за социална мрежа на някоя от страниците, но не на следващата, логично е да позволите достъп от външен източник само на първата страница.

Източниците могат да бъдат въведени като адреси, или като заместващи символи. Следващите символи са позволени:

  • script-src example.com:443 – скриптовете са позволени само от този домейн чрез HTTPS;
  • script-src ‘none’ – не е позволено да бъдат зареждани скриптове;
  • script-src ‘self’ – скриптовете могат да бъдат зареждани от същия източник, като дадената страница, но не и от поддомейни;
  • script-src https: – скриптовете могат да бъдат заредени от всеки домейн, стига да започва с HTTPS;
  • script-src example.com – могат да бъдат зареждани скриптове от този домейн;
  • script-src *.example.com – скриптове от този домейн и всички поддомейни са позволени;
  • img-src data: – могат да бъдат зареждани изображения чрез URL за данни;

Политиката за сигурност на съдържанието на практика постановява, че скриптовете могат да бъдат зареждани от файлове, а не директно от кода на уебсайта, Ако искате да заобиколите това, можете да ползвате командния скрипт „-src ‘unsafe-inline’“. Имайте предвид, обаче, че по този начин отслабвате сигурността . Стандартът за сигурност също забранява функцията „eval ()“. Тази команда може да бъде ползвана да се конвертира текста в код на JavaScript – но това също поставя и риск за сигурността. Ако все пак се нуждаете от тази функция, можете да реактивирате със скрипта „-src ‘unsafe-eval’“.

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

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

<script src=’example.js’></script>

Това, което скриптът прави накрая, е описано в секцията „example.js“. Можете и да съхранявате стилови елементи в разделни шийтове. Ако искате да вградите Политика за интернет сигурността в ролята си на уебсайт оператор, не е достатъчно просто да я въведете в хедъра. Налага се и да проверите и настроите сорс кода на Вашия уебсайт.

NB: Искате да знаете колко е сигурен уебсайта Ви? Mozilla разполага с лесен тест: Observatory от Mozilla сканира Вашия уебсайт и го оценява. Казва Ви и как да го направите още по-сигурен.

Пример за Политика за сигурност на съдържанието:

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

  • Content-Security-Policy: “default-src ‘none’; script-src ‘self’ *.example.com; style-src ‘self’; img-src ‘self’ data:; font-src ‘self’ fonts.google.com/; report-uri example.org/report.html”
  • X-Content-Security-Policy: “default-src ‘none’; script-src ‘self’ *.example.com; style-src ‘self’; img-src ‘self’ data:; font-src ‘self’ fonts.google.com/; report-uri example.org/report.html”
  • X-WebKit-CSP: “default-src ‘none’; script-src ‘self’ *.example.com; style-src ‘self’; img-src ‘self’ data:; font-src ‘self’ fonts.google.com/; report-uri example.org”

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

Първо, нека уточним, че освен ако не е предварително заложено в заповедта, данни не бива да бъдат зареждани от който и да е източник (default-src). Това прави нещата малко по-безопасни. Винаги първо трябва да определяме „default-src“. Това ще предотврати евентуално забравена заповед, която да остави дупка в Политиката на сайта Ви.

След това определяме източника, от който трябва да бъдат заредени скриптове (script-src). В примерът определеихме, че браузърът зарежда скриптове само от един и същи източник и от „example.com”, включително и от всички поддомейни (заместващите символи въведохме, използвайки *). Освен това зададохме, че клиентите могат да зареждат подшийтове само от собствени източници (style-src). Изображенията са позволени само от техния си източник като URL за данни (img-src). Според нашия хедър за CSP, шрифтове могат да бъдат сваляни само от източниците на Google. В примера уточнихме място, от което се пращат известия, в случай че някой опита да наруши стандартаза сигустност (report-uri).

Може и да сте забелязали, че не сме включили всички заповеди в хедъра. Това не причинява проблеми: в случая не се нуждаем от още уайтлистове и скриптът по подразбиране (default src) изключва всички други източници.

Share This

Share This

Share this post with your friends!