I have a web resource which returns json content with Content-Type:application/json. Usually the content is displayed in browser directly but sometimes it's not, instead, a download prompt shows.
I know there's a header Content-Disposition:inline/attachment which can explictly tell browser whether to download or show. But if I don't specify this header, how does browser decide? What's its strategy?
From Mozilla's File types and download actions (emphasis mine):
When you click a link to download a file, the MIME type determines what action is taken. If you see an "Opening " dialog asking if you want to save the file or open it with a specified application, that normally means that your Mozilla application cannot handle the MIME type internally, no plugin is installed and enabled that can handle it and you have not previously selected a download action or helper application to always use for that type of file.
The browser comes preconfigured to handle basic formats like images. Plugins (which may be bundled with the browser) add handling for various common file types like pdfs. There can also be "helper applications", which means the browser downloads and forwards the file automatically to the application (such as a torrent magnet link opening your torrent client)
Everything else, it will ask until a user binds a default action (if the Content-Type is application/octet-stream, you can't set a default action). The other browsers work the same.
What Content-Type is specified in the header? If the browser doesn't know what it is, it probably defaults to application/octet-stream and prompts for download.
Here's a brief blog about it.
Related
I have a web application where user can upload and view files. The user has a link next to the file (s)he has uploaded. Clicking on the link will open the file in the browser (if possible) or show the download dialog (of the browser). Meaning that, if the user upload an html/pdf/txt file it will be rendered in the browser but if it is a word document, it will be downloaded.
It is identified that rendering the HTML file in the browser could be a vulnerability - Cross Site Scripting.
What is the right solution to this problem? The two options I am currently looking at are:
to put Content-Disposition header in the response to make HTML files downloaded instead viewed in the browser.
to find some html scrubbing/sanitizing library to remove any javascript from the file before I serve it.
Looking at the gmail, they do the second approach (of scrubbing) with having a separate domain for the file download - may be to minimize/distract the attack surface. However in this approach the receiver gets a different file than what was sent. Which is not 'right' in my opinion; may be I am biased. In my case, the first one is easy to fix. But I wonder if that is enough, or is there any thing that I overlook!
What are your thoughts on these approaches? Or do you have any other suggestions?
Based on your description, I can see 3 posible attack types (maybe there are more):
Client side code execution
As you said, your web server may serve a file as HTML and run javascript code on the client. This can be avoided with Content-Disposition but I would go with MIME types control through Content-Type. I would define my known type of files (e.g. pdf, jpeg etc.) and serve them with their respective MIME type (e.g. application/pdf, image/jpeg etc.). Anything else I would serve it as application/octet-stream.
Server side code execution
Althougth I see this as an out of topic attack (since it involves other parts of your application and your server) be sure to avoid executing files on the server (e.g. PHP code through LFI). Your webserver should not access directly the files (e.g. again PHP), better store them somethere not accesible through a URL and retrive them on request.
Think if here you are able to reject files (e.g. reject .exe uploads) and ask the user to zip them first.
Trust issues
Since the files are under the same domain, the files will be accesible from javascript (ajax or load as script) and other programs (or people) may trust your links. This is also related to the previous point, if you don't need unzipped exe files, don't allow them. Using an other domain may mitigate some trust problems.
Other ideas:
Zip all files uploaded
Scan each file with antivirus software
PS: For me sanitization would not work in your case. The risk of missing something is too high.
Very basic question.Here it goes.
The client hits a url in the server.The server can send content in the form of
static files(javascript/html).
xml/json(predominantly the purpose of this file is to return some DATA to the client).
Downloadable file-kinda zip files.For this part the server needs to set the content type property to something to let the client know that it wants this file to download of something.
My question is how does the browser differentiate between the static files and api responses(form of xml/json/string) ??
Thanks,
Gully
HTTP Headers.
There's no such thing as a "file" in HTTP. There are requests and responses, each of which consist of headers and content. The response content may be the contents of what was a "file" on the server, and may be intended to be treated as a "file" on the client (such as downloading a .zip file), but the response itself is not a file. The way that the server indicates to the client that something should be a file is through the HTTP headers.
Specifically the two headers you're talking about are:
Content-Type
Content-Disposition
The first tells the client (browser) what kind of data it's receiving. There are lots of examples, and most browsers understand what to do with most common types. The second can be used to suggest to the client that the content should be saved as a file rather than displayed. For example, the Content-Type might be for an image, and by default a browser will just display an image. But you can add a Content-Disposition header to indicate that the image is an "attachment" and even suggest a file name for it, instructing the browser to save the file (or prompt the user asking to save the file) instead of displaying it.
I'm trying to setup some automated testing using Browserstack's Selenium and their Node.js driver. I want to check if the page is showing any insecure content warnings when accessing the URL via HTTPS.
Is there a way to detect that in Selenium? If one browser does it easier than another that's fine.
Here are a few different ways to detect this using Selenium and other tools:
iterate through all links and ensure they all start with https:// (though via Selenium, this won't detect complex loaded content, XHR, JSONP, and interframe RPC requests)
automate running the tool on Why No Padlock?, which may not do more than the above method
utilize Sikuli to take a screenshot of the region of the browser address bar showing the green padlock (in the case of Chrome) and fail if not present (caveat of using this in parallel testing mentioned here
There is also mention here of the Content Security Policy in browsers, which will prevent the loading of any non-secure objects and perform a callback to an external URL when encountered.
UPDATE:
These proposed solutions intend to detect any non-secure objects being loaded to the page. This should be the best practice for asserting the content is secure. However, if you literally need to detect whether the specific browser's insecure content warning message is being displayed (aka, software testing the browser vs your website), then utilizing Sikuli to match either the visible existence warning messages or the non-existence of your page's content could do the job.
Firefox creates a log entry each time it runs into mixed content, so you can check the logs in selenium. Example:
driver = webdriver.Firefox()
driver.get("https://googlesamples.github.io/web-fundamentals/fundamentals/security/prevent-mixed-content/simple-example.html")
browser_logs = driver.get_log("browser")
and, in browser_logs look for
{u'timestamp': 1483366797638, u'message': u'Blocked loading mixed active content "http://googlesamples.github.io/web-fundamentals/samples/discovery-and-distribution/avoid-mixed-content/simple-example.js"', u'type': u'', u'level': u'INFO'}
{u'timestamp': 1483366797644, u'message': u'Blocked loading mixed active content "http://googlesamples.github.io/web-fundamentals/samples/discovery-and-distribution/avoid-mixed-content/simple-example.js"', u'type': u'', u'level': u'INFO'}
How to get Internet media type of a document using SharePoint web-services? I access the service using SOAP. I've tried the Content Types documentation, but it is something different than Conten-type/Internet media-type/MIME.
SharePoint doesn't know about MIME-types. At least it doesn't know this on a per-file basis.
Check out SPFile which represents a file in SharePoint. The closest you might get is SPFile.ProgID: "Gets a string that identifies the application in which the file was created.", but that doesn't correspond to the MIME-type and nor is it always filled.
The MIME types are actually assigned by the IIS web server as you can see in this explanation:
Add new file type in SharePoint
So you will not be able to get the mime type by querying the SOAP web service. Your only chance is to download the file in question and check the HTTP Header in which you should find the Content-Type assigned by the IIS.
You won't be able to query by content type or similar stuff, you will have to use file extensions for that (e.g. xlsx, docx) - the IIS does nothing differently, it assigns the MIME-types by file extension. So instead of trying to get the mime-type, it might be easier to just get the file extension and deduct the mime-type from there.
Lastly: The SharePoint Content Type is a SharePoint internal construct. It represent different types of content in SharePoint, not always relating to downloadable documents. It has nothing to do with mime-types.
In case of server-side code you may use:
SPUtility.GetMimeTypeFromExtension(".pdf")
I'm wondering, is it even possible to treat the request for the Xul Browser component to open a new window? I tried changing the window.open function, but looks like it's never called.
All links that open in a new window are not opening in my application.
I found this page on the subject, but the provided solution is showing no different behavior.
Any hint on this?
(by the way, I'm developing a stand alone application, not a Firefox's extension)
I'm assuming you are in a XULRunner application, and that you are trying to load a chrome URL from a non-chrome source in a browser (e.g. HTTP or local file). While enabling UniversalXPConnect and UniversalBrowserWrite can be helpful, they are also a security risk (since any arbitrary script on the web could use them), so they tend to be disabled in browsers (for example, running that line in Firebug will give you an exception):
>>> netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect UniversalBrowserWrite");
Error: A script from "http://stackoverflow.com" was denied UniversalXPConnect UniversalBrowserWrite privileges.
How about you try using codebase security principals and see if that makes a difference? (http://www.mozilla.org/projects/security/components/signed-scripts.html#codebase). For me in Firebug it does allow me to get the additional permissions after I OK it with a big, nasty looking dialog), but still doesn't allow me to open a Chrome URL with window.open. The next step is probably to try changing your conf file to use contentaccessible so that the relevant parts of your content are accessible (see https://developer.mozilla.org/en/Chrome_Registration#contentaccessible).
To avoid the nasty message when elevating permissions, you could try setting permissions for the right files automatically as described at http://forums.mozillazine.org/viewtopic.php?f=38&t=1769555.
Also, make sure you check the browser type (https://developer.mozilla.org/en/XUL/Attribute/browser.type). If the browser type is not chrome, then it might be worth trying making it chrome and seeing if that makes a difference.
If any of my assumptions are wrong get back to me and I will try something else.
does normal js not work?
window.open(url,windowname,flags);
There are two ways that I know of.
The first is to set the browser.chromeURL preference to a chrome URL that contains a <browser type="content-primary">. The page that the content window tried to open will load into the given browser.
The second is to set the property window.browserDOMWindow with an object that you define to implement the nsIBrowserDOMWindow interface. This allows you to divert the open call into a tab, if you are using a tabbed interface. Note: the tabbed browsing preferences must be set to allow windows to be diverted into tabs, otherwise XULrunner will fall back on browser.chromeURL.