I've a huge classic ASP application where in thousands of users manage their company/business data. Currently this is not multi-user so that application users can create users and authorize them to access certain areas in the system.
I'm thinking of writing a handler which will act as middle man between client and server and go through every request and find out who the user is and whether he is authorized to access the data he is trying to.
For the moment ignore about the part how I'm going to check the authorization and all that stuff. Just want to know whether I can implement a ASP.net handler and use it as middle man for the requests coming for a asp website? I just want to read the url and see what is the page user is trying to access and what are the parameters he is passing in the url the posted data. Is this possible? I read that Asp.net handler cannot be used with asp website and I need to use isapi filter or extensions for that and that can be developed only c/c++.
Can anybody through some light on this and guide me whether I'm in the right direction or not?
Note: To be specific, I cannot modify anything in the existing application because there are hundreds of pages (each page again has couple of different actions, such as posted to the same page again) are there in the system and it is really big mess and we are coming up with a different solution to clear that mess but that takes couple of years to complete, meanwhile to provide the multi-user functionality to the users we are trying to do this. This layer acts like layer where we authorize the user to do certain operation or access a page, nothing more than this.
I've worked with an ASP classic website that runs Javascript on the server side. In IIS we selected JScript as the server-side scripting language and access the session variables and the database simultaneously to check user's access rights when they try to check out various parts of the site. What you're describing is completely do-able. Each page needs to have Javascript in <% %> tags and that identifies the content as server-side code. Be careful with security though!
As for the ASP.NET handler, I also developed an ASP.NET application that I added imported to our site (had to use a .NET thread pool) which could handle Ajax requests. IIS has this option to import ASP.NET applications to your site.
You've got options.
Related
I have an ASP.NET MVC Application and the routing urls looks as follows:
foobar.com/users/8
foobar.com/users/90
foobar.com/exercise/details/5
foobar.com/exercise/details/400
So with this URL route, a user can manipulate the URL directly and change the ID's which are integers. What is the best practice of securing this so that users can't easily manipulate the URL ID's? How do enterprise applications handle this?
For a well designed system, users manipulating URLs should not be an issue. Even if you send the data in an HTTP Post body, users can still manipulate it using an intercepting proxy such as Burp.
Relying on secrecy of IDs (for example, choosing IDs randomly) is also not a solution. In pentester terminology, you will be vulnerable to direct object reference. The classical terminology for this flaw is violation of the complete mediation principle.
Instead of worrying about what users may do with URLs and content sent to your server, you should be securing the server from malicious inputs. The issue here is authorisation. I recommend you have a good, thorough read of Securing your ASP.NET MVC 4 App and the new AllowAnonymous Attribute and NerdDinner Step 9: Authentication and Authorization.
A lot of applications are designed to be URL hackable in that the user can change values. A lot of users like to manipulate the url to change page number, record, etc.
There is nothing wrong with this As long as you make sure its all secure. For instance your Details action should check the user can access record 5 before showing it.
So I am currently evaluating Dart's use as a potential language to re-write a campus organization's website. One critical aspect of this website is it's access control policies. It seems that anything written within the Dart web apps could potentially be compromised, and thus led me to asking the following question.
Is it possible to securely implement access-control to pages in Dart, using either just a web app or a combination of a web app and a dart-implemented server? Could it also be possible to implement that same concept using Apache with a proxy-passthrough to dart?
I don't understand what you actually want to achieve with a proxy-passthrough.
When you create a single page app in Dart all client code is loaded to the client. This is normally no security concern. When a view is shown it usually loads data from a server. Here you enforce security.
You can require the user to authenticate and decide in the server code if or which data you serve for this user or what update command you allow the user to execute. You can just return an error when the user invokes a function that he is not allowed to use.
I've seen several similar scenarios explained here but not my particular one. I wonder if someone could tell me which direction to go in?
I am developing two (and more later) MVC2 apps. There will also be another (thicker) client later on (WPF or Silverlight, TBD).
These all need to share the same authentication. For the MVC2 apps they (preferably) need to be single log on - ie if a user logs in to one MVC2 app, they should be authorised on the other, as long as the cookie hasn't timed out.
Forms authentication is to be used.
All the apps need to use common business functionality and perform db access via a common WCF Service App. It would be nice (I think) if the WCF is not publicly accessible (ie blocked behind FW). The thicker client could use an additional service layer to access the Common WCF App.
What this should look like is:
MVCApp1 -> WCFAppCommon
MVCApp2 -> WCFAppCommon
ThickClient -> WCFApp2 -> WCFAppCommon
Is it possible to carry out all the authentication/authorization in the WCFAppCommon?
Otherwise I think I'll have to repeat all the security logic in the MVCApps and WCFApp2, whereas, to me, it seems to sit naturally in WCFAppCommon. On the otherhand, it seems if I authenticate/authorize in WCFAppCommon, I wouldn't be able to use Forms Authentication.
Where I've seen possible solutions (that I haven't tried yet) they seem much more complex than Forms Authentication and a single DB.
Any help appreciated,
Phil
I thought I should come back to this with what I've learned (and re-learned).
First the re-learned lesson - don't become fixed on an architecture and then try and make everything else fit. I'm fixed on .Net, SQL Server, WCF, MVC2, EF4, and IIS7. Fixing in my mind how I want these to fit together is slighly dumb! Better to go out and look at what guidance exists.
Which brings me to what I learned - here's a link:
http://wcfsecurityguide.codeplex.com/
I discounted this article a couple of times because it's a bit dated. However, I'd say it's actually very relevant and if you're starting a project remotely concerned with securing services go take a look. Part IV had everything I needed.
We are using WCF Web Application hosting Reporting system (we are accessing it from Silverlight) and since it's using same machine keys as our MVC application - we can share cookie authentication as well.
Otherwise, you have to send authentication ticket (custom or not) to your WCF application.
I'm using ASP.NET MVC and I am trying to separate a lot of my logic. Eventually, this application will be pretty big. It's basically a SaaS app that I need to allow for different kinds of clients to access. I have a two part question; the first deals with my general design and the second deals with how to utilize in ASP.NET MVC
Primarily, there will initially be an ASP.NET MVC "client" front-end and there will be a set of web-services for third parties to interact with (perhaps mobile, etc).
I realize I could have the ASP.NET MVC app interact just through the Web Service but I think that is unnecessary overhead.
So, I am creating an API that will essentially be a DLL that the Web App and the Web Services will utilize. The API consists of the main set of business logic and Data Transfer Objects, etc. (So, this includes methods like CreateCustomer, EditProduct, etc for example)
Also, my permissions requirements are a little complicated. I can't really use a straight Roles system as I need to have some fine-grained permissions (but all permissions are positive rights). So, I don't think I can really use the ASP.NET Roles/Membership system or if I can it seems like I'd be doing more work than rolling my own. I've used Membership before and for this one I think I'd rather roll my own.
Both the Web App and Web Services will need to keep security as a concern. So, my design is kind of like this:
Each method in the API will need to verify the security of the caller
In the Web App, each "page" ("action" in MVC speak) will also check the user's permissions (So, don't present the user with the "Add Customer" button if the user does not have that right but also whenever the API receives AddCustomer(), check the security too)
I think the Web Service really needs the checking in the DLL because it may not always be used in some kind of pre-authenticated context (like using Session/Cookies in a Web App); also having the security checks in the API means I don't really HAVE TO check it in other places if I'm on a mobile (say iPhone) and don't want to do all kinds of checking on the client
However, in the Web App I think there will be some duplication of work since the Web App checks the user's security before presenting the user with options, which is ok, but I was thinking of a way to avoid this duplication by allowing the Web App to tell the API not check the security; while the Web Service would always want security to be verified
Is this a good method? If not, what's better? If so, what's a good way of implementing this. I was thinking of doing this:
In the API, I would have two functions for each action:
// Here, "Credential" objects are just something I made up
public void AddCustomer(string customerName, Credential credential
, bool checkSecurity)
{
if(checkSecurity)
{
if(Has_Rights_To_Add_Customer(credential)) // made up for clarity
{
AddCustomer(customerName);
}
else
// throw an exception or somehow present an error
}
else
AddCustomer(customerName);
}
public void AddCustomer(string customerName)
{
// actual logic to add the customer into the DB or whatever
// Would it be good for this method to verify that the caller is the Web App
// through some method?
}
So, is this a good design or should I do something differently?
My next question is that clearly it doesn't seem like I can really use [Authorize ...] for determining if a user has the permissions to do something. In fact, one action might depend on a variety of permissions and the View might hide or show certain options depending on the permission.
What's the best way to do this? Should I have some kind of PermissionSet object that the user carries around throughout the Web App in Session or whatever and the MVC Action method would check if that user can use that Action and then the View will have some ViewData or whatever where it checks the various permissions to do Hide/Show?
What you propose will not work. Actions can be cached, and when they are, the action (and hence your home-rolled security) does not run. ASP.NET membership, however, still works, since the MVC caching is aware of it.
You need to work with ASP.NET membership instead of trying to reinvent it. You can, among other things:
Implement a custom membership provider or role provider.
Subtype AuthorizeAttribute and reimplement AuthorizeCore.
Use Microsoft Geneva/Windows Identity Foundation for claims-based access.
Also, I completely disagree with ChaosPandion, who suggests making structural changes in your code before profiling. Avoiding exceptions for "performance" reasons is absurd -- especially the idea that the mere potential to throw an exception for invalid users will somehow tank the performance for valid users. The slowest part of your code is likely elsewhere. Use a profiler to find the real performance issues instead of jumping on the latest micro-"optimization" fad.
The correct reason to avoid exceptions for authorizations is that the correct way to indicate an attempt at unauthorized access in a web app is to change the HTTP status code to 401 Unauthorized, not throwing an exception (which would return 500).
Define your authorisation requirements as a domain service so they are available to both the web and web service implementations.
Use an authorisation filter to perform your authorisation checks within the web application, this should be as simple as creating an auth request object and then passing it to your auth domain service.
If the authorisation fails, return the correct error - a 401 as indicated by Craig Stuntz.
ALWAYS authorise the action. If you can hide the link to unauthorised users - thats nice.
Simplify your views / view logic by writing a HtmlHelper extension method that can show / hide things based on a call to the auth domain service.
To use your authorisation service from the web service is simply a matter of constructing the auth request object from something passed in via the service message instead of from a cookie passed by the users browser.
I'm building a .Net MVC app, where I'm using one particular view to generate an internal report. I don't want the users of the site to gain access to this page at all.
I've a console app that fires every so often which will scrape some of the details from this page by hitting it's URL.
I don't like the idea of having the URL hanging out there but I'm not sure of another way to go about it.
Thoughts on what might be the best practice way for tackling this?
Edit:
Here's what I ended up doing, created a new WCF Service project in the solution. I also copied basically what was the MVC view page into a new standard web forms page in this project. On top of adding security via the regular .net Authentication methods (eg set only valid windows users can access the page), I can also lock down the vhost to only be accessed by certain IP's.
The best practice would be to expose a wcf service for this, and set up a security model that is different than website.
If you must use MVC the best approach use forms authentication with mvc and set
[Authorize(Roles = "SecureUser")]
On the View.
If the view never needs to be rendered at all except to provide data for the console app, then why not have the console app simply connect to your database to get the data directly instead of going through the web app? You could still do this for the console app even if the view does need to be available for some users, then control access to the view using the Authorization attribute, which could suitably restricted now that an external app need not have access to it.