I need to transfer files from one location to another, and the destination folder should be the user's download location.
I was wondering if it's possible to obtain the browser's download location using Node JS or simply Javascript. I need a way to do it that works for all systems and browsers possibly.
Up to now I was just typing the location manually, but I need an automatised way of doing it of course!
At least on Windows, this will normally be %USERPROFILE%/Downloads.
In NodeJS, you could write:
var downloadFolder = process.env.USERPROFILE + "/Downloads";
It is not possible in node.js to know the user's download location unless you ask the user to specifically type it into some input field in a form. That location is purely a user agent setting that is purposely not disclosed to any server or web page for security reasons.
Furthermore, the server or webpage cannot influence where a file might be saved by the browser on the user's local hard drive anyway (again for security reasons) so there's nothing useful a server can do with that information anyway unless you happen to be running a server that is on the same machine as the browser. If you're working in that type of controlled environment, then perhaps you could use a browser extension that does have access to some of these kinds of things.
Related
I'm working on a windows app which is reading a "authorized" domains list from a txt file with a web request from "domain.com/sub/txtfile"
I don't want people to see the content of the file when entering it directly in the browser. Is it possible to achieve this with some .htaccess hacks or something else?
As your app is a client-side native Windows application, it's not possible to store any secret in the app itself that could be used for authentication. As the user has everything the Windows app may have, it impossible to authenticate the client as discussed many times here.
It also doesn't make much sense. Imagine it was somehow possible and file contents were only visible to your app. What would be the purpose? What if an attacker changed the hosts file on Windows to download the file from a rogue server? What if he used an intermediate proxy to inspect, change or replace contents? The latter is also possible with https, because the user has full control of the client, and can trust whatever certificate he wants.
You could authenticate the user though. An attacker can still see and modify downloaded file contents, but at least not anybody could download the file, only your authenticated users. But this means having a user database where the file is downloaded from, and implementing proper authentication. And it still doesn't solve the other problems.
In short, you can't protect a client-side application from a user that controls the whole client.
I'm bundling a Chrome extension along with a software.
During the installation I'm creating a User ID and writing it in the registry.
I want my extension to "know" this value too, Can I do it without NPAPI plugin?
If you have a web-site for your product, you can do the following. During installation submit new UserID to your site (in addition to writing it into the Registry), then open in Chrome a specific page on your site, which should contain the same UserID in parameters. Your extansion can read outgoing requests, so it can parse out the UserID. Next it should check response from your server, which must compare UserID value obtained from the browser and the one obtained earlier from your installation. This will prevent UserID spoofing.
Also, though I'm not sure you'll not consider next suggestion as an overkill (so NPAPI plugin looks like acceptable solution as well), but here is how I made a binding between a Chrome extension and external program (for some much more sophisticated purposes than just reading the Registry).
You can build a minimal local web-server (or websockets server) processing requests on a dedicated port, provide it with registration information (UserID, etc), and then request required data from the extension just by means of ordinary http-request (for example, AJAX, or websockets client).
The methods have a drawback related to the need to setup user's firewall, so it would allow traffic either from your installer, or from local web-server.
Goal: to download archives from a web-site (ordinary hosting). An user must know nothing about downloading, a connection, a file storage on a web-site.
I use idHTTP+SSL to download archives. But user can access a web-site -> I can set Basic Authentication, but an user can see a user name/password e.g. in HTTP Analyzer.
A program downloads file with settings. Settings are in a form of a plain text. This text can be seen in HTTP Analyzer too.
I can to encrypt this text but what about archives? I need to secure everything at one time.
Therefore I do not want that user could see an web address of archives and setting file. It can be pasted in a web browser -> please download everything...
How to prevent all these?
Thanks!!!!!!!!
I assume "ordinary hosting" means the usual PHP/Perl hosted site where you can't really run arbitrary software or make significant site-wise configuration changes. I'd take the following steps:
Configure the folder where your archives and "text file" reside to only accept HTTPS connection, then make sure you only connect using HTTPS: "HTTP Analyzer" (or any analyzer for that matter) will no longer be able to see your traffic.
Give your archive meaningless names (GUID's?), so there's no way for the user to just enter a file name into the browser and download that. You'll need to "map" the actual file names to the GUID's using your TXT file.
For extra points replace the "TXT" file with a script that authenticates your application before providing the actual data. Even a simple salted hash of the current date and time would be enough to deter most users.
Of course, I expect this question to be followed up with other questions, some on ServerFault, some here on SO:
How to block plain HTTP access to a folder using [name your server software]
How do I authenticate my application so an ordinary browser can't download my TXT file.
How it is possible to move cookie from one browser to another? This must be done through the browser options
It sounds like you would like to be able to set a cookie in one browser (such as Google Chrome) and be able to access it from another browser (such as IE6).
If that is the case, check out evercookie (a very beefy solution).
If you want something more lightweight, you could try Adobe Flash cookies.
An easy way to see flash cookies in action:
In one browser open a YouTube video.
Change the volume.
Open a YouTube video in another browser.
You will be able to see that the volume has been remembered between browsers.
If you're trying to manually copy cookies between browsers, this JavaScript bookmarklet may be useful - it allows you to access and modify the cookies of the current domain; this means you could run it in one browser, copy the cookies to clipboard, then run in another browser and paste.
Note that some apps may store browser-specific data (or flags) in cookies (or related components, like sessions), which may lead to strange behavior (e.g. "this-cookie-was-set-for-IE6=1, enable broken-browser-workarounds").
We're providing a web form whereby users fill in their personal information; some of it is sensitive information (SSN, Birthday, etc). Upon user submission, the data is prefilled into a PDF which is then made available via a link.
We are creating the PDF in a folder that has write access on the website.
How can we safely create and add PDFs in this folder, with whatever naming scheme (use a GUID?), such that another user cannot guess/spoof the PDF file location, type this in the URL and access another person's PDF?
Maybe the PDF folder has rights only specific to the user, but that may be a different question on how that is accomplished. (The number of users is unknown, as this will be open to public).
Any thoughts on this? In a nut shell, we need to allow the user to view a PDF of the data they just entered while preventing more-savvy users to figure out the location of PDF files, allowing access to other files.
Thanks!
trying to obfuscate the path to a file isn't really making it secure. I would find a way to email or another way to fetch it for the user instead of allowing access to an open directory.
Make the web app fetch the file for the user instead of relying on web server open folder permissions.
just keep in mind obfuscation isn't really security.
If it's really just for the moment, create a completely random file (20384058532045850.pdf) in a temporary directory, serve that to the user immediately and remove it after a certain period of time.
Whether your web app has write rights on that directory or not (I assume you are talking about chmod user rights) is not important, it can't be breached trough the web server and I don't see a problem in revealing the directory path per se - you have to reveal something in giving the user a URL to download. If your PDF names are random enough, there is practically no risk of somebody being able to guess the name of another PDF file in the same directory.
As the PDF contains sensitive data: Don't forget to turn off caching to prevent a local copy of the PDF being saved on the client's browser cache.
I don't know for sure whether turning off caching through the appropriate headers is enough to prevent local caching in all browsers. You might have to look into that.
For the purpose of pdf's, would it not be better (I know I will get flamed for this) to store the actual pdf into the database as a BLOB, which would be on the back-end of the website in question?
There will be no reference to the URL anywhere nor will there be a specific path highlighted in any links on that form.
Hope this helps,
Best regards,
Tom.
The simplest way is to proxy the file through your application (fpassthru() in php for example), this allows you to use what ever access control/identification system you already use for the dynamic content.
If you don't have any means of identifying your users and restricting access, and assuming your platform has a secure session mechanism, you can protect the file by storing the filename in the user's session and then returning that file (and only that file) to the user when requested. This should mean that an attacker would have to spoof a session to access the file so this should be as secure as your session mechanism is.