WebServices and credentials

[wtg]

Is there any reason to enforce credentials on web service calls that originate within the local network? Couldn't they recognize the web server settings that allow local network access without logging in?

I ask because using Windows PowerShell it's very easy to invoke web services natively. For instance, try this at a PowerShell command prompt:

Code:

$URI = "http://www.webservicex.net/StockQuote.asmx?WSDL"
$StockService = New-WebServiceProxy $URI
$StockService.GetQuote('MS')

It would be nice to access the NEWA web service functions from within PowerShell. I think it would open up a lot of possibilities from the command-line and scripts that aren't available today, but the credentials make it significantly more complicated and with scripts would require the password be stored in plain text too. It seems like this really shouldn't be necessary if the user has already configured NEWA to not require credentials for their local network.

[UncleJohnsBand]

I'll see if I can come up with an approach to allow non-authenticated access from local network addresses......the issue is that it is possible to spoof ip addresses and the web service interface is publicly open..... the current setup requires time-stamped credentials which protect the access.

[wtg]

the issue is that it is possible to spoof ip addresses and the web service interface is publicly open

But is this really any different than the unauthenticated access that's available through the web interface on the LAN today?

[UncleJohnsBand]

But is this really any different than the unauthenticated access that's available through the web interface on the LAN today?

Yep...since if you try to access the same things from external you have to authenticate......the web services are open from external.......they have to be since web services are headless (no screens/ui)......so you can get to the web service without logging in....but to use it you need to pass in the appropriate credentials for the service to work. If the solution solely relies on IP it is possible for external access to come in with a spoofed IP looking like internal access. I am not a security wizard or anything but I work with security pro's at my dayjob and they assure me IP spoofing is possible.

[wtg]

Ok, I don't want to belabor things, and maybe I'm just being ignorant, but the functions that are available via html on the LAN in the browser w/o authenticating are just as susceptible to spoofing as a web service would be. I understand you might not want to make all web services available w/o authenticating, but it seems like the services that provide the same functions available via unauthenticated html internally could forgo authentication too.

I hope to make it a moot point by getting the authentication to work in PowerShell, and I'll share the results here if I do, but not being a real C# developer its a challenge. It seems like an unnecessary challenge for the services that can be mimicked w/o authentication in a browser.

[UncleJohnsBand]

Ok, I don't want to belabor things, and maybe I'm just being ignorant, but the functions that are available via html on the LAN in the browser w/o authenticating are just as susceptible to spoofing as a web service would be. I understand you might not want to make all web services available w/o authenticating, but it seems like the services that provide the same functions available via unauthenticated html internally could forgo authentication too.

I hope to make it a moot point by getting the authentication to work in PowerShell, and I'll share the results here if I do, but not being a real C# developer its a challenge. It seems like an unnecessary challenge for the services that can be mimicked w/o authentication in a browser.

Not a problem..... you need to consider web services are not internal only....they are external all the time so you need to protect at an external not an internal level. The web pages you mention are protected externally all the time by id/password secured by a random ever-changing salt key generated on the server that is applied to the id/password that is entered by the user in the browser and then is decoded on the server to ensure the id/password was not spoofed. Since the web services do not have a web page where you enter the user id/password you need to use the web services security (standard ws-security). If you look on the wiki there is a c# class available for you to use to generate the authentication key for the web service call.

I just realized I never brought over the web service information pages from the old wiki but thankfully they are still available. I will have to bring them over.

[wtg]

Ok, one last time and then I shall never speak of this again...

I do not enter a user id and password when I connect to NEWA from within my local network. As configured, IPs from 192.168.x.x do not require credentials. I can manage recordings and even delete them without ever being prompted for a user id and password. If someone can spoof a local IP address externally - however unlikely - they could fetch the channel listing, schedule recordings and delete recordings at will.

How is not requiring credentials via browser for internal IPs any different than not requiring credentials for internal web service calls? If one can spoof an internal IP address one can do the same things via HTML that I'm hoping to do via web service calls. I do understand the necessity of securing external calls, whether via browser or web service.

By the way, do you have an example soap message that shows what the header looks like with the authentication included? Unfortunately I'm not experienced with C#, let alone integrating it within PowerShell and I'm not having success incorporating the entire C# class from your example. It was easy to get the HashMe and Encrypt routines imported but I can't import the EWA services correctly. What I have is enough to manually create the soap calls I believe, if I knew exactly what the header's authentication node looked like in raw XML.

[mvallevand]

I am trying to port Ton's myGBPVR to current NEWA and XBMC and I have got to say that the authentication is the biggest obstacle to getting this completed. I have probably put 20 hours into it and I can't get beyond the credential creation process returning “Padding is invalid and cannot be removed” error. It was a challenge in c# in Python and it is turning into a nightmare.

Anything that can be done to reduce security on internal NEWA web services would be greatly appreciated.

Martin

[wtg]

I ended up customizing webServiceAuthentication.cs to bypass authentication when the request comes from an internal network. If someone is able to spoof the IP address they can attack me via the normal web server so I see no extra risk.

And quite frankly if they can get the router to forward a local LAN address from the external to internal side of the network, something a gateway will not do per standard, then they deserve the convenience of an unauthenticated web service.

I think I had to add "using System.Net;" to the top too, but I forgot to save the original so I'm not sure.

Edit: Seems the included image gets reduced too small to see the modification. Added as an attachment.

[UncleJohnsBand]

This feature will be in the next release of NEWA.