Кодування на стороні клієнта: Як запобігти шкідливому використанню?

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

Що стосується мого останнього проекту, я вирішив спробувати рухатися з часом і написати заявку на сторону клієнта.

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

Зазвичай я б свою програму працював на сервері. Я б назвав сторонній API з коду на своєму сервері.

Запуск програми на стороні клієнта означає, що зараз це має відбуватися у веб-переглядачі користувача. Сторонній API надає необхідні файли JavaScript для досягнення цього.

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

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

Я думаю, моє загальне запитання - як ми можемо запобігти зловмисному використанню програми на стороні клієнта?

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

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

Опущення дуже мало допомагає; той тип супротивника, якого ви будете залучати, як тільки все, що стосується віддалених фінансових ресурсів, читає мову складання, як класифіковану рекламу. Шифрування не може допомогти вам, оскільки пристрій, який би захищав ключ, є тим самим пристроєм, про який ви повинні припустити, зламано. Існує багато інших, здавалося б, очевидних контрзаходів, які не спрацьовують з подібних причин.

На жаль, це дуже незручна правда. Світ переповнений операторами малого та великого часу, які думають, що можуть якось подолати фундаментальну ламаність віддаленої довіри, просто тому, що було б так приємно, якби ми могли припустити, що наш код буде працювати так, як ми припускали. І так, це зробило б все набагато простіше, що це навіть не смішно. Але бажаючий цього не зробить, а сподівання проти надії, що ви є одним розумним файлом cookie, яке зможе уникнути неприємності, спалить лише вас та ваших клієнтів. Тому задумайтесь про те, що Інтернет - це ворога територія, включіть у ваші кошториси додаткову вартість, і ви будете добре.

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

Правило тут:

Робіть все на стороні клієнта, що не впливає ні на кого іншого, якщо користувач підробляє його. Зокрема, це означає графічні ефекти.

Виконайте все на стороні сервера, що має бути захищеним, і просто надсилайте події UI від клієнта (наприклад, тоді клієнт просто каже, "користувач натиснув кнопку" Купити ", поки сервер фактично здійснює транзакцію). Зокрема, це означає фінансові операції.

Це саме той випадок, коли зробити його повністю клієнтським додатком не підходить.

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

Ваш середній абзац - серце проблеми:

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

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

Що стосується отриманого .jsфайлу, ви впевнені, що він призначений для браузера? Чи може це бути бібліотека node.js?

Давайте відступимо від цього і подивимось на більш високий рівень .. чи будемо ми .. Чи Eudora чи прогноз (програма для клієнта, яка навіть не потребує браузера) коли-небудь спричинили фінансові збитки для будь-якої компанії? Ні. Будь-хто може писати до API POP / SMTP та бути клієнтом. Але жодних втрат для сервера. Сервер не обмежував дії клієнта, обчислення, зберігання, температуру, розмір диска, розмір диска, монітор DPI, GPU, FPU yada yada клієнта, але точно вказав, на що він би відповів, і не більше. Чи чули ви коли-небудь про те, що прискорене або MS-Money використовували для переходу до банку?

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

1. Ви будуєте свій сервер за допомогою API (який BTW, завжди зводиться до похідних GET POST HEAD тощо).
2. На сервері переконайтесь, що API розмовляє лише з аутентифікованим клієнтом, підтвердженим ідентифікатором, для кожного виклику.
3. Тоді вам байдуже, хто такий клієнт.
4. І тоді вам байдуже, чи це веб-переглядач, встромлений пристрій, скло Google, DOS 3.1 або абсолютно новий Nexus в руках технофоба пра-пра-пра-прадіда, який встиг подорожувати до 2014 року і пропустив усіх технологія, яка заполонила наше життя за останні 15 десятиліть.
5. Тепер ви можете почати завантажувати все інше на сторону клієнта.

SoapBoxBegin

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

SoapBoxEnd

Отже, підсумовуючи. Створіть надійний та жорсткий API сервера. Завантажте все інше на клієнта, виходячи з того, що клієнт може впоратися.

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

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

Я завжди бачив би досвід клієнта JS як доповнення до коду сервера. Перевірка клієнта забезпечує хороший досвід роботи користувачів, але якщо ви не підтвердите, що дані POST також надходять на приймальний сервер, ви відкриваєтесь для атаки. Що-небудь із клієнта слід вважати підозрілим.

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

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

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

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

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

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

Зазвичай я б свою програму працював на сервері. Я б назвав сторонній API з коду на своєму сервері.

Запуск програми на стороні клієнта означає, що зараз це має відбуватися у веб-переглядачі користувача. Сторонній API надає необхідні файли JavaScript для досягнення цього.

Якщо у вас є ключ API, він не призначений для роботи на стороні клієнта. Якщо ви надаєте ключ API на стороні клієнта, будь-хто має доступ до нього, а потім може використовувати його за власним призначенням. Зберігайте його та використовуйте на сервері, коли клієнту це потрібно, а потім надішліть результат за допомогою Ajax / WebSockets.

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