Thinking small docking due to third-party services - correction algorithm and Sign

background

Recently a colleague wrote in the docking of pay utility module, and then cause one or two small Reflections on third-party services.

Think

Callback

To see how our colleagues are doing callbacks.

First of all, when requesting payment interface, the callback URL as a parameter of the requesting body [unencrypted].

{
    "xxx": "xxx",
    "xxx": "xx",
    "xxxxx": "xxxxx",
    "callBackUrl": "http://www.baidu.com"
}

Then, after the success of third-party payment service, payment service will issue a callback URL above http request, then the request body fixed to bring the following parameters:

{
    "code": 0,
    "充值订单号": "3333333333333333",
    "支付订单号": 361504175005106176,
    "支付状态": "SUCCESS",
    "充值数额": 88.00,
    "subject": "游戏",
    "gmtCreate": "2019-08-21 10:49:21",
    "gmtPayment": "2019-08-21 10:49:21",
}

Here, we can see

1, the callback url is not encrypted, so if a hacker to intercept this data, you can get this url continue to attack the server.

2, when the callback parameter party payment services is fixed and do not expand, the caller can not add custom parameters.

So what better solution have it, we can refer to Ali object storage OSS is how to do.
Callback
user only needs to send the request to the appropriate Callback parameter carries the OSS, which can implement callbacks.
Callback contains the following fields (JSON format):

{
    "callbackUrl":"121.101.166.30/test.php",  // 回调url
    "callbackHost":"oss-cn-hangzhou.aliyuncs.com", // 回调host
    "callbackBody":"{\"mimeType\":${mimeType},\"size\":${size}}", //回调请求体
    "callbackBodyType":"application/json" // 回调请求体类型
}

Callback then Json object into a string, then Base64 encoding, and finally the Base64 encoded character string as a parameter to the request. Last request thereof may be as follows:

{
    "xxx": "xxx",
    "xxx": "xx",
    "xxxxx": "xxxxx",
    "callBack": "23jdf7adf8gfasg98g78a9dgda"
}

In this case, we can see that this be intercepted by others, the first glance is certainly ignorant of force. But then, as long as the guess is base64 encoded, after the anti-coding can still be seen inside. If the security requirements are extreme, we can also add the encryption algorithm [can decrypt], do not complete the encryption can not go backwards back. . .

Sign Algorithm

After hKey1 = hValue2 & hKey2 = hValue2 & data = xxxx, and the value of the data is above request parameters splicing: Usually the Sign Algorithm, the request parameters spliced together to key1 = value2 & key2 = value2 format, and then stitching parameter header, the final format string, and finally encrypted.
We can imagine, if the splicing order of the client and server-side stitching inconsistent order, then the string after the last encryption is certainly not equal, then the last word must be returned from the server: signature is not legitimate.
Below, we look at the beginning of the stitching function SignUtil request parameters:

/**
     * 将参数进行拼接
     * 返回结果为: key1=value1&key2=value2&key3=value3
     *
     * @param map Map参数
     * @return String
     */
public static String mapToString(Map<String, Object> map) {
    StringBuffer builder = new StringBuffer();
    map.forEach((key, value) -> builder.append(key).append("=").append(value).append("&"));
    builder.deleteCharAt(builder.length() - 1);
    return builder.toString();
}

We can see, it is to traverse Map stitching. Map If the sort order may be divided into two categories: one is ordered (e.g. LinkedHashMap and the TreeMap), one is disordered (HashMap). If the payment service provider splicing method SignUtil provided above, it means that we developers do not know what type of payment services end to the Map of incoming spliced; this time if the payment server using TreeMap, and we They do not know their own use under the premise of the more commonly used HashMap, then this time a big problem, the signature is always wrong.

Solution (payment services provided by SignUtil):

1, the development of third-party document services must remind developers of the incoming type Map.

Splicing method can still pass parameters to Map, because this is more common use of generics, but do pay attention to remind developers of the document is passed in an orderly or disorderly implementation class.

2, passing stitching method parameter specifies the type of Map, and even specific to the implementation class.

Although this is not to use generics, it was not very common, but because of this, developers can enter mandatory, and can avoid a lot of unnecessary pit.

/**
     * 将参数进行拼接
     * 返回结果为: key1=value1&key2=value2&key3=value3
     *
     * @param map HashMap参数
     * @return String
     */
public static String mapToString(HashMap<String, Object> map) {
    StringBuffer builder = new StringBuffer();
    map.forEach((key, value) -> builder.append(key).append("=").append(value).append("&"));
    builder.deleteCharAt(builder.length() - 1);
    return builder.toString();
}

to sum up

If it is done to provide third-party service program ape, we must take into account the generality of interfaces, there are even more important is accuracy; then there is the document should be simple but not simple, allowing developers to see the document at once get butt, instead of wasting time to try to speculate on exactly how third-party service design.