For example the page is sending a 'link' http headers field that I don't want to load an async CSS from. How can I block it? Is it possible that I get those headers, remove the LINK field from it, and then page will load without this addition CSS (non-placed in page body)?
I have tried to modify the headers to no avail.
request('https://www.google.com', function(err, resp, data){
if (resp.statusCode == 200) {
console.log(resp.headers); // headers
}
else {console.log(err);}
});
Request is a node.js module. I need to modify headers before they are loaded by browser (passing modified headers by 'render' with combination of ejs template is not working).
Yes, its possible to remove the css and js links (they are not headers) from the html response and just display the result using jsdom or cheerio.
Update: The OP is talking about "Web Linking", the RFC5988 stuff on prefetch resource with HTTP response header, and want to block such prefetch behaviour.
In order to do that, a proxy can be made manually, block all unwanted data, and only return HTTP headers and content of interest. For example:
router.get('/proxy-to-google', function(req, res) {
request('https://www.google.com', function(err, resp, data) {
// get interested headers from resp object, and set it in res
res.set('Example-Header', 'XXX');
...
res.send(data);
});
});
There are 3 types of head/header in the world of web, and it seems you have confused with these concepts.
HTTP header. These are the header information delivered in HTTP request and response. In the example of question, the HTTP response headers are printed.
<header> element in HTML. These are visible element exists in HTML page body, mostly used to wrap elements such as title, navigation bar etc.
<head> element in HTML. This is the meta element of HTML document. It is not visible in page, but rather responsible to mark important information of HTML document, such as CSS stylesheet links, JavaScript file URLs etc.
In your case, you are trying to block the 3rd kind of "head" above, and you can make it using #Zuei Zukenberg's proposal. This <head> element has nothing to do with HTTP headers.
Related
From the OWASP's website
https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html:
Send a Content-Security-Policy HTTP response header from your web server.
Content-Security-Policy: ...
Using a header is the preferred way and supports the full CSP feature set. Send it in all HTTP responses, not just the index page.
I don't understand how that could be true as it is possible to set the Content-Security-Policy by using a meta tag in the HTML.
I also don't see how the policy can apply to anything else but HTML pages.
Does anyone have idea why that statement above was made and if it is safe to only send HTTP header Content-Security-Policy for text/html responses?
By the way, the policy is too big and I would like to sent as fewer bytes as possible.
This is still something that’s not formally specified and there ai still some debate on this: https://github.com/w3c/webappsec/issues/520
In general there’s two arguments here:
On the one hand some other file types (XML, PDF, perhaps even SVGs) could benefit from CSP and any resource could become the page by right clicking and opening in a separate tab.
On the other hand CSPs can get quite big and are usually written for HTML pages. So a bit wasteful to send on other resources and most of it won’t be relevant.
The right answer (as suggested by above) is probably to have a reduced, and very strict, CSP for all non-HTML responses.
But I think for most people having it on the HTML only will be good enough and bring most of the benefits of CSP. Then again CSP is an advanced technique so if going as far as that, then why not do it properly?
Using a header is the preferred way and supports the full CSP feature set.
I don't understand how that could be true as it is possible to set the Content-Security-Policy by using a meta tag in the HTML.
Inside the meta tag are not supported the directives:
report-to and report-uri
frame-ansectors
sandox
Also meta tag does not support Content-Security-Policy-Report-Only feature, only the Content-Security-Policy.
All resources that start loading before meta tag in the HTML code are not affected by CSP. Malicious scripts can be injected as first item of the <head> section just before meta tags
The nonce-value is exposed in meta tag therefore can be easely stealing by script and reuse.
Using meta tag you can only set the CSP for HTML pages, but CSP is applied for XSLT in the XML pages, and for some other kinds of content (see below).
Therefore indeed an HTTP header is the preferred way to delivery CSP and using CSP via meta tag does not allow you to use full CSP feature set.
Send it in all HTTP responses, not just the index page.
I also don't see how the policy can apply to anything else but HTML pages.
The specification had in mind a little different - you should send CSP with any response page with HTML content, not only for 200 OK, but even for 404 Not found
403 Access Forbidden, etc.
Because these pages has access to cookie that can be steal in the page not covered by CSP.
CSP is applied not only to HTML pages, but to XSLT in XML-pages, to external javascripts files for workers (in Firefox). Also frame-ancestors directive of CSP HTTP header applies to any content (JPEG/GIF/PNG/PDF/MP4/etc) intended to be embedded into iframe, see the nitty-gritty here.
I'm writing simple web app which generates simple CSS file for user.
I've mapped servlet for writing CSS on specific tag, and depending of the user's session attributes, I use PrintWriter for generating CSS stylesheet.
Problem: Stylesheet doesn't have any effect. Chrone shows it was downloaded (inspect element -> network), but it doesn't have any effect on my htmlpage.
In html, CSS is defined by: <link href="stylesheet.css" rel="stylesheet" type='text/css'>.
That will happen if the response content type is (implicitly) set to something else than text/css. You can easily verify it in response headers section in HTTP traffic monitor.
Explicitly set it before writing any byte to the response body.
response.setContentType("text/css");
// ...
Is it possible (or sensible) to build a custom MediaTypeMapping to select a MediaTypeFormatter based on content from the Request Body?
I'm thinking specifically of a case where I have a very non-descriptive text/plain in a multipart/form-data payload and I want to use heuristics to work out what's contained.
I'm currently doing this in a custom MediaTypeFormatter that looks at the first few lines, and if the content begins with { then it assumes JSON, if it's word,word,word the the commas indicate CSV.
I was thinking that a MediaTypeMapping would be cleaner but I don't know if it's sensible to try and match from the Body content.
Currently there is no way you can really Inspect content in Webapi. You can not read the stream more than once.
I'm doing an AJAX feature for my Umbraco website.
Basically what I'm trying to do is when someone requests for http://mysite.com/news with the XmlHttpRequest header then I want Umbraco to return JSON of the following page.
What I've been trying to do is finding the right place to check for the header in Umbraco. Basically I want to override or inherit some class where I could check the header and return the page in Json or HTML depending on the header.
I'm using Umbraco 4.7.0 (1.0.4090.21631)
Any feedback would be more than welcome! Thanks!
I'd probably use the URL Rewriting module for IIS7 to detect the content-type in the request, then redirect to the same URL with /jsonTemplate on the end of it. You would then create a masterpage called jsonTemplate, with a single macro inside it, which would return your JSON.
This is common for Umbraco - specifying a separate template with a separate macro to return a different view of the same content. Check out http://blog4umbraco.codeplex.com/SourceControl/changeset/view/68424#1138733 for an example of an XSLT macro that returns RSS using this approach.
You should check the Content-Type header from server side logic. Your Javascript should be specifying a Content-Type like application/json.
I'm attempting to dynamically set the backgroundImage for a div where the image source url is not the true/final destination url but instead returns a 301 redirect pointing to the actual image url. Using this redirecting url in a standard < img src=" ... tag works normally as the browser transparently follows the redirect. However, it apparently does not do the same for backgroundImage.
My only thought at the moment is to use XMLHttpRequest to perform a HEAD request, determine the actual URL from the headers returned and use that as the backgroundImage, but this obviously involves significant overhead. Can anyone offer a better alternative?
Have a script build the image dynamically based on session or cookie data. I do it all the time.
Have your current script that is returning the 301 download/generate the image itself, or use URL rewriting to do the redirect at the server side.
If it's a small background image you might consider encoding it in BASE64.
body {
background-image:url(data:image/png;base64,<base64 STRING>");
}