I'm using ASP.NET and rely on the web.config file to secure sections of my site. However, is this truly reliable, or is it also a good idea to add an IsAuthenticated check in the Page_Load event? Also, is it possible for someone to directly call methods (assuming they somehow got my method names and method signature) in my application's DLL? For example, I have a method to add users to a specific group. Can an attacker somehow call that method through their own custom POST and execute it?
Thanks
If you are concerned about specific methods being executed without permission, I'd use code attribute security or your own roles check system to secure the method regardless of who's calling it. I could imagine scenarios where even friendly developers call methods accidentally without making sure the code path has the right to perform privileged functions.
Related
Currently working on an ajax call to an ASP web service (.asmx).
In a situation where I POST to the url/.asmx/WebMethod, am I exposing information of any kind?
In the 'WebMethod' I am running a PostJsonAsync that calls an API and passes along a json string.
As I am still learning, I've been told that calling any public [WebMethod] exposes the code, but I am not sure how that is possible.
Is it possible at all for a user to access the WebMethod server-side code that I have and peek into the API calls that are available?
I've attempted some minor security methods.. We are working with Sitefinity CMS. What I did was call a WebMethod that receives the CurrentUserIdentity and returns a GUID. If the current user is logged in, it returns a valid Guid, if not it returns a Guid full of zeros.
Then, I call the WebMethod containing my API call and post a json object along with the valid or invalid GUID. The server-side WebMethod code will then verify if the GUID is valid and continues based on if a UserProfile can be generated.
To me, this seems to be secure, but I've been told that this still leaves the WebMethod exposed as well as the API. I am however just not understanding what is exposed and what can be used.
If anybody can direct me to any resources that has more information on this, or if anybody can advise me on WebService security, I would appreciate it.
Thanks in advance.
If you're calling the methods via AJAX, then they are exposed to the public...and can be called by anything that can make a call to your server. That being said, there's nothing wrong with it unless you're doing something that's easily abused.
In your particular case, it sounds like the code is accepting a GUID that is assumed to have come from the first API call. If that's really the case, you may want to rethink how the mechanism works. Adding authentication checks for each method that needs to be restricted may be a better solution.
I'm new to this AJAX approach when you're not supposed to use UpdatePanel but rather go with WebMethods and WebServices. My main problem is authentication.
When page is entered or postback request is created, everything works fine. Authentication is passed correctly and I can access Thread.CurrentPrincipal.Identity and get my user identity object from there.
However this changes when I try to call WebMethod on my page. Call is passed correctly to server and everything seems to work just fine until i try to get user identity from thread. Then I get just Anonymous user instead of real one. Enabling session on webmethod didn't seem to help much.
Any ideas what might cause this problem and how to solve it? Someone mentioned that authentication cookie needs to be passed along with the request, but how am I supposed to do it?
Any help will be appreciated.
Edit:
Some clarification and code:
My application is written in standard asp.net. After some deeper research in legacy code I've found out, that all authentications are done in some base class from wchich all other pages inherit. Each time page is loaded, user principal are obtained from HttpContext.Current.Session("..."). I think this is far from good solution, but I'll need to stick with it right now. Problem was, WebMethod is not firing whole page lifecycle since it's static. I've fixed it right now by calling method that obtains user data from session.
I would like to get some ideas how this could be created correctly and what problems might be result of session based authentication.
PageMethods.SomeMethod(parameter, SuccessDelegate, FailureDelegate);
This is how I'm calling WebMethods right now. I assume it's passing all required cookies, am I right?
It depends on how you're calling the method and in what manner?
Jquery for instance with its Post method should push all cookies (including your FormsAuth / Session cookie) up with the request that should still authenticate as appropriate. Bare metal techniques might be making lightweight calls that simply do not push the cookie up...One way to monitor this is by using Fiddler to observe the request and a browser based development plugin like Firebug and see what is occuring and amend your JS code as appropriate.
Personally, if you are starting a brand new project and there is no pressing need to expose your services beyond your web application then I would suggest looking at ASP.NET MVC where you can make Jquery / client-side up to the controller and get your authentication wrapped up for free. I've recently created something simliar using WCF JSON endpoints and some inevitable pain, I then saw MVC and kinda kicked myself...
As noted in comment above, the issue lies in legacy code that handles users. It is needed to make call to special function that assigns appropriate user data to handling thread. Not a best solution, but that's how it sometimes is with legacy code. What you gonna do?
We have a flex application that connects to a proxy server which handles authentication. If the authentication has timeout out the proxy server returns a json formatted error string. What I would like to do is inspect every URLRequest response and check if there's an error message and display it in the flex client then redirect back to login screen.
So I'm wondering if its possible to create an event listener to all URLRequests in a global fashion. Without having to search through the project and add some method to each URLRequest. Any ideas if this is possible?
Unless you're only using one service, there is no way to set a global URLRequest handler. If I were you, I'd think more about architecting your application properly by using a delegate and always checking the result through a particular service which is used throughout the app.
J_A_X has some good suggestions, but I'd take it a bit farther. Let me make some assumptions based on the limited information you've provided.
The services are scattered all over your application means that they're actually embedded in multiple Views.
If your services can all be handled by the same handler, you notionally have one service, copied many times.
Despite what you see in the Adobe examples showing their new Service generation code, it's incredibly bad practice to call services directly from Views, in part because of the very problem you are seeing--you can wind up with lots of copies of the same service code littered all over your application.
Depending on how tightly interwoven your application is (believe me, I've inherited some pretty nasty stuff, so I know this might be easier said than done), you may find that the easiest thing is to remove all of those various services and replace them by having all your Views dispatch a bubbling event that gets caught at the top level. At the top level, you respond to that event by calling one instance of your service, which is again handled in one place.
You may or may not choose to wrap that single service in a delegate, but once you have your application archtected in a way where the service is decoupled from your Views, you can make that choice at any time.
Would you be able to extend the class and add an event listener in the object's constructor? I don't like this approach but it could work.
You would just have to search/replace the whole project.
I am using The Policy Injection Application Block to log methods that are called in my ASP.NET application. I would like these log entries to include information like the current user identity, whether the user is authenticated and so forth. All of this information is provided by the ManagedSecurityContextInformationProvider, but I can't figure out how to get the PIAB to use that provider and how to get that information into my log file.
I may be missing something obvious, but I can't quite figure out what it is.
Sorry to say, it looks like there is no way to get the ManagedSecurityContextInformationProvider information into method call logs. That information is usually logged in extended properties but the LogCallHandler.GetLogEntry method dumps out all of the method parameters and assigns them to the TraceLogEntry ExtendedProperties.
It seems to me that you could either modify the block to add that information or (even better) create your own Custom Call Handler based on LogCallHandler that adds the information that you require. Either option is not that much work.
In my asp.net applications, I've typically used the Application_Error global event handler to log the error and redirect the user to a user-friendly error page.
However, I have read about ELMAH and while that seems interesting, Application_Error seems like the simpler approach.
I've read other questions where people, including myself, have suggested one way or the other. What I'm wondering is if there is any significant benefit to using one over the other and why?
Elmah is a fantastic project and we use it for all of our ASP.NET applications. Not only does it log unhandled errors for you, it grabs the entire original page that the user saw, which contains a lot of detail for you.
It has email support, RSS feeds (both itemized and digest) and has an attractive console.
For 3 lines in config and a dll reference, I'd say that's a slam dunk.
I guess the main drawback of ELMAH is that it might be overkill for what you need. If it's logging and storing more info than you would in your own implementation, that's an unnecessary overhead in storage and processing. You also need to think about how you secure access to ELMAH's console since those exception details could contain juicy details of your app (that needn't be hard, but it's a worry that you didn't have before).
On the other hand, your own implementation will probably grow to log all that extra information once you decide that some stubborn bug requires it, and do you really care about shaving fractions of a second off the time that it takes for the error page to be displayed? Chances are you'll eventually end up building your own version of ELMAH, so why not just use ELMAH and save yourself the time.
I'd recommend that if you do want to write your own error logging rather than using ELMAH, you at least put it in a module rather than straight into Application_Error in global.asax. Just subscribe to the application's Error event in your module's Init method, and you can easily reuse your error handling code in another application with a line in web.config.
I also find it useful to handle any exception logging through ASP.NET's health monitoring. This makes it easy to control the type and level of logging in web.config, and also allows logging of exceptions that were handled in a try...catch without getting as far as Application_Error. Create a custom HandledExceptionEvent class that extends WebRequestErrorEvent, and you can create and raise those events in any catch block where you'd really like to know that the exception happened even though it was handled.