I would like a way of doing this:
User selects client-side file from prompt.
Browser passes file reference to client-side code.
Code can read and write to the file indefinitely without any more user interaction.
It needs to run in the browser.
(This is not a duplicate of How do I open a file stream in javascript?; that question is over 5 years old and the file APIs have changed a lot since then. Also, it doesn't keep the file open.)
I dont think you can open a file w/o re-prompting the user unless your code is privileged in the browser (like a browser extension). I have found an api that let you do exactly what you want. but you need privileges to use it.
Related
I'm not an expert in cyber security and exploits. I need help figuring out if my app is vulnerable and in what way.
Let's assume I'm an idiot (and I'm not to this extent), and I leave the possibility for client users to upload (exploiting my front end) any file they want on my server in a subfolder (let's call it 'danger') of my ASP.NET application, hosted on IIS.
Being that way, anybody can upload a generic example.hml file and access it back at the url mydomain.com/danger/example.html. They can also upload JS files and whatever they want.
Let's forget for a moment the fact they can fill my disk.
Given I prevented ASP execution from files in that folder, what kind of damage can I be subjected to?
Thanks in advance.
Just off the top of my head:
An attacker could upload a corrupted file which would trigger a remote-code execution vulnerability in your antivirus, potentially executing code under the local system account. (I've seen this happen with Windows Defender, and I've seen reports of similar vulnerabilities in other AV products.)
They could upload a file with a mangled name which exploited a bug in IIS to bypass your file-type checks and the "no execute" flag on the folder. (I've seen this reported, albeit in a very old version of IIS.)
If the files can be accessed publicly, they could host their own content on your site, potentially including illegal or malicious content. This could damage your site's reputation, and potentially leave you liable to prosecution.
Well, yes, you do have to be carefull IF YOU allow any kind of preview, or say allow the person to download the file, but when you download, you also attempt some kind of preview on the server.
In fact, this is not a lot different then dropping a simple text box into a form, and then letting the user type in information into that text box, you then say hit submit button, and now re-display the page with what they just typed in.
What happens if they start typing in javascript text into that text box?
Say a multi-line text box in which you can type in a paragrath of comments or text.
So, you type in this:
Hellow how are you
<script>
JavaScript code here
</script>
Now, when you go to re-plot the page - not only are you re-display of what was typed in, but those script code typed in ALSO will run!
In fact, if you drop a text box on a web page, and do this:
Hello, how <script> are you
You notice you get a page exectution error. (becuase asp.net has built in protection to NOT allow this). However, if you adopt some html editor text box (ckEdit, or ajaxtoolkit editior), such controls will have additional security code to prevent end users from typing in script code.
So, a few things you have to be concered about:
If you allow up-loading of files, then ensure that you don't have code that attempts to load/execute that file. So, you might allow users to up-load pdf files, and then maybe a routine that attempt to "open" or use that file. But what happens if they in place of a pdf file up-load a MyTest.exe. In other words, they up-load a exectuable program in place of a pdf? Well, then you mostly ok, but you BETTER NOT have code that attempts to load such files - especially code behind that may use some library or code that in effect launches that pdf or word or exec file. Since that code then might try to load or run what is now a .exe program.
So, this means a few things:
You want to limit the file extensions allowed
You need to ensure that your code does not "execute" that up-load file
If you allow download of that file, then careful how you do this
(again, ensure that you don't open up possibiity to execute that file).
So, for the most part you should be ok, but if up-loaded files are further processed by your server side code, then just be aware of HOW you open or process such up-loaded files.
As noted, say users up-load a simple text file, and after up-loading you take the text from that file, and then display it in some kind of memo or text box in a web page. But, again, you sure it is just text in that file? And if you pull the content from that file and THEN have it render in your browser (because you assumed text), but it now might have browser code injected into that text file.
So, any point in your server side code that opens up-loaded files, pulls the content and THEN say spits out that content for display of data is a caution area.
So, the first simple line of defense?
Limit the types of files. If users are expected to upload only PDF files then ONLY allow say PDF and maybe .zip file extensions - reject anything else.
And as noted, just keep in mind any kind of post-processing code you have that runs AFTER up-loading that file. If your site is taking such up-loaded files, and is to open up the file(s), AND THEN DISPLAY that content back to the end user, then again caution is required, since when you display such content in a browser, that content in theory can have script code - and like anything else your code spits out to the browser (like a web page with HTML etc.) also means that the browser will run that script code.
I mean, a browser simple takes whatever the server sends to that browser, and renders the HTML. However, these days, browsers have MUCH more ability to also run code in that browser. So, that's why now you can say run cool games 100% in a browser, since browsers have become VERY powerful systems, and almost their own computer system in their own right. So, the ability of browsers to run code and give an experience that rivals the desktop in terms of speed and response (and even interactive games) is the result of browsers now being able to run code and do much MORE then just display some simple HTML.
So, under no case should you allow up-loading of files, and then have some software that can "run" or even pull contents of that file and spit it out back to the user in the form of browser display. And the reason is that file content may well have executable code in that file contents.
Used Filesaver.js plugins to download a text file. By default file download in My download folder. Need to store the downloaded file in a specific folder.
It is not possible... fortunately! Imagine what would happen if JS which runs in your browser could change your filesystem. The security hole would be so big that everyone would (and definitely should) stop using the Internet. Imagine a situation where I've built a website which onload fires the code which save a file in your filesystem. The file lands in your cron.daily directory (suppose you use Linux). What is the file doing? - you may ask (if you knew that it's been even saved :smiling_imp:). Nothing special - just looking for some private data and when finished it deletes random files from /usr/bin, /proc, /sys and maybe /etc - just to see what happens.
Do you see the problem now? The code which runs in your browser before you can react to this cannot have such power to save anything in your filesystem. The only thing you can do to give the user a file is to use a module like Filesaver.js which, in fact, does not have access to user's file system at all. It just makes a GET request to the file directly and it's the browser which downloads the file (because that's how a browser works). So the only way you can change the location of the downloaded file is to change the browser settings. No other way I know of.
The answer is No,
changing a directory is not possible due to security reasons in the
File API.
https://github.com/eligrey/FileSaver.js/issues/42
There is a Javascript that needs to be executed after hitting the page in the browser. This javascript runs only when it is stored as a bookmark in the browser. My task is to execute this javascript that is stored in the bookmark in the browser using a java code.
On Googling, I find that the URL can be bookmarked via a java code. But I dont find how to read the bookmark. Please suggest how can I read it through java code.
Thanks in advance!
There is an answer which said that is impossible to do it unless you do a browser extension:
Get browser bookmarks via javascript
Although another answer talks about upload the browser bookmark file and read it in javascript :
Inside the "...\Chrome\User Data\Default\" directory are two files. "Bookmarks", and "Bookmarks.bak". One is for your current bookmarks, and the other one (with the .bak extension) signifies that it is a bookmarks backup, if anything goes wrong. Bookmarks.bak gets overwritten every time you close Chrome.
Bookmarks in Chrome exist as a virtual filesystem. Meaning, that all
your bookmarks are really just stored in one file, but appear as an
actual filesystem inside Chrome.
You only have to copy that file, and back it up somewhere. And if you
want to recovery your bookmarks, simply copy/paste the "Bookmarks"
file you backed-up, back in to the directory you took it from.
Chrome must be closed prior to doing this.
Hope this helps.
(and btw, try opening the "Bookmarks" file with a text editor like
Notepad =])
Location of chrome bookmarks
I'm testing some of the new JS filesystem abilities, i.e. creating an empty text file in the local filesystem. I'm running the HTML & JS files from a local path (file:///). For this purpose I launched Google Chrome with the --allow-file-access-from-files flag from the CLI. The filesystem request is PERSISTENT (and works).
I have read up on different posts about the filesystem, copied and modified some of the code in the tutorials; When I launch the HTML file, my custom success/ failure messages are outputted in the console;
This is the result:
Opened file system:/ // this is the root path of the JS Filesystem.
/wtf.txt // this is the name and path of the text file I created+ it's a success
However, when I look at my directory's (both system and application root), there's no .txt file with the name I assigned to it. How can I know where Javascript really wrote this file? In what "root" (since the 'root' cannot be assigned)? What does it mean that the FileSystem is a 'sandbox'? That I cannot access the (virtual?) contents of it on my local drive, but only with JS? If this is the case, is there a way to prompt the user to save the file?
Thanks in advance for your answers
It seems you're expecting the File System API to work locally similar to an OS file system. The client doesn't work like that. In fact, and API is designed to be your interface, as a programmer, to the files and directories -- the client itself (e.g., Chrome, etc.) will handle the rest on the local level. The API is not designed by which you can create a file via the browser and easily access it via the operating system.
How can I know where Javascript really wrote this file? In what "root" (since the 'root' cannot be assigned)?
Technically speaking, each client can store locally as it chooses. So while you can go to the local file system to look for the file, something is wrong with your approach if you're attempting to do so; the File System API is not meant for that. To your question, you can assume that if there's content the client's storage area (e.g., for Chrome it's something like "C:\Users\USERNAME\AppData\Local\Google\Chrome\User Data\Default\File System\") then you can assume that the JavaScript wrote it. But again, it's not set up for user friendly browsing on the local system.
What does it mean that the FileSystem is a 'sandbox'?
Sandbox simply means an area created and set aside for a specific purpose, outside of which the client cannot see/access. See this from Mozilla: https://developer.mozilla.org/en-US/docs/WebGuide/API/File_System/Introduction#virtual
That I cannot access the (virtual?) contents of it on my local drive, but only with JS?
That is correct, and by design.
If this is the case, is there a way to prompt the user to save the file?
If I understand your question right, you're asking if there is a way to provide a specific file to the user and have it prompt them to save it locally. Well, of course if you provide a link to the file (or push it, a different discussion) then the client will prompt the user to save/store it if their platform allows them to do so. But you have no control over where they save it locally nor can you later get it it. If I've misunderstood your question, comment below and I'll follow up.
I'm developing a web app that needs some sort of filesystem access. Ideally I'd want to be able to "Open..." a file into the app and then "Save" the file back to local filesystem at the location that the user opened it from.
Currently, we use a java applet to achieve this functionality, but since java is going out of style, we're needing to do this with javascript and html5.
Obviously, this can't be done because of security reasons built into browsers, so I'm trying to somewhat emulate it.
I'm using the html5 file api to successfully import/open the files, so that's half the battle. The hard part is getting the saving feature. I'm getting close using an iframe and content-disposition, but problems arise when browsers are set to automatically download the files to a downloads folder... users may get confused and be unable to locate the file they just downloaded.
So, my question is this: is there some sort of onSave event or some kind of way for the browser's "Save As..." window to return at least the filename that the user saved the file under?
Also, I've looked into the filesystem/fileWriter html5 apis, but from my understanding they're limited to only a sandboxed area of the local filesystem and only available in chrome dev releases.
Any help would be appreciated!
No, there is no way to do that with pure JavaScript. You can manage to trigger a download with data URIs or an iframe with some headers but you can't circumvent the browsers' download managers.
You can either use a Flash or Java applet to handle the saving for you, or ask the user to right click on the link and do save as, then he might be able to choose the destination.
One popular option using Flash is Downloadify.