How to resolve "The Content-Type HTTP header is missing charset attribute" in play application? - nginx

We had a security check on our application, and it reported a few issues like missing charset attribute for .css and .js files.
Attack Type: Undefined charset attribute
Error Description: The Content-Type HTTP header is missing charset attribute
Content-Type: text/CSS
I found this answer The Content-Type HTTP header is missing charset attribute
Our application has been developed using play framework and I tried to add in the application.conf like this
AddDefaultCharset : utf-8
AddCharset utf-8 = [.htm .html .js .css]
But it didn't work. How can I resolve this issue in our application?
Thanks

Maybe You can try this one.
application.conf
play.filters.enabled += "play.filters.headers.SecurityHeadersFilter"
change this one, as Play Docs instructed.
play.filters.headers.contentTypeOptions -
sets X-Content-Type-Options, “nosniff” by default.
Source here.

Related

How can i add an HTTP header in my app on App Engine?

I have an Angular app running on App Engine and for security reasons i need to add some headers to server responses, for example the HSTS header. Checking on the App Engine documentation i found that apparently you can do it by adding the following lines in your app.yaml file:
handlers:
- url: /images
static_dir: static/images
http_headers:
X-Foo-Header: foo
X-Bar-Header: bar value
vary: Accept-Encoding
# ...
However, this is not adding headers to my response after adding those lines to my app.yaml file.
Can you help me to find out what am i doing wrong? I am new on App Engine Configurations.
Thanks in advance

APACHE 2.4 Remote Proxy mod_substitute and ProxyHTMLExtended don't work

I built a reverse proxy with Apache 2.4 on a cento's 7 server. It works with standard html pages but i need to substitute some url stored in .js files too. The directive:
ProxyHTMLExtended On
should enable the parsing inside external .css and .js files but it doesn't work. In the log file I can see:
[proxy_html:trace1] [pid 3263] mod_proxy_html.c(823): [client xxx] Non-HTML content; not inserting proxy-html filter
I tried to use mod_substitute, this is the interesting part in my httpd.conf:
ProxyPass /mylocation/ http://remoteserver/
<Location /mylocation/>
ProxyHTMLEnable On
ProxyHTMLExtended On
LogLevel debug proxy_html:trace3 substitute_module:debug
RequestHeader unset Accept-Encoding
AddOutputFilterByType SUBSTITUTE text/javascript text/html
Substitute "s|/css/|/mylocation/css/|ni"
Substitute "s|/js/|/mylocation/js/|ni"
Substitute "s|/custom_logo/|/mylocation/custom_logo/|ni"
Substitute "s|/html/|/mylocation/html/|ni"
Substitute "s|/current_config/|/mylocation/current_config/|ni"
Substitute "s|/web_lang/|/mylocation/web_lang/|ni"
Substitute "s|/custom_lang/|/mylocation/custom_lang/|ni"
ProxyPassReverse /
ProxyHTMLURLMap //remoteserver /mylocation/
ProxyHTMLURLMap http://remoteserver /mylocation/
ProxyHTMLURLMap /mylocation /mylocation
ProxyHTMLURLMap ^\/(.*) /mylocation/$1 R
</Location>
But in the log file there aren't any mod_substitute trace. It seems mod_substitute is never called.
The proxyHTMLURLMap rules works fine, but only on regular html files.
Depending on the .js file I'm asking to the server, I can see in the log file:
[xml2enc:debug] [pid 3259] mod_xml2enc.c(254): [client xxx] AH01434: Charset ISO-8859-1 not supported by libxml2; trying apr_xlate
or
[proxy_html:trace1] [pid 3263] mod_proxy_html.c(823): [client xxx] Non-HTML content; not inserting proxy-html filter
then the process stop, I receive the file but nothing has been replaced on it.
1) Wy the "ProxyHTMLExtended On" rule don't parse external .js files as described in Apache documentation?
2) Wy the mod_substitute don't work?
I'll try to answer to your questions
1) Wy the "ProxyHTMLExtended On" rule don't parse external .js files as described in Apache documentation?
You say that ProxyHTMLExtended Directive:
should enable the parsing inside external .css and .js files but it doesn't work.
That's seems to be incorrect, the current doc says:
Set to Off, HTML links are rewritten according to the ProxyHTMLURLMap directives, but links appearing in Javascript and CSS are ignored.
Set to On, all scripting events (as determined by ProxyHTMLEvents) and embedded scripts or stylesheets are also processed by the ProxyHTMLURLMap rules, according to the flags set for each rule. Since this requires more parsing, performance will be best if you only enable it when strictly necessary.
That means that embedded scripts, the ones in <script></script> are checked. It doesn't mention .js files.
2) Wy the mod_substitute don't work?
About this i don't know for sure why it doesn't work, but assuming the mod_substitute is enabled since apache started without error, the only thing that I can guess is that apache is sending application/javascript as Mime-Type instead of text/javascript that you wrote
Some bonus suggestions:
I wouldn't use ProxyHTMLURLMap ^\/(.*) /mylocation/$1 R with ProxyHTMLExtended On because will translate every / in your scripts, if you have <script> var a = 12/2; </script> will be translated into <script> var a = 12/mylocation/2; </script>. I would consider using ProxyHTMLURLMap / /mylocation/ c (the c flag means: "Pass embedded script and style sections through untouched.")
I don't really think that you need ProxyHTMLURLMap /mylocation /mylocation
ProxyHTMLURLMap http://remoteserver /mylocation/ will add an extra / to your urls, it still works but, imho, it is not a good translation.
Ex. <a href="http://remoteserver/about"> becomes <a href="/mylocation//about">
I suggest to rewrite it like this ProxyHTMLURLMap http://remoteserver /mylocation
I have a similar problem where mod substitute was not working for me.
Then I read somewhere that normally, mod_subsittue is actually by default only working if the HTTP response you get from the server has mime type txt/html.
This was not my scenario.
My scenario was that I want to re-write the content of an XML, namely a JEE web service that was being reverse proxied by apache httpd.
In order to manage to make the mod substitute alter the reply content it was necessary to do:
<Location /mockOutgoingWebServicePortBinding>
# core authentication and mod_auth_basic configuration
# for mod_authn_dbd
AuthType Basic
Authname "Password Required"
# core authorization configuration
AuthUserFile C:\Apache24\conf\htpasswd
Require valid-user
# mod_filter to be able to subsitute text xml
AddOutputFilterByType SUBSTITUTE text/xml text/html
Substitute "s|http://someHostName:8088/|http://localhost:80/|i"
</Location>
The magic step was enabling the mod_filter and adding the directive: AddOutputFilterByType .
When this was added in, the substitue altered the body of the xml. replacing the endpoint address.
About this:
But in the log file there aren't any mod_substitute trace
I managed to get a mod_substitute trace in error.log by using:
LogLevel alert substitute:trace8

