Что должен знать каждый программист о безопасности? [закрыто]

427

Я студент IT, и сейчас я учусь на третьем курсе университета. До сих пор мы изучали множество предметов, связанных с компьютерами в целом (программирование, алгоритмы, компьютерная архитектура, математика и т. Д.).

Я очень уверен, что никто не может узнать все о безопасности, но уверен, что есть «минимальные» знания, которые должен знать каждый программист или студент IT, и мой вопрос: что это за минимальные знания?

Можете ли вы предложить некоторые электронные книги или курсы, или что-нибудь может помочь начать с этого пути?

security 
— MH
источник
6
Очень похоже на stackoverflow.com/questions/325862/…
— Томас
118
Правило № 1: Никогда не доверяйте вводу пользователя. Даже если это твоя бабушка
— Энтони Форлони
2
... и эта ветка также содержит отличную информацию - stackoverflow.com/questions/72394/…
— Срипати Кришнан,
мой вопрос не только о программистах и ​​их ошибках, но и о студентах, изучающих информатику и информатику
— Мохамад Алхамуд
1
Следите за сообщениями об ошибках. Несмотря на то, что вы хотите быть дружественным к пользователю, разница между «Эта учетная запись не существует» и «Пароль недействителен» может быть опасной в некоторых случаях.
— Майкл Миор

Ответы:

551

Принципы, о которых следует помнить, если вы хотите, чтобы ваши приложения были безопасными:

  • Никогда не доверяйте никаким данным!
  • Подтвердить ввод из всех ненадежных источников - используйте белые, а не черные списки
  • Планируйте безопасность с самого начала - это не то, что вы можете использовать в конце
  • Сохраняйте это простым - сложность увеличивает вероятность дыр в безопасности
  • Держите свою поверхность атаки к минимуму
  • Убедитесь, что вы потерпели неудачу надежно
  • Используйте защиту в глубину
  • Придерживаться принципа наименьших привилегий
  • Использовать моделирование угроз
  • Разделяйте - так ваша система не все или ничего
  • Скрывать секреты сложно, а секреты, спрятанные в коде, не останутся секретными надолго
  • Не пишите свой собственный крипто
  • Использование шифрования не означает, что вы в безопасности (злоумышленники будут искать более слабую ссылку)
  • Знайте о переполнениях буфера и о том, как защититься от них

В Интернете есть несколько отличных книг и статей о защите ваших приложений:

Обучите своих разработчиков лучшим правилам безопасности приложений

Кодовая блокировка (платная)

Инновации в сфере безопасности (платно)

Компас безопасности (платно)

OWASP WebGoat (бесплатно)

— bignum
источник
+1 «Эксплуатация программного обеспечения: как взломать код» - отличная книга, однако показ слайдов, на который вы ссылаетесь, ужасен.
— ладья
7
Однако, к сожалению, практически невозможно реализовать принцип наименьших привилегий в любой современной системе. Например, ядро ​​Linux (источник, который я сейчас использую) содержит более 9,4 миллиона строк кода на C и более 400 тысяч строк сборки, причем все они работают в неограниченном контексте. Простой просчет (возможно, намеренный) в одной из этих миллионов строк скомпрометирует всю систему. Возможно, в следующем столетии или два появится решение, возможно, нет, так как на самом деле никто не заботится о создании безопасных ОС / языков / сред.
— L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳
1
Я бы добавил «Справочник хакера веб-приложений» в этот список.
— изгнан
34
Замените "Никогда не доверяйте вводу пользователя!" «Никогда не верь никаким данным!». Входные данные, поступающие из другого программного обеспечения, должны обрабатываться так же, как и пользовательский ввод - например, при входе в систему на веб-сайте большинство людей не воспринимают поле User-Agent / browser ID как «пользовательский ввод», но оно может так же легко содержать, скажем, SQL-инъекция.
— Петерис
2
@ L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳ Ну, есть экспериментальная ОС Microsoft Research (Singularity), построенная на .NET, которая ставит целью безопасность в качестве основной цели (без переполнения буфера, ура!). Никакого совместного использования памяти процесса, никакой модификации кода, даже драйверы устройств - это просто еще один программно изолированный процесс в .NET. Довольно интересная концепция, но было бы очень трудно довести это до людей (что наиболее важно, она почти не может обеспечить обратную совместимость с существующим программным обеспечением или даже драйверами; немного похоже на первые 10 лет Linux: D).
— Луаан
102

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

