Прыкладна год таму мы ў 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 (шляхавыя уразлівасці).
Сканар паведамляе аб такой уразлівасці, калі знаходзіць публічна даступны файл ці дырэкторыю сайта з патэнцыйна канфідэнцыйнай інфармацыяй. Напрыклад, выяўляе асобныя файлы з канфігурацыяй сістэмы ці доступ да файлавай сістэмы цалкам. Такая сітуацыя магчыма, калі на сайце няправільна зададзены правы доступу.
Чым небяспечна: Калі файлавая сістэма «тырчыць вонкі», зламыснік можа праваліцца ў інтэрфейс аперацыйнай сістэмы і паспрабаваць знайсці тэчкі з паролямі, калі яны захоўваюцца ў адкрытым выглядзе (не трэба так!). Ці можна скрасці хэшы пароляў і пераборам падабраць пароль, а таксама паспрабаваць падняць прывілеі ў сістэме і прасоўвацца ўглыб інфраструктуры.
Што варта памятаць вэб-распрацоўніку: Не забывайце пра правы доступу і канфігуруйце платформу, вэб-сервер, вэб-дадатак, каб нельга было "збегчы" з вэб-дырэкторыі.
- Формы для ўводу канфідэнцыйных дадзеных з уключанай функцыяй аўтазапаўнення.
Калі карыстач часта запаўняе формы на сайтах, яго браўзэр захоўвае гэтую інфармацыю з дапамогай функцыі аўтазапаўнення.
Формы на сайтах могуць уключаць палі з канфідэнцыйнай інфармацыяй, напрыклад, паролі ці нумары крэдытных карт. Для такіх палёў варта на самім сайце адключыць функцыю аўтазапаўнення формаў.
Чым небяспечна: Калі браўзэр карыстальніка захавае канфідэнцыйную інфармацыю, зламыснік можа перахапіць яе пазней, напрыклад, з дапамогай фішынгу. Па сутнасці, вэб-распрацоўшчык, які забыўся пра гэты нюанс, падстаўляе сваіх карыстальнікаў.
Што варта памятаць вэб-распрацоўніку: У гэтым выпадку ў нас класічны канфлікт: зручнасць vs бяспека. Калі вэб-распрацоўнік думае аб камфорце карыстача, ён можа свядома абраць аўтазапаўненне. Напрыклад, калі важна прытрымлівацца – рэкамендацый па даступнасці кантэнту для карыстальнікаў з абмежаванымі магчымасцямі.
Для большасці браўзэраў адключыць аўтазапаўненне можна атрыбутам autocompete=«off», напрыклад:
<body> <form action="/be/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, варыянт рэцэпту можна знайсці .
- У кодзе сайта не зададзены загаловак 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; ... } - Уразлівасці PRSSI (Path-relative stylesheet import).
Гэта ўразлівасць у стылях сайта. Яна ўзнікае, калі для звароту да файлаў стыляў выкарыстоўваюцца адносныя спасылкі выгляду href="/be/somefolder/styles.css/". Зламыснік скарыстаецца гэтым, калі знойдзе спосаб перавесці карыстальніка на шкоднасную старонку. Старонка падставіць адносную спасылку ў свой url і імітуе зварот да стыляў. Атрымаецца запыт накшталт badsite.ru/…/somefolder/styles.css/, які пад выглядам стылю можа здзяйсняць шкоднасныя дзеянні.
Чым небяспечна: Ашуканец зможа скарыстацца гэтай уразлівасцю, калі знойдзе яшчэ адну дзірку ў бяспецы. У выніку так можна выкрасці карыстацкія дадзеныя з печыва ці токены.
Што варта памятаць вэб-распрацоўніку: Задайце загаловак X-Content-Type-Options: nosniff. У гэтым выпадку браўзэр праверыць тып кантэнту для стыляў. Калі тып адрозніваецца ад text/css, браўзэр заблакуе запыт.
Крытычныя ўразлівасці
- Старонка з полем для пароля перадаецца з сервера па неабароненым канале (HTML form containing password field(s) is served over HTTP).
Адказ ад сервера па нешыфраваным канале ўразлівы для нападаў тыпу "Man in the middle". Зламыснік можа перахапіць трафік і ўклінавацца паміж кліентам і серверам, калі старонка ідзе ад сервера да кліента.
Чым небяспечна: Ашуканец зможа падмяніць старонку і даслаць карыстальніку форму для канфідэнцыйных даных, якія пойдуць на сервер зламысніка.
Што варта памятаць вэб-распрацоўніку: Некаторыя сайты замест пароля дасылаюць карыстальнікам аднаразовы код на пошту/тэлефон. У гэтым выпадку ўразлівасць не так крытычная, але механізм ускладніць жыццё карыстачоў.
- Адпраўка формы з лагінам і паролем па неабароненым канале (Login Form Is Not Submitted Via 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