renren分离版api开发爬坑

前言

最近做的的一个系统，被内部人员恶意调用api攻击了几次，也算有了些经验（被甲方领导骂了很多次，然后加班了好几个晚上），这块之前一直是空白，出了线上事故后才对接口安全这块有了更多的认识

原有实现思路

过滤器路由配置

我们来简单看下 人人 前后端分离版对 第三方接口开发的实现

整个接口根据 /admin 和 /app 分为两个部分，/admin 这块走的是 shiro 的权限判断，对于第三方接口，我们不放在 shiro 中进行处理

shiro 过滤器这块是写在这里的，可以印证这一点，对 app 前端请求，给的 anno

app 接口层以及注解

我们已开源版本中提供的 AppTestController 为例简单看看

一共涉及到两个注解 @Login 和 @LoginUser ，理解了这两个注解的思路，这块基本上就没多大问题了，下面我们来分别讲解

@Login

提到这个注解，我们需要看 AuthorizationInterceptor

@Component
public class AuthorizationInterceptor extends HandlerInterceptorAdapter {
    @Autowired
    private JwtUtils jwtUtils;

    public static final String USER_KEY = "userId";

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        Login annotation;
        if (handler instanceof HandlerMethod) {
            annotation = ((HandlerMethod) handler).getMethodAnnotation(Login.class);
        } else {
            return true;
        }

        if (annotation == null) {
            return true;
        }

        //获取用户凭证
        String token = request.getHeader(jwtUtils.getHeader());
        System.out.println("token: " + token);
        if (StringUtils.isBlank(token)) {
            token = request.getParameter(jwtUtils.getHeader());
        }

        //凭证为空
        if (StringUtils.isBlank(token)) {
            throw new RRException(jwtUtils.getHeader() + "不能为空", HttpStatus.UNAUTHORIZED.value());
        }

        Claims claims = jwtUtils.getClaimByToken(token);
        if (claims == null || jwtUtils.isTokenExpired(claims.getExpiration())) {
            throw new RRException(jwtUtils.getHeader() + "失效，请重新登录", HttpStatus.UNAUTHORIZED.value());
        }

        //设置userId到request里，后续根据userId，获取用户信息
        request.setAttribute(USER_KEY, Long.parseLong(claims.getSubject()));

        return true;
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

重写的HandlerInterceptorAdapter实现拦截器，重写preHandle方法，

1. 扫描是非带有 @Login 注解，过滤条件
2. 拿到 header 中的 token ,没有则抛出异常
3. 通过 jwtUtils 校验 token 是否有效，粘在了下面，这块有风险，后面详细说，jwt 的思路这块介绍文章很多，jwt 就是无状态权限的思路，还有一种有状态存储的实现，存储介质一般可选 redis 或者 数据库，可以参考 ruoyi

芋道 Spring Boot 安全框架 Spring Security 入门 | 芋道源码 —— 纯源码解析博客 (iocoder.cn) 芋大佬的文章，这篇文章我看过调试过无数次，太经典，权限这块无巧，多看多调试，尚硅谷的 SpingSecurity 也可以，敲过一遍，还讲到了 微服务场景下的实现，Gateway下做的，后面有时间也写篇博客记录下，应该是把谷粒学院的这块单独拿出来了，谷粒商城实现就不太一样了，基于 SpringSession 做的，有空也写写

4. 解析出来的 claims 对象，拿到里面储存的 userId 信息，放到 request 的 Attribute，这块 SpringMvc 练过，Controller 中可以用 @RequestAttribute(“userId”) Integer userId 取到，这块实现很方便也是我为什么采用这块轻量级实现的原因

public Claims getClaimByToken(String token) {
    try {
        return Jwts.parser()
                .setSigningKey(secret)
                .parseClaimsJws(token)
                .getBody();
    } catch (Exception e) {
        logger.debug("validate is token error ", e);
        return null;
    }
}
1
2
3
4
5
6
7
8
9
10
11

@LoginUser

这个注解的前提是需要先加上 @Login ，相关实现类是 LoginUserHandlerMethodArgumentResolver

/**
 * 有@LoginUser注解的方法参数，注入当前登录用户
 *
 * @author Mark sunlightcs@gmail.com
 */
@Component
public class LoginUserHandlerMethodArgumentResolver implements HandlerMethodArgumentResolver {
    @Autowired
    private GarageService garageService;

    @Override
    public boolean supportsParameter(MethodParameter parameter) {
        return parameter.getParameterType().isAssignableFrom(GarageEntity.class) && parameter.hasParameterAnnotation(LoginUser.class);
    }

