Используя сети надежно

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

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

Некоторые атаки, с которыми могла бы встретиться Ваша программа, включают:

Эта глава объясняет, как защитить от отслеживания и атак «человек посередине». Для узнавания больше об инжекционных атаках переполнение буфера и другие аспекты безопасности программного обеспечения, читают Безопасное Руководство по Кодированию.

Включение TLS или SSL

Протокол Transport Layer Security (TLS) обеспечивает шифрование данных для основанной на сокете коммуникации, вместе с аутентификацией серверов и (дополнительно) клиентов для предотвращения спуфинга.

OS X и iOS также предоставляют поддержку для протокола Уровня защищенных сокетов (SSL). Поскольку TLS является преемником SSL, OS X и iOS используют TLS по умолчанию, если поддерживаются оба протокола.

Соединение надежно с URL

Соединение с URL через TLS тривиально. Когда Вы создаете NSURLRequest объект обеспечить для initWithRequest:delegate: метод, указать https как схема URL вместо http. Соединение использует TLS автоматически без дополнительной конфигурации.

Соединение надежно Используя потоки

Можно использовать TLS с NSStream объект путем вызова setProperty:forKey: на нем. Указать NSStreamSocketSecurityLevelNegotiatedSSL как параметр свойства и NSStreamSocketSecurityLevelKey как основной параметр. Если необходимо работать вокруг ошибок совместимости, можно также указать более определенный протокол, такой как NSStreamSocketSecurityLevelTLSv1.

Соединение надежно Используя сокеты BSD

При создании безопасных соединений, если это возможно, необходимо использовать NSStream (как описано в предыдущем разделе) вместо того, чтобы использовать сокеты непосредственно. Однако, если необходимо работать с сокетами BSD непосредственно, необходимо выполнить SSL или шифрование TLS и дешифрование сами. В зависимости от Вашей платформы существует два способа сделать это:

  • В OS X, или в iOS 5 и позже, можно использовать Безопасный Транспортный API в Концепции безопасности для обработки SSL и квитирования TLS, шифрования и дешифрования. Посмотрите Безопасную Транспортную Ссылку для подробных данных.

  • В iOS и OS X, можно загрузить SSL с открытым исходным кодом или реализацию TLS, такую как OpenSSL и включать скомпилированную копию той библиотеки (или некоторая часть этого) в комплекте приложений (или рядом с несвязанной программой). Обязательно соответствуйте условиям лицензирования любых сторонних библиотек, которыми Вы могли бы пользоваться.

Используя другие протоколы системы защиты в OS X

В дополнение к Безопасной Транспортной реализации по умолчанию TLS следующие протоколы сетевой безопасности доступны в OS X:

Частые ошибки

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

Будьте осторожны, кому Вы доверяете

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

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

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

Будьте осторожны, каким данным Вы доверяете

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

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

Для получения дополнительной информации читайте Ввод Проверки и Межпроцессное взаимодействие в Безопасном Руководстве по Кодированию.

Знайте, что много крошечных утечек могут составить в целом лавинную рассылку

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

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

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

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

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

Сертификаты установки правильно

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

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

Для наблюдения, что фактически отсылает сервер введите следующую команду в Терминале (замена www.example.com с Вашим фактическим доменным именем), и нажимают Return:

openssl s_client -showcerts -connect www.example.com:443

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

Никогда не отключайте проверку цепочки сертификата (если Вы не проверяете их сами),

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

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

Если Вы работаете с самоподписанными сертификатами временно, необходимо добавить их к доверяемому списку привязок машин теста. В OS X можно сделать это использование утилиты Keychain Access. В iOS можно использовать SecTrustCopyAnchorCertificates, SecTrustCreateWithCertificates, и SecTrustSetAnchorCertificates функции в Вашей программе.

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