Основи безпеки веб-додатків

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

05 січня 2017 року

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

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

Зміст

• Довіра
• Відхилити несподіване введення форми
  • Недовірене введення
  • Перевірка вводу
  • На практиці
  • Коротко
• Кодування виводу HTML
  • Вихідні ризики
  • Вихідне кодування
  • Застереження та застереження
  • Коротко
• Параметри прив'язки для запитів до бази даних
  • Маленькі столи Боббі
  • Прив’язка параметрів до порятунку
  • Чистий та безпечний код
  • Поширені помилки
  • Функції прив'язки параметрів
  • Коротко
• Захист даних під час транзиту
  • HTTPS та безпека транспортного рівня
  • Отримайте сертифікат сервера
  • Налаштуйте свій сервер
  • Використовуйте HTTPS для всього
  • Використовуйте HSTS
  • Захистіть файли cookie
  • Інші ризики
  • Перевірте свою конфігурацію
  • Коротко
• Хешуйте і соліть паролі своїх користувачів
  • Жити небезпечно
    • Ризики
  • Я можу хешувати парольz
  • Тире солі
  • Використовуйте хеш, який вартий його солі
  • Ще раз із хешированием
  • Остаточні поради
  • Коротко
• Безпечна автентифікація користувачів
  • Зрозумійте свої варіанти
  • Переатестуйте для важливих дій
  • Приховати, чи існують користувачі
  • Запобігання атакам грубої сили
  • Не використовуйте облікові дані за замовчуванням або з жорстким кодом
  • У рамках
  • Коротко
• Захист сеансів користувачів
  • Створіть ідентифікатори безпечної сесії
  • Не виставляйте ідентифікатори сеансів
  • Захистіть свої файли cookie
  • Управління життєвим циклом сеансу
  • Перевірте це
  • У рамках
  • Коротко
• Авторизуйте дії
  • Авторизуйтесь на сервері
  • Заборонити за замовчуванням
  • Авторизуйте дії над ресурсами
  • Використовуйте політику для авторизації поведінки
    • Впровадження RBAC
    • Впровадження ABAC
  • Інші способи моделювання політики
  • Міркування щодо впровадження
  • Коротко

Бічні панелі

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

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

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

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

---