Pregunta

Tenemos una aplicación de Silverlight, que escribimos que llama a un servicio de datos Silverlight habilitado. La aplicación Silverlight no puede requerir un inicio de sesión, ya que se requiere para presentar los datos al público no autenticado.

Tenemos algunos schmoe que se tomaron el tiempo para examinar nuestra aplicación Silverlight, de una manera u otra figura de qué servicio se está llamando, y luego escribió su propio cliente para sorber fuera de los datos para que pueda publicarlo en su sitio y pretender como es el suyo. Hay que evitar esto.

¿Cómo puedo limitar mi servicio de datos de alguna manera para aceptar únicamente las peticiones de mi aplicación Silverlight? He intentado utilizar el allow-uri de dominio en el archivo de configuración de clientaccesspolicy.xml para limitar el acceso al servicio sólo desde el dominio en el que se encuentra la aplicación de Silverlight (por ejemplo mydomain.com). Esto no hizo absolutamente nada sin embargo, y el servicio aún está sirviendo peticiones a los clientes de fuera del dominio. (He probado esto poniendo mi SL aplicación en un dominio diferente bajo nuestro control).

¿Cuál es la mejor manera apropiada / / más eficaz para limitar el servicio de datos por lo que sólo nuestra aplicación puede usarlo? Gracias !!!

Estoy usando SL 3 y .NET 3.5.

¿Fue útil?

Solución

El clientaccesspolicy.xml cuenta la aplicación de Silverlight, que se WEBSERVICE puede consumir. No impedir el acceso a personas de servicio web.

Puedes probar a utilizar un inicio de sesión de autenticación a pesar de que no es necesaria. Esto evita '' schmoes que acceden a su servicio web.

También utilice Dotfuscator para evitar '' Schoes desmontar su aplicación Silverlight y adquirir la entrada.

Otros consejos

La seguridad de servicio web Silverlight sigue los mismos patrones que tendría que utilizar para la seguridad de ASP.NET, especialmente los servicios expuestos a AJAX. La mejor manera de hacer hacer uso de la autenticación de ASP.NET.

RIA Services es una mejor manera de manejar esto. Se monta en la parte superior de la autorización de ASP.NET, pero valida tanto en el cliente y del lado del servidor automáticamente para combatir la suplantación de servicio. Le dejó hacer cargo tanto de la autorización del cliente y del lado del servidor mediante la adición de atributos a los métodos que indican que el método requiere el acceso autorizado, y por el cual los grupos o usuarios si tiene que ser específico.

Además de la seguridad del lado del alambre y la ofuscación, recuerde que los clientes pueden adjuntar un depurador para aplicaciones de Silverlight que se ejecutan en su navegador. Ver este de la Prueba de Seguridad de CI de MSDN Magazine, noviembre de 2008 .

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top