Що повинен знати кожен програміст про безпеку? [зачинено]

427

Я студент ІТ, і зараз я на 3 курсі в університеті. До цих пір ми вивчали багато предметів, пов'язаних із комп'ютерами в цілому (програмування, алгоритми, архітектура комп’ютера, математика тощо).

Я дуже впевнений, що ніхто не може дізнатись про все, що стосується безпеки, але впевнений, що існує кожен "мінімум" знань, який повинен знати про це кожен програміст чи студент ІТ, і моє запитання - що це мінімум знань?

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

security 
— MH
джерело
6
Досить схожий на stackoverflow.com/questions/325862/…
— Томас
118
Правило №1: ніколи не довіряйте вкладенню користувача Навіть якщо це ваша бабуся
— Ентоні Форлоні
2
..и цей потік також має велику інформацію - stackoverflow.com/questions/72394 / ...
— Sripathi Крішнан
моє запитання не лише про програмістів та їх помилки, а також про студентів ІТ та інформатики
— Мохамад Алхамуд
1
Перегляньте свої повідомлення про помилки. Хоча ви хочете бути зручними для користувачів, різниця між "Цей обліковий запис не існує" та "Пароль недійсний" може бути небезпечним у деяких випадках.
— Майкл Міор

Відповіді:

551

Принципи, які потрібно пам’ятати, якщо ви хочете, щоб ваші програми були захищеними:

  • Ніколи не довіряйте жодному входу!
  • Перевірте введення даних з усіх недовірених джерел - використовуйте білі списки, а не чорні списки
  • Плануйте безпеку з самого початку - це не те, на що ви можете вступити в кінці
  • Нехай це буде просто - складність збільшує ймовірність прорізів у безпеці
  • Зведіть атакуючу поверхню до мінімуму
  • Переконайтеся, що ви провалилися безпечно
  • Використовуйте оборону в глибині
  • Дотримуйтесь принципу найменшої пільги
  • Використовуйте моделювання загроз
  • Compartmentalize - значить, у вашій системі не все або нічого
  • Сховати секрети важко - і секрети, приховані в коді, довго не залишаться таємницями
  • Не пишіть власну криптовалюту
  • Використання криптовалюти не означає, що ви захищені (зловмисники шукатимуть слабкіше посилання)
  • Будьте в курсі переповнення буфера та способів захисту від них

Є кілька чудових книг та статей в Інтернеті про безпеку ваших програм:

Навчіть своїх розробників щодо найкращих рекомендацій щодо безпеки додатків

Проведення коду (платне)

Інновації в безпеці (оплачується)

Компас безпеки (оплачується)

OWASP WebGoat (безкоштовно)

— бінгу
джерело
+1 "використання програмного забезпечення: як зламати код" - це чудова книга, однак те, що слайд-шоу, з яким ти пов’язаний, жахливе.
— грак
7
Однак, на жаль, практично неможливо уявити принцип найменшої пільги в будь-якій сучасній системі. Наприклад, ядро ​​Linux (джерело, яке я зараз використовую) містить понад 9,4 мільйона рядків коду С та понад 400 К рядків складання, які працюють у необмеженому контексті. Простий прорахунок (можливо навмисний) в одному з цих мільйонів рядків поставить під загрозу всю систему. Можливо, через найближче століття-два з'явиться рішення, можливо, ні, оскільки ніхто насправді не піклується про створення захищеної ОС / мов / фреймворків.
— L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳
1
До цього списку я додам "Посібник з хакера веб-додатків".
— викарбувався
34
Замініть "Ніколи не довіряйте вводу користувача!" до "Ніколи не довіряйте жодному входу!". До матеріалів, що надходять з іншого програмного забезпечення, слід поводитись так само, як і з введенням користувачів, наприклад, при реєстрації веб-сайтів більшість людей не вважає поле User-Agent / браузера ідентифікатором як "введення користувача", але воно може так само легко містити, скажімо, a Введення SQL
— Петріс
2
@ L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳ Що ж, є те, що експериментальна ОС Microsoft Research (сингулярність) побудована на .NET, яка орієнтована на безпеку як основну мету (немає переповнення буфера, так!). Ніякий обмін пам’яттю процесів, ніяка самомодифікація коду, навіть драйвери пристроїв - це лише інший процес, ізольований від програмного забезпечення в .NET. Дуже цікава концепція, але було б дуже важко підштовхнути це до людей (головне, це майже не може зробити зворотну сумісність з існуючим програмним забезпеченням або навіть драйверами; дещо, як перші 10 років Linux: D).
— Луань
102

Правило №1 безпеки для програмістів: не котуйтесь самостійно

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

