我有一个REST控制器，它有一个接受两个参数的方法12679.100
deleteStudent studentId和Long section {/ 1}}。
String对于上面的代码，checkmarx抱怨此参数值流经代码，最终用于修改数据库内容。 该应用程序不需要为请求重新进行用户身份验证。这可以启用跨站请求伪造（XSRF）。
我在部分尝试了@RequestMapping(value="/rest/deleteStudent/studentId/{studentId}/section/{section}", method = RequestMethod.DELETE)
public Student deleteStudent(@PathVariable Long studentId, @PathVariable String section){
return studentService.deleteStudent(studentId ,section);
}
（来自spring web util），但没有运气。
如何摆脱这个checkmarx问题？
如果字段是Long类型，XSRF和SQL注入攻击是如何可能的呢？
答案 0 :(得分：1)
您确定它是在讨论studentId参数而不是section参数吗？
如果确实如此，我说这是假阳性。
如果它正在讨论section参数，如果您的SQL请求是安全的，我根本不担心（所以如果您使用ORM或准备好的语句等等）
总的来说，我在所有SQL注射案例中都说这是假阳性。
那就是说，对于CSRF attacks，你可能确实很脆弱。
如果黑客让管理员加载页面，如果您不实施CSRF保护，即使没有访问权限，也可以删除任何用户帐户。
答案 1 :(得分：0)
来自 Spring Security(https://docs.spring.io/spring-security/site/docs/3.2.0.CI-SNAPSHOT/reference/html/csrf.html) 的评论：
<块引用>什么时候使用 CSRF 保护？我们的建议是使用 CSRF 保护可以由浏览器处理的任何请求 普通用户。如果您只是创建一个由以下人员使用的服务 非浏览器客户端，您可能需要禁用 CSRF 保护。
如果您的服务仅被非浏览器客户端使用，您可以从预设中排除 XSRF 查询。
如果没有，以下是 Checkmarx 如何检查您是否已验证跨站点请求伪造令牌 (Java/Cx/General/Find_XSRF_Sanitize)：
getNewXsrfToken、setRpcToken、verifyCSRFToken、isTokenValid这些方法调用和变量名用于方法声明。从这些方法声明的这些方法主体内部，所有这些请求都被视为已清理，并从潜在的受污染请求列表中删除。
CxQL 查询 Find_Interactive_Inputs 找到的所有这些源代码元素都是请求。