Если вы сами не являетесь экспертом по безопасности и / или криптографом, всегда используйте хорошо разработанную, хорошо протестированную и зрелую платформу, платформу или библиотеку безопасности, чтобы выполнить работу за вас. Эти вещи потратили годы на обдумывание, исправление, обновление и проверку как экспертов, так и хакеров. Вы хотите получить эти преимущества, а не отвергать их, пытаясь изобрести велосипед.

Это не значит, что вам не нужно ничего узнавать о безопасности. Вам, безусловно, нужно знать достаточно, чтобы понять, что вы делаете, и убедиться, что вы используете инструменты правильно. Однако, если вы когда-нибудь начнете писать свой собственный алгоритм криптографии, систему аутентификации, дезинфицирующее средство ввода и т. Д., Остановитесь, сделайте шаг назад и запомните правило № 1.

— Тайлер МакГенри
источник
10
Это плохое правило на мой взгляд. По сути, вы можете стать мишенью только из-за выбранной вами платформы, а не из-за реального интереса к вашим активам. Подумайте обо всех дырах в безопасности, обнаруженных на сторонних платформах, и обо всех продуктах, которые мгновенно уязвимы только потому, что они их используют. Я бы не стал так быстро доверять свою безопасность третьей стороне.
— Фоско
9
Я думаю, что это хорошее правило для Crypto - использование собственного шифрования - это путь к катастрофе. Но, как указывает Fosco, прокрутка собственного движка блога может быть более безопасной - если вы свернете свой собственный, вы с меньшей вероятностью попадете в ловушку автоматических атак, с которыми сталкиваются установки WordPress.
— Джеймс П МакГрат
5
Когда дело доходит до крипто, это правило абсолютно правильно. Не пишите свой собственный крипто, точка. Когда дело доходит до использования сторонних платформ, это зависит. Некоторые платформы по своей природе более безопасны, некоторые платформы по своей природе менее безопасны, и большинство платформ, вероятно, предоставляют некоторые функции безопасности, а также некоторые известные векторы атак. Возьмем недавнюю уязвимость Rails, которая вызвала дыру в безопасности на github . Несомненно, Rails предоставляет множество функций безопасности, но также имеет некоторые мощные функции с небезопасными настройками по умолчанию.
— Михаил Копинский
7
Когда дело доходит до крипто, не катите свое собственное - но действительно понимаете, что вы используете. Если вы не понимаете, почему использование одного и того же ключа шифрования для RC4 для двух сообщений является ужасной идеей, прочитайте, например, перед использованием любого потокового шифра.
— Кристофер Кройциг
3
Даже после ошибки HeartBleed очевидно, что это хорошее правило. Представьте, как трудно было бы найти ошибку, похожую на перегрев, в пользовательском или проприетарном проекте. Если вы бросаете свои собственные, вы просто прячетесь за мраком и не будете знать, какие ошибки могут быть использованы.
— Сквики
71

Каждый программист должен знать, как писать код эксплойта.

Не зная, как эксплуатируются системы, вы случайно останавливаете уязвимости. Знать, как исправлять код, абсолютно бессмысленно, если только вы не знаете, как проверять исправления. Безопасность - это не просто мысленные эксперименты, вы должны быть научными и проверять свои эксперименты.

