I have a MVC model field that the user enters some html source code into. Currently, I am getting the following error:
A potentially dangerous Request.Form value was detected from the
client
I have had a look at the following resource: http://blogs.msdn.com/b/marcinon/archive/2010/11/09/mvc3-granular-request-validation-update.aspx
The resource says to add the AllowHtml attribute. I have added this attribute, and the error is now not occuring.
My question is this: Is there any other security features that I should add to my application, or is the AllowHtml attribute all that is required? Should I also use the following protection library: http://wpl.codeplex.com/
Thanks in advance
AllowHtml doesn't include any security to prevent malicious scripting. It's just allowing the property to skip this step in the validation process. You should still check that property to make sure it doesn't contain scripting and either sanitize or reject it if it does.
Related
Well I will explain all about my case.
Im trying to set up Azure alerts that sends a custom mails, to do so I need a logic app that parse the info about the said alerts.
The problem is, even if I enable the common alert schema, and fill the custom properties field, as you can see in the image.
But what this alert sends to my Logic App in the customProerties field is a Null value, I don't get why.
But more than that, if I disable the common alert schema, the custom properties field will be sent without problems.
I don't understand if common alert schema doesn't allow customProperties, or if Im doing something bad, I need help.
Thanks for read and ask for it if anything of this post is bad explained.
I have just confirmed this issue with Microsoft support.
If I point an Activity Log Alert Rule to an Action Group Webhook with Common Schema enabled then the Custom Properties don't appear in the JSON payload. If I disable the Common Schema then the property does appear in the payload.
If I do the same for a Metric alert or Log Query alert, the Custom Properties do appear at the Webhook endpoint regardless of whether the Common Schema is enabled or not.
Microsoft pointed that the schemas for each type are documented (no custom property on the Activity Log Common Schema) and that this is not a bug. Well... the Alert Rule form does allow to configure the Custom Properties for each type of alert so... ah well, nevermind.
They also said "There are plans to align the behaviour on all alert types including activity logs, although there is no definite ETA though. For now, the best option for you to be able to customize the payloads of activity log alerts is by using logic app as an action group."
We're using puppeteer and sometimes playwright to run some integration tests. We mock some of the target page's script dependencies, which causes subresource integrity hash mismatches.
Failed to find a valid digest in the 'integrity' attribute for resource 'http://localhost:3000/static/third-party/adobe-target/at-js/2.4.0-cname/at.js' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked."
Is there a way to disable integrity hash checking via a flag or configuration property?
No. I believe the only way is to fix or remove the integrity attribute from the source that loads the script.
Looking at the chromium (or blink) source, unless the integrity attribute is empty, the FetchManager::Loader will instantiate the SRIVerifier, whose constructor calls its OnStateChange method, where for response types of basic, cors, default (leaving out opaque responses and errors), SubresourceIntegrity::CheckSubresourceIntegrity is called. Unless the parsing of the integrity attribute fails, SubresourceIntegrity::CheckSubresourceIntegrityImpl will either successfully verify one of the digests, or it will fail with the given error message. There is no configuration option checked along this path to override a failed check.
On a project we spent considerable effort to work around basic authentication (because webdriver tests were depending on it, and webdriver has no api for basic authentication), and I remember basic authentication in the URL clearly not working. I.e. could not load http://username:password#url
Just google "basic authentication in url" and you will find tons of people complaining: https://medium.com/#lmakarov/say-goodbye-to-urls-with-embedded-credentials-b051f6c7b6a3
https://www.ietf.org/rfc/rfc3986.txt
Use of the format "user:password" in the userinfo field is deprecated.
Now today I told this quagmire to a friend and he said they are using http://username:password#url style basic authentication in webdriver tests without any problem.
I went in my current Chrome v71 to a demo page and to my surprise I found it indeed very well working: https://guest:guest#jigsaw.w3.org/HTTP/Basic/
How is this possible?? Are we living in parallel dimensions at the same time? Which one is true: is basic authentication using credentials in the URL supported or deprecated? (Or was this maybe added back to Chrome due to complaints of which I can't find any reference?)
Essentially, deprecated does not mean unsupported.
Which one is true: is basic authentication using credentials in the URL supported or deprecated?
The answer is yes, both are true. It is deprecated, but for the most part (anecdotally) still supported.
From the medium article:
While you would not usually have those hardcoded in a page, when you open a URL likehttps://user:pass#host and that page makes subsequent requests to resources linked via relative paths, that’s when those resources will also get the user:pass# part applied to them and banned by Chrome right there.
This means urls like <img src=./images/foo.png> but not urls like <a href=/foobar>zz</a>.
The rfc spec states:
Use of the format "user:password" in the userinfo field is
deprecated. Applications should not render as clear text any data
after the first colon (":") character found within a userinfo
subcomponent unless the data after the colon is the empty string
(indicating no password). Applications may choose to ignore or
reject such data when it is received as part of a reference and
should reject the storage of such data in unencrypted form. The
passing of authentication information in clear text has proven to be
a security risk in almost every case where it has been used.
Applications that render a URI for the sake of user feedback, such as
in graphical hypertext browsing, should render userinfo in a way that
is distinguished from the rest of a URI, when feasible. Such
rendering will assist the user in cases where the userinfo has been
misleadingly crafted to look like a trusted domain name
(Section 7.6).
So the use of user:pass#url is discouraged and backed up by specific recommendations and reasons for disabling the use. It also states that apps may opt to reject the userinfo field, but it does not say that apps must reject this.
When a user submits a certain form, I remove all of the forbidden HTML-tags from one of its fields before the whole form is validated, so here is a problem: when a user sends nothing, but forbidden HTML-tags in the field, the field will be totally empty, thus, my site will think it is originally so, and it warn the user that it shouldn't be empty.
To prevent that, I have to check the field's contents before submitting it on the client side to ensure that it has no forbidden HTML-tags and I wonder if there is such a feature built-in in Yii2? If not, is there a JavaScript interface to show any sort of warnings for the field the same way Yii2's validation shows them when something is wrong about the form's contents?
Maybe you should check JavaScript validation at: https://yii2-cookbook.readthedocs.io/forms-activeform-js/#working-with-activeform-via-javascript
I need to send messages to clients using onesignal from my webservice based on vb.net. Those messages are sent between html tags like : <html><body>messagelinktext, but whenever I try to send it through one signal i got this error:
System.Web.HttpRequestValidationException: A potentially dangerous Request.Form value was detected from the client (pushMessage="message<a>link</a>text").
at System.Web.HttpRequest.ValidateString(String value, String collectionKey, RequestValidationSource requestCollection)
at System.Web.HttpRequest.ValidateHttpValueCollection(HttpValueCollection collection, RequestValidationSource requestCollection)
at System.Web.HttpRequest.get_Form()
at System.Web.Services.Protocols.HtmlFormParameterReader.Read(HttpRequest request)
at System.Web.Services.Protocols.HttpServerProtocol.ReadParameters()
at System.Web.Services.Protocols.WebServiceHandler.CoreProcessRequest()
Can someone suggest a solution to send html data through onesignal?
This error appears to be happening on your server side, and not from OneSignal.
Here is Microsoft's guide on this error message: https://msdn.microsoft.com/en-us/library/system.web.httprequestvalidationexception(v=vs.110).aspx
The Remarks section in the link above explains how to resolve this, to quote:
Constraining and validating user input is essential in a Web
application to prevent hacker attacks that rely on malicious input
strings. Cross-site scripting attacks are one example of such hacks.
Other types of malicious or undesired data can be passed in a request
through various forms of input. By limiting the kinds of data that is
passed at a low level in an application, you can prevent undesirable
events, even when programmers who are using your code do not put the
proper validation techniques in place.
Request validation detects
potentially malicious client input and throws this exception to abort
processing of the request. A request abort can indicate an attempt to
compromise the security of your application, such as a cross-site
scripting attack. It is strongly recommended that your application
explicitly check all input regarding request aborts. However, you can
disable request validation by setting the validateRequest attribute in
the directive to false, as shown in the following example: <%# Page validateRequest="false" %> To disable request validation for your
application, you must modify or create a Web.config file for your
application and set the validateRequest attribute of the pages section
to false, as shown in the following example:
<configuration>
<system.web>
<pages validateRequest="false" />
</system.web>
</configuration>
To disable request validation for all applications
on your server, you can make this modification to the Machine.config
file.