问题标签 [websecurity]

反正有没有绕过输入清理并进行 HTML 注入。

这是 bWAPP 的一个练习。当我尝试做 HTMLi 时，会检查输入验证并清理特殊字符。附加了清理代码，还有其他方法可以绕过代码并进行 HTML 注入吗？

通过强制执行特定的标头值来webpack-dev-server尝试减轻哪些安全风险？Host

默认情况下，webpack-dev-server仅允许Host标头指定本地环回地址（localhost、、127.0.0.1等）的连接。所有其他主机都会收到此响应：“无效的主机标头”。但是当然--allowed-hosts/allowedHosts配置允许扩大这个限制。

这似乎仅基于Host标题。我可以使用 curl 设置自定义 Host 标头，并且请求成功：

所以我很好奇——如果allowedHosts不阻止来自 curl 或其他自定义用户代理的连接，它解决了什么问题？它似乎只针对使用普通浏览器的普通用户，以保护他们免受在错误主机上提供的站点的影响。但是中间人攻击可以很容易地代理连接并覆盖主机标头。

为了防止 MITM 攻击，您可以使用 https（带有浏览器信任的证书）。但在这种情况下，证书本身似乎可以减轻 MITM 攻击。

我确定我遗漏了一些东西，所以任何进一步的解释表示赞赏。

在3. CSP Policy Delivery它说

Content-Security-Policy HTTP 响应头字段是传递策略的首选机制

但是有两种有效的机制，通过 HTTP 标头传递和通过 HTMLmeta元素传递：

为什么“首选”通过标头交付，或者更重要的是，通过 HTMLmeta标记交付的缺点是什么？

由于各种原因，在我们的部署中，将 CSP 添加到 HTML 头部更易于管理。

我使用默认的 GeneratePasswordResetToken 方法在用户的电子邮件中发送密码重置令牌，但它非常大，有 200 到 300 个字符长。我想制作更小的令牌，如 5/6 位长，并在 3 分钟内过期。我怎样才能做到这一点？

嗨，目前我有一个角度应用程序和 java 后端。在我的角度组件 html 中，我有一些图像，例如个人资料照片。提供图像文件的资源由 spring security 保护。所以我的问题是将 json Web 令牌作为图像 url 的一部分附加是不是很糟糕？它会导致安全漏洞吗？这是不好的做法吗？

以下是我的角度代码在 chrome 开发人员工具中的样子。

任何帮助表示赞赏。我很想将 access_token 作为 http get 请求标头的一部分传递，但我无法在任何地方找到合适的代码。任何帮助表示赞赏。

style-src = 'self'我想通过设置来限制将 CSS 样式注入 jsp 页面HttpSecurity.headers().contentSecurityPolicy();但是我正在使用的 jQuery 正在尝试将样式注入页面。

jquery-3.4.1.min.js:2 拒绝应用内联样式，因为它违反了以下内容安全策略指令：“style-src 'self'”。启用内联执行需要“unsafe-inline”关键字、哈希（“sha256-+PA1W6zRh5Oc60l8KTKpT7oxFVzjAUR9eAI5Pkr7MGE=”）或随机数（“nonce-...”）。

使用 jQuery 时，如何为 CSS 样式启用内容安全策略 style-src 'self'？

我想允许在父站点上发生的登录以自动允许 iframed 站点登录。

下面是具体情况：

我有一个网站是一个简单的登录页面。登录后，用户会看到带有一系列 URL 的菜单（都具有相同的基域但具有不同的端口）。

用户选择其中一个菜单项，然后将 url 加载到 iframe 中。

菜单是由数据库表驱动的。

所有的 URL 都将从 IIS 加载，但它们都在不同的端口上运行，因此我们可以很好地控制能够在一天中重新启动它们并部署新的。

我正在努力寻找一种方法来允许登录主站点以允许安全登录 iframe 站点。

换句话说，iframed 站点如何安全地知道登录到主站点的用户的用户 ID？

这些不是被 iframe 的任意站点。我们可以控制所有源代码。

在我看来，CSRF 的主要目标是确认发出请求的客户端是我们期望的客户端。

我经常看到的解决方案是：

