justinhunt
commented
7 years ago Thanks for the report. In PoodLL3 we load the players differently so this may no longer be relevant. Some of the older widgets still use Flash and they need to communicate with the browser at times. ie to post the recorded file's name, and a flag that recording has taken place. Its a necessary step if the user needs Flash. But it is possible if using Chrome or Firefox to avoid Flash completely. I will close this now because its a warning of a possible vulmerability, based on the APIs we use. But there is no indication of an actual vulnerability. We won't be working with Flash widgets any more. We will just remove them as soon as we can.
Hello.
We have an automated vulnerability scanner then checks our Moodle and other system.
I has raised the below as a possible issue. Could this please be looked into?
Location Of Vulnerability
moodleurl/filter/poodll/flowplayer/flowplayer-3.2.10.swf
Description Adobe Flash content is commonly invoked with a number of configuration parameters known as FlashVars. Although Flashvars are typically supplied within the body of the HTML document, it is also possible to supply them directly via the query string (e.g moive.swf?flashvar1=value&flashvar2=value2). If a Flashvar value is passed to a function that performs navigation or JavaScript execution, it may be possible to perform a Cross Site Scripting attack (XSS). Cross-Site Scripting Reflected XSS vulnerabilities are typically exploited by embedding malicious script code within links to the application. The attacker would then attempt to coerce the user into following the maliciously crafted link via a social engineering attack such as a Phishing email. Upon clicking the malicious link the embedded script code is executed within user's web browser. XSS vulnerabilities could by exploited to: • Read user session cookies and submit them to the attacker. The attacker can then hijack the users session with the application. • Access sensitive information stored within the body of the page such as HTML forms (or the entire page). The attacker could exploit this to read data protected by the Same Origin policy. • Perform "Onsite Request forgery". Since JavaScript executes within the context of the victim user it is possible to perform any action the user can perform. The attacker could exploit XSS flaws to invoke dangerous functions such as "transfer funds". • Inject JavaScript to log keystrokes • Deploy exploit frameworks (e.g. BeEF, XSSShell, XSS Harvest) to conduct maintain control of the users session even if the user browses away from the affected page. • Attack the users browser using browser exploits. • Deploy Trojan programs exploiting the trust a user may have in an application. • Redirect the user to a malicious website. • Deface the application. Read more on XSS. The following XSS vulnerabilities were idetified The ActionScript Function ExternalInterface.call is used to execute JavaScript within the web browser. If unfiltered user controllable input is passed to this function, it may be possible to perform a Cross Site Scripting attack.
Solution
Strictly Filter User Input Data passed to the SWF application via FlashVar variables should be strictly validated to ensure it contains only known good data.