Cross Domain Hijacking - File Upload Vulnerability
-
Upload
ronan-dunne -
Category
Technology
-
view
1.009 -
download
0
Transcript of Cross Domain Hijacking - File Upload Vulnerability
Flash Cross Domain HijackingFile Upload Vulnerability
Content• Flash & Cross Domain Policy
• Cross Domain Policy
• OWASP & Manual Test Guide
• Flash Cross Domain Hijacking - Outline
• Attack Scenario
• Impact
• AllowScriptAccess Values
• Real Life Examples
• Remediation
• Testing for Cross site flashing (OWASP-DV-004)– https://www.owasp.org/index.php/Testing_for_Cross_site_flashing_%28OWA
SP-DV-004%29
• Category : OWASP Flash Security Project– https://www.owasp.org/index.php/Category:OWASP_Flash_Security_Project
Testing for Cross site flashing
• Formerly called "Macromedia Flash", relabeled as "Adobe Flash" since 2005
• Streaming animation for web pages
• Can be a portion of an html web page or an entire web page
• Flash files are called "Flash movies“ and are .swf format files
• Offers two very special web browsing experiences: – Very fast loading– Vector animation with interactivity
Flash
• A cross-domain policy file is an XML document that grants a web client, such as Adobe Flash Player or Adobe Acrobat permissions to allow data to be handled not only within the current Domain but to other Domains
Cross Domain Policy
www.Domain2.conwww.Domain1.con
www.Domain3.con
• The value of this setting determines the script access to the SWF
• Possible values: –Never – No script access allowed (Deprecated)–SameDomain –SWF from same domain have
script access–Always – SWFs from external domains also
have script access – Dangerous!!
What It Does
• These days a lot of websites allow users to upload files, but many don’t know about the unknown pitfalls of letting users (potential attackers) upload files, even valid files
• What’s a valid file? Usually, a restriction would be on two parameters:
– The uploaded file extension– The uploaded Content-Type.
• For example, the web application could check that the extension is “jpg” and the Content-Type “image/jpeg” to make sure it’s impossible to upload malicious files. Right?
Where's this going Ronan
• The problem is that plugins like Flash doesn’t care about extension and Content-Type.
• If a file is embedded using an <object> tag, it will be executed as a Flash file as long as the content of the file looks like a valid Flash file
• But wait a minute! Shouldn’t the Flash be executed within the domain that embeds the file using the <object> tag?
• Yes and No
• If a Flash file (bogus image file) is uploaded on VictimDomain.com and then embedded at AttackerDomain.com , the Flash file can execute JavaScript within the domain of AttackerDomain.com
• However, if the Flash file sends requests, it will be allowed to read files within the domain of VictimDomain.com
Attack Scenario• Attacker creates a malicious Flash file (SWF) and
then changes the file extension to JPG
• The attacker uploads the file to VictimDomain.com
• The attacker embeds the file on AttackerDomain.com
• The victim visits VictimDomain.com and loads the file
• Attacker can now send and receive arbitrary requests to VictimDomain.com
AttackerDomain.com
VictimDomain.com
“So what can you do!?” you say
• Interact with files of the victim’s website by using current user’s cookies
• Execute JavaScript, XSS
• Communicate with its source domain without checking the cross-domain policy
• Use the Flash file to send requests and to read files from the domain of VictimDomain.com
Why• Attacker sets within the file the AllowScriptAccess as "always“
• SWF file can communicate with the HTML page in which it is embedded
• As we know the SWF file is from a different domain than the HTML page
• FlashVars pass arguments to a Flash file embedded inside an HTML page
• Here it specifies a known file within the VictimDomain.com that would be read by the AttackerDomain.com
<object style="height:1px;width:1px;" data="http://victim.com/user/2292/profilepicture.jpg"
type="application/x-shockwave-flash" allowscriptaccess="always" flashvars="c=read&u=http://victim.com/secret_file.txt"></object>
CrossDomainDataHijack.jpg
• "AllowScriptAccess=always"
• Means that any security functions are actively turned off: – Embedded content has full access too, and control
over the embedding site
AllowScriptAccess
AllowScriptAccess Options
• Three possible values: • Always• SameDomain• Never
• The "always" and "never" values unconditionally turn JavaScript access on or off for the SWF file
• The "SameDomain" value turns JavaScript access on only if the SWF file is served from the same domain and hostname as its surrounding HTML file
• Slideshare.net provides a service that enables you to upload your presentations and share it with the public
• Each presentation Slideshare offers a convenient HTML-code snippet that is ready to copy & paste it into your site
• Here a shortened example:
<object id="__sse763783" width="425" height="355"><param name="movie" value="http://static.slidesharecdn.com/swf/ssplayer2.swf?doc=grant-presentation-1227010891051378-
9&stripped_title=welcome-to-ip-surveillance-101-presentation&userName=grantsupplies"><param name="allowFullScreen" value="true"><param name="allowScriptAccess" value="always"></object>
Real Life Example - Slideshare
Real Life Example - YouTube• YouTube video embedded "AllowScriptAccess“ value="always"
Recommendation• Implement the Content-Disposition
– This lets the user save the file to their computer and then decide how to use it, instead of the browser trying to use the file.
Content-Disposition: attachment; filename=”image.jpg”
• Parse the file to determine its content as well as sending a Content-Disposition header where applicable.
• If possible isolate the domain of the uploaded files.
• Use flash security mechanisms SameDomain, Never
Never Ever make no assumption about the content