Кратки увод у веб сигурност

Приручник за веб програмере о ЦОРС, ЦСП, ХСТС и свим акронимима веб заштите!

Постоји много разлога за учење о веб сигурности, као што су:

  • Ви сте забринути корисник који се брине због цурења ваших личних података
  • Ви сте забринути веб програмер који жели да своје веб апликације учини сигурнијим
  • Ви сте веб програмер који се пријављује за посао и желите да будете спремни ако вас анкетари постављају питања о веб безбедности

и тако даље.

Па, овај пост ће објаснити неке уобичајене скраћенице веб заштите на начин који је лако разумљив, али ипак тачан.

Пре него што то учинимо, побринимо се да разумемо неколико основних појмова безбедности.

Два основна концепта безбедности

Нико никада није 100% сигуран.

Не постоји појам да сте 100% заштићени од хаковања. Ако вам неко то икада каже, греши.

Један слој заштите није довољан.

Не можете само рећи ...

Ох, јер сам имплементирао ЦСП, сигуран сам. Могу да прецртам скрипте са више локација са своје листе рањивости, јер се то сада не може догодити.

Можда је то некима дато, али лако је пронаћи себе да размишљате на овај начин. Мислим да је један од разлога зашто програмери лако могу да мисле да размишљају на овај начин тај што је толико кодирања црно-бело, 0 или 1, тачно или нетачно. Безбедност није тако једноставна.

Започећемо са оним на који свако налети прилично рано на свом путу веб развоја. А онда погледате СтацкОверфлов и пронађете гомилу одговора који вам говоре како то заобићи.

Дељење ресурса више порекла (ЦОРС)

Да ли сте икада добили грешку која је изгледала отприлике овако?

No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access.

Сигурно нисте сами. А онда га прогуглате и неко вам каже да набавите ово проширење које ће уклонити све ваше проблеме!

Сјајно, зар не?

ЦОРС је ту да вас заштити, а не повреди!

Да бисмо објаснили како вам ЦОРС помаже, хајде да прво разговарамо о колачићима, посебно о колачићима за аутентификацију . Колачићи за потврду идентитета користе се да би серверу рекли да сте пријављени и аутоматски се шаљу са било којим захтевом који упутите том серверу.

Рецимо да сте пријављени на Фацебоок, а они користе колачиће за потврду идентитета. Кликнете на bit.ly/r43nugiкоји вас преусмерава superevilwebsite.rocks. Скрипта унутар superevilwebsite.rocksчини захтев на страни клијента на facebook.comкоји шаље ваш колачић за потврду идентитета!

У свету без ЦОРС-а могли би да изврше промене на вашем налогу, а да ви то ни не знате. Све док, наравно, не поставе bit.ly/r43nugiна вашу временску линију и сви ваши пријатељи не кликну на њу, а затим објаве bit.ly/r43nugiна свим временским линијама ваших пријатеља, а затим се циклус наставља у злој шеми најпре која осваја све Фацебоок кориснике, а свет прождире superevilwebsite.rocks. ?

Међутим, у свету ЦОРС-а, Фацебоок би дозвољавао само захтеве са пореклом facebook.comза уређивање података на свом серверу. Другим речима, ограничили би заједничку поделу ресурса. Тада можете питати ...

Па, може ли суперевилвебсите.роцкс само променити заглавље порекла на њихов захтев, тако да изгледа као да долази са фацебоок.цом?

Могу да покушају, али то неће успети, јер ће га прегледач само игнорисати и користити право порекло.

Ок, али шта ако је суперевилвебсите.роцкс послао захтев на страни сервера?

У овом случају, могли би да заобиђу ЦОРС, али неће победити јер неће моћи да пошаљу ваш колачић за потврду идентитета током вожње. Скрипту би требало извршити на страни клијента да би се добио приступ колачићима на страни клијента.

Политика безбедности садржаја (ЦСП)

Да бисмо разумели ЦСП, прво морамо да разговарамо о једној од најчешћих рањивости на вебу: КССС, што је скраћеница за скриптирање на више локација (иаи - још један акроним).

КССС је случај када нека зла особа убризга ЈаваСцрипт у код вашег клијента. Можда мислите…

Шта ће да ураде? Промените боју из црвене у плаву?

Претпоставимо да је неко успешно убацио ЈаваСцрипт у код клијента веб странице коју посећујете.

Шта би могли да ураде да би било злонамерно?

  • Могли би да упућују ХТТП захтеве другој локацији претварајући се да сте ви.
  • Могли би да додају сидрену ознаку која вас шаље на веб локацију која изгледа идентично оној на којој се налазите са неким мало другачијим, злонамерним карактеристикама.
  • Могли су да додају ознаку скрипте са уграђеним ЈаваСцрипт-ом.
  • Могли би да додају ознаку скрипте која негде дохваћа удаљену ЈаваСцрипт датотеку.
  • Могли би да додају ифраме који покрива страницу и изгледа као део веб странице који тражи да унесете лозинку.

