Народження функції: захист від clickjacking

Привіт, мене звуть Кімберлі Прайс (Kymberlee Price) і я нещодавно приєдналася до команди Internet Explorer на посаді керівник групи розробників з безпеки в IE8, і працюю разом з Еріком Лоуренсом (Eric Lawrence). До цього я п'ять років провела в команді Microsoft Security Engineering & Communications (MSEC), де у 2003 році я заснувала команду Security Researcher Community Outreach, а також провела три перші конференції BlueHat. Я приєдналася до команди IE в чудовий час для того, щоб стежити за створенням нової функції, і думаю, що користувачам та дослідникам безпеки може бути цікаво дізнатися подробиці про те, як це відбувається.

У вересні я переїхала в новий кабінет, світило сонечко (навіть у Сіетлі) і Роберт Хансен (Robert Hansen) і Іеремійя Гроссман (Jeremiah Grossman) готувалися представити доповідь на конференції OWASP, що проходила в Нью-Йорку, про новий вид загрози безпеки, який вони назвали ClickJacking. Оскільки через кілька тижнів почали з'являтися деталі, знадобилося проводити їх обговорення. Я стала учасником маси мозкових штурмів з такими експертами з веб-безпеки, як Біллі Ріос (Billy Rios), Брайан Салліван (Bryan Sullivan), Девід Росс (David Ross), Ерік Лоуренс (Eric Lawrence), Спенсер Лоу (Spencer Low), а також членами Microsoft Research, наприклад, Хелен Вонг (Helen Wang). В результаті даних зустрічей стало ясно одне:

Переривають фрейм JavaScript часто представляють як механізм проти ClickJack, але це не найкраще рішення, тому що є способи обдурити переривають фрейми JavaScript. Крім того, переривають фрейми JavaScript ніколи не замислювалися як спосіб пом'якшення ClickJacking. Якщо ви розробляєте якусь технологію не в якості способу запобігання використання уразливості, то є ймовірність, що з цього нічого доброго не вийде.

Опції настройки браузера обмежені. За винятком використання зон безпеки або доповнень для відключення фреймів і скриптів (що серйозно послабить функціональність браузера), користувачі браузера будуть уразливі для даного типу атак.

Тому ми опинилися в ситуації, коли в IE не було способу пом'якшення даної уразливості для кінцевих користувачів, щоб вони могли захистити самі себе і ми знали способи, як запобігти ClickJacking-атаки. "Непереможний" механізм зажадав б внесення надто серйозних змін в код веб-додатки і було б важко змусити ставитися до таких рекомендацій серйозно.

Було саме час задуматися про розробку нового рішення. Девід Росс розробив прототип інструменту, який на 5 секунд відкладав можливість клацнути по посиланню, при цьому виводячи адресу фактичного сайту або домену, за яким клацав користувач. Незважаючи на те, що це забезпечило б користувача захистом, таке рішення серйозно б вплинуло на зручність роботи з браузером. ClickJacking є досить рідкісної атакою, яка є підмножиною набагато більшої проблеми Cross-Site Request Forgery. Якщо сайт не захищає сам себе від CSRF-погроз, то атакуючому немає потреби возиться з ClickJacking. Враховуючи природу загрози, створення механізму захисту, який ускладнив би користувальницький досвід роботи, є неприйнятним варіантом.

У підсумку ми вирішили, що кращим варіантом функції захисту від ClickJacking, який ми могли додати в IE8 під час циклу розробки браузера, це дозволити власникові контенту самостійно вирішувати, повинен Чи його контент перебувати у фреймі чи ні. Це рішення також було запропоновано Майклом Залевська (Michael Zalewski) на форумі WHATWG.

На різноманітних конференціях Ерік і я почали обговорення з дослідниками з безпеки потенційної захисту від ClickJacking і в підсумку отримали даної зворотного зв'язку, що прийняття рішення про нерозміщення контенту в фреймі було достатньо розумним у порівнянні з іншими способами, які призвели б до серйозних проблем сумісності та простоти використання. Але ми все ще хотіли отримати додаткові дані зворотного зв'язку від експертів по мережевій безпеці, тому на початку грудня ми зв'язалися з декількома виробниками браузерів, створюючи відкритий форум з вирішення даної проблеми і пропозиції рішень. Ми поділилися своїми планами, попросили про відгуки і стимулювали інших розробників прийняти таку ж модель в найближчому майбутньому – ми хочемо, щоб були захищені всі користувачі, незалежно від використовуваного браузера.

Тепер, коли вийшов RC1, а, отже, функція захисту від ClickJacking-атак стала публічно доступною, наша робота закінчена. Щоб прийняти необхідні заходи безпеки веб-розробникам необхідно внести зміни в код для активації цього захисту у користувачів. Це означає тренування наших "польових" консультантів і персональних менеджерів. Я буду присутній на TechReady 8, що проходить на цьому тижні, і першим ключовим моментом мого призову до дії буде допомога найбільшим компаніям-розробникам у використанні переваг даної функції. Наступним пунктом буде створення плану міграції, щоб убезпечити застарілі браузери – архітектурні зміни та інвестиції у безпеку, які ми внесли в сучасні браузери, вельми серйозні.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*