We have some Wowza 4.2.0 servers. Basically, they are used for streaming publicly available medias. We don’t use SSL.
Recently some vulnerability scanning were done. One of the suggestion is
“Edit the crossdomain.xml file to be less permissive”
Just wonder if this need to be done and if conf/crossdomain.xml is really needed.
My understanding is that it is honored by Flash Client, other streaming methods such as Apple HLS, RTSP or MS Smooth are not affected. Is this correct?
===== Existing default crossdomain.xml
<?xml version="1.0" encoding="UTF-8" ?>
=====
The Wowza server itself does not host any SWF file and will not use SSL. So the Flash Player is hosted on our web server. For example, vod1.example.com is one of the Wowza server and web.example.com is the web server hosting the web page and the SWF files to play the media.
We don’t mind other domain such as web.nosuchdomain.com to host web page and SWF files to play our medias on vod1.example.com.
So this crossdomain.xml is good enough? Or we can delete secure=“false”?
In order to meet the vulnerability scanning recommendation, should we change it to?
===== suggested crossdomain.xml
<?xml version="1.0" encoding="UTF-8" ?>
=====
And will it be only web server under *.example.com can host SWF to play our medias? Other domain such as web.nosuchdomain.com will no longer to do so?
Any comments?
Thanks a lot.
Answered in a ticket and repeated here:
Crossdomain.xml is used by flash clients when an swf needs to load a resource from a different domain than the one the swf was launched from. It is basically saying, can the resource (the http stream in our case) be sent to the swf that is requesting it? Even though Wowza server doesn’t host any swf files, the crossdomain.xml file will be requested for any http requests that come from an swf launched from a different domain. It is normally only for HTTP type requests so RTMP requests from an swf won’t normally trigger a request for crossdomain.xml
You can edit the conf/crossdomain.xml file to make it more restrictive. In this case, you can specify the domains that are allowed to access the streams. You do need to be careful if using something like the JW Player cloud hosted version because the crossdomain.xml request will come from the cloud domain and not your website domain.
For simple streaming requests, it probably isn’t even worth restricting playback using the crossdomain.xml You are better off to restrict access using Secure Token or DRM. The crossdomain.xml was really designed as a mechanism for one swf to be able to trust and interact with another swf from a different domain. Because there is not any interaction between the stream and the player, the security provided by the crossdomain.xml isn’t really needed which is why the default setting is open access. The file is needed because the swf will request it and if there is no response then the actual resource won’t be requested.
There is a similar file for silverlight players which is the conf/clientaccesspolicy.xml file. For some HTTP streaming (mainly Dash which makes requests from javascript), CORS headers are used to do the same thing. These are special HTTP headers that are returned from the server to indicate that the domain that hosts the javascript is allowed to make requests to the server. Currently, Wowza returns CORS headers for Dash requests and you can enable them as User Headers for other requests.