Защита веб-сервисов
У меня есть проект WebService, который мы создали для представления некоторых методов нашим клиентам (конкретно, если они назовут один из методов, то он инициирует событие на наших серверах), что они могут призвать свои собственные проекты C# (некоторые клиенты будут делать приложения веб-формы, и некоторые будут делать его на их внутреннем сайте).
Из-за природы метода, один из параметров является строкой, которая определяет, кто клиент (таким образом, мы можем инициировать соответствующее событие), и я не чрезмерно уверен, что этого достаточно, чтобы препятствовать тому, чтобы люди отправили случайные данные, пока они не натыкаются на один из допустимых идентификаторов.
Каков стандартный способ защитить что-то вроде этого от злоупотребления? Большинство учебных руководств, которые я нахожу, кажется, ничего не упоминает о хранении их безопасный.Спасибо!
6 ответов
Даниэль Вассалло прав. Вы захотите использовать сертификат X509, чтобы убедиться, что лицо, вызывающее службу, является законным. Однако это значительно увеличивает сложность решения. Вы захотите использовать Microsoft WSE и, вероятно, приобретенный компонент стороннего производителя.
Без этого вы можете использовать переданные имя пользователя и пароль. Однако потребуется некоторый общий алгоритм для хеширования информации на основе даты, времени и т. Д. Без хеша вы открываете себя до взломать гораздо больше, чем нет. Даже с использованием SSL, поскольку словарная атака может в конечном итоге взломать.
- Использование имени пользователя и пароля должно быть допустимым.
- Если вам известны IP-адреса клиентов машин, которые будут вызывать веб-сервис, ограничьте URL-адрес только известными IP-адресами.
Вы можете проверить протокол WS-Security .
Этот протокол содержит спецификации того, как можно обеспечить целостность и конфиденциальность обмена сообщениями веб-служб.
Аутентификация обычно выполняется с использованием заголовков SOAP, см. на этой странице MSDN.
В этой статье codeguru приводится пример, хотя он довольно старый.
как часть протокола вы можете отправить случайное число клиенту. Затем клиент объединяет идентификатор с этим случайным числом и хеширует комбинированное значение. Вы можете вернуть это объединенное значение обратно на сервер.
Сервер затем вычисляет тот же хэш ID + Number и проверяет два значения.
Это, по сути, пароль... только не ждите его имя пользователя и пароль в одном поле.
Нет никакой технической причины как таковой, почему вы не должны объединять имя пользователя и пароль в одно поле, но, по общему правилу, при отсутствии дополнительных секретных ключей, они представляют собой два поля.
Это по трем деловым причинам:
Идентификация учетной записи может однозначно обсуждаться между людьми, которые должны знать идентификатор пользователя (имя пользователя?!), но не иметь пароля
Проще всего по закону доказать несанкционированный доступ, если это когда-либо будет необходимо, если протокол доступа является обычным, потому что в этом случае более вероятно применение прецедентного права и ситуация будет более ясной (и это приведет к меньшим по размеру юридическим законопроектам!). Отсутствие имени пользователя в публичной сети для коммерческой системы не является чем-то неслыханным и в некоторых системах является хорошей идеей (но обычно это просто не ... хорошая идея).
Руководящие принципы по лучшей практике в области безопасности в целом и по конкретным процессам предполагают, что вы используете имя пользователя и пароль, а не комбинированное поле, где это возможно. Это может затруднить формулирование политик консенсуса.
Пароль (или часть пароля, если вы используете комбинированную строку имени пользователя/пароля) будет подчиняться всем обычным рекомендациям по безопасности в отношении политики изменений, неразглашения, сложности и длины. Я предлагаю вам также использовать SSL и WS-Security, чтобы быть как можно более обычными в области безопасности. Наверное, вам нужно шифрование на проводе.
EDIT
Я имел в виду TLS, а не SSL.
EDIT
Извините, нет, я имел в виду TLS или WS-Security.
.