I have built my entire website with Flash and embedded several swf objects (slideshows) into it. Everything works fine when I publish it as swf movie, but now that I want to upload my website, an error message occurs saying:
Error #2044: Unhandled SecurityErrorEvent:. text=Error #2140: Security sandbox violation: file:///mylayout.swf cannot load file:///slideshow_1.swf. Local-with-filesystem and local-with-networking SWF files cannot load each other.
I know that it has something to do with the fact that one of the swf files is local to the filesystem and the other local via networking, but in my publish settings, I told it to access local files only. That didn't help.
I am hosting my website at www.all-inkl.com; besides that, I have not uploaded it yet; I'm just testing it offline. I know I should add this code somewhere:
<allow-access-from domain="localhost" secure="true"/>`
but I'm not sure where to add it. Maybe to my timeline?
The crossdomain.xml file should have your server name specified. For example take a look at http://www.msn.com/crossdomain.xml
You will have to specify the domain names there. Your server should also be having a crossdomain.xml. Add the corresponding server name there. For example if you are using localhost, try adding
<allow-access-from domain="localhost" secure="true"/>
check your swf loading paths. try to specify the entire path like "hppt://www.yourdomain.com/yourweb/mylayout.swf" like this for every swf. and set the html code where the swf embed tag for allowScriptAccess : "always"
Related
I am in a basic Next.js/Node.js project, and want to load a YAML "page metadata" file to generate a social media image. The metadata only has title, url, and image and such. The problem is, I load this YAML metadata from a file that is based on the URL, which can potentially be hacked.
So if I have a URL like /foo/bar/baz, I want to load the YAML config for that page inside $APP_FOLDER/data/pages/foo/bar/baz/metadata.yaml. The problem I'm imagining (in Node.js), is you change the URL to /../../something-secret like even /../../package.json, and doing the following will load the package.json:
fs.readFileSync(`${process.cwd()}/data/pages/${urlPath}`)
So it would resolve to (for example):
fs.readFileSync(`./data/pages/../../package.json`)
I don't want that, that is a security problem.
So I think about the path module, and doing path.relative(a, b), but I'm not sure that is correct or would solve the problem.
My question is kind of generic though, how do I (in Node.js) prevent a user from navigating the file system like this? How can I enforce "only allow searching within the ./data/pages folder recursively"?
Could you put these static files inside the /public directory of your Next.js project? Then you could more safely fetch from URLs instead of local file system. Also, Since Next.js primarily makes isomorphic React apps, you will probably have trouble using fs, or other Node modules that you wouldn't find in the browser, unless you try the new experimental "app" directory.
What I want to do is to create a direct link URL to a mp3 file which is located on my Google Drive and use it on Audio object of HTML5, but I get 403 error.
I know that when one tries to create a link of a file located on Google Drive, it creates not a direct URL to the file but a URL for viewing the file through a viewer such as
https://drive.google.com/file/d/<file ID>/view?usp=sharing
I googled to find it is possible to rewrite it into a direct link URL like this:
https://drive.google.com/uc?id=<file ID>
I set this URL in the src property of my audio element. However, when I try play() method, the following error is thrown:
GET https://drive.google.com/uc?id=<file ID> 403
myProject.html:1 Uncaught (in promise) DOMException: Failed to load because no supported source was found.
So I tried to access to the URL https://drive.google.com/uc?id=<file ID> from my browser.
Then, I got this:
403. That’s an error.
We're sorry, but you do not have access to this page. That’s all we know.
I tried many times so it is not likely that I'm mis-pasting the <file ID>.
What should I do to create a valid direct link URL of the file?
I would appreciate for any information.
Progress
I got what was wrong.
The problem was that a file on Google Drive can be accessed only from the user who is authorized, which means only the owner of the Google account can access the file URL.
I tried to access it from Chrome Browser which is associated with the Google account, then, the error didn't occur.
However, I want to serve this file to all the people.
What should I do to give permission for access to other people?
You understand that Google drive is not a file hosting service right? This solution is not going to be very stable even if you do get it to work.
For it to work your going to need to set the file public so that everyone can access it. Then i would be willing to bet you will need an API key to do this in the long run.
Also remember that file id is not stable it can change in the future if for example you upload the file.
I solved this on my own. I right clicked the file, clicked Get link, and changed the authorization selection from Restricted into Anyone with the link. Then, the 403 error vanished for the access from anyone.
I have a web application where user can upload and view files. The user has a link next to the file (s)he has uploaded. Clicking on the link will open the file in the browser (if possible) or show the download dialog (of the browser). Meaning that, if the user upload an html/pdf/txt file it will be rendered in the browser but if it is a word document, it will be downloaded.
It is identified that rendering the HTML file in the browser could be a vulnerability - Cross Site Scripting.
What is the right solution to this problem? The two options I am currently looking at are:
to put Content-Disposition header in the response to make HTML files downloaded instead viewed in the browser.
to find some html scrubbing/sanitizing library to remove any javascript from the file before I serve it.
Looking at the gmail, they do the second approach (of scrubbing) with having a separate domain for the file download - may be to minimize/distract the attack surface. However in this approach the receiver gets a different file than what was sent. Which is not 'right' in my opinion; may be I am biased. In my case, the first one is easy to fix. But I wonder if that is enough, or is there any thing that I overlook!
What are your thoughts on these approaches? Or do you have any other suggestions?
Based on your description, I can see 3 posible attack types (maybe there are more):
Client side code execution
As you said, your web server may serve a file as HTML and run javascript code on the client. This can be avoided with Content-Disposition but I would go with MIME types control through Content-Type. I would define my known type of files (e.g. pdf, jpeg etc.) and serve them with their respective MIME type (e.g. application/pdf, image/jpeg etc.). Anything else I would serve it as application/octet-stream.
Server side code execution
Althougth I see this as an out of topic attack (since it involves other parts of your application and your server) be sure to avoid executing files on the server (e.g. PHP code through LFI). Your webserver should not access directly the files (e.g. again PHP), better store them somethere not accesible through a URL and retrive them on request.
Think if here you are able to reject files (e.g. reject .exe uploads) and ask the user to zip them first.
Trust issues
Since the files are under the same domain, the files will be accesible from javascript (ajax or load as script) and other programs (or people) may trust your links. This is also related to the previous point, if you don't need unzipped exe files, don't allow them. Using an other domain may mitigate some trust problems.
Other ideas:
Zip all files uploaded
Scan each file with antivirus software
PS: For me sanitization would not work in your case. The risk of missing something is too high.
To render on threejs, we need some images(jpg/png) and , jsons(uv data). All these files are stored in respective folders and the files visible for clients to look at.
I use django/python to start a local server, python code is compiled to .pyc & js code is obfuscated. But the folder structure is accessible for Casual Users. In threejs, we use tex_loader and json_loader functions to which the file paths are given as inputs. Was looking at ways of securing the behind the scenes work.
Happened to read about custom binary formats, but that felt like a lot of work.
or giving access to files only for certain process starting through django/web browser?
Are there any available easy to deploy solutions to protect our IP ?
An option would be to only serve the files to authenticated users. This could be achieved by having an endpoint on your backend like:
api/assets/data.json
and the controller in the backend would receive the file name(data.json), the code could check if the user requesting the endpoint is authenticated and if so read the file from the file system(my-private-folder/assets/data.json) and return it as file with correct mime-type to the browser.
Good day!
Here's a question... we are storing a large file in the third party storage. The link to it is located on our website built with Express in Node. The goal is to make sure that the client doesn't see the path to the external website.
Examples:
File actual location: http://www.some.storage/bucket/SuperBigFile.exe
Path to file from our website: http://www.ourWeb.site/files/SuperBigFile.exe
I tired it with
res.redirect("http://www.some.storage/bucket/SuperBigFile.exe");
and
request('http://www.some.storage/bucket/SuperBigFile.exe').pipe(res);
request(...).pipe(res) would stream the file through our server and the file itself is a pdf report with a size of 300mb. Everything that goes through our primary server usually gets hung after 30-40mb, that was the primary reason of moving the file to the storage, but the client doesn't want the users to see the path to the storage...
Both versions redirect to download the file and it can be in fact accessed through http://www.ourWeb.site/files/SuperBigFile.exe url, but let's say if I'm using fidler debugger, I can see requests to the original file at the storage. Is there a way to hide it completely so, it won't be visible from the client side? So, the client would think that it is coming from our website?
Thanks.