漏洞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代码保存为标题、内容或者其他时，用户在打开列表页就会看见这样的一个东西：



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