I have a LOB Silverlight app that uses web services, and forms authentication to authenticate users. The app has a lot of state on the client side. My problem is when the client comes back to the app after a period of inactivity, and their authenticated session has expired so they get authentication errors back from the web services that require authentication.
What is the best method to prevent this situation?
I have tried using a "heartbeat" via dummy web service method that is called at a regular interval and that seems to work for keeping the session alive, but is there a better solution?
You can increase session timeout or send regular request to service for keeping the session. Or when session is expired ask user relogin to application. I guess, it's standard practices for Web application based on ASP.NET infrastructure.
This post is what I have done and it appears to accomplish what you are asking
Preventing an ASP.NET Session Timeout when using Silverlight
Related
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.
We are planning to implement an AngularJS web application communicating with Business components via REST service layer. The web app needs to offer authentication mechanism.
For example we are particularly concerned by the user authentication process since Angular code is practically available to the users on their clients.
And how can we reassure that the users are authenticated after the initial authentication process (in JSP/PHP we would use sessions)?
Could you please give us some pros. and cons?
Your right client side code is available, viewable, and editable thru standard browser developer tools. If your company does any type of security audits on your software you'll find that for security reasons processing is done on server side outside of the view of the client code. The companies I have worked for have taken the approach to trust nothing that is sent from the client side to the server.
On the server side the REST layer typically contains a authentication layer that will bubble back to the client when.
-invalid session
-incorrect permissions to make rest call
-invalid REST args
-prevents script jacking into text fields
-etc...
When working with angular or other client side only applications, I recommend using Token based authentication.
A demo application in Angularjs
Token Based Application
Angular JS, Web API Token Based Authentication
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.
I'm start building a web application where the user needs to authenticate in order to get access to different modules.
I have been working with ASP.NET MVC in the past and it was quite easy using FormsAuthentication and Server Sessions so I don't have to do roundtrips to the database in order to get the user roles or any other user related data everytime I access a web method.
What I have been reading, AngularJS won't work that way so there won't be any Server Session, etc.. So...
In case I need to verify user identity every time I access a web method do I need to consume database or there is any good practice that I can learn of?
I know there are ways to store state data in client side but how that can affect the performance of a web application?
I have seen that when a user login to an application the best way is to send a Token to the client and then force AngularJS to send that Token everytime a web method is accessed... but what about sending to the client the user sessionId (from database) and then on every web method consumption sending that and then create a filter where you check that the sessionId exists in the database so the user identify is validated?
Appreciate any advice or recommendations.
Thanks.
My take on authentication is that you do not need to bring AngularJS into picture till the user is authenticated. You use simple login page and authenticate user and then redirect him to your app page that has Angularjs. Look at my old answer for more details How to handle authentication in Angular JS application
Let me try to address your concerns.
In case I need to verify user identity every time I access a web
method do I need to consume database or there is any good practice
that I can learn of?
Once you have been authenticated that part is taken care by server and browser cookies, you don't need to do anything. How standard MVC site works.
I know there are ways to store state data in client side but how that
can affect the performance of a web application?
Since AngularJS is a SPA, there is no page refresh. Data stored at $rootScope or using service are there till one refreshes the page. Performance would be better as there are less round trips involved.
I have seen that when a user login to an application the best way is
to send a Token to the client and then force AngularJS to send that
Token everytime a web method is accessed... but what about sending to
the client the user sessionId (from database) and then on every web
method consumption sending that and then create a filter where you
check that the sessionId exists in the database so the user identify
is validated?
This is standard form authentication, and transparent to developer, whatever was required to be done in traditional MVC app for authentication would work here. You don't have to worry about sessionids, tokens etc. To get users identity on the client, you can write a angularjs service with methods such as getUser to get the current logged in user. But i warn you that the authorization related decision should still be done on server.