分类 企业安全 下的文章

大力出奇迹:Web架构中的安全问题一例

前言

在一次对线上业务的测试中,遇到过一个奇怪的问题,经排查和LVS以及后台应用服务的同步有关,现在分享如下;并对web架构的基础知识和个人经验认为可能存在的问题做简单的总结。

现象

  1. 爆破接口本来是做了防护的,即当某IP的请次数超过一定的阀值后返回403(正常请求返回的是200),但是大量的多线程请求中出现了某些请求仍然正常的情况。如图:

burp.png

  1. 在某次对另一个业务的测试中,也发现了类似的问题。某登录接口,多次尝试后开始要求图形验证码确认,但当用户多次点击按钮请求,图形验证码要求却消失了。

原因

经过运维的排查,发现根本原因是后端多台服务器配置不一致导致的,比如有三台服务器的代码是最新的,有防护策略,而有一台服务器的代码没有得到更新,没有防护策略,当多次请求的时候,LVS将流量指向了没有启用防护策略的服务器,响应包也就没有要求图形验证或响应正常,从而导致了多个请求中存在了无需验证的数据包。

测试方法和利用

多线程、高并发请求;这些大量异常包中的正常请求也是有可能被利用的,比如,如果LVS是轮询算法,即每N次就有一次可利用的请求。

总结

现在的web应用早已不是单台服务器的时代了,往往都有一个庞大的web架构来支撑一个应用。个人学习了一下相关基础知识,并根据经验罗列了一下这些架构中可能存在的问题。

习惯了通过思维导图来记录知识,高清大图请点击或者右键查看:

xmind.png

Xmind源文件请访问Github获取。

抵现券一券多用问题原理与总结

背景

支付H5预计2015-12-31上线,故在2015-12-21日提测了一个服务端的安全测试单(单号:1632363),由安全测试人员bit4帮忙跟进测试。bit4于2015-12-26日于redmine系统提交了一个安全bug(单号:266626 【安全】【支付】抵现券高并发处理不当,可一券多用)。

