Limiting web service access to a public facing Flex application

Question

I have a flex application which collects data entered by the user and posts it off to a web service I have running on a back end server. The flex application does not authenticate users (it's available for anyone to use without setting up an account) and communicates to the web service using HTTPS.

There is an XML firewall in place for preventing certain malformed requests, DoS attacks etc and the web service validates all data received from the client.

If I was to sign the content then I could use the XML firewall to verify the signature but I assume that any certificate type data I embed in the client could be extracted out of the flex app through some means of de-compilation.

My question is, is there any way of limiting calls to the web service to only those from my flex client? I understand that a user could input bad information but I'm really trying to prevent another client or 'bot'.

If I were to introduce having user accounts to take advantage of a session based solution then presumably I still face the same issue when I'm trying to set up the account in the first place (would have to still be done in the flex app)?

Answer 1

you can add a crossdomain.xml to your server so then only your flex app can access your domain service and...you can generate some random id when you show the webpage and give it to the flex app as a parameter. so when the flex app makes the first service call, the id should be there. with the service response, generate another id and send it back to the flex to use it with the future call and so on.

Answer 2

Like TheBrain mentioned, the crossdomain.xml file is where you need to start, but this only keeps other flash based applications away. His idea about the random id is also a good one but I could see that being rather complicated to implement. You could implement user accounts only having those accounts set up through some other means than the flex application (something presumably more secure).

Another way would be to have a shared password between the application and the webservice side, and encrypt that password on both sides using some sort of salt that both sides could know. My first instinct is to think of a time based salt. You could pass the timestamp from the flex application along with the rest of the request and then take your password and the same timestamp concatenated together in someway, hash it and pass that along as well. In the webservice when you get the request, you take the same password (not passed with the request in the clear) and the timestamp that was passed and hash it using the same algorithm. Then compare. If they match then it is an authenticated request. You could even store a dictionary of passwords, and use a different one for each day of the week or something like that. Just however you do it, make sure that your two methods of determining the hashed password is identical. This should provide enough security for most applications. Let me know if any of this needs clarification or if I have misunderstood the question.

After re-reading your question, I see you are worried about decompilation. I don't have an answer for this off the top of my head. You could potentially store the password outside of the application and read it in, but that doesn't solve the problem of the person decompiling to be able to read that file. I will think some more on this and see if I can come up with something to guard against that.