OWASP - User contributions [en]

Talk:HTTP Response Splitting

2010-11-16T12:26:45Z

Thursday: Created page with 'I think the example code isn't actually vulnerable. The libraries appear to automatically escape the input.'

I think the example code isn't actually vulnerable. The libraries appear to automatically escape the input.

Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet

2010-10-13T11:36:58Z

Thursday: Remove blatant self-promotion

= Introduction =

Cross-Site Request Forgery (CSRF) is a type of attack that occurs when a malicious Web site, email, blog, instant message, or program causes a user’s Web browser to perform an unwanted action on a trusted site for which the user is currently authenticated. The impact of a successful cross-site request forgery attack is limited to the capabilities exposed by the vulnerable application. For example, this attack could result in a transfer of funds, changing a password, or purchasing an item in the user's context. In affect, CSRF attacks are used by an attacker to make a target system perform a function (funds Transfer, form submission etc.) via the target's browser without knowledge of the target user, at least until the unauthorized function has been committed.

Impacts of successful CSRF exploits vary greatly based on the role of the victim. When targeting a normal user, a successful CSRF attack can compromise end-user data and their associated functions. If the targeted end user is an administrator account, a CSRF attack can compromise the entire Web application. The sites that are more likely to be attacked are community Websites (social networking, email) or sites that have high dollar value accounts associated with them (banks, stock brokerages, bill pay services). This attack can happen even if the user is logged into a Web site using strong encryption (HTTPS). Utilizing social engineering, an attacker will embed malicious HTML or JavaScript code into an email or Website to request a specific 'task url'. The task then executes with or without the user's knowledge, either directly or by utilizing a Cross-site Scripting flaw (ex: Samy MySpace Worm).

For more information on CSRF, please see the OWASP [[Cross-Site Request Forgery (CSRF)]] page.

= Prevention Measures That Do NOT Work =

'''Using a Secret Cookie'''

Remember that all cookies, even the secret ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request. Furthermore, session identifiers are simply used by the application container to associate the request with a specific session object. The session identifier does not verify that the end-user intended to submit the request.

'''Only Accepting POST Requests'''

Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST request, such as a simple form hosted in an attacker's Website with hidden values. This form can be triggered automatically by JavaScript or can be triggered by the victim who thinks the form will do something else.

'''Multi-Step Transactions'''

Multi-Step transactions are not an adequate prevention of CSRF. As long as an attacker can predict or deduce each step of the completed transaction, then CSRF is possible.

'''URL Rewriting'''

This might be seen as a useful CSRF prevention technique as the attacker can not guess the victim's session ID. However, the user’s credential is exposed over the URL.

= General Recommendation: Synchronizer Token Pattern =