Changing MIME type with Meteor

When I'm running my app on localhost, I get 2 warnings concerning MIME type. This is one of them:
Resource interpreted as Stylesheet but transferred with MIME type text/html: "http://localhost:3000/BootstrapEssentials/bootstrap.css".
The other warning is identical with a different file. Both files are in my working directory. So far, I have been to these similar questions but they haven't helped:
Resource interpreted as stylesheet but transferred with MIME type text/html (seems not related with web server)
Chrome says "Resource interpreted as script but transferred with MIME type text/plain.", what gives?
Resource interpreted as stylesheet but transferred with MIME type text/html
Originally I was trying to use this line:
<link rel="stylesheet" href="/BootstrapEssentials/bootstrap.css">
I have since added in the type field:
<link rel="stylesheet" href="/BootstrapEssentials/bootstrap.css" type="text/css">
but that didn't do anything. I also have used the JavaScript Console to see that in the response header it has content-type: text/html; charset=utf-8 and I believe that if I can change that to being content-type: text/css; charset=utf-8 then everything will be fine but I can't find how to do that either.
As per the Meteor docs:
All files inside a top-level directory called public/ are served as-is to the client. When referencing these assets, do not include public/ in the URL, write the URL as if they were all in the top level. For example, reference public/bg.png as /bg.png. This is the best place for favicon.ico, robots.txt, and similar files.
Moving your stylesheets to a directory in public should do the trick!

CSS Files showing up with type text/plain

I am attempting to serve my static blog (powered by jekyll) on my Ubuntu server but the CSS does not apply and I keep getting the issue:
"Resource interpreted as Stylesheet but transferred with MIME type text/plain".
In the source code, however, I explicitly list that these files are "text/css". Any ideas on how to solve this?
This was an Nginx issue. I needed to place
include /etc/nginx/mime.types;
in the "location /" block.
Check if you have set "rel='stylesheet' attribute.

Nginx: Correctly setting the mime type for gzipped styles/scripts

I have a gzip-compressed style and scripts in files:
/scripts.js.gz
/styles.css.gz
The problem is that it does not serve the correct mime-type and browser does not recognize, that the files are compressed css or js (browser recognize the type as application/octet-stream, where it should be text/css or so).
I tried adding the following to mime.type of nginx, but with no effect. I suppose, it does not recognize, that the file is compressed.
types {
text/css css.gz;
application/x-javascript js.gz;
}
When trying to access the files, the browser handle the files as files to download and not to present.
I had the same problem, coming from Apache.
The problem I found is, the types block does not allow you to specify .css.gz as a file extension. However, the location block does! My solution is to make a location for .css.gz and then modify the content type for .gz within that location, like this:
location ~ \.css\.gz$ {
add_header Content-Encoding gzip;
gzip off;
types {
text/css gz;
}
}
Do not change the mime types and use the Gzip Static Module to handle this.
When this is active, Nginx will try to serve "file.ext.gz" first and then try "file.ext", if not found, for all requests within the context (location etc) where it is active.

Resources