Let me see if I can explain
I think you avoid flash fullstop. :)
It seems to work this way:
Site bankinc.compromised has a flash applet on the site which is vulnerable.
You visit the bank and start a logged in session, which is controlled by a cookie only bankinc.compromised can access.
You get bored and go off to evil.comdom which whilst displaying a number of interesting pictures is also trying to load flash objects in the background from various sites with an ill crafted skinName paramater in them. This will allow
code to be injected and hence control the flash applet running on your browser which comes from bankinc.compromise.
They get lucky and the code they inject requests all the cookies on the bank site you are still logged in to the bank. And the bank cookies are now available via the compromised flash. The code also communicates those cookies back to evil.condom thru your browser.
Once evil.condom operator has your cookie, they could hijack your bank session.
It is a cross site attack and they could do more beyond just taking the cookies, but the cookies are the obvious one, and you would hope they checked the IP did not change mid session. Theoretically if the flash was on the make payments page they could automate a payment with it.
Who inserts code where? bad guy calls flash from bank using a skinName param which allow arbitrary to code to run in the bank's flash.
What exactly will I have to do to expose myself to danger? Allow flash to run and use a trusted site that has flash anywhere on the domain.
Is the trick ... ? No - bad site calls the bank flash - like you embed a site in a site, or snaffle an image.
Where is the injection, is javascript to blame? No, javascript is not to blame the flash html object is if you must blame something - but really it is flash.