我已经使用Checkmarx工具对我的项目java Spring boot进行了扫描。该工具发现了大约23次中等严重性的XSRF事件。
在< code>@RequestBody列表上的Rest API方法POST中标记了发现的问题
在附件中,描述结果的屏幕截图:
@RequestMapping(value = "/rules/lineup/{ruleMode}", method = RequestMethod.POST, produces = MediaType.APPLICATION_JSON_VALUE)
public ResponseEntity<Object> getRulesByRuleModeAndLineup(@PathVariable Integer ruleMode,
@RequestBody List<String> lineups) throws Exception {
LOGGER.info("[getRulesByRuleModeAndLineup] ENTER type: " + ruleMode + " lineup: " + lineups);
ResponseEntity<Object> output = null;
List<Rule> rules = new ArrayList<Rule>();
try {
for (String lineup : lineups) {
String lineupSanitized = HtmlUtils.htmlEscape(lineup);
rules.addAll(uiService.getRulesByRuleModeAndLineup(ruleMode, lineupSanitized));
}
output = new ResponseEntity<>(rules, HttpStatus.OK);
} catch (Exception e) {
LOGGER.error(e, e);
output = new ResponseEntity<>("An error occurred: " + e.getMessage() + "'",
HttpStatus.INTERNAL_SERVER_ERROR);
}
return output;
}
是否有示例修复程序来解决此问题?
我试图实现你在回答中提到的第一点,就像遵循代码一样
后端端:
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter;
import org.springframework.security.web.csrf.CookieCsrfTokenRepository;
@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {
private static final Logger LOGGER = LogManager.getLogger(SecurityConfig.class);
@SuppressWarnings("javadoc")
@Override
protected void configure(HttpSecurity http) throws Exception {
http.authorizeRequests().antMatchers("/**").permitAll().anyRequest().authenticated();
http.csrf().csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse());
http.headers().httpStrictTransportSecurity();
}
}
前端侧
我在以下代码中实现了一个xhrRequest estHandler文件名js:
XMLHttpRequest.prototype.origOpen = XMLHttpRequest.prototype.open;
XMLHttpRequest.prototype.open = function () {
this.origOpen.apply(this, arguments);
if (document.cookie) {
var csrfToken = document.cookie.match(new RegExp(`XSRF-TOKEN=([^;]+)`))[1];
if (csrfToken) {
this.setRequestHeader("X-XSRF-TOKEN", csrfToken);
}
}
if (arguments[1].includes("socket/info")) {
this.setRequestHeader('X-Requested-With', 'XMLHttpRequest');
}
};
和索引上.jsp
我用下面的代码导入了上面定义的文件js:
<script src="<c:url value="/resources/js/xhrRequestHandler.js"/>"></script>
并添加了元名称行:
<meta name="_csrf" content="${_csrf.token}"/>
<meta name="_csrf_header" content="${_csrf.headerName}"/>
但我没有解决问题。
有什么问题吗?
您可以选择对该字段进行验证。这里有两种选择:
第二个意思是你有责任更新你的清单。
CSRF攻击迫使经过身份验证的用户(受害者)发送伪造的HTTP请求,包括受害者的会话cookie到易受攻击的Web应用程序,这允许攻击者强制受害者的浏览器生成请求,以便易受攻击的应用程序感知来自受害者。 我们下面来了解这个漏洞的威胁代理,攻击向量,安全弱点,技术影响和业务影响。 威胁代理 - 任何人都可以将内容加载到用户的浏览器中,从而迫使他们向您的网站提交请求。 攻击者的方法 - 攻击者创建伪造
跨站请求伪造(CSRF)是一种漏洞利用,攻击者致使受害的最终用户按恶意URI(例如以误导的链接、图片或重定向提供给用户代理)到达受信任的服务器(通常由存在有效的会话Cookie而建立)。 针对客户端的重定向URI的CSRF攻击允许攻击者注入自己的授权码或访问令牌,这将导致在客户端中使用与攻击者的受保护资源关联的访问令牌而非受害者的(例如,保存受害者的银行账户信息到攻击者控制的受保护资源)。 客户端
跨站请求伪造(Cross-site request forgery), 简称为 XSRF,是 Web 应用中常见的一个安全问题。前面的链接也详细讲述了 XSRF 攻击的实现方式。 当前防范 XSRF 的一种通用的方法,是对每一个用户都记录一个无法预知的 cookie 数据,然后要求所有提交的请求(POST/PUT/DELETE)中都必须带有这个 cookie 数据。如果此数据不匹配 ,那么这个请求
2.5. 跨站请求伪造 跨站请求伪造(CSRF)是一种允许攻击者通过受害者发送任意HTTP请求的一类攻击方法。此处所指的受害者是一个不知情的同谋,所有的伪造请求都由他发起,而不是攻击者。这样,很你就很难确定哪些请求是属于跨站请求伪造攻击。事实上,如果没有对跨站请求伪造攻击进行特意防范的话,你的应用很有可能是有漏洞的。 请看下面一个简单的应用,它允许用户购买钢笔或铅笔。界面上包含下面的表单: COD
描述 跨站请求伪造,或 CSRF 攻击,在恶意网站、电子邮件、即使消息、应用以及其它,使用户的 Web 浏览器执行其它站点上的一些操作,并且用户已经授权或登录了该站点时发生。这通常会在用户不知道操作已经执行的情况下发生。 CSRF 攻击的影响取决于收到操作的站点。这里是一个例子: Bob 登录了它的银行账户,执行了一些操作,但是没有登出。 Bob 检查了它的邮箱,并点击了一个陌生站点的链接。 陌生
CSRF 中间件和模板标签提供对跨站请求伪造简单易用的防护。某些恶意网站上包含链接、表单按钮或者JavaScript ,它们会利用登录过的用户在浏览器中的认证信息试图在你的网站上完成某些操作,这就是跨站攻击。还有另外一种相关的攻击叫做“登录CSRF”,攻击站点触发用户浏览器用其它人的认证信息登录到其它站点。 防护CSRF 攻击的第一道防线是保证GET 请求(以及在9.1.1 Safe Method