Protección de servicios web

Question

Tengo un proyecto de servicio web que hemos creado para exponer algunos métodos a nuestros clientes (específicamente si llaman a uno de los métodos que desencadenará un evento en nuestros servidores) que pueden llamar en su propio Proyectos de C# (algunos clientes realizarán aplicaciones de formularios web y otros lo harán en su sitio interno).

Debido a la naturaleza del método, uno de los parámetros es una cadena que identifica quién es el cliente (para que podamos desencadenar el evento apropiado) y no estoy seguro de que esto sea suficiente para evitar que la gente envíe aleatoriamente datos hasta que tropiezan con uno de los identificadores válidos.

¿Cuál es la forma estándar de proteger algo así del abuso? La mayoría de los tutoriales que encuentro no parecen mencionar nada sobre mantenerlos seguros. ¡Gracias!

Answer 1

Daniel Vassallo es correcto. Deberá usar un certificado X509 para verificar que la persona que llama al servicio sea legítima. Sin embargo, esto aumenta mucho la complejidad de la solución. Querrá utilizar Microsoft WSE y probablemente un componente de terceros comprado.

Sin eso, puede utilizar un nombre de usuario y contraseña pasados ​​pulg Sin embargo, tendría que haber algún algoritmo compartido para hash la información basada en la fecha, hora, etc. sin el hash, se abre a sí mismo un truco mucho más que no. Incluso con SSL, como un ataque de diccionario eventualmente podría entrar.

Answer 2

Es posible que desee verificar el protocolo WS-Security.

Este protocolo contiene especificaciones sobre cómo se puede aplicar la integridad y la confidencialidad en los mensajes de servicios web.

Answer 3

1. El uso de un nombre de usuario y una contraseña debe ser bueno.
2. Si conoce la dirección IP del cliente de las máquinas que llamarán al servicio web, restrinja la URL solo a las direcciones IP conocidas.

Answer 4

La autenticación generalmente se maneja usando encabezados SOAP, consulte this página MSDN.

This codeguru artículo da un ejemplo, aunque es bastante viejo.

Answer 5

como parte del protocolo, puede enviar un número al azar al cliente. El cliente entonces salda el Identificador con ese número aleatorio y Hashes el valor combinado. Puede devolver ese valor combinado de vuelta al servidor.

El servidor luego calcula el mismo hash ID + Número y verifica los dos valores.

Answer 6

Esto es efectivamente una contraseña ... excepto esperar no es un nombre de usuario y contraseña en un campo.

No hay técnico razón por la cual no se debe combinar un nombre de usuario y contraseña en un campo, pero por convención o en ausencia de claves secretas adicionales, son dos campos.

Esto es por tres razones comerciales:

• La identidad de cuenta pueden ser discutidos de forma inequívoca entre las personas que deben conocer la identidad del usuario (nombre de usuario ?!), pero no poseen la contraseña

• Se es más fácil en la ley probar el acceso no autorizado, si esto fuera necesario, si el protocolo de acceso es convencional porque entonces es más probable que se aplique la jurisprudencia y es más probable que la situación sea clara (¡y para generar cuentas legales más pequeñas!) . No tener un nombre de usuario en una red pública para un sistema comercial no es desconocido y en algunos sistemas es una buena idea (pero en general simplemente no es ... una buena idea).

• Directrices sobre las mejores prácticas en materia de seguridad en general y los procesos específicos asumen que utiliza un nombre de usuario y contraseña en lugar de un campo combinado donde sea posible. Puede dificultar la formulación de políticas de consenso en el futuro.

La contraseña (o la parte de la contraseña si vas con una cadena de nombre de usuario/contraseña combinado) estarán sujetos a todas las recomendaciones habituales en materia de seguridad con respecto a la política de cambio, no divulgación, la complejidad y longitud. Sugiero que use SSL y WS-Security también, para que sea lo más convencional posible en el área de seguridad. Probablemente necesites cifrado en el cable.

EDITAR

que significaba escribir no TLS SSL.

EDITAR

En este momento hay que quería decir, ya sea TLS o WS-Security.