Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Flash and Flex clients can make RPC calls to a server using the NetConnection and AMF protocols. It's not uncommon to have these RPC calls setup to authenticate based on a cookie.

I've heard conflicting statements about whether this protocol (or any particular server-size implementation like BlazeDS, GraniteDS, etc) addresses the Cross-Site Request Forgery vulnerability. It would seem that without some special functionality here, a form post request could be forged that executes an RPC call that hijacks a user's session cookie.

Can anybody confirm or deny whether a vulnerability exists here?

share|improve this question
    
With CSRF, the server's API is what matters and you have not provided enough information to answer this question. –  Rook Oct 12 '13 at 17:08
add comment

1 Answer

Flash applets can be used for CSRF exploits but it depends on the same-origin policy or XML-RPC or similar.

If you want to send a XML-RPC request with an xml body in an html form you must use a form like this:

<form name="x" enctype="text/plain" action="" method="post">
<input type="hidden" name='<?xml version'value='"1.1"?><a><b>blah blah</b></a>'>
</form>
<script>document.x.submit();</script>

(But if the web application or server checks the content-type it will not work.)

and for same-origin policy :

CSRF in Plupload (CVE-2012-3415)

The Plupload applet called Security.allowDomain('*') to allow the applet to be used from any domain (so it could be served from S3, for instance). That meant people could interact with the Plupload applet from any other site on the Internet by embedding it on a page and using JavaScript. But due to the way the same-origin policy works in Flash, the applet could still make requests back to the domain on which it was hosted. In addition, people can specify the full URL for an upload request via JavaScript and the result of that request (ie: the HTML of the resulting page) is passed back via JavaScript to the embedding page.

So, if an attacker could convince a target to interact with the applet (by selecting a single file to be uploaded), the attacker could make a request to the domain that the applet was hosted on and read back the full response. That could disclose CSRF tokens or other sensitive information. This issue was especially important for Wordpress installations, where Plupload applets are hosted inside of the wp-includes directory by default.

The issue was resolved by removing the call to Security.allowDomain('*') by default.

Additionally, Flash applets can have XSS vulnerabilities as well. Read More And Reference

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.