I am running into errors like The JSON request was too large to be deserialized..
Quick search on stackoverflow tells you that you should set appSetting aspnet:MaxJsonDeserializerMembers to be higher to fix the issue. However, the msdn documentation on the appSettings says
Caution
Setting this attribute to too large a number can pose a security risk.
I would expect that you are cautioned against setting this value to higher numbers to prevent anyone from submitting large payloads that could impact your system. However, given that I am already setting the value of maxRequestLength to a large number, will changing the aspnet:MaxJsonDeserializerMembers value have any other security implications?
I do not see how 1001 small json members could pose any more security threat that a single large json object.
ASP.NET applications reject requests that have more than 1000 of these elements.
https://support.microsoft.com/en-us/kb/2661403
The Microsoft security update that security bulletin MS11-100 addresses changes the default maximum number of form keys, files, and JSON members that ASP.NET will accept in a request to 1,000. This change was made to address the Denial of Service vulnerability that the Microsoft security bulletin MS11-100 documents.
Related
I know that Request.Headers["Origin"] gets the origin header of a request, but this is changeable on the client-side by setting the header manually. Thus not that safe.
Is there such a value that contains the original, readonly/unchangeable origin of a request? Like the one CORS is using?
I need this value to check if the request is officially coming from the site it's supposed to come from. The trick is that I need it in the controller method to search an object in the database based on this value and a key only used for that site.
The problem with CORS is that it can whitelist a list of URLs but not check if the site and the key belong to each other, thus can whitelisted site 1 access the data of whitelisted site 2 if it mimics the Request.Headers["Origin"] and the key of site 2
Unfortunately (or perhaps fortunately?) there is no reliable way to check this from the data that the browser sends to your server. The user is able to forge any and all information that you receive from the browser.
This is why mechanisms that need to reliably determine the origin of a user use some sort of token mechanism, public/private signatures, certificates and the sort to determine it. Unfortunately this is never as simple as looking up some information that the browser provides you with, so it seems like you might need to redesign your whitelisting mechanism by relying on something else than origin, possibly implicating single-sign-on measures (like SAML). It's hard to provide further suggestions without more information on the underlying problem that the origin-check is intended to solve.
I developed an application using C# and ASP.NET MCV4. In IIS it is set to use Windows authentication which uses only the Kerberos provider.
I used Burp Suite to make tests against poor cookies randomness at login page.
Selected text in the picture was chosen to test how much variable changes during 20k requests.
Results show that estimated entropy is 0 – so variable doesn't change at all.
What are options are there to increase randomness of selected part of header?
What are general methods to increase randomness of session variables stored in cookies?
As #MartinLiversage, this isn't the cookie at all: it's a header from the [MS-N2HT]: Negotiate and Nego2 HTTP Authentication Protocol, which is being used when server recieved the request to protected object without proper auth data.
As you can see, in your case the schema is Authenticate:Negotiate so no need to worry about some data being exposed:
The initial WWW-Authenticate header does not carry any auth-data when
the header is "WWW-Authenticate:negotiate"; it does carry data when
the header is "WWW-Authenticate:Nego2".
More over, this header is simply base64-string and can be easily decripted:
How do I decode a base64 encoded string?
As for the cookies in general, try to add some salt and use the implemented crypto providers, say, RSA provider or something. The question in given form is too broad to find one solution.
I'm getting the error "HTTP Error 414. The request URL is too long." From the following article, I understand that this is due to a very long query string:
http://www.mytecbits.com/microsoft/iis/query-string-too-long
In web.config, I have maxQueryStringLength="2097151". Is this the maximum value?
In order to solve this problem, should I set maxUrl in web.config? If so, what's the maximum value supported?
What should I do to fix this error?
This error is actually thrown from http.sys, not from IIS. The error gets thrown before the request is passed along to IIS in the request-handling pipeline.
To verify this, you can check the Server header value in the HTTP response headers, as per https://stackoverflow.com/a/32022511/12484.
To get https.sys to accept longer request URLs without throwing the HTTP 414 error, in the Windows Registry on the server PC, at Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters, create a DWORD-type value with name MaxFieldLength and value sufficiently large, e.g. 65535.
Reference: Http.sys registry settings for Windows
If you decide to make this change, then obviously it’ll need to be made in all environments (including all production server(s)) -- not just on your local dev PC.
Also, whatever script and/or documentation your team uses to set up new server instances will need to be updated to include this registry setting, so that your team doesn’t forget to apply this setting 18 months from now when setting up a new production server.
Finally, be aware making this change could have adverse security consequences for all applications running on your server, as a large HTTP request submitted by an attacker won’t be rejected early in the pipeline as it would normally.
As an alternative to making this change to bypass the http.sys security, consider changing the request to accept HTTP POST instead of HTTP GET, and put the parameters into the POST request body instead of into a long URL. For more discussion on this, see question Design RESTful GET API with a long list of query parameters.
As described in this answer -> What is the maximum length of a URL in different browsers?
The allowed length of a url depends on a combination of browser and server. Hence it's hard to say exactly how long the url can be. The answer recommends to stay below 2000 char in the url. I do not know why your querystring is so long. Can you shorten it? It's hard to give you any recommendations without knowing more about the solution and your query string.
Generally, Url has its own limits in length and if you set this value you may solve the problem for a while, but bear in mind that for a long url situations, best practice is working with forms. To be specific, it is better to use POST actions instead of Get.
just to complement, if you try with massive parameters, using Request ajax and receive de 414 ERROR. change the dataType property to JSON then submit as POST type.
this resolved my problem.
In the latest Asp.Net December 2013 Security updates Microsoft released a patch for ASP.Net - 'Insecure ASP.NET Web Forms (.aspx) configuration could allow remote code execution'. Related KB is 2905247
As I know ViewStateMac just used to be sure that this ViewState was generated by server, and not an attacker. But in security updates article they say:
If a web developer sets EnableViewStateMac=false for any page in his
site, an attacker could leverage this to upload and invoke arbitrary
executable code within the context of the web service account. This is
an example of a remote code execution (RCE) attack.
For example if I disable EnableViewStateMac for some aspx page, how it allows attacker to execute malicious code in context of my web application? As I understand in the worst case an attacker can spoof ViewState for some fake data\events\validation. But it will affect just this page. And I can't upload any malicious C# code via ViewState that will be executed. What are they mean by RCE attack in that case?
I can't find any further details of this vulnerability, so my answer only speculates to a possible attack vector.
The MAC is a signature of the ViewState value, and with EnableViewStateMac=true ASP.NET will check whether the MAC signature actually signs the ViewState value as authentic. This means that the ViewState value sent from the client in the __VIEWSTATE hidden field has been verified to come from the server.
Now imagine that the code processing the ViewState value is vulnerable to say object deserialisation. The Microsoft advisory states:
An unauthenticated attacker could send specially crafted HTTP content to the targeted server, potentially allowing the attacker to run code on the server in the context of the service account running on the ASP.NET site.
With EnableViewStateMac=true this vulnerability cannot be exploited because the MAC is validated before the ViewState value is processed. Any value that has not come from the server will be met with a Validation of viewstate MAC failed exception message.
However, with EnableViewStateMac=false the whole ViewState value could be manipulated by an attacker to exploit the buffer overflow/escape attack with privilege escalation and execute arbitrary code that is injected as a payload into the __VIEWSTATE field.
So in summary, as the ViewState value is no longer being validated it opens up the field to attack by this unpublicised attack vector.
By itself, it doesn't necessarily allow an attacker to run code, but if you act upon some input expecting it to be valid -- hidden field with values or something similar, then it could be the key they need.
I'm currently fixing some Security issues in our ASP.net website application.
One of the issue was that the ViewState was not encrypted.
So I did check on StackOverFlow and elsewhere on how to encrypt the viewState, and I did it using the <pages viewStateEncryptionMode="Always" /> and adding a 3DES machinekey like this <machineKey validation="3DES" /> in Web.config .
I would like to know if the "EnableViewStateMAC=true" is also compulsorily necessary? since this was mentioned in some of the suggested solutions I had found online.
But, on my checks I found the encryption is working even without this.
[NOTE: I had to do these changes at an application level (Web.config) since making individual page changes is not a practical solution for this application.]
Do not ever set EnableViewStateMac to false, even if encryption is enabled. The MAC guarantees that the client cannot maliciously tamper with the contents of ViewState. (Encryption by itself isn't sufficient to guarantee this; the MAC is necessary.)
The EnableViewStateMac property will be removed in a future version of the product since there is no valid reason to set it to 'false'.
Just in case:
Starting with ASP.NET 4.5.2, the runtime enforces EnableViewStateMac = true
more details here: ASP.NET 4.5.2 and EnableViewStateMac
You might want to note that as of September 2014
All versions of the ASP.NET runtime 1.1 - 4.5.2 now forbid setting
<%# Page EnableViewStateMac="false" %>
and
<pages enableViewStateMac="false" />
http://blogs.msdn.com/b/webdev/archive/2014/09/09/farewell-enableviewstatemac.aspx
It 'll be problem When You host multi server. Because Machine Keys are different.
IF your project runs on single machine. EnableViewStateMAC=true is safely.
Using enableViewStateMac requires that successive requests be forwarded to the same server (i.e. server affinity). This feature is used to help prevent tampering of a page's view state; however, it does so based on an auto-generated validation key on the current server. From this key, a message authentication code (MAC) is generated and sent in the ViewState back to the browser. The problem is that if a POST back is performed and goes to a different server, you will get a nice little error message saying “Corrupt View State“.
To fix this, you can either set enableViewStateMac to false in the element or specify a common value for the validationKey attribute in the element across all servers (in the farm).
By the way, documentation says that this is OFF by default. That is incorrect! Go check machine.config!