Google's downloadDataURI in Firefox - javascript

I use Google's downloadDataURI function to download the PNG exported by a Google Chart.
In Chrome is working well, but in Firefox instead of downloading, replaces the html content with the PNG that is generated.
Anybody knows how to fix that behavior in Firefox?

First of all, this doesn't look like it is a Google project at all, but just a project somebody put up on the free Google Code hosting service (+ appspot)
What it does:
It checks if the browser is "webkit", and if not just changes the location to the data URI. This is exactly what happens in firefox and why the PNG is displayed instead of being downloaded.
Otherwise, it will construct a hidden <form> and <input> and post it to some random HTTP appspot server. And this does not sound very secure. The people running the appspot instance could log requests and/or a man-in-the-middle attacker could passively monitor the unencrypted transmission.
Honestly, I wouldn't use this service, ever, because I cannot trust the transmission channel, and I cannot trust the people behind it.
Instead, consider using <a download=... >, e.g. see Is there any way to specify a suggested filename when using data: URI?

Related

Writing and downloading files clientside crossbrowser

I have a program where the user does some actions (i.e. clicking on several buttons). I want to record their clicks and the buttons that they click to allow the user to then download a text file with a record of their clicks when they click a separate "download" button. I looked at the File-system APIs for HTML 5, but they seemed to not have cross-browser support. I would ideally like to have this entire file generation and download scheme be entirely client-side, but I am open to server-side ideas as well.
TL;DR: Essentially I'm looking for an equivalent to Java's FileWriter, FileReader, ObjectOutputStream, and ObjectInputStream within Vanilla JS or jQuery (would like to stay away from php, but I'll use it as a last option).
Also, why don't all browsers support the filesystem api? (I'm guessing that it would make MSWord and Pages go out of business with all the open source clientside text editors that could come out.)
Unfortunately the HTML5-File-system is no longer a part of the spec, long story short FF refused to implement because they claimed everything you could do in the File-System API was doable in the HTML5 Indexeddb (which was mostly true). Please see this blog post for more on why FF didn't implement. I do not know IE's story. (I may have exagerated why FireFox didn't implement, I'm still bummed because you cannot actually do everything in indexeddb that you can do in the noew "Chrome File-system API")
Typically if two of those three browsers implement a spec, it stays in the spec. Otherwise that spec gets orphaned. However, I'm fairly certain a large reason the file-system api didn't take off is because of the IndexedDB API (caniuse IndexedDB) really took off when both specs were introduced. If you want cross browser support, check this api out.
That all said if you are still set on the file-system api some developers wrote a nice wrapper around the IndexedDB, the File-system api wouldn't actually supply you with a stream anyway. You would have to keep appending events to a given file given a fileWriter object. you'd then have to read the entire file and send to the server via an ajax request and then downloaded from the server once successfully uploaded.
The better route would be to use the IndexedDB apiwhich as stated on developer.mozilla
Open a database.
Create an object store in upgrading database.
Start a transaction and make a request to do some database operation, like adding or retrieving data.
Wait for the operation to complete by listening to the right kind of DOM event.
Do something
with the results (which can be found on the request object).
Here are a couple tutorials on the IndexedDB.
https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Using_IndexedDB
http://www.html5rocks.com/en/tutorials/indexeddb/todo/
As for giving the user that file, as mentioned briefly before you would have to upload the file to the server and download upon the "download" request. Unfortunately you have to trick the user into giving them the data already on their machine. Anyway, hope this all helps.

How to check the authenticity of a Chrome extension?

