Ambica

Members
  • Content count

    3
  • Joined

  • Last visited

About Ambica

  • Rank
    Forum Newbie
  1. Cross Site Scripting Issue

    Thank you for the response. However, could you please let me know if there is an open ticket or release related to this issue in Fusion Charts? We would like to reference it to our IT security team. Please let us know as soon as possible. Thank you.
  2. Cross Site Scripting Issue

    The version of fusion chart we are using is 3.2.2
  3. Cross Site Scripting Issue

    We are using Fusion charts in our application and there has been a security vulenerability issue detected with the usage. The details are below. This needs a modification to the flash code in the fusion charts .sla file. Please let us know if this issue has been addressed in a recent version of this software or can be taken up for an enhancement now. Located in: Charts/MSLine.swf The issue with this vulnerability is that the dataURL variable can be changed to point to an external xml file because the value is not hard coded or limited to trusted sources. This was tested in Firefox v3.6.12 and Chrome 15.0.874.121 Description Force browse is capable on every Fusion Chart. Vulnerability proof of concept for cross site scripting will be found by clicking on one of the green line points. Javascript pop up is executed once line point is clicked. Cross-site Scripting (XSS) is an attack technique where malicious code is executed in the user's browser delivered through the victimized website that allows an attacker to gain control over the content of the application. Solution Flash code needs to hard code or not accept third party URL's. XSS is introduced into the application through untrusted user input. Most XSS threats can be avoided by: (1) Limiting both where and how untrustworthy input is used; and (2) ensuring that all user input is strongly validated and contextually encoded. Use positive whitelist validation for all user input. For example, use built-in optimized platform-specific parsers (e.g., Integer.parseInt()) or regular expressions). Be aware that regular expressions are CPU intensive, and that they can be used by attackers to tie up system resources in a denial-of-service attack. If the application's framework supports casting, then ensure that all types (booleans, integers, floats, etc.) are cast. For rich input validation, an HTML policy engine, such as AntiSamy, must be used to ensure that the rich input does not contain spoofed content or XSS. <P class=reportStandardText>Encoding must be done contextually, making note of the following contexts: String: validate and encode based on context CSS: validate and remove "expression" call, plus XSS HEX encode HTML Body: HTML Entity encode HTML Attribute: Aggressive HTML Entity Encoding, even encoding spaces URL Attribute: Validate that the URL is legal and only contains safe protocols (and that the URL is specifically NOT a javascript:// url); then attribute encode JavaScript: JS Output encode and ensure certain functions like eval() or setTimeout() are not used.