Web services login from python

[jemandel]

As described in a previous post, I'm trying to develop a thin client in python on a Raspberry PI that gets data from a Web Services program. I wrote a simple "Hello World" vi that requires authorization. If I access the URL from IE, Safari, etc, it gives me the Silverlight login screen, and then it works. If I write a simple client using the HTTP Get vi, it works. If I access the URL from Python:

r = requests.get("http://127.0.0.1:8001/DISE/hello"
	auth=('username', 'password'))

 I get 404. I've Read The Fine Manual. Suggestions?

[mikeporter]

My suggestion is to try a python support forum. The LabVIEW piece seems to be working fine.

Mike...

[jemandel]

I'd have no trouble making it work in Python if I knew how to set the header variables to mimic the Labview VI. I presume that I'll find something in the header like:

Authorization: Basic UXNrYXBhggRfoopc5NteWFzcw==<

Now, I can presume that this is probably a Base64 hash of something like username:password, but I'd prefer not to have to reverse engineer this when someone at NI clearly knows what they are doing in the VI, and can document it.

Thanks,

Jeff E Mandel MD MS

Perelman School of Medicine at the University of Pennsylvania

[natasftw]

It's clearly done in a way that every browser you've used understands.  This means it's unlikely it's some proprietary method that isn't understood by those outside of NI.

It works with all of those browsers and other VIs.  The only piece falling short is your python code.

Why would you need NI to tell you how every other browser is handling it?  His advice was pretty much on point.  From a logical standpoint, the issue is entirely in your code.  It's not proprietary to NI unless you believe all of those browsers added extra code just to deal with NI's headers specifically.  Your best bet is to look to a python community as they've probably dealt with similar issues.  That's the only piece of your code that's currently broken.

[jemandel]

It would be helpful if you looked at the HTTP method VIs. 

Clearly, there is a way to include the authorization credentials in the headers. If I had time, I'd write a PHP script that would dump them out to show you. I would be amazed to find username and password were sent as clear text. There is some sort of has function, just as there is one for the API key. That one is documented. This one isn't. Can someone who knows the answer respond.

Thanks,

Jeff E Mandel MD MS

[Dennis_Knutson]

The manual you say you read says that error 404 is a site not found error. Why do you think it's an authorization problem?

[jemandel]

Because if I remove the requirement for authorization, the URL works.

Please people, I'm not a newbie. I was a beta tester for Labview 2. I've got production code in 37 languages. I ran my own VAX. I'll eventually figure this out, but if someone knows the answer to the question I posed, post an explanation of how to authenticate to web services. It might be a good start to read this paper. It gives example code in Python that works on my server. If you can't replicate what Muree did, you probably don't understand the issues.

Thanks,

Jeff

[natasftw]

The problem isn't that we don't understand the issues.  It's that you believe it's helpful to look at those VIs.  It's not. 

The fact that you're able to read the data from all of the browsers you're using shows that it's not something proprietary.  Using LabVIEW -132352 doesn't change that.  You're approaching the problem from entirely the wrong angle.  You don't have to be a newbie to do this.  The snippet you showed doesn't change anything.  In order for those browsers to correctly handle the page, they must understand it.  Let's determine what that means.  There are two possibilities: NI is using proprietary headers that require special handling to understand or they're using something standard.

If the first is true, that means that each of those browsers either decided the few cases when someone would use NI's API in that specific way was worth modifying their code to handle that exact case or NI was able to convince all of them to handle it while opting not to document how to handle it yourself.

If the second is true, you're looking at this from the wrong angle.

Which of the two sounds more plausible?  You can be as condescending as you'd like and offer as many references to your experience as you'd like.  That doesn't change the problem at hand.  It'd be helpful if you'd understand that.

[Darin.K]

It seems to me that the responders to the OP do not, in fact, understand the issue at play here.

NI has two pieces of security for the web services: digital signing and authentication.  The digitial signing is documented and the OP knows how to do this in python.  The authentication is not documented anywhere I know of.  The fact that it works in the browser does not mean anything.  What happens with a browser request for a service which requires authentication is that the response is a new page with a Silverlight app to perform the authentication with the NI-auth service.   The question the OP has is what goes on inside that Silverlight app?  That was written by NI, not the browser developers, so it could be answered by the folks at NI and this is as good a place as any to request that info.  The VIs referenced by the OP recreate the same functionality, presumably by calling into a CLFN.

In the meantime, here is some information that may or may not be of use.  I used to use web services now and then, but issues like this (and the use of silverlight) drove me away eventually.

The NI-auth server apparently uses the SRP protocol to validate username/password combinations.  You send a GET request to host:port/login?username=user.  The response has a header which is something like 'X-NI-AUTH-PARAMS' with the server parameters for the SRP protocol in base-64 encoding.  Then you send a POST request back to the login uri with the client parameters inside the body and the content type is 'application/x-www-form-urlencoded'  If all goes well the final response from the server has a cookie which you can use in further requests.

You will have to play a bit to determine some details like which hash function is used inside the SRP protocol.  The beauty of python is that hashlib, srp, and request modules are already there for you.

If you get it sorted out, let me know.  I figured out enough to do some spoofing, I am curious to fill in the missing gaps.  I'll try to dig into my old code some more for details.

[jemandel]

I poked around a bit more. First, I misspoke; the response was 403 (Forbidden), not 404 (Not found). Having said this, Darin K. is correct  in his recollection of the exchange.

Here is my setup to attack the problem:

Server machine running Labview web service as a standalone server. There is a user "user" with password "password".

Client machine has LV 2014 Professional. NI Web Server is disabled. Proxycap is configured to forward all traffic from Labview to port 8080 on localhost. OWASP ZAP is listenng on that port. A man in the middle attack.

On the client, I have the simple VI (see previous post) that configures OpenHandle with the user credentials. It then issues a get to the server. Here is the (editted) traffic:

It might be good if NI addresses this before the people I fear take an interest. I think someone from NI should acknowledge they are listening to this thread and understand the security issues involved.

I'm still betting that there is some way to generate ss, A, and M using Python. Having said this, I'm even more convinced that I need 2 factor authentication for my application. Or maybe just do everything through ssh tunnels secured with crypto cards. Not that this is a solution most NI customers would embrace.

Thanks,

Jeff

[03/05/2014 - Edited to remove specific details of a potential security issue]