In order to facilitate a "transparent but visible" CSRF solution, developers are encouraged to adopt the Synchronizer Token Pattern (http://www.corej2eepatterns.com/Design/PresoDesign.htm). The synchronizer token pattern requires the generating of random "challenge" tokens that are associated with the user's current session. These challenge tokens are the inserted within the HTML forms and links associated with sensitive server-side operations. When the user wishes to invoke these sensitive operations, the HTTP request should include this challenge token. It is then the responsibility of the server application to verify the existence and correctness of this token. By including a challenge token with each request, the developer has a strong control to verify that the user actually intended to submit the desired requests. Inclusion of a required security token in HTTP requests associated with sensitive business functions helps mitigate CSRF attacks as successful exploitation assumes the attacker knows the randomly generated token for the target victim's session. This is analogous to the attacker being able to guess the target victim's session identifier. The following synopsis describes a general approach to incorporate challenge tokens within the request.

When a Web application formulates a request (by generating a link or form that causes a request when submitted or clicked by the user), the application should include a hidden input parameter with a common name such as "CSRFToken". The value of this token must be randomly generated such that it cannot be guessed by an attacker. Consider leveraging the java.security.SecureRandom class for Java applications to generate a sufficiently long random token. Alternative generation algorithms include the use of 256-bit BASE64 encoded hashes. Developers that choose this generation algorithm must make sure that there is randomness and uniqueness utilized in the data that is hashed to generate the random token.

<form action="/transfer.do" method="post">
<input type="hidden" name="CSRFToken" value="OWY4NmQwODE4ODRjN2Q2NTlhMmZlYWEwYzU1YWQwMTVhM2JmNGYxYjJiMGI4MjJjZDE1ZDZjMTVi
MGYwMGEwOA==">
…
</form>

In general, developers need only generate this token once for the current session. After initial generation of this token, the value is stored in the session and is utilized for each subsequent request until the session expires. When a request is issued by the end-user, the server-side component must verify the existence and validity of the token in the request as compared to the token found in the session. If the token was not found within the request or the value provided does not match the value within the session, then the request should be aborted and the event logged as a potential CSRF attack in progress.

To further enhance the security of this proposed design, consider randomizing the CSRF token parameter name and or value for each request. Implementing this approach results in the generation of per-request tokens as opposed to per-session tokens. Note, however, that this may result in usability concerns. For example, the "Back" button browser capability is often hindered as the previous page may contain a token that is no longer valid. Interaction with this previous page will result in a CSRF false positive security event at the server. Regardless of the approach taken, developers are encouraged to protect the CSRF token the same way they protect authenticated session identifiers, such as the use of SSLv3/TLS.

=== Disclosure of Token in URL ===

Many implementations of this control, such as OWASP CSRFGuard, include the challenge token in GET (URL) requests as well as POST requests. This often implemented as a result of sensitive server-side operations being invoked as a result of embedded links in the page or other general design patterns. These patterns are often implemented without knowledge of CSRF and an understanding of CSRF prevention design strategies. While this control does help mitigate the risk of CSRF attacks, the unique per-session token is being exposed for GET requests. CSRF tokens in GET requests are potentially leaked at several locations: browser history, HTTP log files, network appliances that make a point to log the first line of an HTTP request, and Referrer headers if the protected site links to an external site. The ideal solution is to only include the CSRF token in POST requests and modify server-side actions that have state changing affect to only respond to POST requests. If sensitive server-side actions are guaranteed to only ever respond to POST requests, then there is no need to include the token in GET requests. In most JavaEE web applications, however, HTTP method scoping is rarely ever utilized when retrieving HTTP parameters from a request. Calls to "HttpServletRequest.getParameter" will return a parameter value regardless if it was a GET or POST. This is not to say HTTP method scoping cannot be enforced. It can be achieved if a developer explicitly overrides doPost() in the HttpServlet class or leverages framework specific capabilities such as the AbstractFormController class in Spring. While this is the ideal approach, attempting to retrofit this pattern in existing applications requires significant development time and cost. CSRFGuard and similar solutions attempt to address this concern in a patch-like manner without required the re-design of key application components.

In order for an attacker to successfully carry out a valid CSRF attack against an application that has similar characteristics as described
above (i.e. CSRF tokens on GET and POST requests, no explicitly enforcing HTTP method scoping), several actions are typically required:

#The victim must be interacting with the application such that a valid CSRF token is generated.
#The CSRF token must be transmitted in a GET request by interacting with the web page
#A component with insight into (at least) the first line of the HTTP GET request must process the request at some point between (and including) the browser and the server
#This same component must capture the token in a repository that is accessible to an attacker (ex: server log files, browser history, etc.)
#The attacker must parse this repository and retrieve the token.
#The attacker needs to somehow know what user owns this exposed CSRF token
#The attacker needs to trick the target victim (i.e. the one owning the CSRF token) into interacting with an HTML document.
#The victim's session that holds the exposed token must still be valid (i.e. not invalidated, expired, idle/absolute timed-out, etc.).

While placing CSRF tokens in GET requests does present a potential risk as described above, it is very minimal. The likelihood of successfully discovering and exploiting this vulnerability is significantly low. Coupled with strong session management practices (i.e. timeouts), frequent use of SSLv3/TLS, and network based services that do not log this mechanism, there is little risk to the CSRF token being exposed to an attacker. Even if the CSRF token is exposed and the attacker is somehow able to figure how the associated user, the token is only valid for the lifetime of the session. Ultimately, the acceptance of this risk as opposed to the cost of significant architecture design is up to the business.

=== Viewstate (ASP.NET) ===

ASP.NET has an option to maintain your ViewState. The ViewState indicates the status of a page when submitted to the server. The status is defined through a hidden field placed on each page with a <form runat="server"> control. Viewstate can be used as a CSRF defense, as it is difficult for an attacker to forge a valid Viewstate. It is not impossible to forge a valid Viewstate since it is feasible that parameter values could be obtained or guessed by the attacker. However, if the current session ID is added to the ViewState, it then makes each Viewstate unique, and thus immune to CSRF.

To use the ViewStateUserKey property within the Viewstate to protect against spoofed post backs. Add the following in the OnInit virtual method of the Page-derived class (This property must be set in the Page.Init event)

protected override OnInit(EventArgs e) {
base.OnInit(e);
if (User.Identity.IsAuthenticated)
ViewStateUserKey = Session.SessionID; }

The following keys the Viewstate to an individual using a unique value of your choice.

(Page.ViewStateUserKey)

This must be applied in Page_Init because the key has to be provided to ASP.NET before Viewstate is loaded. This option has been available since ASP.NET 1.1.

However, there are [http://keepitlocked.net/archive/2008/05/29/viewstateuserkey-doesn-t-prevent-cross-site-request-forgery.aspx limitations] on this mechanism. Such as, ViewState MACs are only checked on POSTback, so any other application requests not using postbacks will happily allow CSRF.

=== Double Submit Cookies ===

Double submitting cookies is defined as sending the session ID cookie in two different ways for every form request. First as a traditional header value, and again as a hidden form value. When a user visits a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine. This is typically referred to as the session ID. The site should require every form submission to include this pseudorandom value as a hidden form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. When an attacker submits a form on behalf of a user, he can only modify the values of the form. An attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy. This means that while an attacker can send any value he wants with the form, the attacker will be unable to modify or read the value stored in the cookie. Since the cookie value and the form value must be the same, the attacker will be unable to successfully submit a form unless he is able to guess the session ID value.

While this approach is effective in mitigating the risk of cross-site request forgery, including authenticated session identifiers in HTTP parameters may increase the overall risk of session hijacking. Architects and developers must ensure that no network appliances or custom application code or modules explicitly log or otherwise disclose HTTP POST parameters. An attacker that is able to obtain access to repositories or channels that leak HTTP POST parameters will be able to replay the tokens and perform session hijacking attacks. Note, however, that transparently logging all HTTP POST parameters is a rare occurrence across network systems and web applications as doing so will expose significant sensitive data aside from session identifiers including passwords, credit card numbers, and or social security numbers. Inclusion of the session identifier within HTML can also be leveraged by cross-site scripting attacks to bypass HTTPOnly protections. Most modern browsers prevent client-side script from accessing HTTPOnly cookies. However, this protection is lost if HTTPOnly session identifiers are placed within HTML as client-side script can easily traverse and extract the identifier from the DOM. Developers are still encouraged to implement the synchronizer token pattern as described in this article and implemented in OWASP CSRFGuard.

[http://directwebremoting.org Direct Web Remoting (DWR)] Java library version 2.0 has CSRF protection built in as it implements the double cookie submission transparently.

=== Prevention Frameworks ===

There are CSRF prevention modules available for J2EE, .Net, and PHP.

[[:Category:OWASP_CSRFGuard_Project | OWASP CSRF Guard (For Java)]]

The OWASP CSRFGuard Project makes use of a unique per-session token verification pattern using a JavaEE filter to mitigate the risk of CSRF attacks. When an HttpSession is first instantiated, CSRFGuard will generate a cryptographically random token using the SecureRandom class to be stored in the session.

CSRFGuard is a "reference implementation". Developers are encouraged to leverage more tightly integrated solutions for performance (ex: speed of parsing HTML) and technical (ex: AJAX requests) challenges.

'''Similar Projects'''

CSRFGuard has been implemented in other languages besides Java. They are:

*[[PHP CSRF Guard]]
*[[.Net CSRF Guard]]

== Challenge-Response ==

Challenge-Response is another defense option for CSRF. The following are some examples of challenge-response options.

*CAPTCHA
*Re-Authentication (password)
*One-time Token

While challenge-response is a very strong defense to CSRF (assuming proper implementation), it does impact user experience. For applications in need of high security, tokens (transparent) and challenge-response should be used on high risk functions.

= Checking Referer Header =

The Checking of the http Referer can be used to prevent CSRF. This method is desirable for securing embedded network hardware such as modems, routers, and printers because it does not increase memory requirements. The major limitation is that browsers will omit the Referer in the http header when they are being used over HTTPS. This restriction does not apply for embedded network hardware because HTTPS is not used. There are two known methods of bypass a Referer check. A [http://secunia.com/advisories/22467/ CRLF vulnerability] in the http client could allow an attacker manipulate the HTTP request header and thus spoof the referer. The other method is using XSS to write a form to a page on the target domain and then automatically submit the request.

= Client/User Prevention =

Since CSRF vulnerabilities are reportedly widespread, it is recommended to follow best practices to mitigate risk. Some mitigating include:

* Logoff immediately after using a Web application
* Do not allow your browser to save username/passwords, and do not allow sites to “remember” your login
* Do not use the same browser to access sensitive applications and to surf the Internet freely (tabbed browsing).
* The use of plugins such as No-Script makes POST based CSRF vulnerabilities difficult to exploit. This is because JavaScript is used to automatically submit the form when the exploit is loaded. Without JavaScript the attacker would have to trick the user into submitting the form manually.

Integrated HTML-enabled mail/browser and newsreader/browser environments pose additional risks since simply viewing a mail message or a news message might lead to the execution of an attack.

= No Cross-Site Scripting (XSS) Vulnerabilities =

Cross-Site Scripting is not necessary for CSRF to work. However, all stored cross-site scripting attacks and special case reflected cross-site scripting attacks can be used to defeat token based CSRF defenses, since a malicious XSS script can simply read the site generated token from the response, and include that token with a forged request. This technique is exactly how the [http://en.wikipedia.org/wiki/Samy_(XSS) MySpace (Samy) worm] defeated MySpace's anti CSRF defenses in 2005, which enabled the worm to propagate. XSS cannot defeat challenge-response defenses such as Captcha, re-authentication or one-time passwords. It is imperative that no XSS vulnerabilities are present to ensure that CSRF defenses can't be circumvented. Please see the OWASP [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet | XSS Prevention Cheat Sheet]] for detailed guidance on how to prevent XSS flaws.

= Related Articles =

'''Cross-Site Request Forgery (CSRF)'''

For more information on CSRF please see the OWASP [[Cross-Site Request Forgery (CSRF)]] page.

'''How to Review Code for CSRF Vulnerabilities'''

See the [[:Category:OWASP_Code_Review_Project | OWASP Code Review Guide]] article on how to [[Reviewing code for Cross-Site Request Forgery issues]].

'''How to Test for CSRF Vulnerabilities'''

See the [[:Category:OWASP_Testing_Project | OWASP Testing Guide]] article on how to [[Testing_for_CSRF_(OWASP-SM-005) | Test for CSRF Vulnerabilities]].

'''CSRF Testing Tool'''

Check out the [[:Category:OWASP_CSRFTester_Project | OWASP CSRF Tester]] tool which allows you to test for CSRF vulnerabilities. This tool is also written in Java.

{{Cheatsheet_Navigation}}

= References =

[http://www.isecpartners.com/files/XSRF_Paper_0.pdf Cross Site Reference Forgery: An introduction to a common web application weakness]

[http://www.freedom-to-tinker.com/sites/default/files/csrf.pdf Cross-Site Request Forgeries: Exploitation and Prevention]

= Authors and Primary Editors =

Paul Petefish - paulpetefish@solutionary.com

Eric Sheridan - eric.sheridan@aspectsecurity.com

Dave Wichers - dave.wichers@aspectsecurity.com

[[Category:How_To]] [[Category:Cheatsheets]] [[Category:OWASP_Document]] [[Category:OWASP_Top_Ten_Project]]

Category:OWASP Flash Security Project

2010-06-27T12:08:14Z

Thursday: flare isn't windows only

==== Main ====

== Overview ==

The OWASP Flash Security Project is an open project for sharing knowledge in order to raise awareness of Flash application security.

== Goals ==

The OWASP Flash Security Project aims to share guidelines, tools and resources for securing Flash applications.

<br>

== Table of Contents ==

{| cellspacing="1" cellpadding="1" border="0" style="width: 651px; height: 66px;"
|-
| '''Research'''
| '''References'''
| '''Tools'''
| '''Libraries'''
|-
| [http://www.owasp.org/index.php/Category:OWASP_Flash_Security_Project#Videos Videos]
| [http://www.owasp.org/index.php/Category:OWASP_Flash_Security_Project#References References]
| [http://www.owasp.org/index.php/Category:OWASP_Flash_Security_Project#OWASP_Tools OWASP Tools]
| [http://www.owasp.org/index.php/Category:OWASP_Flash_Security_Project#Third-party_Security_Libraries 3rd Party Libs]
|-
| [http://www.owasp.org/index.php/Category:OWASP_Flash_Security_Project#White_Papers_.2F_Presentations White Papers/Presentations]
| [http://www.owasp.org/index.php/Category:OWASP_Flash_Security_Project#Useful_Specifications Specifications]
| [http://www.owasp.org/index.php/Category:OWASP_Flash_Security_Project#Disassemblers Disassemblers]
|
|-
| [http://www.owasp.org/index.php/Category:OWASP_Flash_Security_Project#Articles Articles]
|
| [http://www.owasp.org/index.php/Category:OWASP_Flash_Security_Project#Decompilers Decompilers]
|
|-
| [http://www.owasp.org/index.php/Category:OWASP_Flash_Security_Project#Example_Vulnerabilities Example Vulnerabilities]
|
| [http://www.owasp.org/index.php/Category:OWASP_Flash_Security_Project#Obfuscators Obfuscators]
|
|-
|
|
| [http://www.owasp.org/index.php/Category:OWASP_Flash_Security_Project#Analysis Analysis/Defense]
|
|-
|
|
| [http://www.owasp.org/index.php/Category:OWASP_Flash_Security_Project#Local_Shared_Object_Editors LSO Editors]
|
|-
|
|
| [http://www.owasp.org/index.php/Category:OWASP_Flash_Security_Project#AMF_Tools AMF Tools]
|
|}

<br>

== Videos ==

* [http://tv.adobe.com/#vi+f15384v1102 Understanding the Flash Player Security Model] Deneb Meketa of Adobe gives a one hour presentation at the Adobe MAX 2008 conference in San Francisco entitled, "Flash Security: Why and how." This presentation provides a good overview of several aspects of Flash Player's security model. Approximately 1 hour long.

* [http://h30431.www3.hp.com/index.jsp?fr_story=3a98c704f7ef61299c19ef1f648f1acb1a5aeab8&rf=bm Billy Wins A Cheeseburger] A video by HP that explains a basic Flash vulnerability that can be found by decompilers. Approximately 3 minutes long.

* [http://securitytube.net/Hacking-Flash-Applications-for-Fun-and-Profit-(Blackhat)-video.aspx Blinded by Flash: Widespread Security Risks Flash Developers Don't See] Prajakta Jagdale describes the attack surface flash applications have based on various things developers overlook. In this presentation she talks about the basic cross domain security model between flash applets, Cross Site Scripting attacks on Flash applications, Data injection attacks, Flash malware, decompilation of Flash swf files, code and binary obfuscation and many other attack vectors which a malicious attacker could use to hack Flash applications. Approximately 1 hour long.

* [https://media.defcon.org/dc-17/video/DEFCON%2017%20Hacking%20Conference%20Presentation%20By%20Jon%20Rose%20-%20Deblaze%20A%20Remote%20Method%20Enumeration%20Tool%20for%20Flex%20Servers%20-%20Video%20and%20Slides.m4v Deblaze - A Remote Method Enumeration Tool for Flex Servers] This is an excellent 20 minute presentation from DefCon 17 by Jon Rose on how to test AMF services using the deBlaze tool that he authored.

* [http://technet.microsoft.com/en-us/security/ee460903.aspx#ria RIA Security: Real-World Lessons from Flash and Silverlight] Jesse Collins from Microsoft's Silverlight team and Peleus Uhley from Adobe's Flash team discuss common threats to RIA applications. Approximately 1 hour long.

<br>

== White Papers / Presentations ==

'''Flash'''

* '''Flash Parameter Injection''' [http://blog.watchfire.com/FPI.pdf pdf], IBM Rational Application Security Team, [http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference OWASP AppSec 2008], 24th September 2008, NYC, NY (USA)

* '''Testing Flash Applications using WebScarab''' [https://www.owasp.org/images/5/58/Testing_Flash_Applications.pdf pdf], Martin Clausen - Deloitte [http://www.owasp.org/index.php/Denmark Denmark Chapter Meeting], March 12, 2008, Denmark

* '''Testing Flash Applications''' [http://www.owasp.org/images/8/8c/OWASPAppSec2007Milan_TestingFlashApplications.ppt ppt], Stefano Di Paola, [http://www.owasp.org/index.php/6th_OWASP_AppSec_Conference_-_Italy_2007/Agenda Owasp Appsec 2007], 17th May 2007, Milan (Italy).

* '''Testing and Exploiting Flash Applications''' [http://events.ccc.de/camp/2007/Fahrplan/attachments/1320-FlashSec.pdf pdf], Fukami, Chaos Computer Camp, 2007

* '''Finding Vulnerabilities in Flash Applications''' [http://www.owasp.org/images/d/d8/OWASP-WASCAppSec2007SanJose_FindingVulnsinFlashApps.ppt ppt], Stefano Di Paola, [http://www.owasp.org/index.php/7th_OWASP_AppSec_Conference_-_San_Jose_2007/Agenda Owasp Appsec 2007], 15th November 2007, San Jose, CA (USA)

* '''Neat, New, and Ridiculous Flash Hacks''' - whitepaper: [http://www.blackhat.com/presentations/bh-dc-10/Bailey_Mike/BlackHat-DC-2010-Bailey-Neat-New-Ridiculous-flash-hacks-wp.pdf pdf], presentation:[http://www.blackhat.com/presentations/bh-dc-10/Bailey_Mike/BlackHat-DC-2010-Bailey-Neat-New-Ridiculous-flash-hacks-slides.pdf pdf], Mike Bailey, Black Hat DC 2010, Washington, DC (USA)

<br> '''AMF'''

* '''Pentesting Adobe Flex Applications''' - [http://www.gdssecurity.com/l/OWASP_NYNJMetro_Pentesting_Flex.pdf pdf], Marcin Wielgoszewski, April 2010 OWASP NYC Chapter Meeting, NYC, NY (USA)

* '''DeBlaze: A remote enumeration tool for Flex servers''' [http://www.defcon.org/images/defcon-17/dc-17-presentations/defcon-17-jon_rose-deblaze.pdf pdf], Jon Rose, [http://www.defcon.org/html/links/dc-archives/dc-17-archive.html#Rose DefCon 17], 31 July 2009, Las Vegas, NV (USA)

<br> '''University Research'''

* '''ActionScript bytecode verification with co-logic programming''' [http://portal.acm.org/citation.cfm?id=1554339.1554342 pdf], Brian W. DeVries, Gopal Gupta, Kevin W. Hamlen, Scott Moore, and Meera Sridhar of The University of Texas at Dallas, Proceedings of the ACM SIGPLAN Fourth Workshop on Programming Languages and Analysis for Security 2009.

* '''Creating a more sophisticated security platform for Flash, AIR and others''' [http://www.utdallas.edu/~mxs072100/Adobe.ppt ppt] Presented at Adobe Systems, Inc. by Meera Sridhar, November, 2009

* '''ActionScript In-Lined Reference Monitoring in Prolog''' [http://www.utdallas.edu/~mxs072100/padl.pdf pdf], Meera Sridhar and Kevin W. Hamlen of The University of Texas at Dallas, Proceedings of the Twelfth Symposium on Practical Aspects of Declarative Languages (PADL), Jan 2010.

* '''ActionScript In-lined Reference Monitoring in Prolog''' [http://www.utdallas.edu/~mxs072100/padl10.pptx pptx] Presented at PADL 2010, Madrid, Spain by Meera Sridhar.

<br>

== Articles ==

'''Development'''
* [http://www.adobe.com/devnet/flashplayer/articles/secure_swf_apps.html Creating more secure SWF web applications] This Adobe Developer Center article discusses secure ActionScript programming practices.

* [http://www.adobe.com/devnet/flashplayer/articles/cross_domain_policy.html Cross-domain policy file usage recommendations for Flash Player] This Adobe Developer Center article discusses some of the common security issues that you should consider when deciding how to use a cross-domain policy file on your server.

* [http://www.insideria.com/2010/03/flash-player-10-security-model.html Flash Player 10 Security Model: Stakeholders and Sandboxes] This is an article that condenses the official Flash Player Security Model down to a one page article discussing the stakeholders and sandboxes.

* [http://theflashblog.com/?p=419 AMFPHP Security Basics] This a blog covering how to secure AMFPHP version 1.9 and higher. AMFPHP is server-side code that receives AMF requests from Flash clients.

* [http://blogs.adobe.com/asset/2009/11/securely_deploying_cross-domai.html Securely Deploying Cross-Domain Policy files] This Adobe ASSET blog provides 5 tips for securely deploying cross-domain policy files.

* [http://askmeflash.com/article/16/securing-your-flash-application Securing your Flash Application] A quick ten item checklist of high level things to look for in your SWF before shipping.

'''Penetration Testing'''
* [http://www.ivizsecurity.com/blog/web-application-security/testing-flash-applications-pen-tester-guide/ A Lazy Pen Tester’s Guide to Testing Flash Applications] A short blog describing some of the basic steps of testing Flash applications by iViZ.

* [http://www.gdssecurity.com/l/b/2010/03/17/penetrating-intranets-through-adobe-flex-applications/ Penetrating Intranets through Adobe Flex Applications] A short blog (03/17/2010) by Marcin Wielgoszewski of Gothan Digital Science introducing the [http://www.gdssecurity.com/l/t/d.php?k=Blazentoo Blazentoo] tool and how to take advantage of open BlazeDS proxies.

* [http://www.gdssecurity.com/l/b/2009/11/11/pentesting-adobe-flex-applications-with-a-custom-amf-client/ Pentesting Adobe Flex Applications with a Custom AMF Client] A short blog (11/11/2009) by Marcin Wielgoszewski of Gothan Digital Science on how to write custom pyAMF-based clients for testing Flex services.

* [http://erlend.oftedal.no/blog/?blogid=103 Client-side Remote File Inclusion in Flash] This blog discusses how to perform cross-site scripting attacks against applications that read in XML configuration files.

* [http://code.google.com/p/doctype/wiki/ArticleFlashSecurity Flash Security] A Google code article on different types of cross-site scripting and crossdomain.xml attacks.

'''Updates to the Flash Player Security Model'''
* [http://www.adobe.com/devnet/flashplayer/articles/fplayer10.1_air2_security_changes.html Understanding the security changes in Flash Player 10.1 and AIR 2] - This Adobe Developer Center article describes the new changes that affect security in Flash Player 10.1 and AIR. This article discusses a new feature, LoaderContext.allowCodeImport, which can help in safely loading remote content via loadBytes(). It also discusses minor changes in behavior that may require action by the developer.

* [http://www.adobe.com/devnet/flashplayer/articles/fplayer10_security_changes.html Understanding the security changes in Flash Player 10] - This Adobe Developer Center article describes the new changes that affect security in the Flash Player 10. This includes information on changes to socket timing, policy file strictness, upload and download, RTMFP and full screen mode.

* [http://www.adobe.com/devnet/flashplayer/articles/fplayer10_uia_requirements.html User-initiated action requirements in Flash Player 10] - This Adobe Developer Center article describes the new user-initiated action requires in Flash Player 10. These requirements include chances to FileReference, Clipboard, full-screen mode and pop-up windows.

* [http://www.adobe.com/devnet/flashplayer/articles/flash_player9_security_update.html Preparing for the Flash Player 9 April 2008 Security Update] - This Adobe Developer Center article describes the new mitigations for DNS Rebinding (socket policy files), cross-site flashing and the introduction of cross-domain header meta-policies to help address attacks such as the UPnP attack.

* [http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html Security Changes in Flash Player 9] This Adobe Developer Center article describes the important changes that need to be made to existing crossdomain.xml and socket policy files. All websites that use cross-domain or socket policy files will need to implement these changes in order to be compatible with Adobe's new format. After the implementation of Phase II, Adobe will no longer support the old format.

<br>

== Example Vulnerabilities ==

''The intent of this section is to provide real-world examples of exploitation. This can be useful for consultants to help demonstrate to clients that these techniques have been used in the wild. In some instances, these examples include individual SWFs that were copied to hundreds of web sites. Therefore, a consultant should look for these specific SWFs on a website when performing an assessment to ensure that they have a current version.''

* [http://blog.watchfire.com/wfblog/2010/03/cross-site-scripting-through-flash-in-gmail-based-services.html Cross-site Scripting through Flash in Gmail Based Services] - This is an example of a cross-site scripting vulnerability that was the result of passing tainted data to ExternalInterface.call.

* [http://docs.google.com/Doc?docid=ajfxntc4dmsq_14dt57ssdw XSS Vulnerabilities in Common Flash Files] - This paper by Rich Cannings shows sample attack URLs for individual SWFs that are hosted across hundreds of websites. The techniques demonstrated in this paper for achieving cross-site scripting including using javascript: URLs, asfunction: URLs, and loading malicious child SWFs (aka cross-site Flashing).

* [http://lists.grok.org.uk/pipermail/full-disclosure/2003-April/004514.html clickTAG Cross-site scripting] - It is very common for Flash-based advertisements to accept a FlashVar called, clickTAG. If the clickTAG FlashVar is passed directly to a browser navigation API, such as getURL, then the attacker can achieve cross-site scripting by changing the clickTAG URL to a javascript: URL. Cross-site scripting as the result of a manipulated clickTAG FlashVar is the most common manifestation of cross-site scripting in Flash content.

<br>

== References ==

* [http://www.owasp.org/index.php/Testing_for_Cross_site_flashing_(OWASP-DV-004) OWASP Testing Guide: Testing for cross-site flashing] - Covers finding both cross-site scripting and cross-site flashing.

* [http://www.adobe.com/devnet/flashplayer/security.html Adobe Flash Player Developer Center Security section] - Where Adobe posts articles and information related to Flash Player security.

* [http://www.adobe.com/devnet/flashplayer/articles/flash_player10_security_wp.html Adobe Flash Player 10 Security Model]

* [http://www.adobe.com/devnet/flashplayer/articles/flash_player_9_security.pdf Adobe Flash Player 9 Security Model]

* [http://www.adobe.com/support/security/ Adobe Security Bulletins and Advisories] This is where Adobe posts all of their security advisories and bulletins.

* [http://help.adobe.com/en_US/Flex/4.0/UsingSDK/WS2db454920e96a9e51e63e3d11c0bf69084-7f9b.html Applying Flex Security] The security chapter from the Adobe Flex 4 manual.

* [http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7d23.html Flash Player Security] The security chapter from the Programming ActionScript 3.0 section the Flash CS4 Documentation.

* [http://help.adobe.com/en_US/Flex/4.0/UsingSDK/WS2db454920e96a9e51e63e3d11c0bf69084-7d14.html Developing and Loading Sub-applications] This Flex SDK framework allows two or more untrusted SWFs to pass limited information between each other through the use of Shared Events.

<br>
== Useful Specifications ==

* [http://www.adobe.com/devnet/swf/ SWF File Format Specification] This documents the file format and structure of SWF files.

* [http://www.adobe.com/devnet/actionscript/articles/avm2overview.pdf AVM2 Specification] Describes the Flash ActionScript Virtual Machine used for ActionScript 3.0 code.

* [http://opensource.adobe.com/wiki/download/attachments/1114283/amf3_spec_05_05_08.pdf AMF3 Specification] The specification for version 3 of AMF used by Flash Player.

* [http://opensource.adobe.com/wiki/download/attachments/1114283/amf0_spec_121207.pdf?version=1 AMF0 Specification] The specification for the first generation of AMF (AMF 0) used by Flash Player.

* [http://www.adobe.com/devnet/rtmp/ RTMP Specification] This is the specification for the Real Time Messaging Protocol used by SWF content

* [http://www.adobe.com/devnet/flv/ Video File Format Specification] The FLV/F4V open specification documents the file formats for storing media content used to deliver streaming audio and video for playback in Adobe® Flash® Player and Adobe AIR™ software.

* [http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html Cross-domain Policy File Specification] This document serves as a reference for the structure and use of cross-domain policy files.

* [http://www.mozilla.org/projects/tamarin/ Tamarin Open Source Project] The Tamarin virtual machine is used within the Adobe Flash Player and is also being adopted for use by projects outside Adobe. The Tamarin just-in-time compiler (the "NanoJIT") is a collaboratively developed component used by both Tamarin and Mozilla TraceMonkey.

<br>

== Third-party Security Libraries ==

* [http://crypto.hurlant.com/ AS3Crypto] - An ActionScript 3.0 cryptography library.

* [http://code.google.com/p/as3corelib/ as3corelib] - An Adobe sponsored Google Code project that contains ActionScript 3.0 implementations of WS-Security, SHA, MD5 and other utilities.

* [http://labs.adobe.com/wiki/index.php/Alchemy:Libraries Alchemy ActionScript 3 Crypto Wrapper] - An Adobe labs project to port OpenSSL to ActionScript using Alchemy (previously known as Flacc). Includes the SHA1, SHA2, MD5, PKCS12 and AES from OpenSSL.

* [http://code.google.com/p/flash-validators/ flash-validators] - An Adobe sponsored Google Code project that contains ActionScript 2.0 and ActionScript 3.0 data validation libraries.

* [http://bugs.adobe.com/jira/browse/BLZ-415 Protected Messaging Adaptor] - This addition to the latest version of BlazeDS protects against an attack that allows an untrusted individual to subscribe to wildcard sub-topics. This threat is described within this [http://www.jamesward.com/blog/2009/07/22/protected-messaging-in-flex-with-blazeds-and-lcds/ blog] by James Ward.

* [http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/mx/validators/package-detail.html Flex validators] - Validation routines contained within the Adobe Flex SDK.

<br>

== OWASP Tools ==

* [https://www.owasp.org/index.php/Category:SWFIntruder SWFIntruder] OWASP Flash security testing tool

<br>
== Disassemblers ==

* [http://flasm.sourceforge.net/ Flasm] Flasm provides both disassembly and assembly functionality.

* [http://www.docsultant.com/nemo440/ Nemo440] Nemo440 is an AIR based ActionScript 3.0 disassembler.

* [http://opensource.adobe.com/svn/opensource/flex/sdk/trunk/bin/ swfdump] The Adobe Flex SDK, when built with ant, creates the swfdump utility ([http://blogs.adobe.com/gosmith/2008/02/disassembling_a_swf_with_swfdu_1.html overview]).

* [http://code.google.com/p/erlswf/ ErlSWF] A SWF disassembly tool based authored in Erlang

* [http://www.masonchang.com/2008/06/building-abcdump.html abcdump] The abcdump tool can be built from the tamarin source tree to disassemble AS3 byte code.

* [http://www.sweetscape.com/010editor/ 010Editor] This commercial tool has a [http://www.sweetscape.com/010editor/templates/files/SWFTemplate.bt template] for analyzing AS2 byte code.

* [http://segfaultlabs.com/swfutils swfutils] An ActionScript 3 library for disassembling SWF files.

<br>

== Decompilers ==

* [http://www.communities.hp.com/securitysoftware/blogs/spilabs/archive/2009/03/20/exposing-flash-application-vulnerabilities-with-swfscan.aspx SWFScan] This Windows tool decompiles a SWF and performs static analysis to identify common vulnerabilities for both ActionScript 2.0 and ActionScript 3.0 content. Available for download from here: [ftp://swfscanr:Zestier9@ftp.usa.hp.com/ FTP]

* [http://www.nowrap.de/flare.html Flare] Flare ActionScript 2.0 decompiler for Windows, Linux and Mac OS X.

* [http://www.buraks.com/asv/ Buraks ActionScript Viewer] '''($):''' An ActionScript 2.0 and ActionScript 3.0 decompiler that is able to extract resources and provide a rough FLA file. Costs @ $80 plus tax/shipping.

* [http://www.sothink.com/product/flashdecompiler/ SoThink Flash Decompiler] '''($):''' An ActionScript 2.0 and ActionScript 3.0 decompiler that is able to extract resources and provide a rough FLA file. Costs @ $80 plus tax/shipping.

* [http://www.dcomsoft.com/download/dfdinstall.exe Dump Flash Decompiler] Freeware program that treats compressed and decompressed SWF-files and shows the detailed structure in the tree form. Windows.

<br>

== Obfuscators ==

It should be noted that no obfuscator can protect a SWF from being reverse engineered. An attacker will always be able to extract data from SWFs if they believe it is worth the effort. Obfuscators are only serve as a deterrent for preventing casual inspection of the SWF.

It should also be noted that some obfuscators generate SWFs that do not conform to the Adobe SWF file format specification. Flash Player may still be able to play them but they do not conform to the spec. This could lead to some security tools such as Blitzablieter rejecting them as potentially malicious.

*[http://www.dcomsoft.com/ DComSoft SWF Protector] '''($):''' ActionScript 2.0/3.0 obfuscator for protecting your SWF files from Flash Decompilers. Available for Windows, Mac OS, Linux. Costs approximately $40.

<br>

== Analysis ==

* [http://www.utdallas.edu/~mxs072100/ASIRM_project.html Certifying IRM for ActionScript Bytecode] This page contains the binaries for Meera Sridhar's research into using In-lined Reference Monitors to rewrite ActionScript bytecode for the purposes of policy enforcement. This project is currently targeted at AVM2 code.

* [http://blitzableiter.recurity.com/ Blitzablieter] Blitzablieter is a project currently run by Recurity Labs and the German government. The goal is to prevent malicious SWFs from entering a network through normalization and policy enforcement. This project currently handles AVM1 code.

* [http://wepawet.iseclab.org/ Wepawet] Wepawet is a service for detecting and analyzing web-based malware. It currently handles Flash, JavaScript, and PDF files. It is currently run by University of California, Santa Barbara.

<br>

== Local Shared Object Editors ==

* [http://solve.sourceforge.net/ SolVE] Cross-platform Local Shared Object editor and viewer.

* [http://sourceforge.net/projects/soleditor/ .sol Editor] Windows based Local Shared Object editor

<br>
== AMF Tools ==

* [http://deblaze-tool.appspot.com/ DeBlaze] A free tool that attempts to identify AMF services through brute force, dictionary attacks.

* [http://www.gdssecurity.com/l/t/d.php?k=Blazentoo Blazentoo] Blazentoo is an Adobe AIR application that can be used to exploit insecure Adobe BlazeDS and LiveCycle Data Services ES servers. Blazentoo provides the ability to seamlessly browse web content, abusing insecurely configured Proxy Services.

* [http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project WebScarab] Full AMF support is currently checked into the main branch of the WebScarab project. It has not been rolled into the SourceForge or Java Web Start versions of the WebScarab project at the time of this writing.

* [http://code.google.com/p/webscarab-amf-plugin/ WebScarab AMF Plugin] This is a google code project to add AMF support as a plugin to WebScarab.

* [http://code.google.com/p/pinta/ pinta] Pinta is a utility that allows a developer to test services by making custom AMF service calls, and viewing detailed output. This Google Code project is based on Adobe AIR.

* [http://www.charlesproxy.com/ Charles Proxy] '''($):''' This is a basic HTTP proxy but it provides support for interpreting AMF communications. Costs approximately $50.

* [http://releases.portswigger.net/2009/08/v1214.html Burp Suite Professional] '''($):''' The 1.2.124 version of Burp Suite Pro adds AMF support to all tools except for Burp Intruder and Burp Scanner is updated to automatically place attack payloads within string-based AMF values.

<br>
== Project Contributors ==

The Flash Security project is run by [[:User:Puhley|Peleus Uhley]].

== Project Sponsors ==

The Flash Security project is sponsored by [http://www.mindedsecurity.com [[Image:|MindedLogo.PNG]]]

==== Project Identification ====

{{Template:Project Details/OWASP_Flash_Security_Project | OWASP Project Identification Tab}}

__NOTOC__ <headertabs />

<br> __NOTOC__ <headertabs />

[[Category:OWASP_Project|Flash Security Project]] [[Category:OWASP_Download]] [[Category:OWASP_Tool]] [[Category:OWASP_Document]] [[Category:OWASP_Alpha_Quality_Document]]