Top security threats to Flash/Flex applications and how to avoid them


Published on

Top security threats to Flash/Flex applications and how to avoid them

Published in: Technology
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Top security threats to Flash/Flex applications and how to avoid them

  1. 1. Top security threats to Flash/Flex applications and how to avoid them<br />@EladElrom<br />
  2. 2. @EladElrom<br /><ul><li>Associate Dev Director @ Sigma Group
  3. 3. Senior Flash Engineer & Lead
  4. 4. Technical Writer
  5. 5. FlashAndTheCity Organizer
  6. 6. Adobe Community Professional</li></li></ul><li>What you’ll gain out of this Preso?<br />Gain knowledge about security in regards to Flash and Flex applications.<br />See some examples of how an attacker can abuse Flash/Flex applications<br />Learn ways to help prevent these attacks. <br />increase awareness so you will take security into consideration when building your applications. <br />
  7. 7. Flash Sandbox<br />“The sandbox defines a limited space in which a Macromedia Flash movie running within the Macromedia Flash Player is allowed to operate. Its primary purpose is to ensure the integrity and security of the client’s machine, and as well as security of any Macromedia Flash movies running in the player."<br />
  8. 8. intro<br />Slide from Deneb Meketa's security presentation at MAX<br />
  9. 9. Decompiling and modifying swf file<br />
  10. 10. Decompile<br />The concept of downloading Flash applications, decompiling, modifying them, and then re-compiling them is one of the oldest & most used cross-scripting techniques out there. Hackers’ use programs such as Sothink SWF decompiler software which allows them to modify the swf.<br />
  11. 11. Decompile Flex Apps<br />Not many developers are aware of the fact that these decompilers are now capable of decompiling Flex projects in addition to Flash applications. Let’s take a look at this simple example.<br />
  12. 12. After the project is restored, you can then import the project back into Flash builder and change the project. Phishing attack is when a hacker tries to obtain user’s sensitive information by impersonating as a trustworthy entity.<br />
  13. 13. Hacking a template site<br />As a second example I went to one of these Flash template site and used a Web Proxy to extract the swf URL and download the swf file to my desktop, then decompiled and opened in Flash Professional<br />
  14. 14. Export to FLA<br />
  15. 15. View .fla<br />
  16. 16. Loading the Flash app SWF file into another project<br />
  17. 17. Hackers gain access<br />Slide from Deneb Meketa's security presentation at MAX<br />
  18. 18. Change properties on runtime<br />Loading a swf file belonging to a Flex project and then having the accessing application make changes to the access application. <br />In the example below the accessing application gains access to an application, and I was then able to change the text property on a label and even use a login service method. Create a new project. <br />
  19. 19. Cross Domain Policy<br />At this point we are loading the accessed application from the same domain; however, if you place the accessed application and the accessing application on two separate domains and place a domain policy that allows accessing the domain from any domain, as in this example below, it will work. <br />
  20. 20. Allow cross domainwho can access?<br />https used for Encryption, Authentication user, change data<br />Avoid: allowInsecureDomain("*");<br />
  21. 21. Id request w/ Custom request headers - control what can be accessed<br />All - any port<br />Master Only - port 843<br />none - no socket policy files allowed<br />
  22. 22. Allow ports<br />List of TCP and UDP port numbers<br /><br />
  23. 23. Attacker figure out application source code<br />
  24. 24. Phishing for public methods<br />In this example we have access to the source code; however, in case the attacker does not have access to the source code, they can find out the source code in two ways. Once the content is loaded we can actually place a break point and see all the methods we have access to, see figure below.<br />
  25. 25. Decompile accessed app<br />Additionally, using decompiling software, the attacker can decompile the accessed application and browse through the classes<br />
  26. 26. Accessing other domain through the accessed application<br />
  27. 27. Similarly to the application I showed you previously, an attacker could load a SWF from a domain that has access to other domain and than make un-authorized service calls. For instance, let’s say that DomainA allow access to DomainB, as you can see from the Cross Domain policy below: <br />Access SWF from another SWF<br />
  28. 28. Security.allowDomain(“*”)<br />Avoid global (wild card) permissions!<br />
  29. 29. Load SWF and access<br />The accessing application can load the SWF and access the service class to make an illegal call, and then it can retrieve the data. For instance, let’s assume that a site allows a certain authorized domain to make service calls but the API is not public. If the authorized <br />domain holds a SWF that can be accessed, one can use that SWF to gain access to the API and make un-authorized service calls. <br />this.content.document.service.send();<br />
  30. 30. Code sample<br />
  31. 31. How to avoid cross-scripting attacks<br />
  32. 32. Solution #1<br />Setting a restricted cross-domain policy that limits the domains that can access the application<br />
  33. 33. Solution #2<br />Use code obfuscation software such as secureSWF from Kindisoft (, which helps you to protect your ActionScript from Flash decompilers. <br />
  34. 34. Solution #3<br />Avoid using Security.allowDomain(“*”) method to permit access to all swfs. Set the ones you allow access.<br />
  35. 35. Cross-site scripting (XSS) vulnerability<br />
  36. 36. What is XSS?<br />The idea is to involve more than one site, and that’s where the name (Cross-site) came from, a second site injects a script and can do anything it wants with the page.<br />Examples?<br />
  37. 37. Account theft<br />Account theft - Attackers can grab cookie information, which can lead to account hijacking since many cookies holds account information.<br />
  38. 38. Change page content<br />Changing content on a page - Misleading user to re-enter their information on a phony site, place incorrect content or read user’s cookies.<br />
  39. 39. Vulnerability in Flex applications<br />Flash Player is not vulnerable to cross scripting directly since the byte-code get compiled through the Virtual Machine (VM), <br />However Flash is often used on a page that includes other scripts and your application may interact with other Web pages elements and that can open a security hole since Web page that generate content dynamically without filtering the results first. Attackers can exploit your application and create XSS. <br />
  40. 40. Inbound/outbound<br />Slide from Deneb Meketa's security presentation at MAX<br />
  41. 41. Cross-Scripting attack to a WebPage from Flex<br />
  42. 42. Simple application example<br />
  43. 43. Hackers can redirect<br /><script>alert('Test')</script><br /><script type="text/javascript">window.location = ""</script><br />
  44. 44. Malicious data injection<br />
  45. 45. What’s Malicious data injection?<br />In cases where a Web Page have permissions to reading and writing from and to a Web Page an attacker can abuse these and rewrite the a web page or redirect users from the Web Page to a phishing site, this type of a attack is know as malicious data injection attack or Script injection.<br />
  46. 46. Flash malicious data injection attack<br />The attacker can inject data and create a cross-site scripting (XSS) attack. Coding in ActionScript and using APIs such as ExternalInterface, navigateToURL or getURL. The attacker can than redirect the URL and even post a JavaScript code, which would capture the user’s cookies with personal information.<br />
  47. 47. Example<br />Let’s say we need a script to retrieve a parameter that was passed through the URL into the Flex application. As you know you can pass variables using FlashVar and than use the following syntax in Flex 4 To read the parameter:<br /><br />However in case you want to pass the parameters through the URL you need to call the SWF directly like so:<br />MyApp.swf?name=Elad<br />My code allows me to read the parameter from the URL without calling the SWF directly.<br />
  48. 48. How it works?<br />Here is how it works. I am registering a callback Javascript function called getParams and once the user click on a button I am calling the Javascript method getURLString, which retrieve the URL parameter and pass it back to the callback. <br />
  49. 49. Example application<br />
  50. 50. Hacker abuse loophole<br />?name=Elad I pass the following parameter: ?name=%3Cscript%3Ealert('Elad')%3C/script%3E <br />
  51. 51. Cross-site scripting through navigation URLs<br />
  52. 52. Attacking browser example<br />Attacking browser navigation URLs is a popular attack. Similar to the example I showed you at "Malicious data injection" section, attackers can inject data through URL. In addition to passing data through FlashVars it's common to use deep linking to change the application state. The application takes params through the URL and than create a link on the application. <br />
  53. 53.
  54. 54. History Management vulnerability in Flex 3<br />
  55. 55. Flex 3 History management<br />The same type of cross-site scripting we just showed you were found in the History Management handled by historyFrame.html in Flex 3. The vulnerability occurs in code used by the History Management feature. In case you use Flex 3 and use the History management features you need to upgrade to at least Flex 3.0.2 SDK Update or just replace the HTML files from Flex 3.02. <br />
  56. 56. How to avoid Cross-Scripting attack<br />
  57. 57. Whitelisting & Blacklisting<br />The way to avoid must of cross-scripting attacks is to sufficiently sanitize user-supplied data, what it mean is that it’s a good practice to apply the same best practices as old-fashioned web application and to filter the data that user enters to insure that the user entered a proper format and contains only expected data.<br />To avoid this type of vulnerability you can add a code to your Flex/Flash application that will stripe HTML tags, tag attributes, values, Javascript, CSS, HTML and URL.<br />You can take the whitelist or blacklist approach in regards to validating the data. Whitelist is preferred, however whitelisting isn’t always possible so blacklisting can be used. <br />
  58. 58. allowScriptAccess<br />
  59. 59. allowScriptAccess options<br />Slide from Deneb Meketa's security presentation at MAX<br />
  60. 60. Set allowScriptAccess correctly<br />Slide from Deneb Meketa's security presentation at MAX<br />
  61. 61. Find HTML tags<br />
  62. 62. Use RegExp to avoid attacks <br />I am using the RegExpValidator component and pass the RegExp "((3C)|<). In case there is no match you’ll get: “field is invalid”.<br />You can insert all the RegExp and see if you get zero results, which means that the expression was present.<br />To read more see Symantec article:<br />
  63. 63. Update Flash Player and SDK often <br />Updating Flash Player and SDK. Adobe is constantly working to fight attackers. For instance during the upgrade to Flex SDK 3.4 Adobe have solved an issues regarding ticket CVE-2009-1879, which took care of Cross-site scripting (XSS) vulnerability in the index.template.html in SDK 3.3. <br />When the installed Flash version was older than a specified requiredMajorVersion value it allowed the remote attackers to inject arbitrary web script or HTML via the query string. <br />
  64. 64. Common security on local builts:Flash Access The Internet<br />
  65. 65. swf trying to access the internet<br />SecurityError: Error #2028: Local-with-filesystem SWF file file:///file.swf cannot access Internet URL http://...<br />
  66. 66. Solution<br /><br />Add "trusted" locations<br />6 - Click on Edit Locations<br />7 - Click on Add Location<br />8 - Click on Browse for folder<br />9 - Select the folder were your flash app is<br />
  67. 67. Links:<br />Elad Elrom’s articles<br /><br /><br />The Flash Player Security Topic Center:<br /><br />OWASP<br />Q&A<br />