Podcast #128: We chat with Kent C Dodds about why he loves React and discuss what life was like in the dark days before Git. Listen now.

Hot answers tagged

99

The short answer is that it takes a loooooong time for software to die. Even in 2018 we still have COBOL running multi-billion dollar companies, despite COBOL being a "dead" language for decades. The longer answer is there's still a significant amount of websites that require Flash, and people re-enable Flash for practical reasons. Oftentimes these are "...


54

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 ...


31

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 ...


19

Because it's not completely "dead". It's just suppressed, for example, in Chrome the user has to click to allow Flash. Google has said that by 2020 it will not support Flash at all.


15

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 ...


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 ...


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 drive-...


10

Unfortunately, a lot of corporate software or internal websites still require Flash for various things (and not necessarily a recent version that may have some patches). If a company decides that their internal application requires a five-year-old version of Flash to simply work, they're not going to patch it. That leaves an awful lot of software and sites ...


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

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 ...


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.


7

Adobe Flash Player is written in an unmanaged code language, vulnerable to the following commonly cited vulnerabilities: Heap-based buffer overflow Use-after-free vulnerability Integer overflow Stack-based buffer overflow Double-free vulnerability Unspecified "type confusion" Crafted format-string argument Typically, unmanaged code is also subject to a ...


7

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 ...


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 ...


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

While "flash cookies" might be easy to clear as cx42net noted above, there are also other techniques that can be used to store hard-to-delete cookie-like data and read it from the server side. Take a look at evercookie for reference. I've seen this used in relatively high profile e-commerce and content sites.


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 cannot find any official statement from Adobe about the problem. But, Flash seems to have bytearrays shared between workers which are similar to SharedArrayBuffer in Javascript and probably can be used for high precision timing. Therefore I think that running Flash content can actually increase the risk of a Meltdown/Spectre attack. Still, given the ...


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

In the Web browser context, there are two kinds of SSL connections: the ones that the browser manages, and the ones that your code (be it Java, Javascript...) manages itself. For the first kind, you are mostly out of luck, because the browser will not give you details about the server certificate chain. The browser tells you "this is all dandy" but gives ...


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

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 ...


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