Веб-сервис для загрузки данных: соображения безопасности - PullRequest
3 голосов
/ 03 мая 2010

Я не уверен, какой метод аутентификации я должен использовать для своего веб-сервиса. Я искал на SO, и не нашел ничего, что мне помогло.

Предварительное

Я создаю приложение, которое загружает данные из локальной базы данных на сервер (работает мой веб-сервис), где все записи объединяются и хранятся в центральной базе данных. В настоящее время я выполняю двоичную сериализацию DataTable, которая содержит небольшой фрагмент локальной базы данных, где все неинтересные вещи уже отфильтрованы. byte[] (сериализованный DataTable) вместе с идентификатором пользователя и хэшем пароля пользователя затем загружается в веб-сервис через SOAP. Приложение вместе с веб-сервисом уже работает точно так же, как и предполагалось.

Проблема

Проблема, над которой я сейчас думаю, заключается в следующем: что, если кто-то просто прослушивает сетевой трафик, «крадет» идентификатор пользователя и хеш-пароль, чтобы отправить свое собственное сообщение SOAP с измененными данными, которые повреждают мою базу данных?

Небольшое обновление: Не поймите неправильно: я не беспокоюсь о синтаксической проблеме / проблеме проверки. Все данные, поступающие в веб-сервис, конечно же, проверены, и я интенсивно их тестировал. Я имел в виду «злоумышленники могут семантически повредить базу данных»: например, Пользователь может редактировать только свои представленные записи. Злоумышленник может воспользоваться этим фактом, выдать себя за какого-то пользователя и отредактировать свои загруженные данные.

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

Опции

Подходы к решению этой проблемы, о которых я уже думал:

  • Использование ssl + сертификатов для установления соединения:
    • Я действительно не хочу использовать ssl, я бы предпочел более простое решение. В конце концов, каждая информация, которая передается на веб-сервис, может быть видна на сайте позже. То, что я хочу сказать: нет секретной / финансовой / бизнес-критической информации, которая должна быть скрыта. Я думаю, что SSL будет своего рода излишним для этой задачи.
  • Шифрование byte[]:
    • Я думаю, что это снизит производительность, учитывая, что целью упражнения было просто аутентифицировать пользователя.
  • Хеширование пароля пользователя вместе с данными:
    • Мне нравится идея: создать контрольную сумму из данных, объединить эту контрольную сумму с хэшем пароля и снова хэшировать все это. Это гарантировало бы, что данные были отправлены этим конкретным пользователем, и данные не были изменены.

Актуальный вопрос (ы)

Итак, что, по вашему мнению, является наилучшим подходом с точки зрения удовлетворения следующих требований?

  • Довольно простое решение (поскольку оно не должно быть сверхбезопасным; секретная / важная для бизнеса информация не передается)
  • Легко реализуемо ретроспективно (не хочу писать все это снова :))
  • Не сильно влияет на производительность

Что вы думаете о моем предпочтительном решении, последнем в списке выше?

Есть ли альтернативное решение, которое я не упомянул, которое подойдет лучше?

Я ни о чем не беспокоюсь? Достаточно ли просто отправить идентификатор пользователя и хэш пароля с каждым сообщением SOAP?

Вам не нужно подробно отвечать на каждый вопрос. Просто подтолкни меня в правильном направлении. Я очень ценю каждое обоснованное мнение.

Заранее спасибо!

1 Ответ

2 голосов
/ 03 мая 2010

Вы абсолютно должны использовать HTTPS. SSL - безусловно, самая простая и надежная система, которую вы можете реализовать, и она стоит всего 30 долларов в год. Не изобретай велосипед! В конце концов, сколько действительно стоит ваше время? Вы не можете просто вызвать «функцию шифрования». Чтобы правильно реализовать этот протокол, вам нужно позаботиться о режимах блочного шифрования, векторах инициализации, функции string2key (s2k) и, наконец, о способе аутентификации сервера и / или клиента (асимметричный cyrpto / PKI ...). Короче говоря, подавляющее большинство программистов не имеют ни малейшего представления о том, что входит в создание действительно безопасного протокола.

Более того абсолютно невозможно создать безопасный сеанс и аутентификацию без SSL. Это идет от OWASP top 10 A3: сломанная аутентификация и управление сеансами .

Хеширование пароля пользователя вместе с данными

Здесь вы описываете код аутентификации хэш-сообщения или HMAC. Это не имеет смысла, если вы просто отправляете имя пользователя и пароль через строку в виде открытого текста. Весь смысл hmac в том, что вы используете секрет, а пароль не является секретом, если вы не используете SSL.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...