序言
去年年底闲来几天,有位同事专门在网上找一些注册型的app和网站,研究其短信接口是否安全,半天下来找到30来家,一些短信接口由于分析难度原因,没有继续深入,但差不多挖掘到20来个,可以肆意被调用,虽然不能控制短信内容,但可以被恶意消耗,或者用于狂发信息给那些不喜欢的人。
漏洞分析
短信接收方无法约束
由于是注册型接口,接收方往往都是平台内不存在的手机号,所以无法约束。
接口请求方无法约束
由于是http(s)接口,任何人都可以请求,只要简单分析你的接口。
调用频次无法约束
一般的,接口开发者可能会想到通过抓取接口请求者的ip,进行频次约束,但实现是,他们拿到只是请求者的公网ip,有可能一个体量很大的局域网用户,接口开发者抓取到的都是他们的同一个公网ip,所以通过ip约束在很多场景下是不能使用的。
漏洞原因
原因其实很简单,接口开发者无法知道哪些请求是合理的,有些请求是不合理或恶意的,因为所有请求者都没有身份信息。
漏洞填补
- 如果你的注册功能是web页面,最好加上验证码功能,但使用便利性会打折。
- 如果你的注册功能是手机端,那就上SSL双向验证,中间人既无法分析你的接口,也无法发起请求连接到你接口服务,更不用说请求你的接口。
SSL/TLS双向验证
单向验证
我们平时浏览器请求的https网页,其实是SSL/TLS单向的客户端验证服务端的证书,也就是服务端不要求客户端有公认的证书,但客户端是要求服务端必须提供受信任的数字证书颁发机构证书。中间传输的数据是加密安全的,但服务端是无法得到能代表客户端的身份信息的,而且,客户端的请求加密数据是可以间接被拦截、解析、重构数据包再发送到服务端的(你可以了解Fiddler是怎么做到分析https接口的)。
双向验证
双向验证是指在单向验证的基础上,服务端也需要验证客户端的证书,只有客户端持有服务端认定的指定证书,服务端才允许客户端通过SSL握手,否则直接关闭tcp连接。对于需要双向验证的https接口,Fiddler也是无能为力,因为它自己也连接到不到服务端。
客户端证书
客户端证书我们不需要花钱去购买,使用openssl tools来自颁发就可以,服务端一般验证其thumdata是否满足就可以了。
安全的asp.net core
短信接口
回到实际干活撸代码阶段,我们可以把短信接口独立出来,做单独一个服务,其提供的只有短信功能的接口,接口必须双向证书验证,使用 kestrel ,我们很容易加入验证客户端的代码逻辑。
public static IWebHostBuilder CreateWebHostBuilder(string[] args)
{
return WebHost.CreateDefaultBuilder(args)
.UseKestrel((context, options) =>
{
var port = context.Configuration.GetValue<int>("SSL:Port");
var serverCertFile = context.Configuration.GetValue<string>("SSL:ServerCertFile");
var serverCertPassword = context.Configuration.GetValue<string>("SSL:ServerCertPassword");
options.Listen(IPAddress.Any, port, listenOptions =>
{
var httpsConnectionAdapterOptions = new HttpsConnectionAdapterOptions()
{
ServerCertificate = new X509Certificate2(serverCertFile, serverCertPassword),
ClientCertificateMode = ClientCertificateMode.RequireCertificate,
ClientCertificateValidation = (cer, chain, error) =>
{
// 你的验证逻辑
},
};
listenOptions.UseHttps(httpsConnectionAdapterOptions);
});
})
.UseStartup<Startup>();
}
}
Openssl生成cer、key和pfx
openssl genrsa -out openssl.key 1024
openssl req -new -x509 -key openssl.key -out openssl.cer -days 3650 -subj /CN=localhost
openssl pkcs12 -export -out openssl.pfx -inkey openssl.key -in openssl.cer
如果你在Postman请求,设置cer和key文件到postman即可,如果在.net环境请求这些接口,你需要使用pfx,你可以简单理解pfx就是前两者使用一个可选的密码进行打包的得到单一文件。关于证书本身的内容非常庞大,本文不作任何解读。
.net的客户端怎么设置证书
这里先卖个关子,使用WebApiClient库,可以轻松完成你想要的。