问题标签 [owasp]

我已经阅读了关于防止 XSS 的 OWASP 指南。该指南似乎仅涉及具有白名单和编码输出。然而，这留下了所谓的自由文本字段的问题，例如我写这篇文章的文本框。

在接受自由文本字段时，除了可以在服务器端完成的黑名单（不可取）之外，是否还有任何预防措施。

从 OWASP 指南中，我得到的印象是应该只允许将 xss 存储在数据库中，并在它显示到前端时对其进行清理。然而，我对此有点不舒服。还是我错了，有没有更好的方法？

I am trying to run CSRFTester tool from OWASP to check for CSRF Attack on my web application. I am able to generate an HTML report from the tool but I dont know how to use it..I tried googling it but to no avail. Here are the steps I am following till now:-

From here On I don't know what exactly I have to do to test for CSRF and how to do it.. Please Guide me..Material available over the net for using this tool have repeatedly stated the same thing which I am not able to understand.

The sites quote :-

Once you generate report open a new browser instance, authenticate as another user with access to the same business function(s) of your testing site, and have then launch the newly created HTML report file. If the action effect after viewing the file in the same browser window that was used to authenticate the the victim, then that particular function is vulnerable to CSRF(cross-site request forgery).

Please guide me..Also if anyone knows about any Free tool to test for CSRF vulnerabilities then please let me know..I tried using Acunetix but to no avail..

我有一个基于 JSF 的 Web 应用程序，其中 MySQL 作为数据库。我已经在我的应用程序中实现了防止 CSRF 的代码。

现在由于我的底层框架是 JSF，我想我不必处理 XSS 攻击，因为它已经由UIComponent. 我没有在任何视图页面中使用任何 JavaScript。即使我使用我真的需要实现代码来防止 XSS 攻击吗？

对于 DB，我们在所有 DB 交互中使用准备好的语句和存储过程。

为了防止这 3 种常见的攻击，是否还需要处理其他任何事情？我已经浏览过OWASP网站和他们的备忘单。

我是否需要处理任何其他潜在的攻击媒介？

I've an ASP.NET web application project that I scan through the Fortify Source Analyzer v3.1.

The web project contains an ASPX that has a case where it redirects to itself.

The code is:

Fortify classifies that as OWASP A10 and CWE / SANS ID 601 issue. I don't understand the vulnerability -- it seems that we're redirecting to a very specific place ... the current URL.

Why is that considered bad?

Thanks in advance.

我需要在我的代码 (asp.net) 中实现 CSRF(Cross Site Request Forgery) Guard。虽然我从 OWASP 获得了一个库，但由于没有提供任何文档，因此实施它很痛苦。有人可以为我提供一种在.net 中实现 csrf 保护或正确配置 OWASP 库的更简单方法吗？

谢谢

-Chandan

我正在研究OWASP 十大移动风险，以便在开发移动应用程序时牢记安全问题。他们提供了有关 Android 和 iOS 平台的非常好的信息。一些值得注意的包括客户端注入、iOS 滥用 URL 方案、Android 滥用意图、击键记录、屏幕截图/iOS 背景、日志等。

这些非常有用，现在我想知道Windows Phone 7 中是否存在任何新漏洞，而 Apple iOS 和 Google Android 中不存在这些漏洞。

我的要求是，我需要构建有点像该死的易受攻击的 WP7 应用程序，以教育我项目中的 WP7 开发人员为我们的客户构建安全的应用程序。

OWASP 已经为 iOS 和 Android 开发人员构建了 iGoat（iOS 应用程序）和 DroidGoat（Android 应用程序）。我没有看到任何适用于 Windows Phone 7 的此类应用程序。

我们的团队希望更好地遵守 OWASP 指南，其中一项任务是防止 SQL 注入攻击。为了促进这一点，我一直在寻找一种方法来自动检查java.sql.Statement我们代码库中的使用情况，因此可以将其标记并更改为使用PreparedStatement.

我们的构建过程基于 Maven，我们还设置了声纳来对项目运行分析。如果满足某些阈值，Sonar 中已经有一些规则可以使我们的构建失败，因此可以在那里实施。我已经看到可以在哪里设置检查样式正则表达式规则以查找导入，但我想看看是否还有其他选项。

