I developed a windows mobile application which connects back to my web services hosted on internet to sync with the server data.
I didnt put any control for CSRF on mobile application, Is it required to have a CSRF protection on native applications? If yes why?
** My application is native application not on web browser.
Is it required to have a CSRF protection on native applications?
No, if your mobile application is the only type of consumer (e.g. no web browsers) and your mobile application does not make web requests to other domains then by definition CSRF is not possible as there is no cross site request to counterfeit.
CSRF protection would be on the web server side, not the app, although you can help yourself by setting a cookie from the server on login and adding that cookie to the header of your requests from the native app.
You application will most likely need to be CSRF aware (if you've implemented protections on the backend).
For instance, a general best practice is to supply a token on each request that will be used on the next request to ensure no duplicate requests can be made. Your mobile app will need to be able to get and use this token (again, assuming you've implemented this on the server side).
It really depends upon if your site can be accessed by a human AND/OR the authentication method that you are using for the web site.
If a user can login in any way to this web site that is hosting your web services via a browser then while the user is logged into the site, the answer is yes because CSRF takes advantage of the fact that the browser will send along session and other cookies when the web site is communicated with due to the fact that cookies are automatically added by the browser for all request targeting the same origin regardless of which web site is sending them.
If your web services can be accessed directly via NT Authentication then as long as you are logged into the network, the answer is yes. The reason is because the attacking web site that is using malicious JavaScript is still accessing the web services as YOU regardless of which site is sending the request.
Finally, if there is absolutely no way to login to the site via a browser and you are not using NT Authentication, SilverlightFox's answer is correct. The reason is because there would never be a Session cookie for the site so there is nothing to send when the CSRF attack occurred.
The Fix:
For web, this is fixed via an anti-forgery token, which is sent back with put and post verbs (although you can do it with all verbs). A malicious web site could try to send a request and would certainly pickup your session cookie, but the absence of the anti-forgery token in the put/post causes it to fail.
For mobile, patwhite above suggests a fix, but it would require different web service end points for mobile vs web due to the fact that it is a different strategy for handling the problem.
Related
I'm working on a product with two apps: one a single-page web app, and the other a native mobile app. Both make use of the same backend API. Currently the user authenticates using username/password credentials to establish a session cookie. I'm planning on adding support for authentication using OpenID Connect.
For the web app, I'm looking at following the advice for "JavaScript Applications with a Backend" in "OAuth 2.0 for Browser-Based Apps". In that scenario, the authorization code gets sent to the backend, which obtains the ID token and begins a cookie-based session.
I'm trying to work out how this would work on Mobile. The "go to" implementation of OAuth/OIDC on mobile appears to be AppAuth. From what I can see, AppAuth uses a different approach where you end up doing the auth code exchange on the device to get the ID token.
Should I have the mobile app send the ID token on to the backend to prove the user identity (and then begin the session)? Is there any best practice around doing this? Presumably at least the backend would need to validate the JWT and verify the signature?
Alternatively, can AppAuth be used to do a similar flow as done on the web app as mentioned above?
The mobile case does indeed work differently, and is defined in RFC8252, which defines the AppAuth pattern. Both the web and mobile cases have this in common:
Open a system browser at the Authorization Server URL with a Code Flow request URL
Cookies are not used in mobile views, and mobile apps can store tokens securely, unlike browser based apps. The mobile app will send access tokens to APIs, and also make token refresh requests when needed.
Out of interest there are easy to run versions of each in my online code samples, if you want something to compare against. Both flows are tricky to implement though.
Our application uses AngularJS and consumed Web API in the backend. This is only internal application and authentication used is 'Windows' mode only. We are using custom authorization(role-base) to limit the access/execution of the application web api methods.
My question is do we need to add ValidateAntiForgeryToken attribute for those web api action with HttpPost and HttpPut attribute? I never use this ValidateAntiForgeryToken before as I was only involved in internal web application (local intranet only). Please guide me when/how to use ValidateAntiForgeryToken.
ValidateAntiForgeryToken protects your users from malicious web apps that send a POST request to your web app unbeknownst to your user, known as CSRF. Still the request would succeed since it's coming from your user who actually has permission to do so.
This is irrespective of the actual authentication mechanism, and is in fact a higher risk for automatic single-sing on that you have with Windows authentication.
If your internal web app is worth the effort, a targeted attack could trick your users to visit the attacker's web site that in turn sends the POST request to your web app.
My take is that you should use ValidateAntiForgeryToken even in this situation as a defense-in-depth measure.
I've been developing RESTful API server communicating with cross-platform clients such as Android, iOS, Web browser, and so on.
When a user login successfully by username and password, this server issue an access token(JWT, 5 minutes) and a refresh token(GUID, 20 days).
When we develop Android client app communicating with server, we just can store this tokens in mobile device and I believe it will not be a problem in terms of security( using SharedPreferences).
But when it comes to Web browsers, (React App) I had to tackle where to store these tokens. Finally, I decided HttpOnly Cookie, because I can manage easily CSRF attacks rather than XSS.
Soon, I doubt this is a typical design. For example, web browser users cannot logout whenever they want. So I determinate change the wrapper server(Node.js) between the React app and the RESTful API server.
In my second design, the React App and the wrapper server authenticate session-cookie model, using passport.js for exmaple. And when the wrapper recognize the request is authenticated, then the wrapper issue a short term access token(1 minute JWT) and reorganize the request by inserting the access token just issued in the header sent to the RESTful API server.
Is this reasonable process? Thank you in advance.
You could simplify your solution by removing the JWT access token altogether. The refresh token could be used as a session id. Every time a client issues an API call to the server the session id is sent in an HTTP header, so you can check if the request is legitimate.
Your approach of using a JWT token with a short expiration time is ok, but it brings some complexity to your system. In my opinion this approach is best suited for systems where you have an authentication service and a resource owner service. So the client would request an access token to the authentication service and use that token to communicate with the resource owner service. Then the resource owner can check the validity of the access token by just checking whether the signature matches the authentication service's.
I hope this helps you, let me know if I'm missing something.
I have developed an AngularJs website, Android & IOS mobile apps. I am using https protocol to make my web service calls more secured. I am using OAuth flow for user authentication process. Once authentication process completed, OAuth token will be sent as a response to client apps.
Anyone can get access to server resources (upload/download user files) using this OAuth token from API response. So the system is not fully secured because it is difficult to check whether the request coming from my app or outside of the app.
If someone found the OAuth access key returned from my service, they can use them to upload/download resources from outside of the app. Server resource should be more secure as it contains more sensitive user records. Please check the below image to understand the workflow. Other programs section refers to custom batch scripts, other client apps, 3rd party tools etc..
How can I restrict my REST web service to send failure response if anyone tries to access it from outside of my app?
Please provide me the way to secure my web service and server resources by resolving these security issues.
We are the process of developing a android phone app using IONIC framework and Web Api as the backend.
My question is ,is it sufficient to use Forms Authentication along with SSL to keep the phone app secure.
Our background is in Asp.Net web development and we could not see any examples that uses Hybrid mobile app development along with forms authentication,that makes me wonder if we are in the wrong track.
We implemented CORS along with WithCredentials both on Angular and Web API side, and the authentication piece seems to work fine for all subsequent calls in debug mode.
Do we need to take additional steps for security ,since its a phone app ?
Edit: I was reading about bearer token authentication with Web Api, is this a recommended way to go with phone apps ?
Thanks !
Yes my recommendation is to go with bearer tokens not with forms authentication.
You need to use OAuth 2.0 Resource Owner Credentials Flow which means that end-user provides the username/password only once for a specific endpoint i.e(/token) and then if the username/password valid you obtain something called Bearer Access Token.
This token is valid for specified period and you can configure this in your Web API. Once you obtain the access token, you need to store it securely in your android/hybrid app, then you keep sending it with each request to your web api protected end points using the Authorization header (Bearer scheme). I've written very detailed post which covers your scenario 100%. Please check the post Token Based Authentication and another one for authentication with AngularJS authentication which should work with your case. Let me know if you need further help.