У меня есть мобильное приложение (в настоящее время IOS и скоро Android), которое общается с веб-сервисом. Нет логина и данные не являются приватными. В основном, приложение POST устанавливает маркер (lon, lat) и ПОЛУЧАЕТ ближайшие 25 маркеров для отображения на карте.

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

Я медленно прихожу к выводу, что это не может быть безопасно. Лучший ответ - «не делай этого». Не предоставляйте веб-сервис без аутентификации. Не так много услуг настолько открыты. Google You Tube API открыт, но большинство - нет. К сожалению, у меня нет выбора. Так что после нескольких дней рассмотрения это мое мышление. Помните, что я очень далек от эксперта по безопасности и уверен, что мой подход может быть улучшен. Но это может указать вам правильное направление. Надеюсь, кто-то более опытный может вмешаться и исправить / улучшить это. я нашелЭта статья и комментарии особенно полезны.

Message Level Security

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

Client Measures

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

Server Side Security

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

Один msg arg - это время UTC, которое используется для ограничения атак воспроизведения. Это должно препятствовать тому, чтобы злоумышленник неоднократно запускал одно и то же сообщение на сервере.

Сервер выполняет ограничение скорости по IP. Да, IP-адреса легко подделываются, и переключение прокси - это детская игра, но все помогает, когда у вас так мало.

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

Transport Level Security

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

The Gaping Great Big Hole In My Approach

Меня предупреждают, что если приложение станет популярным, кто-то скомпрометирует общий секрет на клиенте. Просто потому, что они могут, и они, вероятно, разместят это в Интернете. Так что на самом деле все сводится к серверной части. К несчастью,I have no way to identify and block an attacker, Это я бы очень любил.

A Final Plea

После нескольких дней исследований это все, что у меня есть. Но я хочу больше. Я был бы особенно признателен за любые идеи по усилению серверной части. Итак, я положил все свои SO баллы в качестве награды. Да, сэр, все 97 баллов!