I can easily watch and embedd any stream running on Ant Media Server with help of embedd URL but also it seems as other with the stream information can use the URL on their websites too.
I tried using CORS filter but it seems a little complicated and didn't work.
How can I easily prevent my streams from being embedded to unauthorized webistes/domains?
For workaround solutions in Ant Media server (v2.4.3 or older versions) please check here.
In v2.5.0 and above, you can allow selected domains through a single property file to let them embed the iframe code.
To allow only specific domains to embed the iframe code, edit the /usr/local/antmedia/webapps/app-name/WEB-INF/red5-web.properties file and add the below setting.
settings.contentSecurityPolicyHeaderValue=frame-ancestors 'self' https://allow-domain-name;
If you would like to allow multiple domains, then it should be like this.
settings.contentSecurityPolicyHeaderValue=frame-ancestors 'self' https://domain1 https://domain2;
After making the changes, restart the server with sudo service antmedia restart.
'Self' is required to play the stream on the AMS dashboard panel itself. In this way, other than allowed domains, streams cannot be embedded using iframe code on other websites.
Related
My server has links to other servers. I have a relationship with the managers of those servers. I want to be sure that links to PDF files make the client Browser prompt the user to SAVE the file, not to have the file open directly in the Web browser. I don't believe I need to change the HTTP Headers on my server, I need to ask the admins on the associated servers to change THEIR HTTP headers to "allow cross origin" when they receive requests from my site as the "referrer". Is this correct? It's not easy to get this answer, lots of examples to this type of query talk about "go to your Browser settings and change how PDFs are handled", but I need a solution that, apart from users who HAVE set their Browser as their OS default PDF viewer, the PDF files will download to be opened in a sophisticated and powerful PDF renderer.
Tried some experiments on two servers I have direct control over, it seemed to work, but now need to engage with other server admins and I want to be sure I'm asking them to alter their HTTP config header without bothering them excessively: I don't want to have to do a lot of "experiments" with them, I want to be confident that what I'm asking them to do or change is correct.
My server has been compromised recently. This morning, I have discovered that the intruder is injecting an iframe into each of my HTML pages. After testing, I have found out that the way he does that is by getting Apache (?) to replace every instance of
<body>
by
<iframe link to malware></iframe></body>
For example if I browse a file residing on the server consisting of:
</body>
</body>
Then my browser sees a file consisting of:
<iframe link to malware></iframe></body>
<iframe link to malware></iframe></body>
I have immediately stopped Apache to protect my visitors, but so far I have not been able to find what the intruder has changed on the server to perform the attack. I presume he has modified an Apache config file, but I have no idea which one. In particular, I have looked for recently modified files by time-stamp, but did not find anything noteworthy.
Thanks for any help.
Tuan.
PS: I am in the process of rebuilding a new server from scratch, but in the while, I would like to keep the old one running, since this is a business site.
I don't know the details of your compromised server. While this is a fairly standard drive-by attack against Apache that you can, ideally, resolve by rolling back to a previous version of your web content and server configuration (if you have a colo, contact the technical team responsible for your backups), let's presume you're entirely on your own and need to fix the problem yourself.
Pulling from StopBadware.org's documentation on the most common drive-by scenarios and resolution cases:
Malicious scripts
Malicious scripts are often used to redirect site visitors to a
different website and/or load badware from another source. These
scripts will often be injected by an attacker into the content of your
web pages, or sometimes into other files on your server, such as
images and PDFs. Sometimes, instead of injecting the entire script
into your web pages, the attacker will only inject a pointer to a .js
or other file that the attacker saves in a directory on your web
server.
Many malicious scripts use obfuscation to make them more difficult for
anti-virus scanners to detect:
Some malicious scripts use names that look like they’re coming from
legitimate sites (note the misspelling of “analytics”):
.htaccess redirects
The Apache web server, which is used by many hosting providers, uses a
hidden server file called .htaccess to configure certain access
settings for directories on the website. Attackers will sometimes
modify an existing .htaccess file on your web server or upload new
.htaccess files to your web server containing instructions to redirect
users to other websites, often ones that lead to badware downloads or
fraudulent product sales.
Hidden iframes
An iframe is a section of a web page that loads content from another
page or site. Attackers will often inject malicious iframes into a web
page or other file on your server. Often, these iframes will be
configured so they don’t show up on the web page when someone visits
the page, but the malicious content they are loading will still load,
hidden from the visitor’s view.
How to look for it
If your site was reported as a badware site by Google, you can use
Google’s Webmaster Tools to get more information about what was
detected. This includes a sampling of pages on which the badware was
detected and, using a Labs feature, possibly even a sample of the bad
code that was found on your site. Certain information can also be
found on the Google Diagnostics page, which can be found by replacing
example.com in the following URL with your own site’s URL:
www.google.com/safebrowsing/diagnostic?site=example.com
There exist several free and paid website scanning services on the
Internet that can help you zero in on specific badware on your site.
There are also tools that you can use on your web server and/or on a
downloaded copy of the files from your website to search for specific
text. StopBadware does not list or recommend such services, but the
volunteers in our online community will be glad to point you to their
favorites.
In short, use the stock-standard tools and scanners provided by Google first. If the threat can't otherwise be identified, you'll need to backpath through the code of your CMS, Apache configuration, SQL setup, and remaining content of your website to determine where you were compromised and what the right remediation steps should be.
Best of luck handling your issue!
I have a problem with embedding SWFs via SSL.
I know that the common misconception with embedding SWFs on secure pages is that people always try to embed it using a non-secure link. This isn't the case, as I am trying to host the SWF and swfobject.js locally using relative paths to account for the use of SSL.
It appears that the first of these players (under ssl) will play the audio playback, but won't display the video, while the second one will render the entire SWF fine.
Here are 2 examples that are EXTREMELY similiar. Unfortunately I can only post 2 hyperlinks, so you'll have to swap the http: protocol with https: to see how each player renders under SSL.
These 2 players are using 2 different SWF's, so I'm lead to believe it's a Flash/ActionScript issue, but I have failed to isolate it.
Example 1
Non-secure working embed
Example 2
Non-secure working embed
First, Mixed http & https are different domains that run afoul of the Adobe Flash Player's same-domain security restriction. Using a cross-domain file on the root of your server will allow access.
Second, IE has some known problems with SWF and SSL.
Third, be sure to enable https and check to ensure you have a valid root certificate.
Without more information, this is the best I can do.
The best way is to test your work using the Debug Version of Flash Player. This works best in Firefox. Chances are there is something (dependency or resource) that the player is trying to get without SSL.
How would I let a running process know that a context menu has been clicked in Safari?
I've read that this is not possible due to security, but that seems wrong because 1Password somehow pulls all of the information from the desktop app's database into the Safari extension. I wrote the extension to display the context menu and was trying to send an XMLRPC request to localhost, but couldn't get it to work.
I'm not certain of this, but I think 1Password does what it does by having a background process (1PasswordAgent) constantly polling for certain changes in the extension's local database and/or config files. For example, to initially get your passwords into the extension, the extension could set a certain flag in its localStorage db, which would get written (by Safari, not by the extension) to a file. The agent would then notice the flag in the file and copy your passwords from the main 1Password database into the extension's local database. Similarly, when the extension creates a new password entry, the agent would notice the change in the extension's database and mirror it to the 1Password database.
Perhaps you could do something similar?
Although I have no idea about the implementation of 1Password, LiveReload achieves the same by using WebSocket to connect to a localhost URL (handled by the application). If you do it from the global page, cross-domain limitations do not apply, so you are free to connect to any URL:
var ws = new WebSocket("ws://localhost:98765");
...
(Be careful with that localhost thing, though, Chrome on Linux wants 0.0.0.0 instead of 127.0.0.1 or localhost. At least it used to want it.)
I'm wondering how I can find out where the culprit is, as to what is NOT being transmitted over SSL on my website. It's blowing my mind, because I use relative URLs or explicitly choose HTTPS:// for all links, images, etc...
Any ideas/tools to find out what the issue is?
Thanks.
If you mean that some resources are transferred over HTTP without encryption, you can check for this in Chrome's Developer tools in the tab Resources - that should tell you which parts come from where - look for those with address starting with http:// .
Alternately, use Fiddler: by default, it won't decrypt HTTPS connections, so you'll be seeing CONNECT requests for HTTPS, and GET/POST for HTTP - those are your culprits.
For those, like myself, who run into this issue i suggest a few tips while designing your website.
Always use relative paths when ever possible "images/someimage.png" instead of using domain paths like http://someDomainName/images/someimage.png so on. Any one of these and it will cause the browser to throw that warning at you.
When linking to external content, Google/other Ads, javascript sources(such as jquery, so on), or any other media... make sure you use a https:// link if they have one available. Myself, i had one tiny image for a link to an external site but they did not offer a https link to the image, so i simply downloaded it and put it in my images folder. Problem solved.
The Chrome resources list is a very helpful tool, not sure if Firefox has something similar in its tool box. Another method, if you have shell/command line access, is to use grep to search the files for "http:". This, most often, will show anything that is linking to non secure content.