I have my own site where I host my own unique content.
I am adding the option to download my unique content via torrents.
I understand that you need a .torrent file to download data over a P2P network, but people are talking about completely switching to magnet links and not needing .torrents..???
As far as I'm concerned, Magnet links still point to .torrent files and you need the .torrent to start downloading?
Is a Magnet link similar to a http link, as even though it's not a file, you still end up downloading the .torrent file (.html file) once you click on it?
I.E. I cannot create a P2P network for my site only using Magnet links, I still need to create the .torrent file, right?
Thanks,
The comparable concepts are URL vs. URN, i.e. "physical" location vs. content ID.
Related
I would like to create a shockwave file that can display a website with an internal webbrowser or something similar. The final target to display the website in a pdf file, but I think the only way to do this, is the swf trick.
I tried to find resources for this on the web, but found nothing.
UPDATE:
I am looking for a way to display a website in a downloadable pdf file. The website is only one html file fuelled by jquery and css.
Download SWF template for your website and edit it in macro media flash editor.
I would use a PHP script to create a PDF file (my choice for this kind of stuff is TcPDF, which has many example/how to scripts ready to use), and I'd put a captured image of my website in it; there are several websites offering this service for free, just google it, for example webthumbnail.org.
Disclaimer: I'm not linked to TcPDF nor Webthumbnail.org in any way, they are just the first examples that came into my mind.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
I am trying to sell ebooks on my website. The ebooks are in the form of PDF files. The customers pay to download them with Paypal. But if I type the beginning of the ebook into the google search the PDF file comes up. Anyone can then open the PDF file. I have tried this on someone else's computer and the same thing happens.
Thus, the question is, how can I keep my PDF files from appearing in Google and other search engines?
I'll list two solutions in order of complexity.
Use a robots.txt file to prevent your PDF files from being indexed by Google. That will prevent further indexing, however, if someone knows the exact addresses to your PDF files, they can still share the links and download them without paying.
Store the PDF files in a directory outside your Web server root, but which is still readable by the server itself. When someone buys your e-book, register their purchase in a database and send them a customized download link via e-mail. This link will point to a script on your server which will check the purchase into the database. If the user is authorized to download the file, the script will open the right PDF file on the server, read it and pass through its contents to the Web browser. The browser, depending on how the script was made and on the user's preferences, could open the PDF inline (in the browser window) or ask the user to download it. This is the best way to handle downloads as knowledge of the customized download link is required, and you could also block downloads from a specific user in case he/she gives away his/her personal link.
Either way, since the URLs to your e-books have been exposed, you should change them AND ask Google to remove the old addresses via its tools for Webmasters.
Putting unencrypted PDF files online in a way that allows access without prior authorization will always be insecure, since once the link to the PDF is publicly known, anybody will be able to download it. Therefore you should seriously reconsider your distribution strategy.
One time download links and sending the PDF by mail after a successful purchase are probably the best options.
Until then you might want to replace the PDF with an password-protected RAR file and only give the password to paying customers. This obviously is also insecure and requires decompression software capable of handling encrypted RAR files.
In order to address the issue of your PDF being found by Google and other search engines, you should read about robots.txt. However this is not a solution, since not all web crawlers will honor the content of the robots.txt file.
I also believe that you probably don't know about the Internet Archive. This site takes snapshots of websites which might include a copy of your publicly available PDFs.
I'm making a newsletter editor which will allow file uploads (the sender of the newsletter can upload files to the server which will be linked to in the email).
The site is set up so that only .do URIs are actually executed/handled by servlets so it's not much of a security risk, but I've been told to blacklist .jsp, .php, .asp, .aspx, .exe, .com, and .bat. This does not strike me as a comprehensive blacklist, and I've the impression that blacklists are not a good policy.
On the other hand, a whitelist would be dozens long. What's the correct way to identify allowable/disallowable extensions? Or is it more proper to just allow anything and run it by a virus scanner, or some combination of these?
I would allow any file extension to be uploaded, but I would store the files in a folder that is not directly served by the web server. I would then create a HTTP handler that would be linked to from the email, which would stream the requested file. The file could be requested either by original file name, a system generated file name or by an ID. Either way, I would sanitise the parameter to guard against directory traversal attacks.
e.g. www.example.com/FileLink.ashx?FileName=Word.docx
This way you do not need to worry if in future you wish to serve additional file extensions as executable file types, as any file is served directly from a byte stream from the file system and is never passed through the web server handlers.
You can also use the handler to check that the current user has the correct permissions to load the file.
It would also be worth virus scanning each file, just in case the newsletter author uploads (either maliciously or accidentally) a file that would attack subscribers' computers rather than the server.
Also ensure that the Content-Disposition is set to attachment:
Content-Disposition: attachment; filename="filename.html"
This guards against XSS being achieved by upload of HTML containing script tags, or other Same Origin Policy bypasses using Flash or PDF files. The scenario here is one newsletter editor compromising the session of another newsletter editor. It is worth also setting X-Content-Options: nosniff, which can also protect against this. xap files (Silverlight) could also bypass the Same Origin Policy, so check that the filename cannot be ended in .xap to request your file
e.g. www.example.com/FileLink.ashx/x.xap?FileName=Word.docx
and you could blacklist the setting the content type for Silverlight as extra protection for this special case. Source here:
Note: .XAP files can be renamed to any other extension but they cannot
be load cross-domain anymore. It seems Silverlight finds the file
extension based on the provided URL and ignores it if it is not .XAP.
This can still be exploited if a website allows users to use ";" or
"/" after the actual file name to add a ".XAP" extension.
Note: When Silverlight requests a .XAP file cross-domain, the content
type must be: application/x-silverlight-app.
I've also verified these scenarios myself and are are currently valid attack vectors.
Or is it more proper to just allow anything and run it by a virus scanner.
Yes.
Both blacklists and whitelists are trivially circumvented and cause just administration pain and provide no security whatsoever.
In my opinion, even though the whitelist maybe a bit of a chore to maintain, it's far more secure than using a blacklist.
It's much better to forget to add something to the whitelist, and have to go back and change it, than to forget to add a new file extension to the blacklist and get hacked.
In addition to the whitelist, I would still virus scan the uploaded files, as even seemingly harmless files (such as .pdf or .doc) can have malicious code (.pdf's support javascript, and .doc macros)
I would recommend you:
Use a whitelist approach (by the reasons described above, it's fairly
more secure)
Check the filetype (bypassable but still one more measure)
Store uploaded files in internal folders not exposed to the public (using non enumerative IDs)
Set-up a low grade permission to the folder that will contain the uploaded files
Set-up less privileges as possible to the uploaded files
Make sure if there aren't secure libraries to upload files already available.
Antivirus aren't worth it. Most of web shells signatures are really easy to bypass since any 'hacker' can add some random code and do different types of encodings on an web shell. Sure it will protect you from common shells such as C99 but nowadays there are thousands of these tools publicly available and fully undetectable. And regarding protecting your users from executable files or infected PDF's hosted on your websites, if someone it's capable of get a shell on your site and start up a malware campaign it won't use malware or virus already spotted by av signatures.
Before downloading the file, the site checks out fine. After downloading an .exe (non-malicious; an installer for an app used internally by website staff), the browser alerts:
This website has been reported to
contain the following threats:
Malicious software threat: This site contains links to viruses or other
software programs that can
reveal personal information stored or typed on your computer to malicious
persons.
Checking on a different computer, the site is fine. After downloading the .exe, the same message appears again.
Why does this happen? More importantly, how do I prevent it from happening?
The same does not happen in Firefox or Chrome or Safari, using their similar malware-checking features.
Do you have control over the file that is being downloaded? If so, wrap it in compression (zip, rar, or something else). Browsers do not like .exe files being downloaded.
Make the user physically have a link to the download, in a compressed format would also help. A site that tries to send the user a *.exe file would look suspicious to any browser that cares at all for its user.
I want to let users (i.e. anyone who signs up for an account) upload and download video and text documents. I have been researching the security issues regarding letting users upload files, but everything I can find on the subject assumes that users will only upload images.
Are there any security issues specific to letting users upload videos and text documents? Is security a lot more difficult when users can upload files at video size? Are there any particular file extensions I should look out for?
The problem is this: If you let users upload videos, images and text files, some of them will try to upload viruses, server-side scripts and other malicious code. Such code will then expose your site's users to what ever 'bad things' those users uploaded, within the context of your own site.
If you allow such uploads, you must be very careful that you are only saving files of the actual types you planned on - and not by looking at the file extension, either. You also must make sure those files are placed in locations where execute/script permissions are disabled.
Virus checking is a must - but it is not at all enough. A PHP script may not set off virus warnings at all, but that same script could reveal vital information for your site, or cause other bad things to happen if executed.
You must examine the content of the files - never rely on the extension or MIME type reported by the client. Those can easily be faked.
Serve your downloads from a location for which you have disabled the execution of server side code. This is all you need to do to protect yourself from server side exploits. Relying on file extensions or other such things are all hacks.
If you want to fully protect your users (and indirectly your website) as well, you'll need to run the files through a suitable virus scanner. It is possible, and there are real-life examples of doing so, to exploit video decoders and such software to run arbitrary code. But if you start walking down that line, you could also argue that certain text strings might set off weird behavior in certain software, and that starts getting silly. Luckily, the people who write virus scanners will have done most of the work for you. So:
Never execute that what is uploaded
If you feel it's needed, virus scan them as well.
You can virus check each file that is uploaded. If you look at most web based email clients you will see when you upload a file they are checked by McWhoever. In generally you shouldn't let them upload exe files but checking the extension is a very basic (unreliable) method.
It's quite hard to make an upload REALLY secure.
There are quite a lot of things to check - the file extension is just one part of it. Here are few things which have to be at least checked:
file extension (as you've already mentioned)
mimetype
filesize
depending on the users: maybe check the uploads with ClamAV ...
To answer your question here is a meta attack:
bad guy uploads a binary to your
server, perhaps tricking your
filters by compressing file and
changing extension to .avi
exploit bug in a CGI script to
decompress avi from #1
exploit bug in another CGI to
execute file from #2 -> backdoor
installed
backdoor accessed and rootkit
installed to hide all evidence of steps
1,2,3
Some variation on the above is what typically happens when servers are compromised.