Тепер це не означає, що вам нічого не потрібно дізнаватися про безпеку. Вам, звичайно, потрібно знати достатньо, щоб зрозуміти, що ви робите, і переконатися, що ви правильно користуєтеся інструментами. Однак, якщо ви коли-небудь опинитесь, щоб почати писати власний алгоритм криптографії, систему аутентифікації, дезінфікуючу систему тощо, зупиніться, зробіть крок назад і запам’ятайте правило №1.

— Тайлер Макенрі
джерело
10
На мою думку, це неправильне правило. По суті, ви можете бути націленими лише через обрану вами платформу, а не будь-який реальний інтерес до ваших активів. Подумайте про всі дірки в безпеці, які знаходяться на сторонніх платформах, і всі продукти, які враз вразливі лише тому, що вони її використовують. Я не був би таким швидким, щоб довірити свою безпеку третій стороні.
— Фоско
9
Я думаю, що це хороше правило для Crypto - прокат власного шифрування є рецептом катастрофи. Але прокрутка власного блогу може бути більш безпечною, як зазначає Фоско - якщо ви скачуєте свою власну, ви, швидше за все, потрапите в автоматизовані атаки, з якими доводиться стикатися з встановленням Wordpress.
— Джеймс П МакГрат
5
Що стосується криптовалюти, це правило абсолютно правильне. Не пишіть власну криптовалюту, період. Що стосується використання сторонніх платформ, це залежить. Деякі платформи за своєю суттю більш безпечні, деякі платформи за своєю суттю менш безпечні, і більшість платформ, ймовірно, надають деякі функції безпеки, але також відомі вектори атаки. Скористайтеся нещодавньою вразливістю Rails, яка спричинила загрозу безпеки в github . Безперечно, Rails надає безліч функцій безпеки, але також має деякі потужні функції із небезпечними типовими налаштуваннями.
— Михайло Копінський
7
Що стосується криптовалюти, не котиться сама - але розумій те, що ти використовуєш. Якщо ви не розумієте, чому використання одного і того ж ключа шифрування для RC4 для двох повідомлень є жахливою ідеєю, прочитайте, перш ніж використовувати будь-який шифр потоку, наприклад.
— Крістофер Крейціг
3
Навіть після помилки HeartBleed очевидно, що це хороше правило. Уявіть, як важко було б знайти помилку, схожу на гарячу воду, у власному або власному проекті. Якщо ви скачуєте свою власну, ви просто ховаєтесь за незрозумілістю і не знатимете, які помилки можуть бути використані.
— Sqeaky
71

Кожен програміст повинен знати, як написати код експлуатації.

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

— грак
джерело
10
Я б стверджував, що це взагалі не потрібно. Просто дотримуйтесь принципу: якщо зловмисник може спричинити пошкодження пам’яті будь-якого типу, вважайте себе належним. Не потрібно вникати в подробиці фактично письмових (робочих) подвигів.
— newgre
6
@newgre не кожна вразливість є переповненням буфера. Є кілька тисяч уразливостей, охоплених системою загального підрахунку слабкості. Програмісту потрібно зрозуміти розум зловмисника, або він буде невідомо робити помилки.
— грак
1
Я знаю, що не кожен з них є переповненням буфера, але все, що зазвичай називають "експлуатуванням", ґрунтується на якомусь пошкодженні пам'яті: переповнення буфера, подвійне звільнення, переповнення купи, переповнення, пов'язані з цілими числами, рядки формату і т. д. Звичайно, є й інші речі, такі як помилки логіки, але це не було темою цієї відповіді.
— newgre
5
@newgre Це один з видів експлуатації, але сьогодні написано більше подвигів для усунення недоліків веб-додатків, ніж проблем з корупцією пам’яті. Подвиги пишуться за допомогою використання SQL Injection, локального файлу, CSRF та XSS, це загальні проблеми. (Джерело: exploit-db.com )
— грак
1
Я згоден на це, якщо ти сам можеш писати подвиги, ти можеш зрозуміти, що може піти на хакера на максимум!
— linuxeasy
42

Безпека - це процес, а не продукт.

Багато хто, здається, забувають про цей очевидний факт.

— ericteubert
джерело
23

Я пропоную переглянути CWE / SANS TOP 25 найнебезпечніших помилок програмування . Він був оновлений на 2010 рік, обіцяючи регулярні оновлення в майбутньому. Доступна також версія 2009 року .

З http://cwe.mitre.org/top25/index.html

