Браузер-у-браузері зробить сайт набагато безпечнішим

У першу чергу поясню що ця технологія знаходиться на ранній стадії розробки, і я б хотів подискутувати в цьому топіку про її рентабельність і корисність. Тому прототипу ще немає.


Більшість вразливостей у веб-сайтах є результатом зміни HTTP запиту, підміни URL або заголовків, та інші несподівані для сервера дії. Звичайний користувач не повинен мати можливості так робити, але оскільки сучасна програма складається з клієнта і сервера, то в реальності сервер не має контролю над тим як користувач використовує клієнтську частину.

Через це «подвійна валідація» зустрічається повсюдно - на екрані потрібно показувати тільки об'єкти доступні користувачеві, плюс потрібно на сервері перевіряти чи має користувач доступ до цього об'єкта.

Так виникла ідея SecureCanvas - перетворити сайт на подобу АТМ/терміналу, де користувач може тільки друкувати і рухати мишку. Замість спроби перехопити шкідливі запити ми просто переводимо гру в іншу площину і знижуємо поверхню атаки до нуля, дозволяючи користувачеві робити лише те що він і повинен робити - взаємодіяти з сайтом.

Тепер коли користувач хоче завантажити bank.com цей сайт вантажиться у віртуальному і дешевому інстансі webkit у хмарі, а користувачеві повертається сторінка-синхронізатор. Ця сторінка транслює всі кліки і натискання в хмару використовуючи вебсокет, а в хмарі ці дії виконуються вже в реальному браузері. Таким чином відкрити консоль, подивитися запити або вихідний код просто неможливо.

Спочатку ідея була реалізувати це на основі VNC сесії і canvas елементі, так щоб хмарний браузер повертав саме зображення сайту. Але ця ідея приречена на провал - якість картинки сильно погіршується, шрифти змащуються і затримка мережі користувачам сильно не сподобається. Тому більш перспективний підхід це коли хмарний браузер відсилає спеціальні DOM-знімки сторінки і diff-и з попередніми знімками (схожа технологія використовується в React.js для інших цілей).

Таким чином чуйність сайту залишиться на колишньому рівні - перед вами будуть ті ж відчутні і добре промальовані теги, але бекграундом все що ви друкуєте або клікаєте буде передаватися в хмарний браузер і тільки там Javascript логіка буде генерувати запити на реальний сервер bank.com і змінювати зовнішній вигляд сторінки.

Так само буде URL валідатор для захисту від підміни адреси. Можна просто заборонити використовувати свої URL і завантажувати тільки кореневу адресу - таке ідеально підходить онлайн банкам. Можна кожну адресу підписувати HMAC, таким чином тільки ім'я підпису ви зможете завантажити потрібну вам адресу (ви не зможете відкрити/ private_info/2--SIGN не маючи SIGN для цієї адреси, а SIGN видається тільки після натискання на це посилання в інтерфейсі). Або найзручніший варіант - завантажувати лише адреси, які були завантажені раніше (в результаті взаємодії з інтерфейсом).

Єдине від чого SecureCanvas захистити не може - вразливості засновані на інтерфейсі. Якщо атаку можна провести використовуючи лише інтерфейс сайту - ввести'or 1 = 1 в ім'я користувача або провести брутофорс - то цьому сайту не допоможе вже ніщо.

Технологія абсолютно реалізована, залишилося вирішити питання з цільовою аудиторією (в голову приходять онлайн банки та інші фінансові сервіси) та інвестиціями - нам вони дуже потрібні. До речі, якщо ідея здалася маячнею (і я можу вас зрозуміти) то спочатку подивіться на технологію шейп, потім на $66M інвестицій зроблених в них. Так, це нездійсненно. Або те що у них вийде буде марно. Так як без AI неможливо зрозуміти які запити JS може згенерувати а які ні. Завдання до речі у них приблизно схоже - заборонити «не передбачувані» взаємодії з сайтом через тотальну обфускацію відповідей (security through obscurity приречена на провал)

А ось SecureCanvas і реалізуємо (не без складнощів, звичайно), і користь видно неозброєним оком навіть звичайним людям («це як сайт всередині АТМ, під захисним екраном»). Давайте помріємо або посперечаємося:)

logo