漏洞CSRF修改个人资料和编辑器存储型xss漏洞

在某个产品上,客户的安全部门测试出了两个漏洞,一个是CSRF修改个人资料另一个是编辑器存储型xss漏洞

先说CSRF,这个大概情况是这样:

    分为两个用户,一个正常用户(A),一个非法用户(X)。

    A正常的访问系统,点击编辑用户信息,修改,提交,这时会向服务器发送一条请求。这时X拦截到了这条请求,使用工具编辑信息,并且发送向服务端。

    服务端会分别正常执行A X 两个用户的请求。

    要求:A 用户请求正常执行,X 用户请求要被拦截掉,不能执行。

    方法我知道的有三个:(1)验证 HTTP Referer 字段(2)在请求地址中添加 token 并验证(3)在 HTTP 头中自定义属性并验证

    这里只叙说第一个:验证http referer  referer  会自动判断访问路径是从哪里来的,也就是说判断请求来源。如果用户在浏览器中正常操作,点击按钮 “referer”都会有值,并且是请求的url路径,如果是直接操作浏览器的url “referer”则为空。如果是通过其他系统或工具访问“referer”也是null值。所以可以做一个拦截器。将所有的请求都判断请求来源。如果是A用户正常访问系统,执行通过。否则被拦截,返回提示页面。

    代码截图:

public class TokenInterceptor extends HandlerInterceptorAdapter {
    public static final String TOKEN_NAME = "__TOKEN";
    public static final String TOKEN_SESSION_NAME = "TOKEN_SESSION_NAME";
    public static final Integer TOKEN_SESSION_MAX_LENGTH = 20;
    private static Log log = LogFactory.getLog(TokenInterceptor.class);

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        String current = request.getParameter(TOKEN_NAME);
        String referer = request.getHeader("Referer");
        log.debug("referer:-"+referer);
        String uri = request.getRequestURI();
        // 判断 Referer 是否以 bank.example 开头   首页取消判断
         if (referer == null || !referer.trim().startsWith("http://bank.example")) {
            log.error("被拦截的地址:-" + uri);
            response.sendRedirect(request.getContextPath() + "/notice/repeat");//返回提示页面
            return false;
        }..........

编辑器xss漏洞,简单说一下。:用户在编辑某些东西时,填入了类似于这样的代码<img src="1" onerror=alert(1)>、<svg/onload=alert(1)>

    类似于这样的js代码保存为标题、内容或者其他时,用户在打开列表页就会看见这样的一个东西:



解决办法,只要在后端对“<“转义就可以了,查询的时候不需要转义,系统会自动识别。

将“<”转义成“&lt”


猜你喜欢

转载自blog.csdn.net/hyc123123123123/article/details/79734881
今日推荐