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.
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.
My web application displays some sensitive information to a logged in user. The user visits another site without explicitly logging out of my site first. How do I ensure that the other site can not access the sensitive information without accept from me or the user?
If for example my sensitive data is in JavaScript format, the other site can include it in a script tag and read the side effects. I could continue on building a blacklist, but I do not want to enumerate what is unsafe. I want to know what is safe, but I can not find any documentation of this.
UPDATE: In my example JavaScript from the victim site was executed on the attacker's site, not the other way around, which would have been Cross Site Scripting.
Another example is images, where any other site can read the width and height, but I don't think they can read the content, but they can display it.
A third example is that everything without an X-Frame-Options header can be loaded into an iframe, and from there it is possible to steal the data by tricking the user into doing drag-and-drop or copy-and-paste.
The key point of Cross Site Attack is to ensure that your input from user which is going to be displayed, is legal, not containing some scripts. You may stop it at the beginning.
If for example my sensitive data is in JavaScript format, the other site can include it in a script tag
Yep! So don't put it in JavaScript/JSONP format.
The usual fix for passing back JSON or JS code is to put something unexecutable at the front to cause a syntax error or a hang (for(;;); is popular). So including the resource as a <script> doesn't get the attacker anywhere. When you access it from your own site you can fetch it with an XMLHttpRequest and chop off the prefix before evaluating it.
(A workaround that doesn't work is checking window.location in the returned script: when you're being included in an attacker's page they have control of the JavaScript environment and could sabotage the built-in objects to do unexpected things.)
Since I did not get the answer I was looking for here, I asked in another forum an got the answer. It is here:
https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.security/9U6HTOh-p4g
I also found this page which answers my question:
http://code.google.com/p/browsersec/wiki/Part2#Life_outside_same-origin_rules
First of all like superpdm states, design your app from the ground up to ensure that either the sensitive information is not stored on the client side in the first place or that it is unintelligible to a malicious users.
Additionally, for items of data you don't have much control over, you can take advantage of inbuilt HTTP controls like HttpOnly that tries to ensure that client-side scripts will not have access to cookies like your session token and so forth. Setting httpOnly on your cookies will go a long way to ensure malicious vbscripts, javascripts etc will not read or modify your client-side tokens.
I think some confusion is still in our web-security knowledge world. You are afraid of Cross Site Request Forgery, and yet describing and looking for solution to Cross Site Scripting.
Cross Site Scripting is a vulnerability that allows malicious person to inject some unwanted content into your site. It may be some text, but it also may be some JS code or VB or Java Applet (I mentioned applets because they can be used to circumvent protection provided by the httpOnly flag). And thus if your aware user clicks on the malicious link he may get his data stolen. It depends on amount of sensitive data presented to the user. Clicking on a link is not only attack vector for XSS attack, If you present to users unfiltered contents provided by other users, someone may also inject some evil code and do some damage. He does not need to steal someone's cookie to get what he wants. And it has notnig to do with visiting other site while still being logged to your app. I recommend:XSS
Cross Site Request Forgery is a vulnerability that allows someone to construct specially crafted form and present it to Logged in user, user after submitting this form may execute operation in your app that he didin't intended. Operation may be transfer, password change, or user add. And this is the threat you are worried about, if user holds session with your app and visits site with such form which gets auto-submited with JS such request gets authenticated, and operation executed. And httpOnly will not protect from it because attacker does not need to access sessionId stored in cookies. I recommend: CSRF
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.
Is it possible to secure only the Login.aspx page (and the postback) and not the whole site in IIS?
We are looking to do this specifically with a SharePoint site running Forms Based Authentication against our Active Directory.
Links to this will be helpful.
This is what we have done so far:
1. Setup SharePoint to use FBA against AD.
2. Moved Login Page to Secure/Login.aspx
3. Set the appropriate Login url in web.config as https://..../Secure/Login.aspx
This is not working and help is needed here.
However even if this works, how do we get the user back to http from https?
There's not a whole lot of point. If the only thing that's encrypted is the Login.aspx page, that would mean that someone could sniff all the traffic that was not sent through the login page.
Which might prevent people from getting user:pass, but all your other data is exposed.
Besides all the data which is exposed, and the user's operation which can be changed en route, the user's session id (or other authentication data) is sent in the clear. This means that an attacker can steal your cookie (...) and impersonate you to the system, even without getting your password. (If I remember correctly SPSv.3 also supports builtin password changing module...)
So I would say that this is not a Great Idea, unless you dont care about that system very much anyway.... But then, why bother with authentication at all? just make it anonymous?
I agree with AviD and Dan Williams that securing only the login page isn't a great idea because it exposes other data after leaving the password page. However, you can require SSL for only the login.aspx page via the IIS Manger. If you navigate to the login.aspx page in IIS Manager (I believe it's under /_layouts), you can right-click on the individual file and select Properties. From there, go to the File Security tab and click on the Edit... button under Secure communications. There, you can check the Require secure channel (SSL) box, and SSL will be required for that page only.
I'm not positive about getting the user back to http from there, but I believe its default behavior is to send you to the requested page if the login is successful. If not, I would think you could customize where the login page sends you on a successful login.