Веб-безопасность API

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

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

http://www.codeproject.com/KB/security/SecureStream.aspx

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

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

• Различная гранулярность многопоточности. Cocoa поддерживает все от posix потоков (низкий уровень) до объектно-ориентированной многопоточности с NSLock и NSThread, до высокого уровня parellelism, такой как NSOperation. В зависимости от вашей задачи, использование высокоуровневого инструмента, такого как NSOoperation, проще и позволяет выполнить работу.

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

• openMP. Существуют такие инструменты, как openMP, которые позволяют предоставлять прагматики, описывающие компилятору, что некоторые задачи могут быть безопасно парелеллизированы. Например, итерация набора предметов независимым способом.

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

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

Например, для получения обновлений местоположения GPS необходимо создать экземпляр CLLocationManager, а затем настроить один из классов в качестве его делегата. Ну, на iPhone Simulator можно вместо этого запустить код, который отправляет фальшивые сообщения делегату. Если вы просто вызовете метод делегата так:

[delegate locationManager:nil didUpdateToLocation:newLocation fromLocation:oldLocation];

Ваш код не должен будет знать, что обновление местоположения поддельное. Если вы хотите получить фантазии, вы можете создать новый класс, который реализует все общедоступные методы CLLocityManager, но который отправляет фальшивые сообщения. (Поскольку Objective-C набирается динамически, он не должен быть подклассом, если он отвечает на все отправляемые сообщения.)

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

#if TARGET_IPHONE_SIMULATOR
   locationManager = (id)[[MyFakeLocationManager alloc] init];
#else
   locationManager = [[CLLocationManager alloc] init];
#endif

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

Сигнатуры запросов

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

public static function generateRequestString(array $params, $secretKey)
{
    $params['signature'] = self::generateSignature($params, $secretKey);
    return http_build_query($params,'','&');
}

public static function generateSignature($secretKey, array $params)
{
    $reqString = $secretKey;
    ksort($params);
    foreach($params as $k => $v)
    {
        $reqString .= $k . $v;
    }
    return md5($reqString);
}

Можно создать последовательность запроса запроса API с использованием вышеуказанного кода, просто вызвав метод generateRequestString () с массивом всех параметров, которые вы хотите отправить. Секретный ключ - это то, что предоставляется уникально каждому пользователю API. Как правило, идентификатор пользователя передается на сервер API вместе с подписью, и сервер API использует ваш идентификатор для извлечения секретного ключа из локальной базы данных и проверки запроса таким же образом, как он создан. Предполагая, что ключ и идентификатор пользователя верны, этот пользователь должен быть единственным, кто может сгенерировать правильную подпись. Обратите внимание, что ключ никогда не передается в запросе API.

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

Временные ключи

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

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

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

Сводка

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

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

Для проблемы декомпиляции, вы должны хранить хэш пароля в API, а не оригинальный пароль. См. объяснение здесь: http://phpsec.org/articles/2005/password-hashing.html.