开发/构建路径上的任何位置都可以工作。如果 intellij 中有一些东西可以标记这个，maven 构建过程中有一些东西，或者在 Sonar 中标记这个的不同方式，这些都可以。

谢谢！！

我有一些用户输入。在我的代码中，我确保以下符号被转义：

OWASP声明有更多的字符需要转义。

对于属性，我做了另一种转义：

这确保了所有属性都包含在“。这让我确定我的 html 属性，但不是关于 HTML 本身。

我想知道我的逃跑是否足够。我读过这篇文章，但我仍然不确定我的担忧。

（JavaScript 使用 OWASP 库进行转义）

我知道这个问题本质上可能看起来有点恶意，但我只是想学习 Android/移动应用程序开发的最佳实践，而安全性绝对是软件中的一个大问题。如果您在阅读了这个问题（！）之后仍然认为它本质上是恶意的，请记住我不是在问如何实施任何这些攻击，我只是在问一个好的 Android/移动开发人员需要哪些攻击要认识到。

以下是应用程序的“官方”OWASP 十大安全威胁列表（链接在此处）。我想知道其中哪些（如果有）适用于 Android 开发，或者是否还有其他未在此处列出的主要攻击：

• 注射
• 跨站脚本 (XSS)
• 损坏的身份验证和会话管理
• 不安全的直接对象引用
• 跨站请求伪造 (CSRF)
• 安全配置错误
• 不安全的加密存储
• 未能限制 URL 访问
• 传输层保护不足
• 未经验证的重定向和转发

请注意：我不是在谈论为在移动设备中显示而构建的网站。我说的是部署在移动设备上的实际应用程序。对于 Android，这意味着APKs。

我们目前正在为 OWASP 开发一个开源项目，创建企业安全控制的 C++ API。

已经为 Java EE 定义了企业安全 API (ESAPI)。我们很清楚 C++ 语言对安全控制的要求可能会有所不同。毫无疑问，一些最大的安全问题源于内存管理，我们目前没有提供解决方案。到目前为止，我们专注于从 ESAPI 2.0 for Java 规范中提取的几个项目。但是，我们对其中一些安全部分有一些特定的问题。主要是，Java ESAPI 对 Web 应用程序有很大的倾斜，我们知道这不是 C++ 的规范。因此，我们正在寻找通用安全控制可能对 C++ 社区有所帮助的其他领域。了解 C++ 开发人员通常面临哪些类型的安全问题会很有用。

我们正在尝试确定黑客如何攻击和破坏您的代码，以便我们可以帮助提供适当的安全控制来防止它。

为了汇总对这个项目的反馈，我们创建了一个谷歌调查；但是，请随时在此处留下您的反馈。 https://docs.google.com/spreadsheet/viewform?formkey=dE5feWtjYlBNU05lV1FxTGNLVExIMVE6MQ

提议的安全控制（取自 ESAPI 2.0 for Java）：

• 身份验证 - 生成和处理确凿的帐户凭据和会话标识符的方法。
• 用户 - 表示应用程序用户或用户帐户。
• 访问控制 - 可以在各种应用程序中用于强制访问控制的方法。
• 验证 - 规范化和验证不受信任的输入的方法。
• 编码 - 解码输入和编码输出，以便对各种解释器都是安全的。
• 执行 - 用于运行具有降低安全风险的操作系统命令。
• 加密 - 通用加密、加密随机数和字符串、散列操作和签名。加密功能将建立在 Wei Dai 的 C++ Crypto++ 库之上。但是，我们的目的是提供足够简单的加密功能，以供普通开发人员使用，除了一些基本术语外，无需任何特定的密码学知识。
• 记录 - 设计用于记录安全事件的方法。

你会考虑使用这个 API 吗？

这会给您的发展/业务带来好处吗？

有什么建议吗？

您可以提供的有关此项目的任何其他信息对我们很有用。如果上面列表中缺少某些有用的特定内容，或者您​​可能有一般性建议，那就太好了。上面列表中是否有您建议我们忽略的东西，因为您绝对不会使用它？如果是这样，那么也告诉我们这些事情。

感谢您对此给予关注。我们希望为 C++ 创建一个 ESAPI 将使开发人员更容易编写更安全的应用程序。

https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API http://code.google.com/p/owasp-esapi-cplusplus/