While my primary involvement at Adobe happens to be around the ActionScript language, I also have some background in security, and recently I have been thinking about channeling some of that into designing and implementing tools for secure programming in ActionScript. ActionScript programs are compiled to run as Flash applications (on the web) or as AIR applications (on the personal computer / mobile device); as such, they are run on platforms with security models, and their security on those platforms is controlled by various security mechanisms, both at the language-level as well as at the platform-level.
As for most platforms, there are several security controls that an application developer needs to grok, to churn out something that is actually secure (more on that later); and these controls have various nuanced security implications. Application developers who target these platforms may range from sophisticated power-users who have a deep understanding of web, computer, and mobile security (including environment-specific assumptions, attacks, and defenses) to “novice” graphics-artists who have neither the time nor the patience (and rightly so) to appreciate any cyber-security issue beyond what might be driven by common sense. For the latter users, security controls perhaps need to be automated. And even for the former users, it may be unreasonable to expect thorough and precise knowledge of the semantics of every available security control, let alone the effects they may have (desired or not) when combined in code. Yet, we must assume that attackers will always be sophisticated enough to identify any security vulnerabilities in the code, and exploit them in the worst possible manner.
So what can we do to improve this situation? Rigorous documentation can help. Illustrative tutorials can help some more. But, ultimately, we need to recognize that programmers (as humans) are not very good at combinatorial reasoning…machines are. In other words, programmers need automated tools to help them identify security vulnerabilities and eliminate them in their code. Usually, there is a gap between their high-level security intentions and the low-level security mechanisms that they need to maneuver to satisfy those intentions. Filling that gap is the job of experts; but since not all programmers are experts or have access to experts or even know that such expertise is necessary, the job has to be done by tools designed and implemented by experts…once and for all.
So I met with Peleus Uhley (platform security strategist) today, to discuss some ideas and plans along these lines. I also ended up meeting several others in the security engineering team, including: Dimitri DeFigueiredo (security researcher), who remarked that having language (static or runtime) support for immutability would be very nice from a secure-programming perspective; and Brad Arkin (senior director of product security and privacy), who shared some cool thoughts on improving the perception of security around Flash and AIR. Overall, I pushed the vision of implementing some static security analysis in our authoring tools (Flash Builder / Flash Pro) and eventually baking it into the compiler. Higher-level security intentions become security annotations (manual or auto-generated), and lower-level enforcement of those intentions with the available security controls becomes the job of a specialized static analysis-plus-synthesis tool that correctly understands what security really means on Flash and AIR, and how the security controls are implemented. And understanding what security means on those platforms is really a matter of specification: perhaps something like authorized information flow. To be investigated.