空虚浪子心的灵魂

/文 空虚浪子心

网站给用户发送手机短信，已经是一种流行元素，几乎各大门户网站都有给用户发短信的功能。网站发送短信一般有主动和被动两种方式。主动方式，是让用户填写自己的手机号，之后发送。被动的方式，是用户发短信给某个网站提供的号码，之后网站回复。
朋友以前做过短信服务，短信接口毕竟不是免费的，虽然成本很低，但是大量的短信，也会让有些人心疼一阵。为了节约成本，为了防止用户发恶意内容的短信（欺诈、不“绿坝”等），网站都会采取加入验证码、不允许用户控制短信内容等防御。但是总会有人疏漏很多。

抓个典型：
某大型门户网站有个功能，发送“手机游戏”的下载地址给用户的手机。
 
看看给网页提交了什么内容

发送后，手机就会受到以下内容
三国猛将华娱版
http://XXXXXX（一个URL）

再次把这个包提交，又收到一条短信，再次最后次提交，还有。
这个功能并没有限制发送次数。
从短信内容上看，“三国猛将华娱版”，这个字符经过URLencode后，是http包中的“game_name”的值。改动包中的值，继续发送，收到的短信中，就会相应的改动。
既然我们可以影响短信中的部分内容，就可以给用户传递任何消息了，这里发送的还是个彩信。
这个功能，存在不限制发送次数漏洞，和部分内容可自定义漏洞。
我们可以做个自定义内容的短信炸弹。
 
工具危害巨大，自己研究用，恕不提供。
看看收到的短信：
 
如果用这个平台做个短信欺诈，不知道会有什么后果？最近好像很流行这个，可以发短信“您中奖了，我们是****短信平台，请汇款到XXX。汇款前，请先到****网站确认短信号码是否一致，以免上当受骗”。这毕竟是门户网站的短信平台，即使无所谓短信费用金钱损失，也要考虑用户印象。
目前该漏洞已经修补。

再抓个典型：
GOOGLE的天气预告短信提醒订阅功能。会主动发短信验证码给用户，用户在输入验证码，就可以订阅天气预告了。
 
抓个包看看：
第一次发包请求（如果包中没有COOKIE，就会返回setcookie的包）。

先请求验证码。
返回一个JSON的数组，内容中有个ID，并setcookie。

这个ID会作为发送短信时的参数，和验证码以及COOKIE对应起来，提交给发送短信的页面，就会通过验证码的验证。
第二次发包请求

captcha_answer这个验证码的值，和captcha_id是一一对应的。
两次发包请求，保证了验证码的验证功能，以免被恶意用户利用，发送垃圾短信炸弹。GOOGLE认为，用户都是使用浏览器上网的，所以每次打开短信发送页面，都会刷新cookie对应的验证码，就可以让用户每次都输入验证码，才会发短信：
第一步：打开页面，页面自动完成下面第二步。
第二步：发送注册captchaid的请求。服务器返回一个captchaid。
第三步：使用这个captchaid，请求验证码，服务器刷新当前COOKIE对应的验证码。并返回给用户验证码图片。
第四步：用户输入验证码，手机号，发送短信。页面会把用户输入信息，和captchaid一次发送。服务器收到这些信息，就会发一次短信。
用户再次发开页面，又会生成新的captchaid，cookie对应的captchaid会被替换。
关键问题有以下几点：
1，Captchaid和验证码是一一对应的。
2，获取验证码图片时，需要带上Captchaid。
3，用户再次请求，生成新的captchaid。
问题是，验证码真的用一次就不能用了吗？也就是说，如果用户不再次打开页面，cookie对应的captchaid会被清理掉么？
我们再次提交最后一个包，返回正常，收到短信，再次请求，又正常，收到短信。
经过多次发包验证，分别取消第二个包中的字段后，得出证明，如果用户不主动请求验证码，cookie对应的验证码不变！那么我们就可以做一个工具，先让请求验证码，让用户输入验证码（第二个包中，是需要验证码的），之后就可以疯狂的发送短信了。
工具内部的原理：
1， 先请求captchaid
2， 使用captchaid去请求验证码，就可以得到并生成“可以无限发送的那个包”需要的cookie，referer，captcha_id等信息。
3， 最后根据用户定义的手机号和发送次数进行轰炸。
 
工具危害巨大，自己研究用，恕不提供。
GOOGLE的这个功能，可以用来发送短信炸弹，填满你的收件箱。
漏洞已经两次发给google安全团队，但是收到自动回复后，一个月了，迟迟不见动静，也许他们不认为这是个漏洞。
最后一个典型：
Qq.com，这是个正面的典型。
QQ有很多很多短信相关业务，看看他们是怎么运作的。
 
这幅图已经可以说明所有问题了，腾讯几乎所有的短信接口，都在采用这种被动的方式。用户不能主动给自己发短信，只能使用手机给腾讯发短信，等候回复。当然，如果让腾讯的这个短信功能和google或者其他短信炸弹联动起来，不知道会发生什么美妙的事情。偶只是猜测，不知道是否有DDOS的可能性存在。
被动模式，除非用户可以伪造短信的发送方，否则是很难出现短信安全问题的。当然，如果用户群体不多，用户不怎么喜欢，看到这个功能后，可能会嫌麻烦，不如主动方式简单。（QQ用户多的恐怖啊）

如何防御：
对于广泛的，公用的，暴露在网站上给任何人免费使用的短信接口，应该有一套详细的安全方案，本文只是纸上谈兵一下。
最好的方式，是让所有的服务都采取被动发送，只有用户发短信来请求了，才会给他发回复短信。
然而，我们不能总是否定需求，如果一定要采用主动地方式，那至少应该做到以下几点：
1， 限制每天发送给某个号码的次数（YAHOO就是这么做的），这一点，只能在最外层应用上做，不能直接在接口处HOOK，可能多个应用同时使用一个短信接口。
2， 禁止从客户端提交短信发送的内容或部分内容，所有的发出短信内容都不应该有用户参与。
3， 每次发送需要输入验证码，一定要用一次，清除一次。
4， 在web应用层，记录详细日志。
综合以上几点，可以尽量少的避免短信接口攻击。随着业务的复杂性，可能有一些覆盖不到的地方，就只能根据业务具体定制方案了。