Укрепление кода

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

Вот некоторые укрепляющие код методы:

• Добавьте код, проверяющий вводы для предотвращения целочисленных переполнений.

• Замените любые небезопасные вызовы строковой функции вызовами, которые осведомлены о размере буфера для предотвращения переполнения буфера.

• Избегите передающих данных к интерпретаторам, когда это возможно. Когда использование интерпретаторов неизбежно, данные передачи к интерпретаторам безопасным способом.

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

  Избегите POSIX system функция.

• Установите рыночную стоимость для переменных окружения (PATH, USER, и т.д.), и не принимают решения безопасности на основе их значений.

• Исправьте ошибки та причина условия состязания; они могут привести к неправильному поведению (или хуже).

В конце этой главы Вы найдете ссылку к документу, описывающему эти методы более подробно, вместе с другими укрепляющими код методами.

Подписывание кода

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

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

Принцип наименьшего количества полномочия

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

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

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

• Запросите поднятые полномочия, если не абсолютно необходимо

• Ослабьте полномочия на частях его комплекта приложений

• Сделайте ненужные сетевые соединения

• Прислушайтесь к соединениям на ненужных сетевых портах

• Прислушайтесь к соединениям в интерфейсах сети общего пользования непреднамеренно

• Считайте или запишите файлы в публично перезаписываемых папках, если не направлено сделать так пользователем

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

Игра в песочнице приложения

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

Точно так же в вычислениях, преимущества песочницы не ограничиваются неработающими приложениями. Любое приложение, содержащее дыры в системе безопасности, может «разложиться», если использовано должным образом, потенциально заставив приложение выполнить произвольный код. Таким образом, в вычислениях, песочницы должны быть применены широко — ко всем приложениям, идеально — гарантирующий, что они не могут нанести много ущерба, если они скомпрометированы.

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

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

Разделение полномочия

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

Для реального примера швейцар должен быть в состоянии вынуть мусор. Вспомогательная позиция обычно не требует очистки высокой безопасности. Но предположите, что существует корзина в комнате, заполненной сверхсекретными документами. Поскольку та корзина является якобы ответственностью швейцара, минимальное полномочие для задания довольно широко — швейцару нужна очистка высокой безопасности. Лучшее решение состоит в том, чтобы переместить корзину вне двери. Также сотрудник, у которого уже есть необходимая очистка, мог вынуть корзину в конце дня.

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

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

Разделение полномочия выполняется путем записи помощнику, демону или агенту, цель которого состоит в том, чтобы выполнить работу от имени другой части программного обеспечения. Тот помощник, демон или агент могут поиграться в песочнице, не поиграться в песочнице или привилегированы.

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

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

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

  Привилегированные помощники не могут быть созданы в поигравшей в песочнице среде; однако, они играют основную роль в создании той более применимой среды. Например, привилегированный агент (привилегированный только потому, что это работает вне песочницы) используется OS для предоставления многих услуг поигравшим в песочнице приложениям, таким как блок питания, выводящий на экран “открытый файл” диалоговое окно от имени приложения и затем временно добавляющий выбранный файл к правам песочницы приложения.

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

OS X v10.7 представил XPC Services API для создания поигравших в песочнице вспомогательных приложений, которые являются определенными для отдельного приложения. Эти вспомогательные приложения могут иметь различные полномочия, чем главное приложение. OS X v10.8 и позже также обеспечивает API NSXPC, делающий процесс разделения полномочия еще более прозрачным, позволяя главному приложению удаленно вызвать указанный набор методов на конкретных объектах во вспомогательном приложении и наоборот.

Узнавать больше

Для более подробного концептуального обзора укрепления кода считайте Безопасное Руководство по Кодированию.

Для узнавания больше о Тестовой среде приложения считайте Руководство по проектированию Тестовой среды приложения.

Для получения дополнительной информации о XPC Services и NSXPC, считайте Руководство по программированию Демонов и Служб.

Можно также узнать о другом Apple и сторонних книгах безопасности в Других Ресурсах Безопасности.