    @Override
    public Object resolveArgument(MethodParameter parameter, ModelAndViewContainer container,
                                  NativeWebRequest request, WebDataBinderFactory factory) throws Exception {
        //获取用户ID
        Object object = request.getAttribute(AuthorizationInterceptor.USER_KEY, RequestAttributes.SCOPE_REQUEST);

        if (object == null) {
            return null;
        }

        //获取用户信息
        GarageEntity user = garageService.getById((Long) object);

        return user;
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

这块其实是需要自己去扩展的，注入第三方用户类的Service ，根据@Login注解注入的 userId，拿到实体类，个人很少用，就不赘述了

存在的问题（为了整理方便我们按照时间线来列，主要突出时间纬度的还原，后面总结时在提出整体性的方案）

1. 用户使用 api 工具，使用自己的 token ，查看，修改其他人的单据

问题描述：我们的详情查询api接口设置， xxx?id=1 来做的，查询参数是 单据主键，单据主键使用默认自增，查询和操作时没有校验用户和单据的权限匹配关系，列表查询我们做了校验，但是详情查询这块没有做处理

解决：详情查询接口，操作接口添加校验，校验单据里的userId与登录用户token中取出来的 id 是否匹配

2.查询接口未做过滤，敏感数据部分泄露

问题描述：一个 下拉框的选择接口，没有do层与vo层没做过滤，返回了某些敏感数据

解决：查询接口创建单独 vo，做 do 与 vo 转换，只返回需要返回的数据

3. 某个只能精确查询的接口，在用户模拟输入空字符串时，会返回全量数据

问题描述：mapper 层的xml拼接如下

<where>
    <if test="a.name != null and a.name != ''">
        and c.name = #{a.name}
    if>
where>
1
2
3
4
5

我们正常用代码生成器生成的代码都是这个样子的，但其实这里根据需求理解我们不应该允许传入空字符串以及null（当然这块相等绝不可以用 like）

解决：这里有多种方案

1. 查询参数参数校验 @NotBlank
2. 查询前 使用 StringUtils.isNotEmpty 手动判断
3. mapper 中去掉为空的 if 动态 sql

4.用户使用api工具，修改结算总金额，以及操作已提交的历史单据

问题描述：这块同样是用户使用 api 工具，篡改提交的 json，并且由于我们的单据没有做状态判断，用户使用修改接口修改已经提交过的单据（篡改他人单据这块已经处理）

解决：根据问题描述分为三步

1. 添加单据修改时的状态校验

2. 添加加签验签（根本上解决 使用 api 工具修改单据问题，原则上敏感接口都需要使用这种方式）

   (目前的实现可参考上一篇博客，若依升级小记05-加签验签加强安全防护_周周写不完的代码的博客-CSDN博客 这块后面也有优化，可参考文章 https://mp.weixin.qq.com/s/B9wL2xGvN5lI0dc-OEy_Jg)

3. 总和计算，以及冗余数据写入，金额处理都应该放在后端处理，前端只返回对应id（id是否为正常可操作性的id后端也要校验）

5. Token 过期时间设置的太久，导致禁用用户后，凭证仍然有效

问题描述： 前期这块估计不足，这块 renren 实现也有 bug，我们把 token 过期时间设置成了 两周，导致在临时禁用用户后用户仍然可访问系统

解决：也是分为几步

简单的修改用户的账号只能防止用户再次登录（生成新的 token），但是由于 jwt 的秘钥没有修改，所以拦截器仍然会放行，并且我们只修改了账号，用户的 userId 仍然可以查询到，相当于用户仍可以正常操作自己的单据。

1. 受制于jwt方案，我们如果需要作废 token ，只有修改配置文件中的 jwt 秘钥，才能做到作废，后续考虑放在配置中心里面统一管理，定时刷新
2. 缩短 token 有效时间，目前设置成两个小时
3. 使用有状态存储替代完全无状态的jwt

6. sql 注入

提交的表单可以sql注入

简单粘一下，就是添加一个过滤器，匹配是否有sql的关键字

@Slf4j
@Component
@WebFilter(urlPatterns = "/*", filterName = "SQLInjection", initParams = { @WebInitParam(name = "regex", value = "(?:')|(?:--)|(/\\*(?:.|[\\n\\r])*?\\*/)|" +
        "(\\b(and|exec|execute|insert|select|delete|update|count|drop|%|chr|mid|master|truncate|char|declare|sitename|net user|xp_cmdshell|or|like'|and|exec|execute|insert|create|drop|table|from|grant|use|group_concat|column_name|information_schema.columns|table_schema|union|where|select|delete|update|order|by|count|chr|mid|master|truncate|char|declare|or|--|like)\\b)") })
public class SqlInjectFilter implements Filter {
    private String regx;

    @Override
    public void init(FilterConfig filterConfig) throws ServletException {
        this.regx = filterConfig.getInitParameter("regex");
    }

    @Override
    public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {
        HttpServletRequest req = (HttpServletRequest) servletRequest;
        Map parametersMap = servletRequest.getParameterMap();
        Iterator it = parametersMap.entrySet().iterator();
        while (it.hasNext()) {
            Map.Entry entry = (Map.Entry) it.next();
            String[] value = (String[]) entry.getValue();
            for (int i = 0; i < value.length; i++) {
                if(null != value[i] && this.regx != null){
                    Pattern p = Pattern.compile(this.regx); Matcher m = p.matcher(value[i]);
                    if (m.find()) {
                        log.error("您输入的参数有非法字符，请输入正确的参数！");
                        servletRequest.setAttribute("err", "您输入的参数有非法字符，请输入正确的参数！");
                        servletRequest.setAttribute("pageUrl",req.getRequestURI());
                        servletRequest.getRequestDispatcher( "/error").forward(servletRequest, servletResponse);
                        return;
                    }
                }
            }
        }
        filterChain.doFilter(servletRequest, servletResponse);
    }

    @Override
    public void destroy() {

    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

后续展望

目前先写到这里，后面再补充

参考 https://mp.weixin.qq.com/s/B9wL2xGvN5lI0dc-OEy_Jg)

需要补充sql注入的实现过程