Наскільки легко зламати JavaScript (у браузері)?

Моє запитання стосується безпеки JavaScript.

Уявіть систему аутентифікації, де ви використовуєте рамку JavaScript, як Backbone або AngularJS , і вам потрібні захищені кінцеві точки. Це не проблема, оскільки сервер завжди має останнє слово і перевірить, чи маєте ви право робити те, що хочете.

Але що робити, якщо вам потрібно трохи безпеки, не залучаючи сервер? Це можливо?

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

Наскільки легко користувачеві змінити цю змінну та отримати доступ?

Мої знання про безпеку (та JavaScript) не великі. Але якщо змінна не знаходиться в глобальному масштабі і знаходиться в приватній частині шаблону модуля, в якому є лише геттери, але не сеттери, навіть у такому випадку ви можете зламати річ?

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

Безпечна схема зв'язку клієнт-сервер без необхідності автентифікації з сервером вручну на кожен запит:

Ви все ще даєте останньому слову сервер, і сервер все ще повинен перевірити все, що говорить клієнт, але це відбувається прозоро.

Припустимо протокол HTTPS для запобігання нападів "людина-посеред" (MITMA).

• Клієнт вперше вручається з сервером, а сервер генерує для клієнта відкритий ключ і зберігає приватний, використовуючи асиметричну схему шифрування. Клієнт зберігає "відкритий" ключ сервера у локальній пам’яті, зашифрований захищеним паролем, який ви ніде не зберігаєте.

• Клієнт зараз офлайн. Клієнт хоче виконати довірені дії. Клієнт вводить свій пароль і хапає відкритий ключ сервера.

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

• Коли клієнт в Інтернеті, клієнт надсилає свій ідентифікатор клієнта, а всі дії, які виконує клієнт, надсилаються на сервер, зашифрований відкритим ключем сервера.

• Сервер розшифровує дії, і якщо вони мають правильний формат, він вважає, що вони виникли у клієнта.

Примітка:

• Ви не можете зберігати пароль клієнта ніде, інакше зловмисник зможе отримати ключ і підписати дії як власні. Захищеність цієї схеми покладається виключно на цілісність ключа, який сервер створює для клієнта. Клієнту все-таки потрібно буде аутентифікуватись із сервером, коли він запитує цей ключ.

• Ви все ще фактично покладаєтесь на сервер для безпеки, а не клієнта. Кожну дію, яку виконує клієнт, ви повинні підтвердити на сервері.

• Можливо запуск зовнішніх скриптів у веб-працівників . Майте на увазі, що кожен ваш запит JSONP - це набагато більша проблема безпеки. Вам потрібно захистити ключ за будь-яку ціну. Після того як ви його втратите, зловмисник може представити себе за себе.

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

• Відповідь Йоахіма досі правильна . Ви все ще фактично виконуєте всю автентифікацію на сервері . Єдине, що ви зберегли тут, - це необхідність перевірки паролів із сервером кожного разу. Тепер вам потрібно залучати сервер лише тоді, коли ви хочете виконати або витягнути оновлені дані. Все, що ми тут зробили, - це зберегти надійний ключ на стороні клієнта і змусити клієнта повторно його підтвердити.

• Це досить поширена схема для програм на одній сторінці (наприклад, для AngularJS).

• Я називаю відкритий ключ сервера "загальнодоступним" через те, що це означає в таких схемах, як RSA , але він насправді є конфіденційною інформацією в схемі і повинен бути захищеним.

• Я б ніде не зберігав пароль у пам’яті. Я б змусив користувача вводити свій "офлайн" пароль кожен раз, коли він / вона починає працювати в автономному коді.

• Не котуйте власну криптографію - використовуйте відому бібліотеку на зразок Стенфорда для аутентифікації.

• Прийміть цю пораду як є . Перш ніж розпочати цю аутентифікацію в реальному світовому бізнесі, зверніться до експерта з питань безпеки . Це серйозне питання, яке боляче і легко помилитися.

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

Використовуйте a promptі ні поле, вбудований пароль, якщо ви не впевнені в собі і не відкладаєте його виконання (тобто воно не повинно жити до того моменту, коли події мають доступ до нього, але лише в коді синхронізації). І фактично не зберігайте пароль у змінній - знову ж таки, це працює лише в тому випадку, якщо ви довіряєте, що комп'ютер користувача не порушений (хоча це все справедливо і для перевірки на сервері).

Я хочу ще раз додати, що ми все ще не довіряємо клієнту . Ви не можете довіряти клієнту самотужки, і я думаю, що відповідь Йоахіма це відчуває. Ми лише отримали зручність не потребувати пінг-сервера перед початком роботи.

Схожі матеріали:

• Сертифікати проти імені користувача + пароль .
• Чому ми не можемо забезпечити безпеку через сторону клієнта?
• Не котуйте власну криптовалюту.
• Пов’язана дискусія про те, як зробити JS захищеним для криптовалют

Це просто: будь-який механізм захисту, який покладається на клієнта, щоб він робив лише те, що ви йому сказали, може бути порушений, коли зловмисник має контроль над клієнтом.

Ви можете проводити перевірку безпеки клієнта, але лише для того, щоб ефективно діяти як "кеш" (щоб уникнути дорогого зворотного шляху до сервера, якщо клієнт вже знає, що відповідь буде "ні").

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

Як бачите, ця відповідь насправді не згадує жодної специфіки JavaScript / браузера. Це тому, що ця концепція однакова, незалежно від того, який ваш клієнт. Це не дуже важливо, що це товстий клієнт (традиційний додаток для клієнтів / серверів), веб-додаток для старої школи або односторінковий додаток з широким JavaScript на стороні клієнта.

Після того, як ваші дані залишають сервер, ви повинні припустити, що зловмисник має повний доступ до нього.

У ігровій спільноті є приказка: « Клієнт перебуває в руках ворога". Будь-який код, який працює за межами захищеної області, як-от сервер, є вразливим. У самому базовому сценарії, вразливий, щоб не запускатись в першу чергу. Це рішення клієнта фактично запустити ваш" код безпеки ", і користувач може просто "відмовтеся". У той час як з нативним кодом у вас є принаймні автоматична обтурація на збірку та додатковий рівень захисту через те, що зловмиснику потрібно бути хорошим програмістом, щоб маніпулювати цим, JS звичайно є безперешкодним і як звичайний текст. Все, що потрібно для того, щоб здійснити атаку, - це примітивні інструменти, такі як проксі-сервер та текстовий редактор. Зловмиснику все одно знадобиться певний рівень освіти щодо програмування, але змінити сценарій за допомогою будь-якого texteditor простіше, ніж ввести код у виконуваний файл.

Це не питання злому JavaScript. Якби я хотів атакувати ваш додаток, я використовував би приватний проксі-сервер, який би дозволив мені фіксувати, змінювати та відтворювати трафік. Ваша запропонована схема безпеки не захищає від цього.

Якщо говорити конкретно про Angular:

Захист сторони клієнта маршруту просто не існує. Навіть якщо ви "ховаєте" кнопку на цьому маршруті, користувач завжди може її ввести, Angular поскаржиться, але клієнт може кодувати це.

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

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

Побічна примітка: ніколи не повинно бути нічого вразливого, вбудованого в шаблони перегляду, які запитують Angular, просто не робіть цього. Якщо з якихось божевільних причин є, вам потрібно захистити шаблони перегляду на стороні сервера так само, як це було б, якщо ви робили рендеринг на стороні сервера.