I have the below code in the controller.
The parameters base64String, fileName are being sent from the browser.
var fileContent = Convert.FromBase64String(base64String);
return File(fileContent, contentType, fileName);
How do I address the XSS threat here?
The above code is based on a fix recommended here
Kendo UI Grid Export to Excel / PDF not working on IE9
I'm assuming you are not returning HTML to your users (you are returning PDFs or Excel files, or something else for download by the browser instead of for render).
The general guidelines are as follows:
Set the correct Content-Type header.
Set the following response header: X-Content-Type-Options: nosniff. Browsers such as Internet Explorer will try and auto detect the content type and ignore the one you've just set.
Set the Content-Disposition header so the browser downloads the file rather than displaying it: Content-Disposition: attachment; filename="bar.pdf"
Following the above should ensure that any script code contained in the file is not executed by your browser. Be aware that IE (again!) can sometimes process script in XML files, so you should test for this.
Related
When I set response content type as Excel, the Open/Save dialog is shown twice , just on IE8. It works fine on other browsers (tested on Chrome/Firefox/Opera).
The code for setting response content type is:
response.setContentType("application/vnd.ms-excel");
response.setHeader("Content-disposition","attachment;filename=abc.xls");
I searched for solutions/workarounds. Turning off Smartscreen didn't help.
Also, another suggestion was to wait for 5-10 sec before clicking Save/Open. That too didn't work.
What's the cause of this? Are there any IE specific workarounds?
It's a pain but IE8 is still widely used by the users.
This is just a guess, but it could have something to do with the way Office (used to) embed itself in IE with plugins.
A workaround might be putting it in a zip file before sending it over to the user.
I'm sending the HTTP header "Content-type: application/atom+xml; charset=utf-8" in my Atom 2.0 feed right now (using the header() function in PHP).
Whenever I open the URL in Chrome or Konqueror, it will just show text.
If I change that to application/xml, Chrome will display an XML tree and Konqueror will still display that as text.
Since I have an Agregator on my computer, shouldn't that xml be opened with it?
And if not, since these standards have more than 10 years, shouldn't these browser at least put a button on top of the page to invite downloading an Agregator?
Because of these 2 reasons I guess I'm not using the proper content-type. What do you think?
That's the correct Content-Type for an Atom feed (application/atom+xml). However, Chromium does not handle it correctly (Issue 104358: RSS feeds are not parsed correctly).
One possible workaround for Chromium's bug is to use a more general type (e.g., application/xml). Alternatively, stick with the correct type and accept that users who have chosen that browser will get a more confusing experience.
I have the following code snippet:
WebClient client = new WebClient();
String htmlCode = client.DownloadString(newurl);
webBrowser1.DocumentText = htmlCode;
BTW, webBrowser1 is defined globally elsewhere in the program. Likewise, "newurl" is a valid url also defined globally elsewhere.
WebClient gets the complete html which I pass to webbrowser1 using DocumentText.
This result is all kinds of link, syntax, remote javascript, and other errors as though the html is corrupted. However, if I use
webbrowser1.Navigate(newurl);
the target page displays just fine.
I am getting the source html so I can make changes before I display it.
Clearly I am missing something.
Any thoughts?
Regards,
Jim
webBrowser1.DocumentText = htmlCode; will set the HTML only, but will not load any linked-in resources, such as JS, images, CSS, ... .
If you want to do, what you seem to want to do, you can e.g. load the HTML via a WebClient, rewrite it (this includes changing relative paths to absolute ones or setting a base url), write it to a file, then webbrowser1.Navigate("file://path/to/file");
I'm trying to build a chrome extension that overrides a download of a file and displays it in the browser. For example if you click on a link to a '.csv' file I'd like it to render in the browser instead of downloading it.
Chrome already does it for PDF's types and the Xml Tree extension also does exactly that for xml files.
So it should be possible, just not sure how to go about catching that event?
An implementation along the lines indicated by in the previous answers and specifically designed for CSV files can be found in this extension of mine on github:
https://github.com/rgrp/chrome-csv-viewer
Furthermore, with the new(ish) chrome webrequest API a direct approach is also now possible along the following lines:
Listen to onBeforeRequest (this has to be in a background script - see background.js)
Check if this is a CSV file (mimetype or file extension)
If so cancel the request and then display the data using xhr
A working version of this can be found in a branch of that extension: https://github.com/rgrp/chrome-csv-viewer/tree/4-webrequest-intercept
You could always look at the XML Tree code :).
If you only need to work with links, and not opening files from the address bar or File > Open, you could build a content script that adds a click event listener to every link.
In the event listener function:
Add e.preventDefault() in the first line to prevent the browser 'following' the link.
Using the link href value, get the data with XMLHttpRequest.
In the XMLHttpRequest callback, open a new tab and render content accordingly.
Obviously, in many ways, this is not a great solution:
you want 'normal' links to be handled as usual by the browser
how can you tell if a text file contains comma-separated values (for example) except by looking at the file extension which, of course, may not be reliable?
Are you specifically thinking of .csv files -- and/or other specific types of content?
I'm dynamically generating a text file in PHP, so it has a .php extension but a text/plain MIME type. All browsers display the file as nicely preformatted text, except IE8.
Googling tells me that they've added security where if the HTTP header content type doesn't match the expected content type (I think based on the extension and some sniffing) then it forces the file to be downloaded. In my case I have to open it, and also give it permission to open the file I just told it open! That's probably a Win7 annoyance though. Serving a static plain text file works fine, of course.
So can I stop IE8 from downloading the file and get it to view it normally? The code has to run on multiple shared hosting environments, so I think I'm stuck with the .php extension.
Add this to your HTTP header:
X-Content-Type-Options: nosniff
It's an IE8 feature to opt-out of its MIME-sniffing.
Source
Alternatively, you can "trick" IE8 into thinking that it is indeed serving up a text file. These 2 lines do it for me and don't involve using non-standardized "X-" headers:
Header("Content-Type: text/plain");
Header("Content-Disposition: inline; filename=\"whatever.txt\"");