I am having some issues setting security policies for my UI which can be framed by more than one site. I am setting CSP policy with multiple frame ancestors. Adding XFrame option is mandated so if I leave it empty the parent class rendering all UIs will add XFO SAMEORIGIN which contradicts with CSP frame ancestors.
One option is to use ALLOWALL but that is not supported widely. Is there any other way I can set an X Frame Option but allow from multiple Uris?
If you supply an invalid value, X-Frame-Options will basically be ignored allowing this to fallback to the frame ancestors you are providing.
Since it can be any value, have fun:
X-Frame-Options: totally chill
Related
I'm reading tutorials on ASP .NET Core and Razor Pages.
One of them, when dealing with the BindProperty attribute, has remarks I find hardly understandable:
Razor Pages, by default, bind properties only with non-GET verbs.
Binding to properties can reduce the amount of code you have to write.
Binding reduces code by using the same property to render form fields
(<input asp-for="Customer.Name" />) and accept the input.
For security reasons, you must opt in to binding GET request data to
page model properties. Verify user input before mapping it to
properties. Opting in to this behavior is useful when addressing
scenarios which rely on query string or route values.
To bind a property on GET requests, set the [BindProperty] attribute's
SupportsGet property to true: [BindProperty(SupportsGet = true)]
(emphasis mine) Source: Introduction to Razor Pages in ASP.NET Core ยง Writing a basic form
I do not understand. Why do extra security measures need to be taken when dealing specifically with GET requests?
As far as I can tell, GET requests are supposed to be safer, not less safe than POST requests, because GET only retrieves data, while POST sends data to the server. So, more often than not, POST requests need extra security measures GET reqs don't need.
And yet now I'm reading that it's fine to do X with POST but careful, don't do this with GET recklessly, you must opt-in and be warned, take precautions!
Why are these warnings necessary? What kind of security vulnerabilities can be introduced by binding GET request data to page model properties? And why are these vulnerabilites not applicable to POST requests?
Binding is two-way model, meaning it binds a given element for both rendering ("show this value here") and submitting back ("save this value there"). For example, you'd use binding to populate an input field with a value that a user could then update and POST back. Binding handles dealing with the value automatically.
If you simply want to display a value, you don't need to use binding at all. Simply make it a public property of your model and reference it directly ({Model.PropertyName}).
There are a bunch of reasons for avoiding [BindProperty(SupportsGet = true)] but I think HTTP's RFC 7231, Section 9.4 covers it well:
URIs are intended to be shared, not secured, even when they identify secure resources. URIs are often shown on displays, added to templates when a page is printed, and stored in a variety of unprotected bookmark lists. It is therefore unwise to include information within a URI that is sensitive, personally identifiable, or a risk to disclose.
Authors of services ought to avoid GET-based forms for the submission of sensitive data because that data will be placed in the request-target. Many existing servers, proxies, and user agents log or display the request-target in places where it might be visible to third parties. Such services ought to use POST-based form submission instead.
Since the Referer header field tells a target site about the context that resulted in a request, it has the potential to reveal information about the user's immediate browsing history and any personal information that might be found in the referring resource's URI.
There are various places in my Sharepoint generated web pages where element IDs are assigned values by Sharepoint with the prefix "ct100".
How safe is it to refer to these IDs in my javascript?
How static are they?
How likely are they to change for any reason?
Is there any documentation that discusses how they are generetad and answers the above questions?
Thanks,
George
"Safe" is relative here and depends on the specific page and controls involved.
The individual IDs that look like ctXYZ are generated automatically by the parent ASP.Net Naming Container when the control has not been explicitly assigned an ID - that is, the ID is auto-generated like ct001, ct002, etc, making sure not to create duplicates.
The final Client ID - which is assigned as the id attribute in the HTML - is the made up of joining all the IDs of the control and all ancestors with underscores; thus the stability of a single Client ID is affected by multiple controls.
The generated Client IDs are generally guaranteed to remain stable only if the Control Tree is always re-created in the same way - this holds true in many cases, but it is not absolute. Dynamically adding or removing controls can easily break this assumption.
ASP.Net 4 (or 4.5?) introduced a different ID mode - primarily "Predictable", see the Naming Container link - but I do not believe that SharePoint uses this new feature anywhere; and it's definitely not used for IDs that contain ctXYZ components.
Based on research, the safest approach is to use css and jquery to identify and manipulate the "ct001" elements. I have tried this approach and it appears to be working fine.
for hidden field tampering protection: Id, RowVersion, I use a version of Adam Tuliper AntiModelInjection.
I'm currently investigating a way to prevent tampering of valid options found in select lists/drop downs. Consider a multitenant shared database solution where fk isn't safe enough and options are dynamic filtered in cascading dropdowns.
In the old days of ASP.NET webforms, there was viewstate that added tampering prevention for free. How is select list tampering prevention accomplished in ajax era? Is there a general solution by comparing hashes rather than re-fetching option values from database and comparing manually?
Is ViewState relevant in ASP.NET MVC?
If you can, the single solution here is to filter by the current user ids permission to that data, and then those permissions are validated once again on the save.
If this isn't possible (and there are multiple ways server side to accomplish this via things like a CustomerId fk in your records, to adding to a temporary security cache on the server side, etc) , then a client side value can provide an additional option.
If a client side option is provided like was done with Web Forms, then consider encrypting based on their
a.) User id plus another key
b.) SessionId (session must be established ahead of time though or session ids can change per request until session is established by a value stored in the session object.
c.) Some other distinct value
HTTPS is extremely important here so these values aren't sniffed. In addition ideally you want to make them unique per page. That could be the second key in A above. Why? We don't want an attacker to figure out a way to create new records elsewhere in your web app and be able to figure out what the hashes or encrypted values are for 1,2,3,4,5,6,etc and create essentially a rainbow table of values to fake.
Leblanc, in my experience, client side validation has been used mostly for user convenience. Not having to POST, to only then find out that something is wrong.
Final validation needs to occurs in the server side, away from the ability to manipulate HTML. Common users will not go on to temper with select lists and drop downs. This is done by people trying to break your page or get illegal access to data. I guess my point is final security needs to exist in the server, instead of the client side.
I think a global solution could be created given a few assumptions. Before i build anything I'll like to propose an open solution to see if anyone can find flaws or potential problems.
Given all dropdowns retrieve their data remotely. - in an ajax era and with cascading boxes this is now more common. (We are using kendo dropdowns.)
public SelectList GetLocations(int dependantarg);
The SelectList will be returned back as json - but not before having newtonsoft serialization converter automatically inject: (done at global level)
EncryptedAndSigned property to the json. This property will contain a Serialized version of the full SelectList containing all valid values that is also encrypted.
EncryptedName property to the json. This property will have the controller actionname - For this example the EncryptedName value would be "GetLocations"
When the http post is made EncryptedName : EncryptedAndSigned must be sent in the post also. For this JSON POST example it would be:
{
Location_Id: 4,
GetLocations: 'EncryptedAndSigned value'
}
On the server side:
[ValidateOptionInjection("GetLocations","Location_Id")
public ActionResult Update(Case case)
{
//access case.Location_Id safety knowing that this was a valid option available to the user.
}
To hand over values from an XPage to a custom control, which approach should be used ?
a) Define properties in the custom control at design time. Fill in the properties at the XPage with computed values. Use the value via 'compositeData' in the custom control at runtime.
or
b) Put the value in a session scope variable at the XPage in BeforePageLoad event. Bind the session scope variable to the field in the custom control.
The session scope is primarily intended for ensuring that values persist as the user navigates between pages. I like to call it the "shopping cart" scope: if you built an e-commerce site in Domino, you wouldn't want the site to forget that a user had added a product to their cart just because they clicked back to the home page. So this scope is also useful for features like remembering search / sort / filter options as the user navigates the app so each time they navigate somewhere else and come back, it remembers their prior behavior without having to store this information permanently in the NSF.
For passing in-page information to a Custom Control from a container, however, compositeData is definitely the way to go. This is because that variable is populated with the passed parameters only for the duration of the processing of the relevant control. Once that control has been dealt with, all pointers to the passed parameters are cleaned up automatically, which provides incremental scalability improvement for each instance compared to storing the same information for the duration of each user's session.
There will be cases where there is overlap: a given Custom Control might reference information that is appropriate to store in the session scope. In this scenario I like to mix the two techniques... for example:
<xp:inputText value="#{sessionScope[compositeData.scopeKey]}" />
The above syntax allows a Custom Control to be passed by its container the identifier for where in the session scope the relevant information is stored. This provides some serious flexibility, because I can drop the same control into multiple contexts, with each telling the control which information it should retrieve / store in scope.
I am essentially storing a private key (Hash) in any of the OctetString attributes within Active Directory.
My question is, what attribute is secure by default and makes sense to keep private data there? This value should be considered similar to a password, where even administrators shouldn't have access (if possible), just like the current AD Password.
Here is a start of a list of attributes that are enabled by default on a Windows 2008R2 + Exchange 2010 domain.
Update:
Does anyone know of an Octet String attribute that does not expose "read" permissions to all users in the domain by default? I don't want to store my hash publicly and allow someone to build a rainbow table based on the hashes.
Here is the answer for the fella who upvoted my question... it's pretty interesting:
The default permissions in Active Directory are such that Authenticated Users have blanket read access to all attributes. This makes it difficult to introduce a new attribute that should be protected from being read by everyone.
To mitigate this, Windows 2003 SP1 introduces a way to mark an attribute as CONFIDENTIAL. This feature achieved by modifying the searchFlags value on the attribute in the schema. SearchFlags contains multiple bits representing various properties of an attribute. E.g. bit 1 means that the attribute is indexed. The new bit 128 (7th bit) designates the attribute as confidential.
Note: you cannot set this flag on base-schema attributes (those derived from "top" such as common-name). You can determine if an object is a base schema object by using LDP to view the object and checking the systemFlags attribute of the object. If is the 10th bit is set it is a base schema object.
When the Directory Service performs a read access check, it checks for confidential attributes. If there are, then in addition to READ_PROPERTY access, the Directory Service will also require CONTROL_ACCESS access on the attribute or its property set.
By default, only Administrators have CONTROL_ACCESS access to all objects. Thus, only Administrators will be able to read confidential attributes. Users are free to delegate this right to any specific group they want. This can be done with DSACLs tool, scripting, or the R2 ADAM version of LDP. As of this writing is not possible to use ACL UI Editor to assign these permissions.
The process of marking an attribute Confidential and adding the users that need to view the attribute has 3 Steps
1.Determining what attribute to mark Confidential, or adding an attribute to mark Confidential.
2.Marking it confidential
3.Granting the correct users the Control_Access right so they can view the attribute.
For more details and step-by-step instructions, please refer to the following article:
922836 How to mark an attribute as confidential in Windows Server 2003 Service Pack 1
http://support.microsoft.com/default.aspx?scid=kb;EN-US;922836
It doesn't actually important whether you use an attribute of OctetString syntax or somewhat else such as DirectoryString. What is important from the security point of view is the security descriptor assigned to the entry or branch of entries that hold your attributes. In other words, a binary attribute value hardly makes your system more secure, unless a proper security is assigned to the directory tree.
You cannot have security similar to unicodePwd attributes has, because it's kind of special. While you can assign a security descriptor that prohibits accessing your attribute values even by an administrator, you cannot disable administrator from changing security descriptor and ultimately acquiring the access to the value.
Unless you totally plan to lock yourself into AD I would suggest just adding an Aux class with your Octet String attribute and use that. (I.e. Not all other schema's might have the same attribute with the same syntax. Just ran into that with destinationIndicator. SunOne and eDirectory have different schema syntaxes.)
Then I would encrypt the contents of the attribute, since it is too hard to guarantee privacy of the data otherwise.