Appsec在RSA 2013上

这是我第二次参加RSA IT安全会议 。 与去年一样 ，我专注于appsec方面，从为期半天的微型课程开始，该课程由OWASP的Jim Manico和Eoin Keary讲授如何为开发人员编写安全的应用程序。 这是一个出席人数众多的会议。 真正懂得编写安全代码的人的坚实而明确的指导。 他们解释了为什么仅仅依靠笔测试是远远不够的（您的白帽子笔测试员每年需要2个星期来破解您的应用程序，黑帽的笔测试员每年需要52个星期），并且涵盖了所有主要问题，包括密码管理（安全存储和忘记密码功能），如何保护应用程序免于点击千斤顶，适当的会话管理和访问控制设计。 他们展示了代码示例（好坏），并向开发人员指出OWASP库和备忘单以及其他免费工具。

我们必须解决XSS和SQL注入

他们花了很多时间在XSS （Web应用程序中最常见的漏洞）和SQL注入 （最危险）上。 Keary建议，确保应用程序安全的一个良好的第一步是查找并修复所有SQL注入问题：SQL注入易于查看且易于修复（将代码更改为使用具有绑定变量的准备好的语句），并完成此操作不仅可以提高您的应用程序的安全性，还可以证明您的组织发现安全问题并成功解决它们的能力。

在整个会议期间，SQL注入和XSS不断出现。 在以后的会议中， Nick Galbreath更加深入地研究了SQL注入攻击以及开发人员可以采取哪些措施来检测和阻止它们 。 通过研究数千种SQL注入攻击，他发现攻击者使用了Web应用程序开发人员很少使用的SQL构造：联合，注释，字符串和字符函数，十六进制数字文字等等。 通过在SQL语句中查找这些构造，您可以轻松确定系统是否受到攻击，并有可能阻止攻击。 这是诸如Green SQL和DB Networks这样的数据库防火墙背后的核心思想，两家公司都在RSA上展示了其解决方案。

在会议的最后一天，Coverity Research的Romain Gaucher问：“ 为什么我们还没有淘汰SQL Injection和XSS？ ”。 通过对几个代码库的静态分析，他发现尽管许多开发人员试图通过使用参数化查询来停止SQL注入，但并非在所有情况下都可以这样做。 大约15％的SQL代码无法正确参数化-至少对于开发人员来说，使用另一种方法是不方便的。 Gaucher还强调了它试图保护应用免受XSS攻击的痛苦：

“ XSS不是单个漏洞”。 XSS是一组漏洞，主要涉及将污染数据注入各种HTML上下文中”。
Jim Manico在安全开发类中解释了同样的问题：为了防止XSS，您必须了解上下文并进行上下文敏感的编码，并希望不要犯错。 为了帮助解决此问题，除了OWASP提供的库外，Coverity还提供
开源的库可保护Java应用免于XSS和SQL注入。

善良

尽管大多数主题演讲都提供了赶上电子邮件的机会，但加密小组非常有趣。 中国对加密技术的研究正在飞速发展。 这可能是一件好事。 或不。 我很想听听斯坦福大学的Dan Boneh谈谈他对浏览器之外的数字证书处理和SSL所做的研究。 他的团队发现，几乎在所有情况下， 尝试在自己的应用中执行SSL证书验证的人都做错了 。

微软的Katie Moussouris介绍了有关漏洞处理的 ISO标准工作的更新。 ISO 30111提出了用于调查，分类和解决软件安全漏洞的结构化流程。 该模型并不令人惊讶-唯一令人惊讶的是，该行业实际上需要ISO标准以达到显而易见的目的，但是它应该为不知道从何入手的人们树立良好的标准。

Jeremiah Grossman解释说Web应用程序安全性问题有两个方面。 一半是网站的弱点，例如SQL注入和糟糕的密码处理以及访问控制中的错误。 另一半是利用浏览器基本问题的攻击。 试图突入浏览器的攻击（浏览器供应商通过沙盒，反网络钓鱼和反恶意软件保护引起了人们的广泛关注），以及停留在浏览器内部但损害了浏览器内部数据（例如XSS和CSRF）的攻击，浏览器供应商对此没有任何关注，因此应由应用程序开发人员来处理。

Grossman还使用了White Hat Security从其客户群收集的数据，提供了有关Web应用程序安全性状态的一些统计信息。 意识到他们的客户代表了已经对其应用程序进行定期安全测试的更成熟的组织，结果仍然令人鼓舞。 每个应用程序的平均漏洞数量逐年下降。 SQL注入现在是第14个最常见的漏洞，仅在7％的经过测试的应用程序中发现-尽管出于上述原因，超过50％的Web应用程序容易受到XSS的攻击。

来自Cigital的Gary McGraw同意，作为一个行业，软件正在变得越来越好。 缺陷密度正在下降（没有达到应有的速度，但是正在取得真正的进步），但是软件安全性问题并没有消失，因为我们正在编写更多的代码，并且更多的代码不可避免地意味着更多的错误。 他重申，我们需要继续关注基础知识-我们已经知道该怎么做，我们只需要这样做。

“现在是时候停止寻找要添加到列表中的新错误了。 只需解决错误”。

另一个亮点是Rugged Devops小组，该小组继续了去年年底在OWASP Appsec上开始的讨论，并涵盖了几乎相同的理由：使开发人员和操作人员共同努力以使软件安全地在生产中运行非常重要，我们需要更多的自动化（测试，部署，监视），并且devops如何通过多种方式提供改善系统安全性的机会，因此应该被IT安全社区所抵制，而不是被拒绝。

这些想法很大程度上基于Etsy，Netflix和Twitter在将安全性纳入其快速开发/部署实践中所做的工作。 我几乎总是同意一半的专家组（Nick Galbreath和David Mortman，他们在Devops商店中有软件安全方面的实际经验），而在其余大部分时间中，我不同意另一半的专家组。 每天持续部署10或100或1000次更改以及“混乱猴子”仍然有太多宣传。 Etsy每天都多次移至持续部署，因为他们无法正确管理其发布周期–这并不意味着每个人都必须做同样的事情，甚至不应该尝试。 如果您要信任像AWS这样不可靠的基础架构，您可能确实需要像Chaos Monkey这样的东西，但是同样，这不是您必须做出的选择。 开发人员还有很多事情要做，不幸的是这些想法得到了如此多的关注。

坏人与丑陋

对我而言，只有一个低谷–由McAfee的John Viega和Adobe的Brad Arkin组成的小组称为“ 软件安全性：浪费时间 ”。

Viega开始扮演恶魔的拥护者，声称大多数人不应该为appsec做任何事情，花时间和金钱在编写可以运行并处理安全问题的软件上更好，更便宜。 Arkin表示不同意，但不幸的是，专家小组不清楚他认为组织应该怎么做。 两位小组成员都质疑appsec依赖的大多数工具和方法的价值。 既不认为静态分析工具可以扩展，也不认为手动安全代码审核值得一做。 Viega还认为“对安全性进行同行评审是浪费时间”。 阿金接着说：

“我还没有看到值得购买的Web应用防火墙，并且我已经停止寻找了”

“使某人辞职的最佳方法是将他们置于威胁建模练习中”

“您永远无法模糊和修复每个错误”

Arkin还反对监管，理由是PCI未能为零售空间提供安全支持-忽略了许多公司甚至试图保护其软件的主要原因是因为PCI要求他们采取负责任的措施。 但是Arkin至少确实相信安全的开发培训很重要，每个开发人员都应该接受一些安全培训。 Viega不同意，认为培训只对少数真正关心的开发人员重要。

这个面板就像是周六夜现场的小品，脱颖而出。 我不知道小组成员什么时候是诚实的，或者什么时候他们讽刺性地发挥作用。 本次会议不辜负它的名字，确实是在浪费时间。

玩具

今年的贸易展览会比去年更大，整个展厅都有溢出的空间。 今年的展位上没有赛车或相扑摔跤手，脱衣舞娘（阿姆模型）作为摊位兔子变少了（当日在白天，你可以称其为“月光下吗？”），尽管有一个穿着打扮的人像钢铁侠，还有太多狂欢游戏。

今年的主题与安全中的大数据有关，因此有很多昂贵的分析工具可供出售。 对于appsec，我看到的最有趣的事情是Cigital Secure Assist，该插件适用于不同的IDE，每次打开或关闭文件时，它都会对代码（Java，.NET或PHP）中的安全性问题提供快速反馈。 Cigital的员工非常谨慎，不要将其称为静态分析工具（他们并不想与Fortify或Coverity或Klocwork竞争），但令我感到兴奋的是，反馈的质量，小的客户足迹以及他们打算以非常合理的价格为开发人员提供通过Web直接购买的价格，这意味着对于希望处理代码安全性问题的小型开发商店，这最终可能是一个可行的选择。

总而言之，这是一个很好的会议，并且是一次难得的机会，可以结识如此众多专注于IT安全的聪明人。 我仍然认为，对于纯粹的appsec来说，OWASP的年度会议会更好，但是没有什么比RSA更好的了。

参考： Buildsec Real Software博客上的JCG合作伙伴 Jim Bird 在RSA 2013上发布的Appsec 。

翻译自: https://www.javacodegeeks.com/2013/03/appsec-at-rsa-2013.html