后端：任何客户端的东西都不可信任

有这么一个问题，许多做业务开发的同学往往一点点安全意识都没有。如果只是用一些所谓的渗透服务浅层次地做一下扫描和渗透，而不在代码和逻辑层面做进一步分析的话，能够发现的安全问题非常有限。要做好安全，还是要靠程序员和产品经理点点滴滴的意识

 

    对于 HTTP 请求，我们应该在脑子里有一个根深蒂固的概念，那就是任何客户端传过来的数据都是不能直接信任的。客户端传给服务端的数据只是信息收集，数据需要经过有效性验证、权限验证等后才能使用，并且这些数据只能认为是用户操作的意图，不能直接代表数据当前的状态

    举个例子，我们打游戏的时候，客户端发给服务端的只是用户的操作，比如移动了多少位置，由服务端根据用户当前的状态来设置新的位置再返回给客户端。为了防止作弊，不会由客户端直接告诉服务端用户当前的位置。因此，客户端发给服务端的指令，代表的只是操作指令，并不能直接决定用户的状态，对于状态改变的计算在服务端。而网络不好时，我们往往会遇到走了 一段距离又被服务端拉回来的现象，就是因为有指令丢失，客户端使用服务端计算的实际位置修正了客户端玩家的位置

一、客户端的计算不可信

比如在电商下单这个场景中，我们可能会暴露这么一个 /order 的 POST 接口给客户端，让客户端直接把组装后的订单信息 Order 传给服务端

 
@PostMapping("/order")
public void wrong(@RequestBody Order order) {
    this.createOrder(order);
}

订单信息 Order 可能包括商品 ID、商品价格、数量、商品总价

 
@Data
public class Order {
    private long itemId; //商品ID
    private BigDecimal itemPrice; //商品价格
    private int quantity; //商品数量
    private BigDecimal itemTotalPrice; //商品总价
}

用户下单时，客户端肯定会有商品价格等信息，也会计算出总价给用户确认，但这些信息只能用于呈现和核对。即使客户端把商品价格传了过来，服务端也一定要去数据库获取商品的价格，重新计算最终的订单价格。不然很可能会被黑客利用，商品总价被恶意修改为比较低的价格

因此，我们真正可以信赖并且能直接使用的只有商品的id和数量，然后重新计算总价。如果总价和客户端传过来的商品总价不一致，可以给客户端一个友好提示，让用户重新下单。

还有一种方法，客户端只给服务端传商品id和数量进行下单操作，下单成功后，服务端处理完成并返回诸如商品单价、总价等信息给客户端。此时，客户端可以进行一次判断，如果和之前客户端的数据不一致的话，给予用户提示，用户确认没问题后再进入支付阶段。

通过这个案例可以发现，在处理客户端提交过来的数据时，服务端需要明确区分，哪些数据可信任，哪些数据不可信任。

二、客户端提交的参数需要校验

对于客户端的数据，还容易忽略的一点是，误以为客户端的数据来源是服务端，客户端就不可能提交异常数据。下面有个案例

有一个用户注册页面要让用户选择所在国家，我们会把服务端支持的国家列表返回给页面，供用户选择。现在我们的注册只支持中国、美国和英国三个国家，并不对其他国家开放，因此从数据库中筛选了 id<4 的国家返回给页面进行填充。页面拿到数据进行渲染后，肯定只有三个可选项。

但是，页面是给普通用户使用的，而黑客不会在乎页面显示什么，完全有可能尝试给服务端返回页面上没显示的其他国家 ID。如果直接信任客户端传来的国家 ID 的话，很可能会把用户注册功能开放给其他国家的用户。

即使我们知道参数的内容本来就是服务端返回的，也需要对参数进行校验。因为接口不一定要通过浏览器请求，还有很多其他工具直接请求接口。

所以应对措施是，对参数进行校验，如下：

 
@PostMapping("/right")
@ResponseBody
public String right(@RequestParam("countryId") int countryId) {
    if (countryId < 1 || countryId > 3)
        throw new RuntimeException("非法参数");
    return allCountries.get(countryId).getName();
}

