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.
Related
I'm currently creating a simple script that is essentially just a form that people can fill out an upload a couple of files.
When I click Deploy as a Web App, one of the form items asks "Execute the app as". One of the options is: Me (example#gmail.com)
Is this safe?
Does that mean anyone who has a link to the script essentially becomes logged in to my account?
Are there security risks to this?
One of the most important issues is, who has access to the Apps Script file. The file sharing settings are set totally differently than the web app deployment settings. You can have the Apps Script file SHARED settings, set to not being shared with anyone, and still have anyone be able to access the web app. So, access to the web app, and access to the file are two different things. That's a key point to understand.
The Execute the app as me, is not inherently unsecure. It doesn't log someone into your account. IF you somehow configured your app to give broad access to your account, which you can do, that's obviously a potential security hole. You should set scopes manually in the appsscript.json manifest file that are more restricted. For example, restricted scopes to your Gmail and Drive if the Web App sends an email, or accesses your Google Drive. You can restrict the email scope to only be able to send an email, and restrict the Drive scope to only be able to access files and folders that the script created, or that the user picked with the Google file picker. You can restrict access to only the current spreadsheet, instead of all your spreadsheets.
Are there potential security holes? Yes. But there aren't any security holes that you wouldn't have with any web app. So, it's really dependent upon the practices you use.
Don't use/store settings/parameters in client side HTML, that directly cause a server function to perform an action that you don't want anyone to be able to execute.
How secure your app is depends on some simple practices.
Don't store settings or information in HTML that could cause a security hole. Passwords is the obvious example. Don't put names of files in HTML code. Don't pass settings or parameters in Client side calls to the server that are obviously a direct link to a server function that has broad access to your account.
You can put an underbar at the end of server side function names so that a user can't know the names of your server function.
https://developers.google.com/apps-script/guides/html/communication#private_functions
Have a main server function that then calls a private function, that in turn branches to other functions. So the user will never know the name of the function that is ultimately doing all the real work.
If someone else has access to modify your Script, then yes, he can re-publish the app that will have access to whatever you previously authorized, but won't have new authorizations. Eg, if you used only SpreadsheetApp as your first code and authorized it, someone who has access to modify this script you already published can open all your Spreadsheets and erase them, but wont be able to touch the Docs.
Someone with the published app URL will have none of this, it will only run the scripts you/shared scripters published.
I use "Me"/"Anyone Even Anonymous" quite frequently, published dozens of apps and never had any issue.
I don't have a clue of what I have to do in order to fix that and after searching this website it looks like I could get an answer here.
I'm working on a website of a client. He's a marketer and he has digital products and he allows some of them to be downloaded for free.
After they click the download, I send them an email with a link for the download.
My question is: how can I encrypt this link so that the file location remains hidden? The files are usually in video, mp3, or pdf format.
IF the files are protected only by not publicising their URLs, this is not good security practise (security through obscurity), particularly if directory browsing is enabled. However, you may not have the option to redesign their website.
The best way is to issue them with some form of token or user name that they present (type in to a web page or supply on the URL) which is verified by the web server and, if successful, the download then starts. A few considerations:
These tokens (effectively passwords) should be generated randomly (such as through a cryptography standard random number generator)..
A hash of the token is stored on the server (say using PBKDF2).
The tokens should time out. Remember that the E-mail sent to the customer is not encrypted and can be intercepted or viewed by many. Similarly, unless the site is accessed over SSL, they are sent unencrypted to the site, too.
You cannot encrypt HTML links. By definition, the browser needs to know where to send the user clicking the link. Even if you did obfuscate the links within the HTML, a junior-level security analyst would be able to bypass this 'security' mechanism using a proxy such as Paros.
What you need to do is authenticate users to your client's site before authorizing them view resources (download your client's files). Programmatically restrict users to see/download only what they should be allowed to access.
Let's say, there is a website for an online diary. Users upload their secrets to the web server and stored in the database. Normally, a user without the password can't see the diary items. However the web admin or DB admin could still can connect to the DB and see everything.
Is there a solution to prevent this? I mean a solution for the whole web application, not only for a single user.
Client-side javascript can encrypt the content, using a key known only to the client and never sent to the server, prior to saving.
However, the server can at any time start serving up malicious JS that would send the keys back down to the server. The only way to make this impossible is to make your application an installable client-side app (via an extension or whatever - but nothing that auto-updates). Additionally, all of this paranoia is pointless unless the user can verify what the app is doing, so it would need to be open-source.
At this point you're basically writing GnuPG, so you might as well just use that.
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.
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.