The Context:
You have a web server which has to provide an exclusive content only if your client has your specific Chrome extension installed.
You have two possibilities to provide the Chrome extension package:
From the Chrome Web Store
From your own server
The problem:
There is a plethora of solutions allowing to know that a Chrome extension is installed:
Inserting an element when a web page is loaded by using Content Scripts.
Sending specific headers to the server by using Web Requests.
Etc.
But there seems to be no solution to check if the Chrome extension which is interacting with your web page is genuine.
Indeed, as the source code of the Chrome extension can be viewed and copied by anyone who want to, there seems to be no way to know if the current Chrome extension interacting with your web page is the one you have published or a cloned version (and maybe somewhat altered) by another person.
It seems that you are only able to know that some Chrome extension is interacting with your web page in an "expected way" but you cannot verify its authenticity.
The solution?
One solution may consist in using information contained in the Chrome extension package and which cannot be altered or copied by anyone else:
Sending the Chrome extension's ID to the server? But how?
The ID has to be sent by you and your JavaScript code and there seems to be no way to do it with an "internal" Chrome function.
So if someone else just send the same ID to your server (some kind of Chrome extension's ID spoofing) then your server will consider his Chrome extension as a genuine one!
Using the private key which served when you packaged the application? But how?
There seems to be no way to access or use in any way this key programmatically!
One other solution my consist in using NPAPI Plugins and embed authentication methods like GPG, etc. But this solution is not desirable mostly because of the big "Warning" section of its API's doc.
Is there any other solution?
Notes
This question attempts to raise a real security problem in the Chrome extension's API: How to check the authenticity of your Chrome extension when it comes to interact with your services.
If there are any missing possibilities, or any misunderstandings please feel free to ask me in comments.
I'm sorry to say but this problem as posed by you is in essence unsolvable because of one simple problem: You can't trust the client. And since the client can see the code then you can't solve the problem.
Any information coming from the client side can be replicated by other means. It is essentially the same problem as trying to prove that when a user logs into their account it is actually the user not somebody else who found out or was given their username and password.
The internet security models are built around 2 parties trying to communicate without a third party being able to imitate one, modify or listen the conversation. Without hiding the source code of the extension the client becomes indistinguishable from the third party (A file among copies - no way to determine which is which).
If the source code is hidden it becomes a whole other story. Now the user or malicious party doesn't have access to the secrets the real client knows and all the regular security models apply. However it is doubtful that Chrome will allow hidden source code in extensions, because it would produce other security issues.
Some source code can be hidden using NPAPI Plugins as you stated, but it comes with a price as you already know.
Coming back to the current state of things:
Now it becomes a question of what is meant by interaction.
If interaction means that while the user is on the page you want to know if it is your extension or some other then the closest you can get is to list your page in the extensions manifest under app section as documented here
This will allow you to ask on the page if the app is installed by using
chrome.app.isInstalled
This will return boolean showing wether your app is installed or not. The command is documented here
However this does not really solve the problem, since the extension may be installed, but not enabled and there is another extension mocking the communication with your site.
Furthermore the validation is on the client side so any function that uses that validation can be overwritten to ignore the result of this variable.
If however the interaction means making XMLHttpRequests then you are out of luck. Can't be done using current methods because of the visibility of source code as discussed above.
However if it is limiting your sites usability to authorized entities I suggest using regular means of authentication: having the user log in will allow you to create a session. This session will be propagated to all requests made by the extension so you are down to regular client log in trust issues like account sharing etc. These can of course be managed by making the user log in say via their Google account, which most are reluctant to share and further mitigated by blocking accounts that seem to be misused.
I would suggest to do something similar to what Git utilises(have a look at http://git-scm.com/book/en/Git-Internals-Git-Objects to understand how git implements it), i.e.
Creating SHA1 values of the content of every file in your
chrome-extension and then re-create another SHA1 value of the
concatenated SHA1 values obtained earlier.
In this way, you can share the SHA1 value with your server and authenticate your extension, as the SHA1 value will change just in case any person, changes any of your file.
Explaining it in more detail with some pseudo code:
function get_authentication_key(){
var files = get_all_files_in_extension,
concatenated_sha_values = '',
authentication_key;
for(file in files){
concatenated_sha_values += Digest::SHA1.hexdigest(get_file_content(file));
}
$.ajax({
url: 'http://example.com/getauthkey',
type: 'post'
async: false,
success:function(data){
authentication_key = data;
}
})
//You may return either SHA value of concatenated values or return the concatenated SHA values
return authentication_key;
}
// Server side code
get('/getauthkey') do
// One can apply several type of encryption algos on the string passed, to make it unbreakable
authentication_key = Digest::<encryption>.hexdigest($_GET['string']);
return authentication_key;
end
This method allows you to check if any kind of file has been changed maybe an image file or a video file or any other file. Would be glad to know if this thing can be broken as well.

Download file without javascript

There's this website which has a javascript method in it that downloads a file. To call this method you have to set what language and serial number you're looking for and when that's done, the file is being generated according to the specified information you've just stated and then the file is being downloaded. Does anyone know how to specify this information, then send it and then download the file without going to this website?
Thanks in advance, Steve-O
If you use any tool that shows you what actual networking happens, you can discover the specific web requests that downloads the file. Chrome has those tools built in. The Firebug add-on adds those tools into Firefox. There are also apps that record all networking to/from the browser such as Fiddler which can be used to sleuth on the networking being done.
Of course, there may also be some authentication going on (a log-in, some cookies, etc...) that might be required, but all of that is visible with the right developer tools. Once you see exactly what is being sent over the wire, it's usually not hard to send that same request without a browser or without visiting that web page. If login credentials are required, that will still be required, but even that can be provided without a browser (e.g. from a server-side script).
JavaScript, as of the moment, can't download files. So how files gets downloaded? Well, the developer redirects the browser to a URL using
location.href = 'http://site.com/download.zip';
When the browser is redirected to this URL, it can't open the file, so it downloads it.
You need to determine that URL the browser redirects to. There are many ways to do that. One that comes to mind is the Fiddler app that records each HTTP request and thus can give you the URL.
My guess, however, is that the URL is generated on the fly. You need to study the JavaScript in this case and see the required mechanism to make the server generates the URL.

Least complicated way to get full file paths with Javascript

This has been asked a lot of times already: I need to get the full file path via a web-page. The use case is an application running on the same machine as the browser (i.e. the application starts a local HTTP server and fires up the browser.) File-paths are of course valid and the same for both client/server now. The use case it that the user selects a file and then the server process does some computation on it, and the input files are typically large (read: several GiB in size.)
The easiest thing would be to directly access the path using , but for security reasons, this is disabled. I'm looking now for the least intrusive workaround to this problem. The target browser in question is Chrome. I'm fine if the user has to click "accept" once on some security warning, as long as I can ensure that it won't appear again.
Do I have to write an extension, NSPlugin, can I use some special header magic to mark my page as "local", is there some security setting I can set? The less the client has to do the better, and I would prefer some "click here to allow access ..." solution above everything else. Can I directly install an extension from the server process that would do this (after the user clicks accept?)
Is it possible to do this with a Java applet/Flash? That would be the easiest solution, and clients are guaranteed to have Flash installed (as it is bundled in Chrome...)
You can create Java applet for tasks like this and self-sign it. User will have to allow it to run, but then you will be able to access applet's function that will return file path string via Javascript.
Clearly file io on the client's system is forbidden from JavaScript. If this wasn't the case it would be absolutely trivial to hack every web browser that visits your website.
Battlefiled 3 is controlled though the browser. To do this EA wrote a browser extension for the top three browsers. But that's resource intensive. If you just care about chrome you can use an addon, and for that i suggest using the NPAPI.
And as MOleYArd said, Java is a good solution and probably more common than an extension or addon.

File upload with Javascript without user intervention

I have a Firefox component for PDF signing that I invoke via Javascript. The problem is that this component outputs the signed PDF as a file on the user's filesystem - there is no way to get a byte[], stream or similar.
I need to post this signed PDF file back to the server. Is it possible to do this in plain Javascript, without additional Firefox components?
You can't do this without under intervention, this would he a huge security hole. Think about visiting a webpage and it being able to grab and upload any of your files without you doing a thing...you can see how this would be abused really fast.
You might be able to do this with a Firefox extension, I'm not sure of the security limitations it imposes (though I wouldn't be surprised if it disallowed this as well), but JavaScript would not be an option here.
There's no direct way to access data on a user's file system within a browser unless you're doing it through an extension. This would be a huge security risk.
If the file can be put into an <input type="file" /> element in Firefox, you can use JavaScript to automatically upload the data to the server without user intervention, but you would need something to initially get the file into the page's memory, not the file system.
Hell no - And for very good reason. You wouldn't want every Tom, Dick and Harry automatically grabbing all your files.
I believe it's the file input that needs user interaction. You can post the form automatically but you can't fill it in.
IMO your best bet is replacing the whole Firefox component with a single Java applet - I'd all but guarantee there's a Java project for PDF signing. Perhaps even Flash or Silverlight as long as you can do what you need with your PDF.

Categories

Resources