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.
Related
Currently, for our web application, we are generating nonce values to attach to script tags. I have recently found out about Subresource Integrity and considering that we're using a CDN (as most examples reference), I was curious if this was something my web app should use.
Is there ever a case for both nonce and integrity attributes to be used? Is one better than the other? Or, do they support multiple use cases entirely?
Thanks
They support different use cases and you can use both.
Nonce instructs the browser to execute only <script> elements which have the same nonce value set in the CSP header.
nonce-*
A cryptographic nonce (only used once) to whitelist scripts. The server must generate a unique nonce value each time it transmits a
policy. It is critical to provide a nonce that cannot be guessed as
bypassing a resource's policy is otherwise trivial. This is used in
conjunction with the script tag nonce attribute. e.g.
nonce-DhcnhD3khTMePgXwdayK9BsMqXjhguVV
So let's say your application set a Content-Security-Policy header like script-src'nonce-r4nd0m'; then the script at good.com/good.js will be executed because the nonce value is the same.
<script nonce="r4nd0m" src="//good.com/good.js">
What happens if an attacker compromises good.com and add a malicious script to good.js? That your web application still allows the execution of that script because the check is made on the nonce value not on the script content. So you need also to be sure that the content of good.js remains the same.
Here integrity attribute is involved. It implements Subresource Integrity and tells to the browser to run resources only if the computed hash matches with the one stored in the integrity attribute.
Subresource Integrity (SRI) is a security feature that enables
browsers to verify that resources they fetch (for example, from a CDN)
are delivered without unexpected manipulation. It works by allowing
you to provide a cryptographic hash that a fetched resource must
match.
So let's suppose the first time you included the script in the web app, the content of the script was safe and the integrity value was X. Then you added integrity="sha384-X" to the script element as follows.
<script src="//good.com/good.js"
integrity="sha384-X">
The attacker modifies good.js so the resulting hash of the modified script becomes Y. The browser doesn't run the script because the computed hash (Y) and the required hash (X) don't match.
I think you can combine both like this.
<script nonce="r4nd0m" integrity="sha384-X" src="//good.com/good.js">
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.
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.
I am using the URLLoader class to send data to a script that sends an email with that data; the URLLoader is also used to receive the return data on the status of the request. This email script is located on another domain (webscript.io, in this case; they host scripts written in LUA that can perform various functions when called). I don't want to have to get them to host a crossdomain.xml file, but when I visit the page to use the Flash app, I don't even get a security warning. Is that not the default action when there is cross-domain scripting in a Flash application without a crossdomain.xml file?
For your reference, here is the application: http://www.canadadocks.ca/build-dock-app/
The cross domain issues are specifically for data that your SWF is retrieving from other domains. So if you're sending data (via a HTTP POST/GET), then this is not a problem.
Also, unless you're using the debug player, you won't see the security exception that occurs.
There are also various things that will not trigger the exception: like downloading and displaying an image from another domain. However, if you then try to access the bitmap data of that image, you'll get the security exception (unless the crossdomain.xml permits it).
So it can depend on what you're retrieving and what you're doing w/the data you fetch.
If you're still curious, you should further explain what type of data you're retrieving and what you do with it. As usual, it's better to explain that with code than with words ;)
I have a method for parsing a config file into a dictionary. I'm unsure how it should behave if a config parameter is missing. Should it use a default value and log an error or raise an exception?
I suggest that you separate: (1) the parsing of the configuration file and storing the parsed details into a dictionary, from (2) retrieving name=value pairs from the dictionary. This separation of concerns will then enable you to provide an overloaded API for (2) that specifies if a missing name=value pair should result in a default value being returned or an exception being raised. For example (pseudo code):
cfg = parseConfigurationFile("example.cfg")
x = cfg.lookupString("x"); // throws an exception if the name=value is missing
y = cfg.lookupString("y", "hello, World!"); // returns default value if name=value is missing
I also suggest that the API should provide type-safe lookup methods such as lookupInt(), lookupBoolean(), lookupDouble() and so on. Those methods should throw an exception if a looked-up value cannot be parsed into the specified type.
Edit to respond to a comment
"Thanks for the example. I was more wondering if it was a good idea to even
provide default settings and start the application if the config was wrong."
I like the Fail Fast Principle, so I recommend that if any configuration data is invalid, your application should report an error and stop, rather than try to silently repair the error (perhaps by using a default value instead of a bad configuration value) and continue on.
However, I don't think you should necessarily view missing name=value pairs as being an error. Instead, it is valid to use a default value for a missing value. If you take this to an extreme by allowing all the configuration name=value pairs to be optional, then your application will be able to work "out of the box" without any configuration file at all, which arguably improves the application's ease of use for new users.
A few years ago, I wrote Config4* (C++ and Java libraries for parsing a particular configuration-file syntax). Config4* provides an elegant way to enable any/all name=value pairs to be optional: it's what the Config4* manual calls fallback configuration. If you want to learn about that, then I suggest you skim-read Chapter 2 of the Config4* Getting Started Guide to get an understanding of the configuration syntax, and then read Chapter 3 of the same manual to understand the API. Pay particular attention to Sections 3.6.2 (Parsing Embedded Configuration) and 3.6.3 (Using Fallback Configuration).