6 Ризики безпеки веб-бекенду, які слід враховувати при розробці

Вживайте заходів щодо розвитку, щоб зміцнити та забезпечити безпеку веб-сервера.


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

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

Що таке Backend?

Веб-додаток розділений на дві частини – Frontend та Backend.

  • Фронтальний бік – це клієнт, це частина, з якою користувач взаємодіє. Зазвичай він створений за допомогою HTML, CSS та Javascript.
  • Резервний сервер на стороні сервера. Це в основному, як програма працює, застосовує ділову логіку, зміни та оновлення. Деякі з популярних технологічних стеків на сервері включають PHP, NodeJS, Java, Ruby, C, Python, базу даних, безпеку (автентифікація, контроль доступу тощо), структуру та управління вмістом..

Невелике нагадування перед початком роботи – автентифікація, контроль доступу & управління сеансом

У нас звичайно плутати терміни. Тож давайте уточнимо це швидко:

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

Розглянемо наступне, щоб покращити безпеку веб-безпеки.

Недоліки ін’єкцій

З 2010 року OSWAP класифікує ін’єкцію як найнебезпечніший ризик веб-додатків.

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

uname = request.POST [‘ім’я користувача’]
passwd = request.POST [‘пароль’]
sql = "ВИБРАТИ ідентифікатор від користувачів, де ім’я користувача = ‘" + уніме + "’І пароль =’" + passwd + "’"
database.execute (sql)

Тепер зловмисник може маніпулювати полем пароля за допомогою ін’єкції SQL, наприклад, ввівши пароль “АБО 1 =” 1, що призводить до наступного запиту SQL:

sql = "ВИБІРІТЬ ідентифікатор від користувачів, де ім’я користувача = ” І пароль = ‘пароль’ АБО 1 = ‘1’

Роблячи це, зловмисник може отримати доступ до всіх таблиць користувачів бази даних, при цьому пароль завжди дійсний (1 = ‘1’). Якщо вони увійдуть як адміністратор, вони можуть внести будь-які зміни, які він захоче.

Як запобігти?

Це дуже ЛЕГКО щоб уникнути недоліків ін’єкцій.

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

І ви також повинні зробити наступне.

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

Полювання на Трою отримав блискучий курс на ін’єкцію SQL. Якщо вам цікаво, ви можете це дослідити.

Зламана автентифікація

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

Розбита автентифікація відбувається в основному за трьома моделями:

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

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

Як запобігти?

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

А відповідно до відповіді, ви можете зробити наступне.

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

Порушений контроль доступу

Контроль доступу існує для того, щоб гарантувати те, що дозволено робити користувачеві з аутентифікацією. Автентифікація та управління сеансами – це основа або правила контролю доступу. Але коли ці правила недостатньо встановлені, це може призвести до значних проблем.

Загальні недоліки контролю доступу включають:

  • Неправильна конфігурація CORS, яка дозволяє несанкціонований доступ до API.
  • Маніпулювання метаданими для прямого доступу до методів.
  • Примусовий перегляд: Зловмисник спробує URL-адресу, змінить шляхи (наприклад, http: //website.domain/user/ до http: //website.domain/admin) і навіть може виявити важливі файли.

Як запобігти?

Переважно недоліки доступу виникають через незнання суттєвих вимог ефективного управління доступом.

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

Експозиція даних

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

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

Вплив на бізнес великий з фінансової сторони: середнє порушення може коштувати 3,92 млн. Дол. США IBM.

Як запобігти?

Як розробник програми, ви повинні запитати, яка інформація, яка потребує захисту.

І тоді для запобігання таких недоліків:

  • Шифруйте конфіденційні дані: Для даних на REST зашифруйте все. Для передачі даних обов’язково використовуйте захищені шлюзи (SSL)
  • Визначте дані, які потребують додаткового захисту та обмежте доступ лише до кількох законних користувачів, лише застосувавши шифрування на основі ключів..
  • Уникайте слабкого алгоритму шифрування: використовуйте сучасні та сильні алгоритми.
  • Майте захищений план резервного копіювання.

Небезпечна десеріалізація

Серіалізація та десеріалізація – це поняття, які використовуються при перетворенні даних у об’єктний формат для зберігання або надсилання до іншої програми. Серіалізація складається з перетворення даних у формат об’єкта, як XML або JSON, щоб зробити їх корисними. Десеріалізація – це просто зворотний процес.

Атаки проти десеріалізаторів можуть призвести до відмови в обслуговуванні, контролю доступу та атак на віддалене виконання коду (RCE), якщо є класи, які можна змінити, щоб змінити поведінку.

Другий приклад документа про топ-10 OWASP дає хорошу ілюстрацію серіалізатора об’єктів PHP:

a: 4: {i: 0; i: 132; i: 1; s: 7:"Маллорі"; i: 2; s: 4:"користувач";
i: 3; s: 32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

Це надрукове печиво, що містить інформацію, наприклад, ідентифікатор користувача, рівень користувача та хешований пароль.

Зловмисник може змінити серіалізований об’єкт, щоб отримати доступ до привілеїв адміністратора:

a: 4: {i: 0; i: 1; i: 1; s: 5:"Аліса"; i: 2; s: 5:"адмін";
i: 3; s: 32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

Як запобігти?

Важливо не приймати серіалізовані об’єкти з недовірених джерел.

Вам також слід:

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

Сервер XSS

Сервер XSS (Крос-сайтовий сценарій) – це тип ін’єкції, коли зловмисник використовує веб-додаток для надсилання шкідливого коду різним користувачам. Це відбувається, коли зловмисник розміщує деякі створені дані, що містять шкідливий код, який зберігає додаток. Ця вразливість є серверною; браузер просто надає відповідь.

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

Як запобігти?

Після первинної ідентифікації всіх операцій, які потенційно загрожують XSS і які потрібно захистити, слід врахувати наступне.

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

Висновок

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

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map