Могућности су бесконачне.

ЦСП покушава да спречи да се ово догоди ограничавањем:

  • шта се може отворити у ифраме-у
  • које табеле стилова се могу учитати
  • где се могу поднети захтеви итд.

Па како то функционише?

Када кликнете на везу или упишете УРЛ веб локације у траку за адресу прегледача, прегледач шаље ГЕТ захтев. На крају се отвара до сервера који опслужује ХТМЛ заједно са неким ХТТП заглављима. Ако вас занима која заглавља примате, отворите картицу Мрежа на конзоли и посетите неке веб локације.

Можда ћете видети заглавље одговора које изгледа овако:

content-security-policy: default-src * data: blob:;script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self';style-src data: blob: 'unsafe-inline' *;connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* //fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;

То је политика безбедности садржаја facebook.com. Преформатирајмо га да бисмо олакшали читање:

content-security-policy: default-src * data: blob:; script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self'; style-src data: blob: 'unsafe-inline' *; connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* //fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;

Сада, хајде да разбијемо директиве.

  • default-src ограничава све остале ЦСП директиве које нису изричито наведене.
  • script-srcограничава скрипте које се могу учитати.
  • style-src ограничава табеле стилова које се могу учитати.
  • connect-src ограничава УРЛ-ове који се могу учитати помоћу интерфејса скрипти, зато дохватите, КСХР, ајак итд.

Имајте на уму да постоји много више ЦСП директива него само ове четири приказане горе. Прегледач ће прочитати ЦСП заглавље и применити те директиве на све у ХТМЛ датотеци која је послужена. Ако су директиве постављене на одговарајући начин, оне дозвољавају само оно што је неопходно.

Ако није присутно заглавље ЦСП-а, онда све иде и ништа није ограничено. Где год видите *, то је џокер. Можете да замислите да замените *било чиме и биће дозвољено.

ХТТПС или ХТТП безбедно

Свакако сте чули за ХТТПС. Можда сте чули како неки људи кажу ...

Зашто ми је стало да користим ХТТПС ако сам само на веб локацији и играм игру.

Или сте можда чули другу страну ...

Луди сте ако ваша веб локација нема ХТТПС. 2018. је година! Не верујте никоме ко каже другачије.

Можда сте чули да ће Цхроме сада означити вашу веб локацију као несигурну ако није ХТТПС.

У основи ХТТПС је прилично једноставан. ХТТПС је шифрован, а ХТТП није.

Па зашто је ово важно ако не шаљете осетљиве податке?

Припремите се за још један акроним ... МИТМ, што је скраћеница за Човек у средини.

Ако у кафићу користите јавни Ви-Фи без лозинке, некоме је прилично лако да се понаша као ваш рутер, тако да сви захтеви и одговори пролазе кроз њих. Ако ваши подаци нису шифровани, они са њима могу да раде шта год желе. Они могу да уређују ХТМЛ, ЦСС или ЈаваСцрипт пре него што уопште стигне у ваш прегледач. С обзиром на оно што знамо о КССС-у, можете замислити колико ово може бити лоше.

Ок, али како то да мој рачунар и сервер знају како да шифрују / дешифрују, али овај МИТМ не зна?

That’s where SSL (Secure Sockets Layer) and more recently, TLS (Transport Layer Security) come in. TLS took over for SSL in 1999 as the encryption technology used within HTTPS. Exactly how TLS works is outside of the scope of this post.

HTTP Strict-Transport-Security (HSTS)

This one is pretty straightforward. Let’s use Facebook’s header as an example again:

strict-transport-security: max-age=15552000; preload
  • max-age specifies how long a browser should remember to force the user to access a website using HTTPS.
  • preload is not important for our purposes. It is a service hosted by Google and not part of the HSTS specification.

This header only applies if you accessed the site using HTTPS. If you accessed the site via HTTP, the header is ignored. The reason is that, quite simply, HTTP is so insecure that it can’t be trusted.

Let’s use the Facebook example to further illustrate how this is helpful in practice. You are accessing facebook.com for the first time, and you know HTTPS is safer than HTTP, so you access it over HTTPS, //facebook.com. When your browser receives the HTML, it receives the header above which tells your browser to force-redirect you to HTTPS for future requests. One month later, someone sends you a link to Facebook using HTTP, //facebook.com, and you click on it. Since one month is less than the 15552000 seconds specified by the max-age directive, your browser will send the request as HTTPS, preventing a potential MITM attack.

Closing Thoughts

Безбедност на Интернету је важна без обзира где се налазите на путу веб развоја. Што се више излажете томе, биће вам боље. Сигурност је нешто што би требало бити важно свима, а не само људима који то имају изричито у називу радног места! ?