— ладьи
источник
10
Я бы сказал, что в этом нет необходимости. Просто придерживайтесь принципа: если злоумышленник может вызвать повреждение памяти любого рода, считайте себя владельцем. Не нужно вдаваться в детали написания (работы) эксплойтов.
— Newgre
6
@newgre не каждая уязвимость - это переполнение буфера. Система подсчета Common Weakness Enumeration охватывает несколько тысяч уязвимостей. Программист должен понимать разум атакующего, иначе он будет неосознанно совершать ошибки.
— Ладья
1
Я знаю, что не каждый из них является переполнением буфера, но все, что обычно называют «эксплойтом», основано на некотором повреждении памяти: переполнении буфера, двойном освобождении, переполнении кучи, переполнении целых чисел, строках форматирования. и т.д. Конечно, есть и другие вещи, такие как логические ошибки, но это не было темой этого ответа с самого начала.
— Newgre
5
@newgre Это один из типов эксплойтов, но сегодня написано больше эксплойтов для использования недостатков веб-приложений, чем проблем с повреждением памяти. Эксплойты написаны с использованием SQL Injection, Local File include, 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 2010 года - это список наиболее распространенных и критических ошибок программирования, которые могут привести к серьезным уязвимостям программного обеспечения. Их часто легко найти и легко использовать. Они опасны, потому что они часто позволяют злоумышленникам полностью захватить программное обеспечение, украсть данные или вообще запретить работу программного обеспечения.

Список «Топ 25» - это инструмент для просвещения и повышения осведомленности, помогающий программистам предотвращать виды уязвимостей, от которых страдает индустрия программного обеспечения, выявляя и избегая слишком распространенных ошибок, которые возникают еще до того, как программное обеспечение даже поставляется. Клиенты программного обеспечения могут использовать тот же список, чтобы помочь им запросить более безопасное программное обеспечение. Исследователи в области безопасности программного обеспечения могут использовать Top 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 по умолчанию позволяют анализируемому документу читать произвольные файлы в файловой системе. Смешнее :)
— benmmurphy
источник
5

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

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

Я бы добавил следующее:

  • Как работают цифровые подписи и цифровые сертификаты
  • Что такое песочница

Понять, как работают разные векторы атаки:

  • Переполнение буфера / недополнение / и т. Д. В нативном коде
  • Социальный инжиниринг
  • DNS-спуфинг
  • Человек посередине
  • CSRF / XSS и др.
  • SQL-инъекция
  • Крипто-атаки (например: использование слабых алгоритмов шифрования, таких как DES)
  • Ошибки программы / платформы (например: последний недостаток безопасности в github )

Вы можете легко Google для всего этого. Это даст вам хорошую основу. Если вы хотите увидеть уязвимости веб-приложений, есть проект под названием google gruyere, который показывает, как использовать работающее веб-приложение.

— Miguel Ping
источник
4

когда вы создаете какое-либо предприятие или какое-либо собственное программное обеспечение, вы должны просто думать как хакер. поскольку мы знаем, что хакеры также не являются экспертами во всем, но когда они обнаруживают любую уязвимость, они начинают копаться в ней, собирая информацию обо всех и, наконец, атака на наше программное обеспечение. Поэтому для предотвращения таких атак мы должны следовать некоторым хорошо известным правилам, таким как:

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

Вы можете найти больше ресурсов безопасности по следующим ссылкам:

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

— rahul_pratap
источник
3
  1. Почему это важно.
  2. Это все о компромиссах.
  3. Криптография в значительной степени отвлекает от безопасности.
— Ричард
источник
3

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

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

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

— Дэн Эспарза
источник
3

Также не забудьте проверить список 10 лучших OWASP для классификации всех основных векторов атак / уязвимостей.

Об этих вещах интересно читать. Умение думать как злоумышленник научит вас думать о том, как вы пишете свой собственный код.

— Михаил Копинский
источник
2

Соль и хэши пароли ваших пользователей. Никогда не сохраняйте их в виде открытого текста в вашей базе данных.

— Abdull
источник
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.