As you already know, due to the missing sticky session functionality, session information in Azure web roles have to be stored in places like SQL Azure or the Appfabric Cache when using multiple role instances. I know this is the best approach - but apart from that, would it also be possible to store sessions on client side like described here on msdn? I can imagine using cookies would be easy, but what about the other solutions mentioned there? I'm not going to do this, I'm just interested in how reliable such a solution would be.
Yes, these options are all available.
As far as the client side is concerned there's no discernible difference between an ASP.NET site running on Azure from any other kind of ASP.NET site.
If you know you are working with clients with reasonably recent browsers (such as mobile devices) you may find HTML 5 storage is also an option. See here: http://dev.w3.org/html5/webstorage/
Related
What are the pros and cons of Azure Active Directory to manage the accounts of a simple website (at most 10 accounts, just for login to control panel), instead of SQL membership provider or the new bogus identity system in my own database. I never tried this service before but I like the fact that I don't need to take care of the database and credentials of my users, it's free and very secure I guess. Someone has tested it in production? any security advise? thanks.
Among the many upsides there's that it is free, highly available, enterprise-grade and basically management-free - all flows for entering and changing passwords and similar are already implemented for you. Also, it can be used for both web sites and web API - so that if tomorrow you want to add a mobile app for the same user population, we've got you covered.
About having tested it in production... yes, there are many many (MANY) apps using AAD in production today.
I guess that one possible downside for such a small use case is that all the defaults are set to a higher security level than you'd probably use in your scenario, translating in a bit more involvement from your users: passwords templates requiring special characters, mandatory password expiration, and so on. Of course to me it's a good thing, but I am biased :-)
Another current limitation is that the user names must be of the form alias#yourADdomain, as of today you cannot use an arbitrary string. That's usually not a big deal, but calling it out in case you have preexisting user names you need to stick to.
HTH
V.
How to work when internet connection down in a asp.net application ?
Means Users are working on application and suddenly internet connection down then user should still be able to add/edit/ delete operation on data, but when internet connection is up then
all changes should be done at server. Is that possible, Is there any example available to achieve this?
Thanks.
HTML5 has some offline capabilities. http://www.html5rocks.com/en/features/offline
But do you really have a business case for this? It will get complicated when you need to try and update stale data etc.
This requires use of JavaScript to store local data http://code.msdn.microsoft.com/Working-with-HTML5-local-b0cbe2ef and it needs to check whether the server can be reached before doing a proper postback, or more likely just use AJAX to communicate between the JavaScript application and the server.
There are several applications like this such as Google Mail, and such solutions are more JavaScript based than ASP.NET and you need to avoid relying on the web forms mechanisms and use .NET for building the initial page, dealing with AJAX requests and managing the application data and persistence. See How to write an offline version of an AJAX/ASP.NET web application
I build ASP.NET websites (hosted under IIS 6 usually, often with SQL Server backends and forms authentication).
Clients sometimes ask if I can check whether there are people currently browsing (and/or whether there are users currently logged in to) their website at a given moment, usually so the can safely do a deployment (they want a hotfix, for example).
I know the web is basically stateless so I can't be sure whether someone has closed the browser window, but I imagine there'd be some count of not-yet-timed-out sessions or something, and surely logged-in-users...
Is there a standard and/or easy way to check this?
Jakob's answer is correct but does rely on installing and configuring the Membership features.
A crude but simple way of tracking users online would be to store a counter in the Application object. This counter could be incremented/decremented upon their sessions starting and ending. There's an example of this on the MSDN website:
Session-State Events (MSDN Library)
Because the default Session Timeout is 20 minutes the accuracy of this method isn't guaranteed (but then that applies to any web application due to the stateless and disconnected nature of HTTP).
I know this is a pretty old question, but I figured I'd chime in. Why not use Google Analytics and view their real time dashboard? It will require minor code modifications (i.e. a single script import) and will do everything you're looking for...
You may be looking for the Membership.GetNumberOfUsersOnline method, although I'm not sure how reliable it is.
Sessions, suggested by other users, are a basic way of doing things, but are not too reliable. They can also work well in some circumstances, but not in others.
For example, if users are downloading large files or watching videos or listening to the podcasts, they may stay on the same page for hours (unless the requests to the binary data are tracked by ASP.NET too), but are still using your website.
Thus, my suggestion is to use the server logs to detect if the website is currently used by many people. It gives you the ability to:
See what sort of requests are done. It's quite easy to detect humans and crawlers, and with some experience, it's also possible to see if the human is currently doing something critical (such as writing a comment on a website, editing a document, or typing her credit card number and ordering something) or not (such as browsing).
See who is doing those requests. For example, if Google is crawling your website, it is a very bad idea to go offline, unless the search rating doesn't matter for you. On the other hand, if a bot is trying for two hours to crack your website by doing requests to different pages, you can go offline for sure.
Note: if a website has some critical areas (for example, writing this long answer, I would be angry if Stack Overflow goes offline in a few seconds just before I submit my answer), you can also send regular AJAX requests to the server while the user stays on the page. Of course, you must be careful when implementing such feature, and take in account that it will increase the bandwidth used, and will not work if the user has JavaScript disabled).
You can run command netstat and see how many active connection exist to your website ports.
Default port for http is *:80.
Default port for https is *:443.
Like a lot of people I've gone with ASP.Net Forms authentication because it's already written and writing our own security code we're told is generally a bad idea.
With the current problems with ASP.Net I'm thinking it might be a good time to look at alternatives.
Important: ASP.NET Security Vulnerability - ScottGu
Video demonstrating attack
Microsoft advisory including workaround
From what I understand Microsoft tend to store things on the client side because it makes it easier to operate over server farms without needing database access calls.
I don't really care about server farms though and I'd like to simply have an opaque cookie that demonstrates my lack of trust in the callers.
Is there a decent solution that's already been proven solid?
Update: to clarify my question. I'm talking about the authentication token part of the forms authentication that I'd like to replace. The back end is quite easy to replace, you can implement the interfaces to store your users and roles quite easily. You can also use existing libraries like http://www.memberprotect.net/ which has been mentioned here.
I'd like to change the front end part of the process to use a token that doesn't provide the client with any leverage. Sticking with the existing back end infrastructure would be useful but not essential.
I've been working on an HttpModule that basically does what you're looking for. When a FormsAuthenticationCookie and FormsAuthenticatedTicket are generated, before the response is sent to the client (i.e., during the processing of the postback of the Login page/action), all of the details about the cookie & ticket are stored on the server. Also, the UserData from the ticket is moved to the server (if present) and replaced with a salted SHA-512 hash of the other properties in the ticket along with a GUID that serves as a key into the server-side store of the ticket.
The validation of the cookie & tickets compares everything the client provided (optionally including their IP address) with all of the properties that were known about them at the time they were issued. If anything doesn't match, they are removed from the request before the FormsAuthenticationModule even kicks in. If everything does match, the server's UserData is stuck back in the FormsAuthTicket in case you had any modules or code that depend on it. It's all transparent. Plus, it can detect suspicious and blatantly malicious requests and inserts a random delay in the processing. It also has some explicit padding oracle workarounds in there.
The demo app actually lets you create/modify your cookie & ticket values on the server, with the server encrypting your ticket for you with the machine keys. This way you can prove to yourself that you can't create a ticket/cookie that gets around the server validation unless you write the exact set of data to the server (which should be impossible under normal circumstances).
http://sws.codeplex.com/
http://www.sholo.net/post/2010/09/21/Padding-Oracle-vs-Forms-Authentication.aspx
http://www.sholo.net/post/2010/09/22/Sholo-Web-Security-and-the-EnhancedSecurityModule.aspx
-Scott
If you have your keys in the web.config and the attacker gets to it, they are pretty much done.
If that's not the case (they don't get the keys from your .config), then afaik the padding oracle shouldn't allow them to sign a new auth ticket. The paper explains ability to encrypt by taking advantage of the cbc mode, ending with a tiny bit of garbage there. It should be enough to make it an invalid signature.
As for the video where they get the keys with the tool, its against a dotnetnuke install. A default dotnetnuke has those keys in the web.config.
Implement the workaround, keep your keys off your site level web.config, if you don't use webresource.axd and scriptresource.axd disable those handlers, and apply the patch as soon as ms releases it.
I will simply recommend taking a look at InetSolution's MemberProtect product, it's a component designed with security in mind for the banking and financial services industries but is widely applicable to any site designed on ASP.NET or application built on top of the .NET platform. It provides support for encrypting of user information and a host of authentication methods from the simplistic to the very advanced and the various methods and functions are designed to be used as the developer sees fit, so it's not a canned solution so much as a very flexible one, this may or may not be a good thing depending on the particular situation. It's also a very solid foundation on which to build new member-based websites and applications in general.
You can find out more about it at http://www.memberprotect.net
I am the developer for MemberProtect and I work at InetSolution :)
This isn't a value-less question, but I have to say that I think your logic is suspect. It's no bad idea to consider alternative authentication solutions, but the newly-announced ASP.NET vulnerability should not push you to abandon a current (presumably working) solution. I'm also not entirely sure what the relevance of this comment is:
From what I understand Microsoft tend to store things on the client side because it makes it easier to operate over server farms without needing database access calls.
What is it about the vulnerability that makes you think that ASP.NET forms auth is broken any more than another solution?
The detail of the MS advisory would seem to suggest that pretty much any other authentication system could be rendered similarly vulnerable to attack. For example, any solution that uses the web.config file to store settings would still have its settings open to the world, assuming a successful attack.
The real solution here is not to change security, but to apply the published workaround to the problem. You might switch authentication providers only to find that you are still vulnerable, and your effort has gained nothing.
Regarding tokens/sessions: you have to push something to the client for authentication to work (whether you call it a token or not), and it's not this part of the process that causes the current security issue: it's the way the server responds to certain calls that makes this secret vulnerable to attack.
I am looking for ways to keep track of simultaneous users within an application. I cannot use IIS logs due to a load balancer that abstracts the users IP address. I am looking for a .NET code based solution or a configuration item, possibly with health monitoring to be able to track the "true" simultaneous user count.
I know that I can monitor the number of sessions, but that isn't really an ideal method to show, as it can be bloated based on the number of sessions with users abandoning their session.
There is a similiar question here: Tools and methods for live-monitoring ASP.NET web applications?
I found an advanced logging tool for debugging and monitoring .NET applications: SmartInspect. But I don't know if it meets your requirements.
What do you mean of "simultaneous users"? Perhaps you should monitor simultaneous TCP connections to your IIS application? Windows Performance Monitor tools should help you there.
Otherwise there is no sure way of telling how many users are using your application right now. If you can monitor number of sessions, then I'd suggest going with that. Just take into account the last modification time of the sessions, so you could get something like "active sessions in the last minute". That should give you a close measurment.
In the end we decided to use ASP.NET Performance counters, as well as generic information from the IIS Logs.
I parsed the information from both sources using the Microsoft Log Parser tool!
You just want to know the number of active users at a particular time? An easy option that omits inactive users as well as most bots would be to register the user as active through a JavaScript AJAX call on page load along with their SessionID. You can then purge old records from the log as you see fit. *Be careful of how you build your table's performance for read/write optimizations. ... just an idea off the top of my head.
We are using an expensive solution which is AVICode but it is great. You can monitor so many thing with that.