1. 服务器生成随机 CSRF Token
2. 服务器在 cookie 中设置 CSRF 令牌
3. 1. 服务器在生成表单时将 CSRF 令牌注入表单或
   2. 服务器将 CSRF 令牌传递给 javascript，并且 javascript 将 CSRF 令牌作为 XMLHTTPRequests 上的标头注入
4. 收到请求时，通过检查 cookie 中的 CSRF 令牌是否与标头/表单值中的 CSRF 令牌匹配来验证请求。

服务器为 (3)(1) 生成 CSRF 对我来说很有意义，但我无法想出为什么 (3)(2) 需要它的原因。

相反，如果客户端是纯 javascript，我相信这是安全的：

1. Javascript 生成随机 CSRF 令牌
2. Javascript 在 cookie 中设置 CSRF 令牌
3. Javascript 在发出 XMLHTTPRequest 时在标头中传递 CSRF 令牌
4. 服务器检查标头和 cookie 中的 CSRF 令牌是否匹配

我的理解是 3 和 4 都是攻击者不能做的事情，所以这也足以阻止攻击。那是对的吗？

如果那是安全的，我们甚至需要执行步骤（1）和（2）吗？由于同源策略（假设 cors 配置正确），这是否也是安全的？

1. Javascript 在 XMLHTTPRequest 中设置一个 'CSRF-Safe: true' 标头
2. 服务器检查标头 CSRF-Safe 是否存在并设置为“true”

对于正在积极开发的软件，我们使用 Spring Boot（带有 Spring Security）和 Keycloak Adapter。

目标是：

• 需要对所有端点进行有效的身份验证，除了那些注释的端点@Public（参见代码片段）（这有效）
• 身份验证必须通过 OAuth - 客户端直接从 Keycloak 获取令牌，Spring Security + Keycloak 适配器确保它有效
• 可选地，还支持基本身份验证（可以将 Keycloak 适配器配置为执行登录并使其看起来像其余代码的常规令牌身份验证）（这也适用）

一切正常，但我在理解一些细节时遇到了一些问题：

• KeycloakWebSecurityConfigurerAdapter启用CSRF保护。我认为这样做只是为了它可以注册自己的 Matcher 以允许来自 Keycloak 的请求
• 它启用会话管理并需要一些相应的 bean
• 即使使用令牌身份验证发出请求，JSESSIONID也会返回 cookie

根据我的理解：

• 由于使用了无状态令牌身份验证，因此不需要会话（那么为什么要KeycloakWebSecurityConfigurerAdapter启用它）。这仅适用于BASIC Auth部分吗？
• 由于启用了会话，CSRF因此确实需要保护 - 但我不希望首先使用会话，然后 API 就不需要CSRF保护，对吧？
• 即使我http.sessionManagement().disable()在super.configure(http)调用后设置了JSESSIONIDcookie（所以这是从哪里来的？）

如代码片段中所述，由于我们使用Keycloak 的一部分并且应用程序是一个（因此管理这些资源记录） ，SessionAuthenticationStrategy因此不会将其设置为 null 一次。AuthorizationService Account Manager

如果有人能把事情弄清楚，那就太好了。提前致谢！

我们有一个使用 Angular 构建的应用程序。并且应用程序触发后端 REST api 来显示数据。

问题是，

该应用程序使用 LDAP SSO 身份验证来验证用户（它是公司内部的应用程序，因此没有外部用户）

步骤是，

1. 如果用户启动站点，它将重定向到 WebSec 登录，用户提供用户名和密码进行身份验证（隐式流）。

2. 一旦成功验证，我们将从 WebSec 访问 JWT 令牌，该令牌将存储在会话存储中，并将用作后端服务的“承载”令牌。

3. 后端服务有它的 WebSec 证书来验证他们身边的这个 JWT 令牌，如果没有，它将响应身份验证错误。

对于前端 - 我们正在使用 Angular 对于后端 - 我们是 Java，Sprint 启动。

问题是，

1. 这是用户身份验证的正确方法吗？
2. 如果是这样，隐式流的安全性如何。参考：https ://www.instagram.com/developer/authentication/ - 每个人都推荐显式流（服务器端调用）。我们的 UI 应用程序在不同的服务器中维护，后端服务在不同的服务器中维护。

如果有人对此提供解决方案，我将不胜感激。