Топ-25 найнебезпечніших помилок програмування CWE / SANS - це список найпоширеніших і найважливіших помилок програмування, які можуть призвести до серйозних вразливих програм. Їх часто легко знайти та легко експлуатувати. Вони небезпечні тим, що часто дозволяють зловмисникам повністю переймати програмне забезпечення, красти дані або взагалі не дозволяти програмному забезпеченню працювати.

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

— jschmier
джерело
1
Зауважте, що перші 4 помилки у цьому списку (та ще й ряд інших) - все ті самі помилки - довірчі дані.
— Кріс Додд
13

Хорошим початковим курсом може стати курс MIT з комп'ютерних мереж та безпеки . Я б запропонував одне - не забувати про конфіденційність. Конфіденційність, в деяких сенсах, є дійсно основоположним для безпеки і не часто охоплюється технічними курсами з безпеки. Ви можете знайти деякі матеріали про конфіденційність у цьому курсі з етики та закону, оскільки він стосується Інтернету.

— об. Тванфоссон
джерело
Посилання на курс MIT не працює
— AntonioCS
1
Посилання виправлені (поки що). Дякую.
— tvanfosson
8

Важливість безпечних параметрів за замовчуванням у рамках та API:

  • Багато ранніх веб-фреймів не вимкнули html за замовчуванням у шаблонах, і через це виникли проблеми з XSS
  • Багато ранніх веб-фреймворків спростили об'єднання SQL, ніж створювати параметризовані запити, що призводять до безлічі помилок введення SQL.
  • Деякі версії Erlang (R13B, можливо, інші) не перевіряють сертифікати однорангових ssl сертифікатів за замовчуванням, і, ймовірно, існує безліч коду erlang, сприйнятливого до атак SSL MITM
  • Трансформатор XSLT Java за замовчуванням дозволяє виконувати довільний java-код. Було створено багато серйозних помилок безпеки.
  • API розбору XML Java за замовчуванням дозволяють розібраному документу читати довільні файли у файловій системі. Більше веселощів :)
— бенмурфія
джерело
5

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

— рападура
джерело
1
Не всі авторизації вимагають автентифікації. "Від ABAC до ZBAC" протиставляє контроль доступу NBAC (на основі автентифікації) рішенням, які не потребують аутентифікації. "IBAC, RBAC, ABAC і навіть CBAC - Контроль доступу, заснований на претензіях, усі покладаються на автентифікацію ... Для простоти цей документ розглядає їх як єдине рішення і ігнорує ті версії, які реалізували аспекти архітектури ZBAC. Вони спільно називаються аутентифікацією Базований контроль доступу (NBAC). "
— Майк Самуель
4
  • Пам'ятайте, що ви (програміст) повинні закріпити всі частини, але зловмиснику потрібно лише досягти одного удару у вашому броні.
  • Безпека - приклад "невідомих невідомих". Іноді ви не знаєте, які можливі вади безпеки (до цього часу).
  • Різниця між помилкою та захисним отвором залежить від інтелекту зловмисника.
— Рорі
джерело
4

Я додам наступне:

  • Як працюють цифрові підписи та цифрові сертифікати
  • Що таке пісочниця

Зрозумійте, як працюють різні вектори атаки:

  • Переповнення буфера / підтоки / тощо на рідний код
  • Соціальний інженер
  • DNS підробка
  • Людина в середині
  • CSRF / XSS та ін
  • Введення SQL
  • Крипто-атаки (наприклад: використання слабких крипто алгоритмів, таких як DES)
  • Помилки програми / рамки (наприклад, останній недолік безпеки в github )

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

— Мігель Пінг
джерело
4

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

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

ви можете знайти більше ресурсу безпеки за наступними посиланнями:

для отримання додаткової інформації google про потоки безпеки постачальника програми.

— rahul_pratap
джерело
3
  1. Чому важливо.
  2. Мова йде про компроміси.
  3. Криптографія багато в чому відволікає від безпеки.
— Річард
джерело
3

Для отримання загальної інформації про безпеку, я настійно рекомендую прочитати Брюса Шнайєра . У нього є веб-сайт, його криптовалютний бюлетень , кілька книг та зроблено багато інтерв'ю .

Я також ознайомився б із соціальною інженерією (та Кевіном Мітником ).

Для гарної (і дуже цікавої) книги про те, як працює безпека в реальному світі, я б порекомендував чудову (хоча і трохи датувану) «Яйце зозулі» Кліффа Столла.

— Дан Еспарца
джерело
3

Також не забудьте ознайомитись із списком «Топ-10» OWASP для категоризації всіх основних векторів / вразливостей атаки.

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

— Михайло Копінський
джерело
2

Соліть і хешуйте паролі користувачів. Ніколи не зберігайте їх у простому тексті у вашій базі даних.

— Абдул
джерело
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.