I am building an android app which consumes a soap web service that I have hosted on my server. I will have client apps for other mobile OS also in the near future. There are a few concerns with the web service security which I have posted below.
How to secure the username/password used for wsse authentication on the mobile device app ? I do not want to use something specific to android as I may have apps out for iPhone/Blackberry in the near future
If someone de-compiles the apk file and get the wsdl url, how to prevent the DOS - denial of service attacks ?
is HTPPS really worth it ? if a hacker gets the wsdl url from the app, he can trigger faulty requests which can end up in DOS.
Does using oAuth with REST have an advantage over SOAP with wsse ?
I feel that if the hacker ultimately gets the wsdl url, he can trigger hundreds of faulty unauthenticated requests itself which can overload my server.Please help me in figuring out the best solution for my scenario.
Related
I'm looking for a little top/level guidance. I don't expect a solution to the problems at hand. My goal is to create a native mobile application (not web) for iOS and Android. I want the content to be served from an in-house Microsoft Server, not a cloud based service like Azure. The mobile clients need to be able to login and make authorized read and write requests to the server. I figure I will return data as plain text and/or JSON. I'm debating using SQL Server or a NoSQL solution. I am also considering using something like ElasticSearch if I can't get speedy text searching working. The Microsoft topic has been somewhat confusing because I have never developed a Microsoft Web Application and most of the resources seem to assume a web based application or Azure hosting. So I was hoping for a little assurance I'm on the right track and hoping for a point in the direction to some resources that will help me on my way.
Microsoft Server. Not sure if I should be looking into ASP.NET MVC or ASP.NET WEB API, or something else entirely. If I use these frameworks, I can perform other async tasks on the machine right? For example, making additional calls to other web services to process requests.
Login: SSL for all connections. User sends username/password and system authentication. Server sends back token. With every request, client sends back token and server verifies token before processing request. Is this valid as long on a HTTPS connection? Just store the tokens in the server database and verify?
This application is not going to generate profit so an MBAAS is not really an option. It also is expected to handle roughly 2000 users and may need to scale to 10,000. Traffic would likely be concentrated as well. I know this is super broad, I just want a little direction to resources and big picture regarding Microsoft in this context.
If you're building an app that will communicate with a server, you probably want a Windows Service (SOAP) or a Web Service (REST) that it can communicate with.
You don't need ASP.NET MVC or WebAPI unless you're planning on creating a website (ASP.NET MVC) and communicating from said website using HTTP requests from the client side (WebAPI).
A Microsoft server hosting a Windows Service or Web Service should be fine. Yes, you can perform other requests from the server, even if you're hosting websites, a web service or Windows service on the same machine. Each HTTP request is a separate request that will be processed independently of one another.
Yes, you can secure the communications of between your web service and application quite easily using HTTPS/SSL. I'm not sure about just sending an identifier back and forth and that's it, this probably wouldn't be that secure. Maybe you can employ oAuth or a method that already exists. I believe that if you're creating you're own security system that you're probably doing it wrong - Leave it to people that specialise in those things.
I'm building a mashup app for Android Wear, using speech recognition so I can post to Fitbit's API. Single-purpose and pretty simple. I generated the OAuth 1.0 credentials with the excellent Temboo library and granted access in a desktop browser, then naively hard-coded those keys and tokens into my app and let Temboo take care of the HTTP requests and API calls to Fitbit.
I've gotten errors from Fitbit stating that my requests are being refused by Temboo's server because of invalid OAuth signature (Fitbit uses OAuth 1.0). I've come to the realization that I probably need to have the user grant access on the wearable app itself. I'll need to launch the mobile browser and pass it the authorization URL from Temboo in a WebView, then have the user grant access, and then pass this approved data back to the watch.
Is there a pattern for doing this in order to allow access to third-party web service APIs already? I've not seen documentation on it so far. Does anyone have a tip on how the authorization process would flow for a wearable watch app?
Thanks much!
There is no web browser or direct internet connection on Android Wear devices - all web connections must be done on the phone part of your app and then forwarded to your Wearable app via the various Data Layer API methods - using messages is an easy way to send information in a lightweight, time sensitive manner.
Therefore your phone app should do all of the OAuth dance as part of an initial setup.
I have a MVC application that I would like to port at least a small part of it to a mobile app (android first). My first objective was to try to figure out how to authenticate the users.
It seems that forms based authentication uses cookies and that is not usable by mobile apps? Definitive confirmation would be appreciated.
But it seemed that you could do some form of authentication using a WCF service to create a token. Now I found a lot of sites that discussed how to create and secure the service end point but none really discussed the token generation.
Then quite by accident I stumbled upon WIF and the usersecuritytoken, which seems to what I am looking to accomplish.
So if some could please confirm this is where I need to be looking so I can actually get back to coding rather than reading I would appreciate it.
The way I see this working is:
Secure WCF service.
Using the System.IdentityModel it generates a token for a valid user and passes it back to the mobile app.
Then the app passes the token along anytime a service requiring privilege is called. For example updating the user's profile.
Is that how it is suppose to work? If not could you please point me to an example of how it is suppose to work.
One other question, looking at the WIF site it seems to provide a lot of token types, what is the preferred type for android and iOS?
UPDATE As it was pointed out it would be helpful if I provided more context.
The original website is a MVC3 web app.
I am attempting to write an app for some of the backend administration features using mono touch.
WCF seems to be a bad solution for cross platform and a package called ServiceStack is what I am now leaning towards for my web services. ServiceStack has its own authentication module but it does not interface with the .net membershipprovider which is an issue since the web app was designed with the membership provider.
I have to be overthinking this. It can't be this complicated to have an android or iphone app securely authenticate to a .net membership provider through some form of web service.
Thank you in advance,
Chris
I'm planning to develop an Android application with an app-engine backend.
However I would like to refrain from using authentication (either with Google accounts or Open ID). Since the data will be sent only from my app and not any other client, and will be over SSL connection, I consider the data safe and trusted.
So my question is two-fold:
Is there any security issue I'm missing here ?
All the examples I found use some sort of authentication. Is it at all possible to use the android appengine infrastructure (RequestFactory, etc) without authenitcation ?
An app engine application is just a regular web application deployed on app engine. If you need to authenticate your users, do so. If you don't need to, then don't.
You're missing something, though: once a web app is deployed on app engine, it's accessible from anywhere on the web, and so anyone (and not just your app) could send requests to this application, whether you use SSL or not. SSL will just make the communication encrypted, and ensure the client that they're talking to your web app, and not to a rogue web app maskerading as yours.
What is the best solution to secure a REST service provider (assume a java servlet running on google appengine) by allowing requests only from iOS or Android device from a specific app?
Assume I have a servlet running on google appengine that does some processing and responds to a GET request with some JSON data. And I want to restrict this access to my app that runs on Android and iOS.
My current solutions are:
Use if(tokenValue ==
request.getHeader(tokenKey)) on the
appengine servlet. And
response.addHeader(tokenKey,
tokenValue) on the mobile apps'
code. So basically only my app would
know the token key.
Use HTTP(s) for the above solution, appengine supports this
Use oAuth - but I need to have the user sign-on to some oAuth provider from the app, which complicates the app
Suggest other useful approaches to tackle this problem. Assume this servlet only serves GET requests and maybe use Restlet or Jackson
Only 3 would be an appropriate solution if security is important to you. This is because anyone using the application can intercept the traffic and just replay the values against your web service. SSL offers some protection but a good attacker can work out how to capture data if they control the device. With OAuth the damage done by an attacker is limited to a single user (as long as they are not an app admin).
How about using a client SSL certificate? I haven't tried this, but I'm considering it. Here's a page that describes the approach, with some sample code:
http://blog.crazybob.org/2010/02/android-trusting-ssl-certificates.html