We have a worker role in Azure which uses Process.Start to kick off a background process (which hosts a native application we need to run)
FxCop gives me a whole load of CA2122 errors due to a link demand. When I tried to add this attribute:
[PermissionSet(SecurityAction.LinkDemand, Name = "FullTrust")]
I then started to get CA2135 instead, the solution to which seems to be to add the SecurityCritical attribute instead.
But then I get the CA2122 again.
Are either of these things an issue? Under what circumstances could they be and how can I be sure that I'm not introducing a security problem?
SecurityCritical should perform an equivalent role as a LinkDemand for full trust:
The SecurityCriticalAttribute is equivalent to a link demand for full
trust. A type or member marked with the SecurityCriticalAttribute can
be called only by fully trusted code; it does not have to demand
specific permissions. It cannot be called by partially trusted code.
Ergo, I'd suggest adding SecurityCritical (to fulfil the needs for CA2135) and suppress the CA2122, which is presumably just Microsoft forgetting to account for their newer solution in their code analysis.
The objective of CA2122 is to ensure that the method...
no longer provides unsecured access to the link demand-protected
member.
This isn't the case once SecurityCritical is added (which ensures the member can be called only by fully trusted code), so the second CA2122 is a false positive.
Related
I'm trying to access user's presence off of https://learn.microsoft.com/en-us/graph/api/presence-get?view=graph-rest-1.0&tabs=http
I've granted my AD app Presence.ReadWrite.All which is described as "Allows the app to read all presence information and write activity and availability of all users in the directory without a signed-in user. Presence information includes activity, availability, status note, calendar out-of-office message, time zone and location.
".
There seems to be a bit of a conflict between the docs and what the permission's name is - the docs seem to imply it doesn't work with an application scope, while the permission name/description seems to say it does.
The error i'm getting is Forbidden. This seems to be different from accessing a resource with insufficient permissions (which straight up says InsufficientPermissions).
The docs are clear that you can't do this with Application scope. That means even if the particular permission seems like it should work, it might be because it's used in that way for another endpoint. Notice that, for instance setPresence and clearPresence both support Presence.ReadWrite.All.
What's really crazy though is that neither getPresence (your endpoint) nor (get Presence for Multiple Users)[https://learn.microsoft.com/en-us/graph/api/cloudcommunications-getpresencesbyuserid?view=graph-rest-1.0&tabs=http] support Presence.*Read*Write.All - there is no supported read scenario!
From what I can see, your best bet is to keep an eye on this request and to upvote it. Microsoft (Darrel Miller) is quite active there from last year - perhaps there's an update coming.
I'm new to parse, and have a question about the security of data in the parse.
It really speeds up the development and gives you an off-the-shelf database to store all the data coming from your web/mobile app.
How we can enforce security in parse.
Can anyone please explain me ?
Basically, there are two levels of security. First, every connection to the Parse servers is made via SSL, every other way of trying to connect is automatically blocked by their servers. That's something you don't need to worry about, but it's good to know the connection is encrypted.
There is, however, something you can and should do, to ensure the integrity and security of your data. It's called ACL, and can be defined for every object. Here is the documentation of it. With ACL's you can define which user has read access on an object, and which user can write/edit/delete it. Additionally, you can define global ACLs via the databrowser.
Another thing worth mentioning is client enabled class creation. In development it is quite useful to have that enabled, because this means every time you call a new class which doesn't already exist, it's automatically created for you. Similarly, there is the possibility to disable the creation of new fields for a class. Also useful in development, these things should be disabled in production, unless you really have to have them enabled (which shouldn't be the case if your data structure is good enough).
Additionally, you should read this page by Parse, it's all about security and data integrity.
I developing a stateless REST API that makes use of token based authentication, where I'm manually adding an Authentication object to the security context by calling SecurityContextHolder.getContext().setAuthentication(authentication) from within a custom security filter. I've been experiencing problems with the context not being set correctly which I believe is due to this :
Storing the SecurityContext between requests
In an application which receives concurrent requests in a single session, the same SecurityContext instance will be shared between threads. Even though a ThreadLocal is being used, it is the same instance that is retrieved from the HttpSession for each thread. This has implications if you wish to temporarily change the context under which a thread is running. If you just use SecurityContextHolder.getContext(), and call setAuthentication(anAuthentication) on the returned context object, then the Authentication object will change in all concurrent threads which share the same SecurityContext instance. ...
You can customize the behaviour of SecurityContextPersistenceFilter to create a completely new SecurityContext for each request, preventing changes in one thread from affecting another.
So the question is - how do you change the behaviour of the SecurityContextPersistenceFilter?
I'd like the security context to not be associated with the http session, but don't want to set the session creation policy to stateless, because I still want to implement CSRF protection etc.
I had this exact question this afternoon, and this open question matched my search exactly, so I thought I would add the little I learned.
We had threads that were accessing the same SecurityContext. I was unable to figure out how to customize the behavior of the SecurityContextPersistenceFilter directly (and in the pattern of the framework), however there were two ways that I could get it to be thread safe.
The first solution was to ensure that an empty context was created in our main authentication filter. This covered all of our authenticated requests, so it would work for our solution.
SecurityContextHolder.createEmptyContext();
The second thing that worked for me was to change our WebSecurityConfig to be stateless, which I know doesn't work for the OP, but added here for completeness.
http.authorizeRequests()
.anyRequest().authenticated()
.and()
.sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS)
...
Both these solutions work independently for our particular configuration. I'm certain there is a 3rd solution that would read better, but I don't know what it is but would like to.
This is my first time posting. I welcome any feedback.
In my Cake 2.3 app, I have an action that's called via ajax. Since I'm using the Security component, I had to use $this->Security->unlockedActions, otherwise the action would fail.
However, unlockActions doesn't work when $this->Security->requireAuth() is called. Is this a bug? Do I have a misunderstanding of how CakePHP handles security?
Why doesn't unlockActions override requireAuth?
SecurityComponent::requireAuth() adds that action to an array of required actions, stored in SecurityComponent::$requireAuth.
If you take a look at the Security Component's startup code, you'll find that SecurityComponent::_authRequired(), the method that checks the $requireAuth array, is called before the unlocked actions are even checked. I imagine if you require an action to be authorized, that should take precedence over telling the app that it doesn't.
I would still consider this a bug (or incorrectly documented), as it clearly states in the documentation:
There may be cases where you want to disable all security checks for
an action (ex. ajax request). You may "unlock" these actions by
listing them in $this->Security->unlockedActions in your beforeFilter.
This is a new feature so it might be good to open up a ticket explaining the confusion and see what the core team thinks about it.
I should also note here that disabling the Security Component for ajax requests isn't always necessary. I have several apps that successfully use the Security Component, along with CSRF checks, side-by-side with ajax.
Authentication is very different from security.
Security protects against several ways to hack into your website, while the auth components handles the clearance of your users. When a member is updating his profile, I do want to verify that it is a logged in member (authentication), but i might not want to use the security component for the action he is calling.
I need a gear for custom authorization in business logic classes. It has to be permissions based system, but I can not decide how to apply authorization rules to methods.
My first thought was to apply custom attributes to method
[NeedPermission("Users", PermissionLevel.Read)]
public IList<User> GetAllUsers()
{
// some code goes here
}
My business logic class has interface, so I can use, for example, Unity Interception behavior and check in runtime if current user has required permissions. And throw an exception if he has not.
But now I'm concerned about reliability of this method.
Usually the reference to business logic class injected by unity container. So there is no problem because it is configured to apply interface interception mechanism.
But what if some developer will instantiate my business logic class directly? Then no interception will be applied and he will be able to call any method even if current user has not permissions to make some actions or even he is not authenticated.
Also somebody can change unity container configuration, turn off Interception extension completly. Again my authorization system will not work.
I saw ASP .NET MVC is using similar mechanism for authorization. Authorization rule is applied only when request came by standard way (IController.Execute). I think this is not a problem in this case because end user of controller (web user) has no way to access controller class directly.
In my case end user of business logic is a programmer who develops front end and he can intentionally or unintentionally screw things - create instance of business logic class and call any methods.
What can you suggest me? How do you deal with this kind of problems?
Thank you.
The .NET Framework supports a mechanism for declarative permission verifications that does not depend on Unity interception or other "external" AOP. In order to take advantage of this, your attribute must inherit from System.Security.Permissions.CodeAccessSecurityAttribute. The System.Security.Permissions.PrincipalPermissionAttribute that is included in the BCL is an example of using this mechanism to evaluate user permissions. If it does not suit your needs, there's nothing stopping you from creating your own attribute that does.
If your constructors are internal and your objects instantiated from a factory, a developper won't be able to bypass your security by error.
If someone really, really wants to create your objets without the security, he could still do it using reflection, but this would have be pretty intentional to do so.