问了3家AIR应用检测公司后发现，懂ActionScript的工程师太少了

去年等保2.0复测，我们那个金融客户端用的是Adobe AIR。CTO让我牵头找安全检测公司，我心想这还不简单，市面上做App安全的一抓一大把。

结果打了十几通电话，聊了五六家，越聊越虚。

有的说“AIR我们扫过，跟Android差不多”，有的看完SWF文件直接说“这种格式我们解析不了”，还有一家报价12万，聊了半小时我发现对方连ANE是什么都不知道。

最后我筛选了三家进入技术暗访环节，把团队整理的一份《AIR技术栈攻击面清单》甩过去，挨个问他们对沙箱逃逸、LSSO泄露、SWF字节码逆向这几个核心问题的检测能力。差异之大，超出预期。

第一轮：某头部云厂商，只有通用套路

先联系了一家云安全大厂，销售很热情，第二天就安排了技术对接。

我直接问：你们对AIR运行时Application Sandbox和Remote Sandbox之间的通信做不做跨沙箱脚本检测？

对方愣了一下，然后说“我们基于OWASP Top 10做全量代码审计，ActionScript在支持范围内”。

这个回答其实是在回避。AIR的安全模型跟普通Web应用完全不一样——Application Sandbox内的内容拥有完整系统权限，可以访问FileStream读写本地文件，而Remote Sandbox的内容默认被隔离。两者之间如果要通信，必须通过Sandbox Bridge做显式授权。

审计工具如果按常规Web漏洞标准跑，根本不会关注Sandbox Bridge的配置风险。我追问他们有没有针对allowLoadBytesCodeExecution这个属性的检测规则，对方沉默了几秒，说“需要确认一下”。

懂行的人知道，allowLoadBytesCodeExecution是Loader.loadBytes()方法的一个开关，默认是false，但如果开发者为了动态加载SWF内容把它设成true，远程加载的不可信代码就能绕过沙箱限制。这是AIR特有的高风险配置点。

后来对方给我发了一份报告模板，关于本地存储安全的检测项写的是“建议使用强加密”——这种套话等于没说。

第二轮：传统漏扫厂商，能跑但不懂

第二家是国内做漏洞扫描的老牌厂商，RSAS知名度很高。

他们的优势是有本地部署方案，数据不出域，符合我们的合规要求。而且扫描能力确实强，23万+漏洞库，自动化程度高。

但问题出在技术深度上。

我问他们怎么审计ANE原生扩展的安全性。ANE是AIR Native Extension的缩写，允许ActionScript调用Java/Objective-C/C代码。这意味着一份AIR应用可能有三个攻击面：AS3层、JNI层、C层。普通扫描工具只能扫到AS3层的API调用，对so文件里的内存破坏漏洞根本无能为力。

对方技术顾问很诚实，说“我们对so文件的逆向分析需要额外排期，一般按工时计费”。

我又问LSSO（本地共享对象）的数据泄露风险怎么检测。LSSO类似于浏览器的Cookie，但存储在用户本地，默认是明文。如果应用把Session Token或加密密钥存进去，任何有本地文件读取权限的进程都能拿走。

对方给的方案是“检查代码中是否有SharedObject.getLocal()调用，然后人工判断存储内容”。这意味着没有自动化检测能力，纯靠人工审计，效率和覆盖率都堪忧。

价格倒是不贵，4-10万区间，但修复指导只有通用建议，复测还要额外收费。对我们这种deadline明确的团队来说，检测完修不动等于白做。

第三轮：垂直厂商，技术对得上话

第三家是专做底层代码保护的厂商，规模不大，在安全圈里口碑还行。

技术对接一开始，对方问了三个问题：

1. “你们SWF编译的时候设的是local-with-network还是application沙箱？”
2. “ANE扩展里有没有调私有API？”
3. “SQLite用的是加密版还是官方原版？”

这三个问题问完，我心里有底了。

第一个问题对应的是沙箱逃逸风险。AIR的沙箱类型决定了API权限边界——Application Sandbox内的SWF可以调用FileStream、NativeApplication等敏感API，而local-with-network沙箱的SWF连本地文件都读不了。很多开发者图省事把所有SWF都放进Application Sandbox，等于把最高权限交给所有模块，攻击者只要劫持任意一个SWF就能拿下整个应用。

第二个问题关于ANE逆向。苹果App Store在2019年开始拒绝使用非公开API的应用，AIR的ANE扩展经常触碰这条红线。检测公司如果不懂iOS的私有API检测规则，很可能报告里说“通过”，上线后被苹果下架。

第三个问题更关键。AIR自带的SQLite是明文存储，但凡存了点敏感数据，Root过的设备直接拖库。正确的做法是接SQLCipher做加密，但很多外包团队图省事直接上官方版，安全检测如果没测出来，等保测评机构的密评章节必挂。

对方的检测方案分了四层：

• 静态分析：反编译SWF，审计ActionScript控制流，识别硬编码密钥、不安全网络配置、eval()动态执行等高风险模式
• ANE审计：对so/dylib做逆向，检查JNI边界处的输入校验、本地权限提升漏洞
• 运行时检测：注入探针监控内存dump、动态调试、Hook攻击
• LSSO专项：枚举所有SharedObject存储路径，检测明文敏感信息

报告模板我看了，每个漏洞标注了等保2.0对应的控制点（比如“安全计算环境-数据完整性”），密评也有专门章节。修复合约里写明了两次免费复测，修复建议附带代码示例。

价格比大厂略高，但把修复和复测打包进去了，算总账反而便宜。

真实差异：懂与不懂的5个判断标准

这三轮暗访下来，我整理了一份技术评审清单，采购前逐条问：

① 沙箱配置审计

• 不懂的：只看网络通信权限
• 懂的：检查application.xml中每个SWF的沙箱类型，审计Application Sandbox与Remote Sandbox之间的Bridge配置是否过度授权

② LSSO数据流追踪

• 不懂的：搜索SharedObject.getLocal()关键字
• 懂的：追踪SharedObject的写入内容，识别是否包含token、密钥、设备指纹，审计serialize()调用链

③ ANE扩展的Native层审计

• 不懂的：只扫AS3层API调用
• 懂的：反编译so文件，审计JNI边界处的数组边界、字符串校验、本地权限提升漏洞

④ Loader.loadBytes()动态代码审计

• 不懂的：不关注这个点
• 懂的：检查allowLoadBytesCodeExecution是否为true，审计加载的字节流来源是否可信

⑤ SWF反编译难度评估

• 不懂的：不涉及
• 懂的：用ffdec等工具实测反编译难度，评估代码混淆强度，给出加固方案

给技术负责人的建议

如果你正在找AIR应用安全检测服务商，不要只看品牌和报价。约技术沟通时，直接抛出这几个问题：

1. “AIR Application Sandbox里的SWF怎么安全地调用Remote Sandbox里的内容？”
2. “LSSO默认存储路径在哪？怎么检测有没有泄露敏感信息？”
3. “ANE扩展的so文件你们做不做符号还原和静态分析？”
4. “SWF你们用什么工具反编译？如果反编译出来的代码跟源码几乎一样，算高危吗？”
5. “等保2.0三级对移动应用的个人信息保护要求，对应AIR应用的哪些检测项？”

能完整回答这三个以上的，再进入报价环节。

我们最终选的是第三家。不是因为技术最强——论漏洞库规模他们肯定不如大厂——而是因为在这个细分场景里，能跟我的开发团队对上话，能给出可落地的修复方案，能把报告送到等保测评机构一次通过。

对于技术负责人来说，这才是真正的“省心”。