如何验证各种攻击的请求主体?
我正在写弹簧靴 REST API。
是否有更好的方法来 请求主体中的字段,以便它不应包含任何可能导致 owpasp 。
我的方法:目前使用Javax-validations @pattern注释。
public class Request {
@JsonProperty(value = "name")
@Pattern(regexp = "^[a-zA-Z][a-zA-Z\\s]*[a-zA-Z]$", message = "invalid name value")
private String name;
}
因此,如果我们通过 json 喜欢:
{
name : "<script>alert(1)<script>"
}
当请求body 获得 时,这将被拒绝。
这是进行服务器端验证以防止盲人XS和二阶SQL和跨站点脚本等攻击的正确方法。
I am writing a spring-boot rest api.
Is there any better way to validate fields in the request body such that it should not contain anything which could lead to any kind of attack defined by OWASP.
My Approach : Currently using javax-validations @Pattern annotation.
public class Request {
@JsonProperty(value = "name")
@Pattern(regexp = "^[a-zA-Z][a-zA-Z\\s]*[a-zA-Z]quot;, message = "invalid name value")
private String name;
}
So if we pass json like:
{
name : "<script>alert(1)<script>"
}
This will get rejected when RequestBody gets validated.
Is this the correct way to do server-side validation to protect from attacks like blind XSS and second-order SQL and Cross-Site Scripting.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我们需要分析SQL注入是如何发生的以及XSS的发生方式。
对于SQL注入,我们最好限制SQL操作的输入参数。将用户限制以附加或重建无效的值以构建执行SQL。
一个例子是:
[1]: https://github.com/iihero/blog/blob/main/main/securityprj/src/main/java/java/com/com/sean/workshop/security/security/sqlins/sqlinspent.java
在您的示例中,如果您没有直接输出源的内容:“警报(1)”。它不会产生影响。
We need to analyze how SQL injection happens and how XSS happens.
For SQL injection, we'd better restrict the input parameters for the SQL operation. Restrict the user to append or reconstruct invalid values to construct the executing SQL.
An example is:
[1]: https://github.com/iihero/blog/blob/main/securityprj/src/main/java/com/sean/workshop/security/ids/SQLInjection.java
For XSS, the most important part is to validate and restrict the response part. Analyze the response content and avoid the XSS value.
In your example, if you don't output the content of the source: "alert(1)" directly. It will not have impact.