I'm thinking of creating a diagnostics page for an ASP.NET app, which would be mostly intended for admin use to get more information about the application for diagnosing problems.
Examples of the info the page might have :
System.Environment.MachineName (might be useful in web farm scenarios)
System.Environment.Version
Environment.UserName
database name
current user's session ID
Some of the info on this page might be sensitive from a security perspective.
If you've done this sort of page before, what sort of security did you put on access to this page ? .
EDIT :
I should add - occasionally it might be useful to see this page whilst logged in as a specific (i.e. real) end user. e.g. say a problem can only be reproduced when logged in as a particular user. Being able to see the diagnostics page for that user might be useful. e.g. knowing the current session ID might be helpful for debugging.
EDIT 2 :
I'm starting to think that this diagnostics page should in fact be two different pages. One to display stuff which is the same for all users (e.g. database name, CLR version), and another for stuff which can vary by session (e.g. browser info, session ID).
Then you could lock down security more for the first page.
Yes, I've added this sort of page before (and found it useful). The security was pretty simple: the page contained a password form. The server-side code checked this password against a configured value and, if correct, displayed the real content and set a value in the user's session to say that they've been authenticated as a developer, so that they're not prompted again next time.
I suppose there was also a little security by obscurity, since the URL of the page wasn't published anywhere.
I was also careful not to reveal anything really sensitive on the page. For example, it allowed viewing our application config values, but masked out anything with "password" in it - hey, if we really want to see the password we can open a remote desktop session to the server.
There's also a couple of other ways you could do this:
If your web application has user authentication, restrict access to this page by checking that the user is flagged as an administrator or belongs to some kind of admin role.
Use a simple if (Request.IsLocal) ... type check, though the downside of this is that you still have to connect to the server and browse the website locally - which might not always be possible. However, this does still have the benefit of being able to easily view key system settings.
Personally, I've used a combination of both methods where a local request always allows access, and non-local requests require an admin user - eg. if (!Request.IsLocal && !IsAdminUser()) throw new SecurityException().
Also, I'm in agreement with Evgeny - be careful not to reveal anything really sensitive on this page (such as application connection strings or passwords).
use forms authentication and setup a user or two with access to that page. that way you can change passwords and revoke access once the site is deployed.
It sounds like you want a robust solution for your error page. I would take a look at open source projects like Elmah (http://code.google.com/p/elmah/) for a good example of a robust error page which includes configurable security. To give you an idea, here is a post on configuring Elmah which takes you through setting up the security. The security I have tested allows me to use my domain credentials to login.
Related
I have built an ASP.Net MVC site using Forms Authentication for a client.
Recently, they have requested that an authenticated user be restricted to a single browser session. That is, if the user raises a new browser instance, or opens a new tab on the original browser window, that he/she be logged out of the original. They insist on the added security.
Does anyone know how I might approach this? Thanks in advance.
Personally, I would push back and ask exactly what security this is bringing. Maintaining state like this counter to web architecture and is only going to bring you and your users grief.
Here is what I would do if presented with this problem:
Store the username of the user in your database (i.e. LoggedOn table).
When a user logs on, check to see if their username is already present in the LoggedOn table.
If the user isn't already logged on, insert a row into the table with the username and the current time; otherwise present the user with a message informing them that they can only log into the system from one device at a time.
Include logic to expire and delete the rows in the table if a user's session expires or if the user logs out.
First a disclaimer: I'm no expert in web programming.
Perhaps you might try a system where every user interaction requires the submission of a random value that's been generated for that page (much like what's used for CSRF protection.) That key could be kept under the user's session information on the server, and if a page is ever requested without the correct key as a URL parameter, the session is invalidated. The URL from one browser won't work in another, either, since once a URL is gone to, the user's session key has changed. The only way for a user to transfer a session between tabs would be to copy the URL of an unclicked link and paste it in a new tab's address bar. Switching browsers would be even more complex assuming that ASP.Net uses a session cookie: the user would have to transfer the cookie from one browser to another. Going back would also fail, as all the links on the previous page, and the URL for the page, would carry an incorrect session key.
Also, for reference, I believe the US Gov't TreasuryDirect site works in the way you've described, though I've never looked at how they manage it.
Thanks, people for the suggestions. Each had strong merits, however I had to take a hybrid approach. I found an incredibly simple suggestion from this post.
I implemented table of active users as Karl suggested as well. This will give the client the ability of deactivating the user on demand.
Thanks again.
Think of it as one active view at a time instead of one browser or tab. Or convince the customer to view it this way.
You can always issue a unique cookie for the browser session (ASP.NET Session) and allow communication to the latest cookie issued effectively making only one session active at a time, and therefore rendering other open sessions (browsers, tabs, etc) useless with the app by disallowing them communication any longer or serving up an error page for them. To do so you have to recognize who the user is and authenticate them against your app. This is half the puzzle and will force the user down to use your app in only a single browser at a time on their machine.
The other part of the problem is to pare down the windows and tabs that are part of the same browsing session of that browser, to allow only one view to be active at a time. To do so you can issue a unique sequential ID to the viewstate of each page for postback to the server to uniquely identify that page apart from other pages sharing the same session state (whether that page be in a browser tab, a frame or new window, etc). Or a code of your choice that's traceable. You then know which page is posting back within the session and can disallow others or deactivate previous ones by, again, shutdown down communication in some manner or serving up an error page, etc.
A new browser instance or a new tab may or may not be part of the same browsing session depending on how the browser is configured. I believe, for example, IE provides a setting that allows the behaviour to be set of whether a tab opens in a new process or session or shares the session. You won't necessarily get expected consistency across browsers to rely on for this feature, therefore you need to take programming steps to reign it in, like those described above.
You can additional steps like disallowing the user to be connected from a different IP# at the same time.
I have an existing Wordpress site. The plan is to rebuild the site using the cakePHP framework. Due to time restrictions, I want to replace individual sections of the Wordpress site one at a time. This will mean that both apps will be running side by side for a certain period of time. I need to control access to the cakePHP app using the authorization provided by Wordpress. I'm not sure the best way to go about doing this. I've seen similar questions asked a lot, but I have not yet found a clear solution.
I'm thinking about two approaches:
Plan A:
Configure Cake to look for Wordpress's authorization cookies.
configure Cake to look at Wordpress's database.
Borrow some of Wordpress's authorization logic to teach Cake's Auth component how to authenticate WP users.
Plan B:
set up an authorization API on my Wordpress site.
set up separate auth component in cake.
ping the WP endpoint when a user hits a protected page in the cake app and then manually log in the user. (This would create a second set of auth cookies)
Do either of these sound like the right approach? Is there a better way to do this?
Helpful references: Article about Cake session handling, Cake Auth component documentation, Cake Auth tutorial, brief overview of WP authorization, a more in depth look at wordpress authorization
UPDATE
We've started working on this, and it seems like it will work, but there is a very tricky aspect involving password hashing that warrants its own question. If you're following this thread, you may want to have a look.
I once had a similar situation: Cross framework authentication zend + codeigniter which was few months ago...
Anyways, this is what I will prefer:
set up an authorization API on my Wordpress site.
set up separate auth component in cake.
ping the WP endpoint when a user hits a protected page in the cake app and then manually log in the user. (This would create a second set of auth cookies)
Here, I would suggest a slight change which is do-able.
Make sure, you have a token system of SSO. As in, when person is logged in on Wordpress, set another cookie which will have a token: Token will be username + password (hashed) + secret key, which will be same between Wordpress and CakePHP. On either site, look up for cookie and manually log the user in or just perform a database look up. Hashing is important for that cookie!
However, if the site is using different domains, you might need to re-strategize:
I had different domains once. At the login or unauthorized page, I would ping the other website and bring up their login box. On the other website if the user is logged in, they get post login page and if request URI has sent a token, we perform normal operation and return the authorized token to this (current) domain.
In simple words:
Site A = WordPress & Site B = CakePHP
Site B hits a page where authorization is required then, ping Site A for a login (as it happens when u do Login-with-Facebook sort), which will request via a Token (private key) and REQUEST_URI which will be part of SSO verification table on Site A, if person is already logged in then, Site A will return (via POST) a token, which further will be decrypted via (private key) of Site B and log the user in. Private key of B and A will be same.
Hope this was understandable.
Questions? :)
Answer to your questions in comment:
Ideally, why we use SSO? We use it because of many constraints. For example: You have a database of say... a million row with more than thousand tables, you need to add a module over ur huge app already... so, instead, you will use another database... SSO will return user information, which can further be replicated. For example, when you click on 'Login with Facebook', it returns requested information, like email address, or user's name or even profile picture. Which can further be added to our database... Keeping different databases is strongly recommended :)
To your 2nd and 3rd question: Should both sites reference the same users table in the database? different databases is recommended unless, you are using the same data. Or say changing the software platform.
Should I copy the site-specific user rows into separate user tables for each app? Yes, that should happen automatically. Once you are registered on a main site, nothing happens, things should happen once you are logged in already and then go to site B... Once logged in, user info can always be requested :) That way, new site will have active users ! 2 birds?
Don't complicate (bother) yourself with how what works but, concentrate on how, what is achievable in short period. SSO - Logged in - Restricted page - Look out for log ins - Either login - If already logged in - fetch user info - If user info exists - login via secondary site OR set the new user info . Done!
We developers love flow charts! Don't we? I just created one:
Further answers:
Does the "Fetch User Info" stage mean that we take the user info from the site which is logged in, and create a new user (row) automatically in the other site?
Ideally, you will ask permission from the user before they 'allow' their info to be used but, it varies how your privacy policies are.
In other words, one site handles all the registration/user-creation and the other site just waits for that user to show up and trigger automatic creation. OR at the moment a user registers on the one site, BOTH databases get a user row inserted?
one site handles all the registration/user-creation and the other site just waits for that user to show up and trigger automatic creation. You can have both. Sign up on your website and also a trigger based automatic creation. Depends on your strategy. OR at the moment a user registers on the one site, BOTH databases get a user row inserted? That would be a horrible practice! It will kill the motive of SSO. Motive of SSO is to create an auth family which can be used by users so that they do not have to register every now and then for different websites. update only one database at a time and other when required :)
Questions? :)
I have done this once. I don't have the snippets and/or any references to anything. But thought it might be helpful.
Configure WP and CakePHP both to use same session, you can do this by session id and session name,
When User registers for your website, register them using both WP and CakePHP,
Choose one framework that will handle login view from the front end. I had chosen CakePHP as I was more proficient with it, once the login is successful locate the same user in other framework's DB and authenticate the user using their authentication system.
Hope this helps !!!
Suggestions:
If you are building a closed system, meaning you have to be signed in to access anything useful in the site, then you can use CAS . I know it's used by mainly universities, but for closed systems it works.
( If you need to handle anonymous users the suggestions below might help)
Keep it simple and, similar to Part A of your plan, have a cookie ( visible by both cake and wordpress ) that simply states if a user is logged in. The cookie should be created/checked by both cake and WP. Cake does not need to look at WP's DB. The cookie can have information on how the users in each system are mapped.
Have a central login screen, this is similar to what CAS does. But please build your own. CAS does not handle anonymous users. I am currently creating a central login screen for work. It's simple. The central login screen will handle all authentication and create the cookie visible to both WP and cake. This would mean that the login link for WP and cake will redirect a user to a common page. The link will need to provide a callback URL so that after the user authenticates successfully, he is redirected back to the original service. You will need to decide on a central DB for user authentication.
The cookie approach has following bonus:
It's a lightweight solution and can be wrapped with an on/off switch. In WP, simply wrap the cookie logic with a wp_options value.
You can use WP's and cake's authentication system. no need to work with API's and/or sessions. No need to couple applications by looking at each other's DB.
You can keep roles and permissions native, meaning WP will work with it's own roles and permissions system and your cake application will work with it's system.
Adding a new "service" to your platform is as simple as "create/check for a cookie" then use the system out-of-the-box auth system to log the user in.
Single Sign On is as simple as creating a cookie. Single Sign Off would be deleting the cookie.
I can definitely go into more detail on each suggestion if you're interested.
How does Symfony's security component work?
Currently, I grab user login data, auth them against a database, and store their info in a session variable to log them in. When a user accesses a page, it checks their session to ensure they have rights to view a specific page. All of this is organized into services.
I've been looking into Symfony's security component but can't figure out exactly how it works. Specifically, is there some extra security benefit (I have an admin panel that I need to have proper security on) that it offers?
I also hate learning framework specific stuff without understanding what's going on, so would appreciate a general breakdown of how the component works.
Thanks
This video is a good resource of how the security component works. The video is from the Symfony live conference in Paris last year. The speaker Johannes Schmitt is the one who has led the development of the security component.
http://www.youtube.com/watch?v=lSxgEK8WKGA
Security is a two-step process whose goal is to prevent a user from accessing a resource that he/she should not have access to.
In the first step of the process, the security system identifies who the user is by requiring the user to submit some sort of identification. This is called authentication, and it means that the system is trying to find out who you are.
Once the system knows who you are, the next step is to determine if you should have access to a given resource. This part of the process is called authorization, and it means that the system is checking to see if you have privileges to perform a certain action.
More information can be found at :
http://symfony.com/doc/current/book/security.html
Im building an ASP website with user login. Does any one knows what is the best and must secure way to make login page and make pages restricted access? I know some ways and used them for some website but sometimes they were not that secure. There is couple access level for this website. Admin, User, Sales Team, and couple more. Thanks.
you can use session variables to store user level and then on asp code define what user can or can not see.
Or in database, I assume, you have field where level of access is defined as well.
Basically make your security level part of SQL query and show only data user should be able to see.
Basically you should have level of access in database, login page verify credentials and then store user level in session variable.
On any given page, while header loads, ASP retrives session variable and compare it to database.
If user have clearance to see that data he will if not-- display message that he is not authorized or redirect somewhere else where he can be.
Add an include file at the top of your ASP pages which is executed before any of the page's code. This way you can write your security code once, and apply it to all of your pages.
Assuming you are using IIS as your web server, you can let it handle your website security by using the different available authentication methods.
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/9b619620-4f88-488b-8243-e6bc7caf61ad.mspx?mfr=true
http://www.authenticationtutorial.com/tutorial/
Perhaps the best authentication method for you would be Windows Integrated Authentication since it allows you to create groups (or maybe use the existing ones) to give access to certain directories or pages.
Encouraged by SO, I'm trying to write an ASP.NET site that uses OpenID for user authentication. It's a regular WinForms site (not MVC.NET), using the DotNetOpenId library for authentication.
Is it safe for me to permit/deny administrative functions on the site by simply comparing the current session's "ClaimedID" (as returned in the OpenIdLogin_LoggedIn event, as member DotNetOpenId.RelyingParty,OpenIdEventArgs.Response.ClaimedIdentifier) to a known administrator's OpenID (i.e. mine)?
If so, is it safe for this ID to be visible (e.g. in open source code), or should it be "hidden" in a configuration file or a database row? (I know it's better design to make it configurable, my question is just about safety.)
My solution is to follow the same idea of the Roles table. After you've authenticated the user, look up that user's roles. If the user has role "Administrator" in the UserRoles table, then they can do whatever the Administrator can do.
I don't broadcast open ID's in my app. They're stored in the table. On every action result, I'm hitting the Users table, since I have also modified mine to store various user state information. With the exception of the home page, there is going to be some user information that I need from that table. I'm using LINQ, so I include the .LoadWith() to load the User with his list of roles when it serializes.
Jarrett makes some good comments about using database tables.
Just to answer another one of your questions, no, it's not a confidentiality thing to put your OpenID in your code generally. If setting up roles seems overkill for your site, a simple equality check against your ClaimedIdentifier is just perfect.