XSS security enhancements #121
Comments
|
…yer swf from loaded from. Fixes fixes #121
|
@blacktrash Why is playerId parsing with regex needed? |
|
Maybe I'm wrong, but I understood that api methods and events normally only work if there's a playerId present - again normally generated by the API scripts. |
|
This might be possible via the application domain api possibly for the loader. It will follow whatever the cross domain policy is normally. |
|
Hi gentlemen, |
|
Doh, If I knew how to read I would have seen that anssip fixed it in the dev branch. |
|
checkout the dev branch + flash-build rep. You run the build file from the flash-build directory now. |
|
Pew. Spent all day trying to set up the flex/ant/build. I'm officially deeming it over my head. Looking forward to an official release. |
|
If you follow the developer instructions all you have to do is type "ant build-biz" |
|
@anssip - the external config file restriction is not working: http://flowplayer.blacktrash.org/test/embed-external.html - core loaded from (releases.)flowplayer.org, config loaded from (media.)blacktrash.org. Maybe it does not check against the location of the core, but of the viewing domain. |
|
Has this been fixed yet? |
|
So, now even security vulnerabilities are not fixed in Flash version anymore? I think a sign is clear, Flowplayer Flash is not supported anymore. |
|
Bypasses of the XSS checking introduced here went public at Black Hat 2015. http://www.bishopfox.com/download/5439/ (around slide 54) |
|
Thanks for that update. There is a possible issue with the local domain check. I say remove this completely and I have no idea what it is for. Ads plugins are loaded externally also so not sure what to say other than to specifically whitelist those domains internally and block all external domain plugins. I'm sure there is a simpler way with the use of the loader context which initially checks for the policy file. This probably needs to be scrapped also or looked into. |
|
This would be under the assumption siteA has been modified to begin with. It could also affect any plugin based player also. They might just go ahead with javascript malware includes then if the page is modified :) Within JWPlayer's own AssetLoader which is still used for Flash plugins it has no such check at all, it only uses the cross domain context and relies on crossdomain policies as standard checking for "http" on the url. This may be blown out of proportions but ideally just scrap these bits out, allow only under same domain and add whitelists for the ads plugins. Javascript injections is by far more common and much worse. This is the bit the document mentions.
|
…abled wildcard security for loading crossdomain plugin code for now as same domain does not need this.
|
Please take a look at that branch. It fixes this bypass. I am not sure what that forward slash was for really. It could simply check for "http" to determine local loading but this particular code wants to include http://localhost. Another check elsewhere was looking for occurances of which needed to be changed to To accomodate the new protocoless urls. |
|
This is probably not needed anymore but needs heavy testing. Not sure what to do with the ads plugins yet apart from whitelist them ? Is there another ticket for this ? |
The text was updated successfully, but these errors were encountered: