我是我所在大学当地 ACM 学生分会的成员，作为我们活动的一部分，我计划就 Web 应用程序安全（以及可能的安全编码措施）的当前问题发表演讲。演讲将在我们计算机科学系的学生面前进行，将持续大约一小时的理论，然后是演示/动手模块（大约 1 小时）。
我想就您认为我应该涵盖哪些主题以及如何演示其中一些主题征求您的建议。我倾向于介绍 OWASP 的“Web 安全问题 TOP10 列表”，讨论它们并使用“OWASP 构建安全 Web 应用程序指南”中的资源来寻求对策和建议。
对于动手实验室，我正在考虑使用故意易受攻击的应用程序，例如 WebGoat 或相关的东西。你觉得呢？你有没有什么想法？谢谢。
OWASP Top 10 是一个很棒的内容创意——尽管正如你从我的其他帖子中看到的那样，我总是推荐一篇关于商业实用性的文章，所以如果你可以将谈话与关于实施和商业风险的信息结合起来，我认为它可以非常强大的演示文稿。
例如，合并关于每个 OWASP 前 10 名的修复有多复杂的信息可能具有很高的价值（例如，在具有输入验证和输出编码模块的编码框架中，用于降低 SQL 注入攻击风险的代码更改相对简单）
您可能认为这对于技术人员、开发人员等来说可能是题外话，但如果他们能够了解补救工作的业务驱动因素（或阻碍因素），这将对他们有所帮助。
就更多内容而言，您可以介绍Sammy Worm以及它如何完全避免HTTPOnly cookie的问题。需要注意的是，XSS 不仅仅是document.cookiePoC 警报框。CSRF 变得非常难以预防，但并非不可能。即使存在 XSS（深度防御），验证码也可用于防止 CSRF 。事实上，谷歌使用这种方法，例如授权在 youtube 以及其他地方的帐户取消链接。
有很多不同类型的 XSS， 基于 dom 的 xss是一种非常奇怪的类型。所以是的，事实上你可以编写不安全的 JavaScript，尽管这通常不是问题。（我在做 XSS 演讲时经常遇到这个问题。）
最近，来自 post-xss 世界的CSP和注释引起了很多关注。有很多伟大的头脑在研究 xss 的问题。Chrome、IE 和 Firefox 的 NoScript 中的抗反射 XSS 安全功能也很有趣，但它们也存在缺陷。IE 的 XSS 过滤器是迄今为止缺陷最多的地方。
我还告诉开发者，XSS 是一个输出问题，在一个 Model View Control 中，View 是防止 XSS 的最佳位置。试图逃避输入并将其存储在数据库中是一种可怕的做法。一方面，数据格式不正确，比较操作可能会失败。但更重要的是，当您将数据插入数据库时，您不知道将如何使用数据，您通常会盲目地应用错误的 XSS 清理方法。