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.
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.
Need to test file upload feature for security. Purpose is to avoid/stop any type of malicious files from being uploaded.
Thanks !!
There are multiple vulnerabilities that usually come up around file uploads/downloads.
Malware in uploaded files
Any uploaded file should be virus-checked. As #CandiedOrange responded, you can use the EICAR test for that purpose.
Path injection
The filename for an uploaded file is te same type of user input as any other field in the request, an attacker can freely choose the filename. As a tester, you can send something like "../filename" to try and save it to unintended locations or to overwrite other files.
Filetypes
If the filetype restriction is only on the client, that's obviously useless for security. But even if the file extension is restricted on the server side, say only .pdf is allowed, you can still try to upload something.pdf.php or something.pdf.exe or similar to get around the filter. It's best if the application uses some real content discovery to find out if the uploaded file is actually an allowed filetype.
Content sniffing
Some browsers have this awesome (not) feature that when a file is downloaded, the browser looks into its content and displays it according to the content, regardless of the content type header received from the server. This means even if uploads are restricted to say .pdf, an attacker might upload an html file with javascript, in a file named "something.pdf" and when somebody else downloads that file, the browser may run the javascript, thus making the application vulnerable to XSS. To prevent this, the application should send the X-Content-Type-Options: nosniff response header.
Uploaded file size
If an attacker can upload too many or too big files, he may be able to achieve denial of service by filling up the space on the server.
Download without restriction (direct object reference)
An application might save uploaded files to a location directly accessible to the webserver. In such a case, download links would look similar to /uploads/file.pdf. This is only suitable for public files, access control cannot be enforced that way, anybody that has the link can download the file.
Lack of access control
If files are not available to all logged on users, the application must perform authorization to decide whether the user that's logged in can actually download the file he is requesting. Too many times this authorization step is missing or flawed, resulting in the application being able to serve the wrong files to users cleverly modifying requests.
So the bottom line is, file upload/download vulnerabilities are much more than just virus checking uploaded files.
If you're security is signature based consider uploading an EICAR test file. It should trigger your protection and if it doesn't, and is somehow executed, all it will do is print "EICAR-STANDARD-ANTIVIRUS-TEST-FILE!" and stop.
Well you can activate malware protection on your network firewall. Snort is good option for protecting websites.
You can also add input filters to your application code so it checks if the uploaded file has malware
is there any security issue if I send a path in a QueryString? like if send this request http://localhost/eCTDTreeViewer/Home/Index/?pathOnServer=G:\test\company2
Thinking about QueryString security, you should keep in mind (read as "worry") the following moments:
URLs are stored in web server logs
URLs are stored in the browser history
URLs are passed in Referrer headers
You can find more detailed information about this reading How secure are query strings over HTTPS article and Is an HTTPS query string secure? question on SO.
The risk of exposing a path, given the filesystem is not externally accessible, is negligible.
Especially if the sole purpose of the component you're talking about is to display directories as they exist on the server. What you see in the query string is what you will see in the payload of the response, so it's just fine having the path there in plain text.
Trouble can arise when this "TreeViewer" exposes sensitive files and allows the user to browse to arbitrary locations, enabling them to retrieve passwords stored in files and what not.
Of course it never hurts to add HTTPS, but that only prevents a man in the middle from finding out which directories and files exist on that server and does not offer anny additional security.
HTTPS does not make your improperly secured application secure, you still have to implement authentication and authorization, input sanitation and so on.
Yes, you open yourself up to Directory Traversal (DT) and Local File Inclusion (LFI) attacks.
The main difference between the two is that DT is read-only in which a user can access any file on your web server provided that they have sufficient privileges. LFI on the other hand would allow you to invoke a file (e.g. a PHP file) on the web server rather than reading it.
If, for example, you have a SQL Injection vulnerability on your web application, an attacker may deploy a web shell into your system:
SELECT "<?php system($_GET['cmd']); ?>" INTO OUTFILE C:/tmp/shell.php
An attacker could then invoke the file:
http://localhost/eCTDTreeViewer/Home/Index/?pathOnServer=C:/tmp/shell.php?cmd=echo "foo"
This is very brief but it should provide a good idea as to how dangerous it can be.
If you stay in plain HTTP, yes. The request will be sent in plain text over the network. Don't be confused, it will be the same issue with a POST request with your information inside the body of it.
The good way to make it safe is to use HTTPS. Because of the handshake done before the exchange, the full request will be encrypted (with the path as well) to be sent to the endpoint.
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.
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.