测试步骤

  1. 通过PaySdk客户端,生成业务订单,并点击支付生成支付订单,但不进行购买,如此反复生成多个初始化的购买订单
  2. 通过抵现券查询接口(有三个,都可以),直接进行支付流程就会有这个接口的的返回信息,抓包查看即可,选取一个抵现券记录下它的code值,比如:d2404ac1b2a54a1aadad752b536fxxxx
  3. 截获支付流程中的购买接口(https://pay.xxx.com/pay/oauth/voucher/deal/buy),真正进行支付订单支付的接口,替换其中的code值为刚记录的值,并替换订单值为第一步骤中所记录的初始化订单的值。
  4. 同时发起订单号不同而抵现券值相同的多个请求,构成并发请求。之后查看结果。发现有两个请求均获得支付成功。

注:以上环境中,设置的订单金额和使用的抵现券的金额都是一元,以保证请求是有效的,不受其他逻辑的干扰。而且测试的时候资金账号基本余额也做了检查,余额未变动。而抵现券也只是少了一个。

现象

同一个抵现券在高并发请求下出现被多次使用成功,多个订单可以使用同一个抵现券购买成功。

核实问题

根据安全测试人员提供的订单号及抵现券code, 分析日志及DB中的订单状态,抵现券状态,确实发现两个不同的购买订单使用同一个抵现券code购买成功,且可重现。

分析问题出现原因

经分析代码AccountServiceImpl.decrVoucherFirst()方法发现调用消费抵现券方法VoucherServiceImpl.consumeVoucherCode()时未对方法是否消费抵现券成功做处理,而该方法本身也没有对是否成功消费抵现券做处理。

故导致,同一个抵现券在高并发请求下,有多个请求同时满足消费抵现券的前置条件,到达如下图二所标识部分,则多个请求都可以执行完该方法,只是返回值不同, 上层调用者如图一所示, 并未对返回结果做判断。

1.png

2.png

验证问题

修改VoucherServiceImpl.consumeVoucherCode()方法,不更改程序原有逻辑,仅添加详细日志来验证分析出的原因是否正确, 修改如下。

3.png

重新打包,提交到测试环境,请安全测试人员重新测试, 日志如下:

4-1.png

日志与预期结果相符,验证了猜测。
 
于2015-12-27日,修复了该bug, 修改如下图所未, 调用到更新DB时,更改失败时,抛出消费抵现券失败异常, 阻止程序继续执行。

5.png

重新打包,部署到测试环境,测试结果如下:

测试时发现有三个请求在同时尝试修改券的状态,其中两个返回了“消费抵现券失败”,只有一个成功。确认修复有效。

总结

Mysql处理高并发,防止库存超卖的问题,大部分人一般想到的都是事务,但是事务是控制库存超卖的必要条件,但不是充分必要条件。

举例:

  • 商品总库存:4个商品
  • 并发请求人:a、1个商品 b、2个商品 c、3个商品

假如产品表名为:t_store, 商品id为:12345, 商品库存字符为: amount, 请求减掉的库存数量: quantity

程序如下:

BeginTransaction(开启事务)
try{
    $result = $dbca->query('select amount from t_store where product_id = 12345');
    if(result->amount > 0){
        $dbca->query('update t_store set amount = amount - quantity where product_id = 12345');
    }
}catch($e Exception){
    rollBack(回滚);
}
commit(提交事务);
EndTransaction(结束事务)

以上代码就是我们平时控制库存写的代码了,大多数人都会这么写,看似问题不大,其实隐藏着巨大的漏洞。

数据库的访问其实就是对磁盘文件的访问,数据库中的表其实就是保存在磁盘上的一个个文件,甚至一个文件包含了多张表。
例如由于高并发,当前有三个用户a、b、c三个用户进入到了这个事务中,这个时候会产生一个共享锁(读锁,允许多个事务读,但是不允许修改),

---me:为什么这里加的是共享锁而不是排他锁呢?因为是先query,也就是读取,所以加共享锁。而下边的update是修改,只能是排它锁。

所以在select的时候,这三个用户查到的库存数量都是4个,同时还要注意,mysql innodb查到的结果是有版本控制(MVCC,有兴趣的同学可以自己百度)的,在其他用户更新没有commit之前(也就是没有产生新版本之前),当前用户查到的结果依然是旧版本。

然后是update,假如这三个用户同时到达update这里,这个时候Mysql会把update更新语句并发串行化,也就是给同时到达这里的是三个用户排个序,一个一个执行,并生成排他锁(可读可写,独占资源),在当前这个update语句commit之前,其他用户等待执行,commit后,生成新的版本;

这样执行完后,库存肯定为负数了。但是根据以上描述,我们修改一下代码就不会出现超买现象了,代码如下:

BeginTransaction(开启事务)
try{
    $dbca->query('update t_store set amount = amount - quantity where amount>= quantity and product_id = 12345');
}catch($e Exception){
    rollBack(回滚);
}
commit(提交事务);
EndTransaction(结束事务)

这样就可以控制库存超卖的情况了, 但是还需要处理一点,就是执行这个update事务究竟是否更新成功(即更新成功的records是否大于0)呢 , 上面的update更新成功才能够接着处理用户扣钱,等一系列的操作。

再来看看此次我们所犯的错误:

很明显所犯的正是没有关心update执行是否成功亦即更新成功的records是否大于0,在没有做任何的判断的情况下让程序继续向下执行。故而导致此bug的出现。

本内容选自小密圈:

20180613075812.jpg

验证码安全那些事

前言

最近在研究验证码安全,本文主要分析四种流行的验证码(图形,短信,语音和滑动)进行分析,写这篇文章的出发点并非是绕过或破解验证码,而是根据自身业务情况来选择对应的验证码类型,在用户体验和安全性中找到属于自己的平衡点。

有问题可与我联系Wechat:atiger77

目录

0×01. 图形验证码  
0×02. 短信验证码
0×03. 语音验证码
0×04. 滑动验证码
0×05. 总结

备注:无论使用哪种验证码,只要开发不当都可能存在安全漏洞,为了减少文章重复内容,只在短信验证码中讲解漏洞以及对应加固方案,在语音验证码中讲解风控预防措施。

0×01 图形验证码

图形验证码是出现最早也是使用最为广泛的验证码没有之一,从最早的简单验证码到现在各种五花八门的验证码,为了防止被识别有加噪点的,有加干扰线的,有加各种背景的,有加逻辑题的…

之所以会有越来越恶心的验证码主要是防止验证码被机器识别,所设计的验证码难度也在不断上升,相比较来看下面两张图就知道为什么会这么设计了。

一般识别流程:

14917152134767.png

一般验证码加固方法:

14917152549751.png

随着验证码难度的提高识别的成本也随即提高,为了进行识别测试,我分别收集了四家不同类型互联网公司的验证码,情况如下:

某招聘网站验证码 – 字母周围有噪点,字体扭曲

20170424112448.png

某电商网站验证码 – 不同样式,字母阴影,字母粘连,背景色干扰

20170424112458.png

某社交网站验证码 – 主体干扰线,背景色干扰,背景字母干扰,字体扭曲,字母粘连

20170424112509.png

某生活类网站验证码 – 背景干扰线,背景色干扰,背景字母干扰,字体扭曲,字母粘连,字体镂空

20170424112522.png

首先针对某招聘网站的验证码进行识别,这里基于tesseract写的一个OCR程序,测试样本10张,最后准确率在50%,反溯以下发现对识别相近字时会比较吃力比如”z”和”2″,”0″和”O”等等,因为验证码做了反识别部分验证码人眼也比较难识别,如果继续优化识别率达到70%左右应该问题不大。

14917154289847.png

接着对某电商网站的验证码进行识别,最后准备率在40%,由于该网站验证码难度各不相同对于这种类型的验证码比较难做统一处理,即使使用机器学习的方法一个模型也很难去识别所有的验证码。

后面两个网站的验证码使用图像识别去做难度就很高了,为了不被识别分别做了大量的反识别工作,那么对于这类验证码一般使用的是人工打码平台,之前有文章已经介绍过了这里就不重复描述了。

这是某打码平台的价格,网上可以找到很多类似的网站。

14917154282029.png

那么对于企业来说,怎么防止验证码被人工打码呢,从安全角度来说是比较难做到防止的,为了不失去用户体验每张验证码的失效时间并不会很短,对于一个熟练的人工打码人员来说完全不在话下,那么我们从验证码本身出发去提高攻击的一个成本,举一个例子,可以使用DataURI scheme的方法把验证码图片直接写到HTML文件中去增加识别的时间和成本,当然还会有很多方法可以去增加攻击成本。

如果想从根本去除打码平台的困扰,这里可以参考支付宝和微信这两个产品的验证码机制,在某些地方所弹出的图形验证码是和使用者有关,比如选择联系人头像,选择购买过的物品,对于人工打码的人来说是完全不知道答案的,但是用了这种类型的验证码也会出现问题,比如“好友”足够了解你的情况下(个人信息泄露太多)可能会成功的进入。

现在有很多文章会用到神经网络CNN的方法用来识别验证码,相比传统的识别用机器学习有了样本的学习,识别率会更加的准确,对一些人眼可能判断错误的字母机器或许能判断准确,不过学习成本也是很高的。

0×02 短信验证码

短信验证码常见于注册,忘记密码,确认下单等阶段,特别是一些涉及到用户个人敏感行为时候,为了确认操作是用户本人执行的通常会使用短信验证码进行二次认证。同时,短信验证码也是最为常见的验证码类型之一,这里总结一些验证码逻辑漏洞。

a. 接口没设频次上限导致短信轰炸

起因:短信轰炸问题往往出现在一些小站或者子站,这几年很少看到通过GET请求发送短信验证码了,基本都是使用POST请求,使用抓包软件可以重放请求对于后端没有做限制的网站就可以达到短信轰炸的效果。

危害:对用户来说个人生活受到骚扰,对企业来说造成一定的负面影响,很多小公司因为短信接口被大量调用出现运营问题,对于公司没有安全工程师的情况下,一般都是业务方发现了数据异常向上汇报,最后和开发一起反溯才会找到这个问题,那么在这段时间中对企业所损失的钱也是无法挽回的。

预防:这里主要是针对两种攻击场景来进行防御,第一种是对单用户的短信轰炸,即重放发送请求且phonenum为一个值。第二种是对多用户发送短信骚扰的场景,即将phonenum参数设置为字典,重放短信接口。

设置发送间隔,即单一用户发送请求后,与下次发送请求时间需要间隔60秒。

设置单用户发送上限,即设置每个用户单位时间内发送短信数的上限,如果超过阈值就不允许今天再次调用短信接口(阈值根据业务情况设置)。

设置单IP发送上限,这种情况是预防第二种攻击场景的,由于IP的特殊性可能存在所处IP是大出口,一旦误杀后果会很验证,所以这个限制根据自身情况酌情考虑,对于有风控的团队来说,当发现发送IP存在异常可以对该IP增加二次认证来防止机器操作,也可以降低误杀情况。

备注:b和c两个漏洞场景一般截图说明下开发就知道问题所在了,这里修复建议的内容写的就比较少。

b. 验证码内容包含在返回包中

起因:因为开发不严谨导致通过抓包可以看到验证码在回显中显示。

14917155261248.png

危害:由于验证码直接返回,通过该漏洞可以注册任意用户,重置已注册用户密码,修改绑定信息等高危操作,对用户造成一定影响。

修复建议:不要将短信验证码在回显中显示,验证码只存于服务端中并不能通过任何api直接获取。

c. 修改返回包内容绕过验证

起因:前端校验导致下列问题。

14917155974535.png

14917155573802.png

危害:可跳过正常校验逻辑。

修复建议:服务端严格做检验,和开发谈谈心。

假设网站验证码接口没有以上说的任何漏洞,那么短信认证是否安全呢?

在用户手机没有被种木马,用户手机没被强制降频到GSM等情况下,当攻击者无法获取短信验证码则某些关键操作是无法继续的,在一定程度上起到了拦截的作用。特别针对盗号的场景,由于设备或常用地发生了变化,在用户登录时候弹出验证码进行校验防止被盗号的情况。短信验证码只对部分场景可以起到防护作用,单一的认证对于企业来说无法阻止以下的场景。

14917155587746.png

这张图在我上一篇文章中出现过,这是在某打码平台注册了一个帐号的截图,从图上就可以看出虽然用了短信验证码,但是可以通过打码平台来自动获取并完成注册流程。

针对打码平台的垃圾注册场景也可以通过一些手段去增加批量自动化的注册成本,防御手法有相同之处,在语音验证码中会简单讲解。

0×03 语音验证码

相比短信验证码,语音验证码存在以下的优势:

a.语音验证对防刷单效果更显著;
b.语音验证码到达率更高;
c.用户体验更加友好;

为什么说语音验证码对防刷单更有效,这里贴一张某打码平台的收费情况,可以看到语音验证的价格是短信的十倍。很多公司是不会对17开头的虚拟号段进行发送的,为此卡商提供的卡号基本是实名认证的且没有停机的正常号段,所以收语音验证的成本就会比短信高很多。

14917156829962.png

这家打码平台对语音识别有两种方式,一个是系统识别,另一个是自己听取,对于系统识别平台解释是由听码团队负责听取验证码后传输文字回来,自己听取则是自己下载语音验证码录音自己听候识别。

跟公司研究移动端安全的小伙伴讨论了下,根据目前的技术要做到全自动也并非不可能,这里简单画了一个流程,从触发语音认证开始到最后的填入完成验证一条龙。

14917156821814.png

首先要获取语音认证,等语音验证码说完以后自动保存录音,进行语音分析,国内有几家厂商有语音识别的服务并都提供SDK,所涉及的服务可以用来进行识别,将语音转换成文字并提取验证码部分,完成最后验证。

对于企业来说我们如何防止这种垃圾注册的场景呢,说几种通用的思路供参考,这里主要可以分事前和事后基于规则和行为做判断。

对于事前,可以借助反欺诈接口检测请求的号码是否存在风险,WEB端判断用户UserAgent是否存在异常,APP端判断用户DeviceID是否存在异常,由于事前可以拿到的信息并不多,可以围绕可以拿到的参数做规则,对触发规则的用户进行阻断操作,可以在发送短信或者语音前让其先填写一次图形验证码,多一步校验。当然,也有公司会将部分手机号进行拉黑操作,在源头上禁止某些手机号进行注册。

对于事后,服务端校验以后就可以拿到状态等信息,围绕这些信息又可以制定一些规则,这里可以举一个通用的规则,比如单位时间内单IP登录失败超过阈值的对这个IP进行某某处理,这也是最基本的频次规则。对于不同的业务有着自己不同的策略,比如金融公司的APP会索取用户通讯录的权限,根据用户的好友做用户画像,某些公司也会做二度关系画像来判断用户是否存在风险。

这里不会说太多的规则和策略,由于公司的业务都不尽相同,当日志接入以后针对目前场景存在的问题去设计不同的规则即可。

0×04 滑动验证码

现在有不少的互联网公司开始使用滑动验证码进行校验,看似一个简单的滑动操作,背后都有风控引擎和相应的规则作为保障,首先讲一下滑动验证码的整个流程。

1491715758468.png

我们说一下正常的逻辑,首先用户滑动验证码到指定位置,完成后会给服务端回传各种加密信息,为了做风控规则来判断是否异常,个人猜测其规则会包含用户IP,操作行为路径,UA,COOKIE,设备指纹等等,如果没有命中规则,就会放行校验通过,如果命中规则就会弹出二次校验,只有通过校验后才可以放行。

那么如何破解滑动验证码呢,第一种是模拟正常用户操作,并让风控不要命中风控规则。第二种是尝试破解第二阶段的验证,对于图片可以使用OCR技术进行识别(针对类ReCAPTCHA验证码)。第二种的难度比较高,网上的文章也是针对第一种来进行破解,这里简单讲一下破解方法。

我对某商业滑动验证码进行了测试,整体流程梳理如下:

14917157589764.png

全部过程可以用自动化来实现,整体成功率要分为两个部分来看,第一是验证码自身风控能发现多少问题,我所测试的接口破解成功率在76%左右。第二是企业自身的风控规则能发现和阻断多少异常情况。两者结合最后的成功率就会有所下降,虽然有接口破解但是价格昂贵,已经提高了攻击成本,如果账户不涉及到金钱也不会考虑这么高的攻击成本,其实说到底还是成本和收益的一个衡量。

这里聊一下商业化滑动验证码厂商的优势和弊端。首先说优势,滑动验证码肯定会成为一种流行趋势,对于企业来说自研的成本比较大,无非也就是几个工程师参考已有的进行模仿,先不说效果开发流程上就会耽误人力,这点钱宁愿使用商业化的,现在的产品都已经相对成熟也有专门的团队进行升级维护,安全和体验性上来说都还不错。弊端到也谈不上,这里主要说几点使用前要考虑的地方,一个是响应延迟,当大量并发过来的时候是不是撑得住,最高响应时间是否有上限,如果超过是否会降级,如何降级等等,万一碰到不可预计的问题,比如碰到光缆被挖断,服务是否能即使切换,灾备是否完善等等,在购买前这些问题最好都要进行测试并有应急方案。

0×05 总结

前面也总结了很多验证码,我认为一个好的验证码首先不能有逻辑上的漏洞能绕过,否则再复杂的验证码都是形同虚设。其次,不能为了增加破解难度而抛弃用户体验,不要把验证码做的极其复杂人眼都识别不了,这种也会失去验证码的意义(用户都没了还给谁验证…)

目前来说大部分的企业还是偏向使用图形验证码,在测试过程中只有极少数的公司会动态升级自己的图片验证码,随着输错次数的上升验证码难度也随机上升。统一验证码的设计初衷是好的,即使攻击者使用了OCR技术进行破解,一旦失败数触发到阈值即自动上升图形验证码难度,增加破解成本。

为了防止验证码被爬虫获取后专门进行分析,针对性的破解攻击,需要准备多套图形验证码定期进行替换。

统一验证码体系如果只用单纯的规则去匹配所弹出的验证码,那么这种情况会出现不少的误杀,会让某些正常用户操作频次超过设定阈值,用户在尝试输入密码的过程中验证码越来越难,最后导致用户投诉。所以我认为一个完善的统一验证码体系应该由风控来判断是否触发规则,对触发规则的请求进行相应的验证升级,而不是设定一个死的阈值,对关键操作可以用多种验证码组合的形式来进行校验,常见的组合有,滑动+图形,图形+语音等。

就我个人而言,比较喜欢点触式和滑动式的验证码,通过采集用户当前各种的参数行为(行为轨距,操作时间,当前环境等等)来判断是否为机器行为。在用户体验上,手机端不是很建议使用选字类型的验证码,对于非大屏的手机不是很友好。在安全性上,这类验证码要比其他验证码破解成本高。我相信验证码的趋势也会逐渐向这种类型的靠拢。

下面的图片引用了google的ReCAPTCHA,分别截取图片和语音验证,ReCAPTCHA在安全性和用户体验做的都很好,即使这样还是被安全研究者破解过,所以不要完全依赖一种验证码,对敏感操作可以使用多种验证码。下面是官网的DEMO:

图片类:

14917158615511.png

声音类:

14917158896397.png

无论哪种验证码都有自己的适用场景,也没有一种绝对安全的验证码,根据自身业务情况来选择对应的验证码类型,在用户体验和安全性中找到属于自己的平衡点。最后,有做业务安全的同学可以一起学习交流。

互联网企业安全高级指南读书笔记

前言

春节前花了几天时间,终于把这本书完整读完了。受益匪浅!

这是市面上第一本从总览的视角陈述甲方企业安全建设思路与框架,描绘企业内部信息安全全貌的书。

除了“战略”层面的全局观,这本书还难能可贵的深入了一些技术细节,在“战术”层面也不乏很多干货。

为了帮助记忆和理解,我基本上每章都用思维导图的方式整理了笔记。

这些笔记并非对全书的完整总结,亦非斗胆点评,仅作为个人理解和梳理思路的笔记之用。

第三章 甲方安全建设方法论

第三章.png

第四章 业界的模糊地带

第四章.png

第五章 防御架构原则

第五章.png

第六章 基础设施安全

第六章.png

第七章 网络安全

第七章.png

第八章 入侵感知体系

第八章.png

第九章 漏洞扫描

第九章.png

总结

总得来说,互联网企业和传统行业企业在安全建设的思路上,殊途同归。

不同点

  • 扩展性

互联网企业的业态具有大流量、高实时性、海量用户、海量数据的显著特征。由于流量太大,所以“两个海量”的特征与传统企业非常不一样。同时,互联网企业的线上业务就是钱,这样就决定了高实时性是必保的点。传统企业的线上业务即便是挂了,在一定时间内也不会直接影响生产力。

为了应对一大一高两个海量,传统安全企业的解决方案存在先天不足:无法无缝横向扩展。这就导致了互联网企业更多的选择自研防护手段。

互联网企业对安全防护手段的要求是,低维护成本+高扩展性。而传统企业呢,更看重的是易配置+防护全面。

  • 自研能力

这一点非常容易理解。互联网企业拥有足够的薪资吸引高端人才,所以才能支撑自研的需求。而传统企业除了保护线上业务外,还需要应对合规、内部防泄密等安全外延业务诉求。自身也不具备自研的能力。

相同点

  • 分层防御+威胁感知

无论是线上业务防攻击,还是内部治理防泄密,都必须依赖分层设计的多重防御措施交互实现立体化、深层次的防御能力。应对瞬息万变的攻击特征,必须具备第一时间感知威胁发生的能力。所以,无论是威胁情报,还是大数据分析,这些技术在不同业态的甲方企业内都会有持续的生命力和价值点。综上,虽然业态不同,但核心思想还是相通的。

另外,作者赵老师在书中提到,传统企业迫于提高生产力、提高效率的压力,业态向互联网转化的速度会越来越快。所以,互联网企业在线上业务安全防御方面的经验,领先传统企业十年,此言不虚。安全的本质始终没有变,就看在不同环境下怎么玩的踏实,怎么玩出精彩。

与君共勉。

业务安全冷知识

前言

年前突然想写一篇简单易读的文章,讲一点可能会被忽略的业务安全问题,这些问题都算不上是漏洞,但可以对公司造成一定的影响,所以我这里称他们为冷知识,当中会涉及一些竞品分析的点,部分内容对中小型互联网企业都通用。有问题可与我联系wechat:atiger77

序号

  1. 前端提示内容过多;
  2. 用户ID自增隐患;
  3. 域名到期时间;
  4. 短信接口任意调用;

前端提示内容过多

所谓提示内容过多,一般常见于登录重置密码等页面。以登录页面举例,当输入的用户名和密码不正确时,返回的内容过于详细,常见的有: a.你输入的用户名不存在 b.密码必须大于等于6位 c.你输入的密码不正确 等等内容。

排除逻辑漏洞的问题,当前端返回给攻击者越多的信息,对于攻击者而言也缩短了攻击者的成本,还是拿上面的情况来说,第一种,攻击者根据提示可以测试出用户覆盖率,第二种当登录处没有验证码机制的时候,对攻击者字段选择上能节省大量时间。

  • 造成原因:开发安全意识薄弱
  • 解决方法:去除不需要的回显内容

用户ID自增隐患

国内互联网情况就是看到别人的产品不错马上就拿过来抄,除了少数一些以技术为核心驱动的公司,其他的都可以在短期内搞一个看着一样的产品出来,那么这个安全冷知识在竞品分析中可以获取一定成果。

当公司业务线多起来后,必然要上用户中心集中管理用户,一般的设计逻辑都是单表存一千万的用户并且UID自增,那么这个风险点也会随之而来。

设想一下这个情况,你的公司有一家“孪生兄弟”,你又想知道他们的运营情况,那么可以尝试这样做,今天的8点注册一个号,抓包记录UID,在明天的8点再注册一个号也记录下UID,一直重复在同一时间点注册用户并记录UID,将后一天的UID减去前一天的UID即可得出一天的注册情况,当你产品运营数据被竞品所得到的时候,是不是很可怕呢。

  • 造成原因:UID顺序自增,规律性太容易被发现
  • 解决方法:混淆UID生成规则

域名到期时间

公司域名管理其实是算在运维部下的,为什么这里要说因为一直会看到新闻说某某公司因为域名到期忘记续费,导致域名被抢注的情况。

简单一提,需要定期的查看域名到期情况,对快到期的域名做续费处理,对于公司而言,买域名的钱和买白菜一样。所以,在域名快到期的时候尽快解决把。

  • 造成原因:到期域名未即时续费
  • 解决方法:记录域名到期时间

短信接口任意调用

这个问题也很普遍,短信接口的应用场景很多,用户注册、忘记密码、重置密码等等。之前也看到新闻说一家创业公司短信接口被恶意调用,无缘无故损失了一大笔钱。

往往公司发现这个异常都是通过周的数据统计或者是月的数据统计,那么这个时候已经无法挽回之前的损失了。

那么防范的措施也不复杂,增加验证码机制,设置短信发送上限,接口请求参数GET->POST等等。

  • 造成原因:没有校验过程
  • 解决方法:风控措施

总结

暂时就想到这么多,以后想到我还要继续添加进去,有问题可以和我联系。