Hot answers tagged

53

In theory, if all servers and connections to them were perfectly secure (impossible) and trustworthy (not true), neither one would be more "secure" than the other - mainly because the developer(s) of the website are in full control of the content of the site. Since Flash and the JS is served to clients, the server would have to serve malicious content to the ...


30

In addition to WillS' excellent answer, a couple more differences that affect security: Flash is a product, while HTML5/Javascript is a specification. With a product (and especially a closed-source one), you always depend on the vendor to play a game of whack-a-mole (which Adobe is doing admirably, but long term it is a losing battle). A specification can ...


13

Obfuscation might look as the first obvious step, but obfuscation has to protect something in the code and that something cannot be webservice functionality because that is reverse engineered by intercepting the traffic even if it is SSL encrypted. Certificate pinning can prevent simple SSL interception by trusting a predefined certificate. You can ...


11

Adobe Flash is 21 years old (started as FutureWave's SmartSketch), over the years it had to be able to deal with many different OS's, standards, and all the quirky restrictions they brought along with them. Most of the work done on Flash is aimed at keeping it up-to-date with the latest technologies, adding more and more features over time. This doesn't ...


10

It's not called Flash Drive By, but Drive-By Download, and yes, it's basically downloading malware just by visiting an infected website. Usually drive-by downloads work by exploiting a browser vulnerability (or a vulnerability in plugin like Flash or Adobe Reader), which leads to remote code execution triggering the download of malware. Unfortunately ...


9

No virus is possible if the browser has no bug. No escalation to admin rights is possible if the OS has no bugs. Unfortunately, bugs happen... in both the OS and the browser. Vulnerabilities which allow a non-admin process to gain admin rights (e.g. this one) are rather common, and it is usually assumed that getting through the browser is the complex part, ...


9

Fundamentally you cannot secure your client. At best you can obscure and obfuscate in order to make it more difficult for an attacker to modify the client. You mention that it is not a security issue because the server is properly secured, but merely an annoyance. It may be more annoying to try to obscure your client than to let a few modified clients make ...


8

SWFScan for any Nemo 440 for AS3, Flex, AIR Flare for AS2 (Flasm for disassmebly). These aren't as useful anymore There is an IDA Pro plugin for Flash disassembly written by some guy from Microsoft Also see osflash.org and flashsec.org


7

Targeting sandboxed platforms like Flash and Java will be excessively difficult if you're just starting out, so I suggest you learn to walk before you try to run. Some stuff you'll want to know: How to code in a low level language like C. What the stack, registers, heap, etc. do, and what happens when you overflow them in various ways. At least basic x86 ...


7

A parameter is a parameter: a data element (necessarily a character string, in the context of a URL) indexed by a formal name. What is done with that parameter on the server is entirely up to the server. We here enter the realm of suppositions. The parameter name "xmlPath" is suggestive of the parameter value being a path name for a file which uses XML. We ...


7

None. If they don't decompile your app, they will just put it through a proxy with it's own SSL certificate. Your client can't provide security for your backend.


6

While the "watching a screen" aspect of that site is pure flash, the screen sharing component is not. When you attempt to share your screen, it downloads an executable to install; an .exe on Windows, and a .pkg on Mac. So, yes - it's a foreign binary with the capability to steal all of the data you mentioned and more; but the sharing isn't using flash, so ...


6

Older versions of flash .swf's contain vulnerabiltiies. A user could upload a clip created with an older version of Flash CS and thus expose hundreds of end users. If they don't have the latest flash player (and many don't), they could catch a nasty bug. The .swf could be triggered to launch a cross-site injection that deploys an IFRAME within the user's ...


6

Flash has been a high-value target for exploit developers for years, particularly because of its near-ubiquitous installation base and the fact that (historically) it will generally run automatically whenever a page with Flash content is loaded. This makes it very easy for a large number of systems to be targeted and compromised with a single exploit. As it ...


5

Check out Fuzzing with DOM Level 2 and 3 "Overview Fuzzing techniques proved to be very effective in finding vulnerabilities in web browsers. Over time several valuable fuzzers have been written and some of them (mangleme, cross_fuzz) have became a "de-facto" standard, being widely adopted by the security research community. The most common ...


5

Original source -- http://my.safaribooksonline.com/book/networking/security/9780596806309/inside-out-attacks-the-attacker-is-the-insider/content_ownership 2.4.1. Abusing Flash’s crossdomain.xml The same origin policy can often be deemed too restrictive, causing application developers to clamor for the ability for two different domains to work interactively ...


5

EMET software participates in a defence-in-depth approach of security. It adds an effective supplementary security layer when an attacker manages to successfully exploit a vulnerable software without being blocked by the anti-virus. However, in such domain is an endless race, since while EMET is getting more popular, attackers will try to craft their ...


5

In most cases flash content is served with a distinct content-type like application/x-shockwave-flash. Proxies like squid can log this content-type additionally to the URL and I'm sure lots of the better firewalls can log this too. Note that simple packet filtering firewalls (iptables etc) will not be able to do this. Since I doubt that you will replace ...


5

I think that the answers you get here are mostly speculations. But the question is interesting nevertheless. I see the following main reasons: Other usual attack vectors like Java or ActiveX were harder to exploit because the relevant functionality was either switched off or layers of interaction were added (i.e. click to play, warnings with unsigned code ...


4

You are right. There are really many ways for a website to store persistent data on you, even if you dont want them too. Evercookie by Samy Kamkar is an example of this. Quotede from the site of Evercookie it stores persistent data on you with the help of these storage mechanisms: Standard HTTP Cookies Local Shared Objects (Flash Cookies) ...


4

Actually, depending on the browser and plugins used, there are many ways for a website to store persistent information on users' computer. It's not cookies and cache anymore. Some of these new methods require user confirmation, some don't - it also varies by browser. Flash has Local Shared Objects, Silverlight has Isolated Storage, HTML5 itself gives Offline ...


4

No - the DOM does not expose access to the SSL certificate for the current page, all you get access to is location.protocol which allows you to check if you are being delivered over HTTPS


4

You can try SWF Decompiler to convert SWF to FLA for getting any information that might you wouldn't get from FLA Movies for penetration testing http://www.sothink.com/product/flashdecompiler/


4

The answer is: yes. You should always worry about software. "Complexity is the worst enemy of secuirty" --Bruce Schnieir That being said, even if your machine is fully patched, one of the many Flash 0-days could still compromise the machine. XSS is exploitable regardless of if your machine is patched. This flaw is usually exploited with ...


4

Everything here depends on the version of your Flash Player. Here's a list of stuff, which you should try on this .swf file. Our first guess was Cross Site Scripting so we should try our hand at XSS, especially that we noticed one of the unsafe method: loadMovie. Cross Site Scripting There are a few types of unsafe functions. Each of them has different ...


4

Another good tool that I have used successfully in the past is OWASP's SWF Intruder.


4

The risks of Flash are client side. When viewing an compromised site that is well designed (not susceptible to XSS), there should be no difference in security between Flash and HTML 5 since the content is not malware. The main security problem with flash is for the client. When they visit a site infected with Flash based malware, bad things can happen to ...


4

There are a several ways I'm aware of. You can technically "view the source" of executables by using tools such as IDA Pro. or OllyDbg. Assembly knowledge is required! Stack Exchange also has a Reverse Engineering site you're interested. You can test input fields for common vulnerabilities. You can make a fake client/server to receive information from a ...


3

Flash is jailed by the some-origin policy and can only act upon a site that loads the flash applet with scripting access enabled. However, flash can become a vector for XSS. The demo above lists various XSS vectors. So for example in the extremely unlikely condition where you are loading a flash applet where the attacker can control the loadMovieNumVar ...



Only top voted, non community-wiki answers of a minimum length are eligible