I'm working on a C# MVC application where users submit applications to administrative users for review. Applications can be approved or denied by administrative users. My home page for administrators renders a list of submitted applications, and clicking on each application opens a new page where applications are processed.
My concern is simple: since the "Id" attribute for each application is a hidden html element on the admin "Process Application" form, it is possible that a user could modify the application ID and submit the form (in turn approving/denying the inappropriate application). I can get around this by using a Session object for "AppId" and verifying the AppId posted by the form is the same as the session AppId.
However (and this is the real problem), if I set Session["AppId"] = applicationId that session object can easily be overridden if the user was to let’s say attempt to process another application before submitting the first. Perhaps the admin user fancies their self a multi-tasker and opens two "Process Application" windows. Essentially, the first Session["AppId"] will be overridden by the second. This causes a problem on postback because now I can't validate anything based on Session.
While writing this, I realize I could add controls to prevent the user from processing more than one application at the same time. Is there an alternative approach though? Also worth noting, only admin users would have the ability to forge an application ID, which is unlikely because the Web-App is meant to help the admin users. Really I’m just looking for a best practice for these scenarios, as opposed to fearing someone will actually forge elements on my form.
Is my best approach actually storing an AppId in session, and preventing admins from processing more than one App at a time (so that the session object isn’t overridden)? It would seem so, but I’d love advice from the community.
PS: I realize this issue is similar to Secure way to stop users from forging forms. However, I think the biggest difference is I’m currently allowing users to process more than one application at a time, which prevents me from using a single session object for “AppId”.
I'd approach this from the "sanity & security" point of view. Users should only be able to change what they are supposed to change, data should [also] be validated on server side, and then you can disregard all forgery :-)
The best approach I’ve found is to check the AppId session object on page load. If it exists, then the user did not finish processing the original application (that scenario can be handled in various ways. I'll let you decide what is best, but you could probably redirect the user back to process the original application with an appropriate warning message explaining what happened). This is the only way I can think of to prevent the forgery of an AppId on the form using a single session object.
Related
Objective
Restrict direct URL access to all pages but Logon.aspx ensuring that a user must be referred to every other page.
Driver
The driver behind this requirement is our internal security department. They feel that this is the only acceptable solution to ensure the application is always secure.
Problem
The problem is two-fold, so let's deal with the first one. If a user is logged in and on a page they can copy the URL, open up a new tab, close the previous tab, paste the URL, and the session is still alive. I understand why this is happening but they are saying we need to keep that from happening. And please don't ask me why, if I could answer that I probably would be convincing them otherwise.
The second part of the problem is that the way the application was originally written (insert really angry face here) two of the web forms are reused for enrollment. This specifically means that those pages are accessible even if the user isn't logged in. However, we have to make it so that they were specifically referred to those pages through the process flow and thus not directly accessible.
As an example for the aforementioned paragraph, consider the following. The user copies the URL to one of the shared forms, opens up a new browser, and pastes in the URL. The session is dead but the form displays for the purposes of enrollment. However, this is problematic because they haven't accepted the terms and they have broken the already fragile flow.
What have I tried?
Honestly, nothing. I'm up here panning for ideas because the best I've seen thus far Googling is stuff surrounding ensure the user is logged in first. Some use cookies and others use the membership provider, but the fact that the user is logged in already doesn't address either of my problems.
I look forward to hearing from you all!
Once user has been logged into the system , what the point of hiding anything which you have given access. but anyways here might be few ways to do this:-
For the first the My suggestion is to wrap your page inside an IFrame and disable the right click, so that you cannot access the view source or link information.
Once above is achievable . you can also attach a token to every URL. then you can check the if token is available or not. If available , request is valid, else invalid request.
I will give you more solution if crossed my mind.
Now that my project is almost finished I am trying to implement the login and security.
I got a table in my database with all the users in it.
Next to the normal login and password columns I also got 7 booleans.
Those booleans represent the categories(folders) which the users may access or not.
After the user logins I put the record (user) in my session.
So depending on those booleans I will display tabs in my masterpage.
But how do I implent the security measures which redirects the user back to the login when they aren't logged in yet or when they don't got the proper rights to be on that page.
Somebody told me to add some code in de global.asax but I have no experience with it. And got no idea on how to start and it seems like i can't find any examples on the internet
ASP.NET Membership sounds like what you need. No point writing something from scratch when your chosen Framework will already handle it for you, right?
http://msdn.microsoft.com/en-us/library/yh26yfzy.aspx
So i have a custom CMS running under .Net 3.5 written entirely in c#. The engine is optimized to render for mobile devices, but also server to normal web browsers. It also supports cookieless sessions. Great...
I've chosen not to cache anything (including browser data) in order to control the rendering completely from data. This has been all good until lately.
The engine implements a basic login function that simply logs the user state within a session object.
The behavior is rather strange. User will click through the site no problem. Then login. The login will either go through successfully or just redisplay the login screen, suggesting a cached page being returned or redisplayed... If the login is successful the concurrent page hits will switch arbitrarily between logged in and logged out state... Also suggesting either the session state is not accessible or a cached page being returned.
I have debugged the hell out of the thing.... including using fiddler and the like. When debugging the behavior disappears.
Huh?
One of the sites running on the engine is http://www.wiseguy.mobi (sorry customized for South Africa, so you'll probably not be able to get the password Text Message)!
Ok, so i've been a dumbass...
The issue was related to the fact that my IIS application was running 2 WorkerProcesses. Thus InProc Session state would return different session object states when the user hits either of the worker processes.
This is why the SQL SessionState persistance has resolved it. Either was its set up rather nicely now, and the issues have been resolved...
is there a way to redirect a user when there are n people/sessions on a site. I have a requirement to redirect to a 'sorry we are busy, please try later' page if there are too many people currently engaging the site (this is to stop flooding a live business service that is behind the webpages). The ideal is that only new users (users not already logged in) are shown this page. I was going to just count concurrent logins but wondered if there was a better way to count current activity rather than login status being that most users might stay logged in for a while.
thanks in advance.
There are several ways you could do this.
I think the most obvious way would be to do this in IIS. If you are using IIS 6.0, you can do this by going into the website properties, go to the performance tab and change the connection limit to what you require. You can then customise the default IIS error message (I think this is classified as code 500).
Alternatively, you could do something when the user attempts to login to the website. You would need to have a mechanism to keeping track how many users are connected, one way of doing this might be to use the Membership provider, which allows you to track (count) how many users are currently logged in (presumably through some basic math on the timestamp values in the membership tables).
Finally, you could probably at a push do something with Ajax to keep telling the server that the a user is "still online", but I would do this as a last resort.
My money would be on the first option.
Hope this helps
I have to design a CMS where a set of credentials can only be used once. So if a user has logged in from his computer, no-one can login with his credentials from another location until that user logs out.
Now using the asp.net membership provider out the box, the IsOnline method returns a boolean that reflects the timeout window vs. the last activity date. This is not a viable option for me, because if the user just closes the browser after logging in, IsOnline will still be true. But his session will be destroyed(assuming he's not using Remember Me) so if he tries to log in somewhere else it will say "Sorry you still logged in".
Are there any hard and fast options for doing this..?
I was thinking of forcing the users to be "Remembered" so when he logs in a boolean "IsReallyOnline" will be set to true and vice versa when he logs out.. Although this option has it's limitations, (people turn off cookies, not logging out and closing the browser then sum1 else comes and browser to the site and he's logged in etc....) it seems like the most viable for now?
Any suggestions?
Thanks in advance
You are really asking for something that is outside of the remit of the web. The HTTP protocol is by definition stateless, meaning that at any one time; a server never need know if a client still exists. The newer/older implementations of web server programming languages (e.g. php / asp.net mvc) for the most part shy away from storing any state about connected/active clients.
Some things to ask yourself include:
How long may a user be 'active' on a page without causing a postback? Javascript based pages may allow for a user to interactively be using a page for quite some time before any kind of postback happens.
Will the users be going through a proxy or caching server? Multiple requests from 'different' users may come from the same machine in this case.
Will your application be running on one machine only, or maybe a server farm? You'll need to ensure that load balancing (for example) doesn't punt different users onto different servers allowing multiple logins.
How about a user legitimately using two different browsers on the same machine? Is this to be allowed?
One might suggest your problem here stems from trying to use the wrong technology given your requirements? Maybe writing a client application which uses direct connection to your servers would be more 'secure'? (Yes I understand this is huge hassles but if your one user / one logon requirement is absolute maybe you could explore this avenue?)
Oh alright, a web solution
For a http centric solution you could try a javascript timer making a request to your server every X seconds to indicate that the session is still active. As long as the browser is open and the network connection valid you should be getting these 'pings'. The session is kept open by the cookie passed by the httprequest.
You'll be able to code the 'ping' page to store the user details into either the application object or some membership provider of your choice then interrogate this provider whenever a client attempts to log in.
This will require a relatively short time-out on a session or some other mechanism to ensure that a crashed browser doesn't lock your legitimate user out for too long.
Please note: This will fail horribly if the user doesn't have javascript turned on (Don't assume that they will have!)
Fast Option: Store IsOnline as a session.
Check if session is true, then allow. If not, don't allow.
If user closes browser, he will be logged outas its in a session.