Tag Info

Hot answers tagged

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


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


7

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

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


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.


5

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


5

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


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

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


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

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


4

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


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

It largely depends on the chip and the person that programmed it. Microcontrollers usually have a feature that allows you to pull the existing firmware binary off, but in many cases that can be disabled with a so-called "secure flag", which disables the download process until a new firmware is uploaded containing directives that turn the secure flag off. Of ...


3

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


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


3

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


3

You asked about alternatives. Quite frankly, this is a tough one: if someone is playing man-in-the-middle on your SSL session, and the user hasn't noticed or has allowed it to proceed, you're in a really tough spot. However, I'll try to brainstorm some alternatives that you could consider, if Javascript isn't able to check the cert the server provided on ...


3

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.


3

Since 6u10 Java applets have been able to store "muffins" (effectively cookies) using java.jnlp.PersistenceService. Also from the same release, Java applets can also open files through FileOpenService, FileSaveService and ExtendedService.


3

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


3

Silverlight can actually access the local filesystem, depending on the permissions granted. It is subject to .NET security mechanisms, but if these are badly configured, it is possible to read a user's files, or even change them.


3

Security advantages on the server side, or client side? For serverside (hacking the server - getting access to the server files) I don't see any advantages to do either one or the other. They are both files that do nothing. If you use PHP or another serverside language, that may cause problems, but then it's PHP, not Flash or HTML5. On the client side, ...


3

It means that the standard defenses against XSS when serving user-uploaded content are not sufficient. The standard defence against XSS when serving user-uploaded content is to serve it from a different address (ideally different domain and IP address completely, but a subdomain stops some attacks at least). That is, you allow it to fall victim to XSS, ...


3

XSF is, essentially, XSS in a Flash applet. Where in XSS you find vectors (e.g. URL parameters or form fields) for injecting content into the DOM that is parsed as script, in XSF you look for cases where you can get untrusted data to be placed into Flash variables, which may then be used in an unescaped context inside the Flash applet, resulting in script ...


2

i think, to block both are not better solution than, keep your system, flash engine, and antivirus updated. Flash and Javascript are not more dangerous than any other application in your computer. They had bugs? Yes, they were fixed? Yes. As your browser, as your operational system and as every single piece of software. With flash blocked. you should know ...


2

I don't know. I'm not Michael Zalewski, and I can only speculate about the basis behind this advice. Did he say anything more in the book? The crossdomain.xml file contains policy that Flash uses to determine how other sites may interact with this site. If it contains a permissive policy, then bad things can happen. Therefore, you don't want users to be ...



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