Что нужно знать о безопасности при написании легкого сетевого протокола передачи файлов - PullRequest
1 голос
/ 22 августа 2009

У меня есть настольное приложение, которое будет синхронизироваться с приложением iPhone. Синхронизация на самом деле является простой копией файла - приложение для iPhone является средством просмотра, поэтому мне не приходится сталкиваться со сложностями фактической синхронизации данных в двух направлениях.

Я написал свой собственный протокол, поскольку мне нужно, чтобы он был легковесным, и я отправляю файлы, которые могут быть больше, чем объем ОЗУ, доступный на устройстве - поэтому файлы передаются прямо из сети на диск.

Файлы состоят из одного файла «данных» (база данных SQLite) и нулевого или более ресурсов, которые представляют собой изображения, PDF-файлы и т. Д. После того, как соединение было принято, клиент и сервер обмениваются данными частями, которые начинаются с следующая структура:

struct ChunkHeader {
    UInt32 headerLength;
    UInt32 totalChunkLength;
    UInt32 chunkType;
    UInt32 chunkNameLength;
    UInt32 chunkDataLength;
} __attribute__ ((packed));

После структуры следует строка имени файла UTF-8, за которой сразу же следуют данные для этого файла. Структура заголовка содержит длину строки имени файла (chunkNameLength) и длину двоичных данных (chunkDataLength). chunkType содержит «тип» чанка, поэтому клиент знает, что делать с данными, и может иметь одно из следующих значений:

typedef enum {
    kChunkTypePreSyncInfoDictionary = 0,
    kChunkTypeDataFile = 1,
    kChunkTypeResource = 2,
    kChunkTypeEndOfData = 3,
    kChunkTypeSyncCancelled = 4
} ChunkType;

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

Итак, какие шаги я должен предпринять, чтобы обеспечить адекватную безопасность данных 1017 *? Я работаю в Objective-C, но я не ищу ответы для конкретного языка, а просто концепции. Вещи, о которых я беспокоюсь:

  • Должен ли я принять меры для предотвращения подмены данных?
  • Должен ли я предпринять шаги для фактического шифрования данных?
  • Должен ли я принять меры, чтобы другое приложение не претендовало на роль моего приложения, и заменить клиент или сервер чем-то другим?
  • Должен ли я предпринять шаги для проверки полученных данных на предмет повреждения?

1 Ответ

2 голосов
/ 22 августа 2009

«Должен ли я предпринять шаги, чтобы проверить полученные данные на предмет чего-то, что вызывает повреждение?»

Всегда. Безоговорочно. Без исключения.

По другим вопросам:

  • Должен ли я принять меры для предотвращения подмены данных?

  • Должен ли я принять меры для фактического шифрования данных? (Слежка)

  • Должен ли я предпринять шаги, чтобы убедиться, что другое приложение не претендует на роль моего приложения, и заменить клиент или сервер чем-то другим? (снова обманывает)

Вы сказали, что «копируемые данные не содержат конфиденциальной информации», поэтому отслеживание, похоже, не является сценарием угрозы, который вас волнует.

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

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

Идея состоит в том, чтобы иметь «достаточно» информации для клиента и сервера, чтобы знать, что другая сторона заслуживает доверия. Некоторые люди довольны известным URL. Другие люди хотят какой-то «общий секрет» (например, пароль). Некоторым людям нужно еще больше, и они включают многочисленные подробности в протокол. Некоторые люди включают в протокол алгоритмические детали (например, HTTP Digest Authentication требует от клиента небольшого алгоритмического танца с данными, предоставленными сервером.)

...