或者想要优雅一点，使用 Spring Validation 采用注解的方式进行参数校验（我个人一直用的这种方式，优雅永不过时~）：

 
@Validated
@RestController
public class TrustClientParameterController {
 
    @PostMapping("/better")
    public String better(
            @Min(value = 1, message = "非法参数")
            @Max(value = 3, message = "非法参数") int countryId) {
        return allCountries.get(countryId).getName();
    }
}

客户端提交的参数需要校验的问题，可以引申出一个更容易忽略的点是，我们可能会把一些服务端的数据暂存在网页的隐藏域中（比如浏览器的localstorage），这样下次页面提交的时候可以把相关数据再传给服务端。虽然用户通过网页界面的操作无法修改这些数据，但这些数据对于 HTTP 请求来说就是普通数据，完全可以随时修改为任意值。所以，服务端在使用这些数据的时候，也同样要特别小心。

三、不能信任请求头里面的任何内容

一个比较常见的需求是，为了防刷，我们需要判断用户的唯一性。比如，针对未注册的新用户发送一些小奖品，并且不希望相同用户多次获得奖品。而未注册的用户因为没有登录过所以没有用户标识，我们可能会想到根据请求的 IP 地址，来判断用户是否已经领过奖品。

下面的这段测试代码。通过一个 HashSet 模拟已发放过奖品的 IP 名单，每次领取奖品后把 IP 地址加入这个名单中。IP 地址的获取方式是：优先通过 X-Forwarded-For 请求头来获取，如果没有的话再通过 HttpServletRequest 的 getRemoteAddr 方法来获取。

 
@RequestMapping("trustclientip")
@RestController
public class TrustClientIpController {
 
    HashSet activityLimit = new HashSet<>();
 
    @GetMapping("test")
    public String test(HttpServletRequest request) {
        String ip = getClientIp(request);
        if (activityLimit.contains(ip)) {
            return "您已经领取过奖品";
        } else {
            activityLimit.add(ip);
            return "奖品领取成功";
        }
    }
 
    private String getClientIp(HttpServletRequest request) {
        String xff = request.getHeader("X-Forwarded-For");
        if (xff == null) {
            return request.getRemoteAddr();
        } else {
            return xff.contains(",") ? xff.split(",")[0] : xff;
        }
    }
}

这么做是因为，通常我们的应用之前都部署了反向代理或负载均衡器，remoteAddr 获得的只能是代理的 IP 地址，而不是访问用户实际的 IP。这不符合我们的需求，因为反向代理在转发请求时，通常会把用户真实 IP 放入 X-Forwarded-For 这个请求头中。

但是这种过于依赖 X-Forwarded-For 请求头来判断用户唯一性的实现方式，是有问题的：完全可以通过 cURL 类似的工具来模拟请求，随意篡改头的内容：

 
curl http://localhost:8888/trustclientip/test -H "X-Forwarded-For:183.84.18.71, 10.253.15.1"

因此，IP 地址或者请求头里的任何信息，包括 Cookie 中的信息、Referer，只能用作参考，不能用作重要逻辑判断的依据。而对于类似这个案例唯一性的判断需求，更好的做法是，让用户进行登录或三方授权登录（比如微信），拿到用户标识来做唯一性判断。

四、用户标识不能从客户端获取

业务代码非常容易犯错的一个地方是，使用了客户端传给服务端的用户 ID，类似这样：

 
@GetMapping("wrong")
public String wrong(@RequestParam("userId") Long userId) {
    return "当前用户Id：" + userId;
}

如果接口面向内部服务，由服务调用方传入用户 ID 没什么不合理，但是这样的接口不能直接开放给客户端或 H5 使用。

如果你的接口直面用户（比如给客户端或 H5 页面调用），那么一定需要用户先登录才能使用。登录后用户标识保存在服务端，接口需要从服务端获取。比如使用session存储、使用redis存储。

最后，安全问题是木桶效应，整个系统的安全等级取决于安全性最薄弱的那个模块。在写业务代码的时候，要从我做起，建立最基本的安全意识，从源头杜绝低级安全问题