聊聊应用系统的安全控制

​剧情是这么展开的,从发现微信通讯录多了个新好友(我老爹)小红点到老爹给我电话咨询他微信几十万的零钱为毛变成零余额,前后间隔不会超过三十分钟。所以今儿我们就用菜场卖菜的语言,来简单的谈谈应用系统主要的安全漏洞/控制。

为什么要做安全控制?

所谓安全控制,并不是说有无安全控制的概念。只是因为时代不断发展,软件系统的安全级别需要不断上升的一个过程。在过去,国内互联网刚刚起步,接触的人都少之又少,根本不需要过多的安全级别限制。后来随着互联网技术的不断发展和传播,人们对于计算机的认识程度越来越高,也有越来越多的不良分子投身于这一行业,才有了下面我们所有说的各种安全防范手段。

这个过程就好比二十年前,水果市场前翻了辆运送水果的集卡,根本没有人哄抢,众人拾柴帮司机归位了四散的水果兄弟,送到老板那一过称,哎呀妈呀!竟然多了十来斤!(很多人在帮忙的同时也许就忘了手上拎的是自己买的水果,一并给了司机)

现在车翻了,说不定四个轮子都让丫一哄而散,司机车拉起来还得找道路救援借四个备胎。

所以说,随着大环境的发展,软件系统的安全级别不得不被动的提升,以保护自身利益不受损害。毕竟,保险他也不赔不是。

聊聊应用系统的安全控制_第1张图片

从何说起?

前面我们也说了,安全级别的提升,一定是基于大环境的。也就是说,你去菜场买菜,要是菜场全是良心商人,根本不可能短斤少两,你其实根本就不需要留心眼带个电子秤什么的。有一天出现了一个黑心商贩,那么我们把它叫做攻击者,所以说我们今天要说的安全,一定都是从攻击方来谈起。我们所说的漏洞其实也容易理解,就我们的菜场理论来说,比如你是个盲人、是个弱智或者是个菜场新面孔,这些统统都可以称为安全漏洞。

有哪些攻击方式?

今天我们不谈多大也不谈多深。

第一心哥粉丝基数真的忒少,公众号本就是业余时间和大家一起分享人生的一副业,所以专注度肯定有限。

第二说白了心哥也就一个被吐槽连单例都写不好的行业小白,实在无脸装逼。

最后,最后,最后,重要的事情说三遍:心哥小学时,也就是QICQ刚创业时,邮箱里面躺着一大波(至少两百来个)密码键盘记录发来的五位数QQ账号密码啥的,二十多年前就是一个本可富可敌国的天才黑客,现在长成了一个屌丝码农,心哥实在无颜回江东。

今天,我们简单谈谈以下几个攻击方式/安全相关:

二次放号

密码加密

验证码

提权攻击

重放攻击

跨站脚本攻击

聊聊应用系统的安全控制_第2张图片

菜场好戏开场了

马上要开始准备晚餐,上午游戏打得手疼,所以腿不太方便走路了,只能让我那个八百度近视双耳失聪外加先天性小儿麻痹的室友前往了。走之前我丢给他他一张黑金VIP卡,菜场三折优惠。

二次放号

室友到了菜场,直奔羊肉铺要了三斤羊腿,一百二大洋。他把黑卡一亮君临天下,老板诺诺的收了36块了事。刚想走,身边的老头从柜台下给他递过来10块钱,眼神示意借卡一用。最后老头用他的卡一次买了20斤羊腿,净省560块。

这就是典型的变种二次放号事件,因为不记名或者记名信息的不同步,导致肉铺老板(系统)无法识别VIP卡(登录手机号)的具体所有者,从而导致只要是持卡人的人,都能享受屌炸天的折扣优惠。

这一情况理论上不属于安全攻击或是安全控制的范畴,他只能算是一种漏洞,在国内的运营商和各个系统间,这一现象是普遍现象。

就比如我老爹,换号了但是他根本不知道需要微信解绑手机号再重新绑定新手机号码,这样一来只要是几个月后之前的手机号注销,号码被运营商重新分配给新的号码所有者,然后这丫通过微信短信验证码登录。哐当!瞬间发现登进去的账号里竟然有几十万的零钱余额,炸不炸裂!?(当然微信没那么傻,肯定做了类似常用设备、安全问题等风控策略)

再反过来说,二次放号对于新号码拥有者,也同样有着各种不爽。比如说用新手机号注册各类用户时,发现其实这号码已经被绑定注册过了,更蛋疼的是也许绑定的应用压根就不允许短信找回密码。(当然,多数情况不会)

基于以上,二次放号实际上一种挺危险(傻逼)的事情,它存在巨大的安全风险,不管是对原号码持有者还是新号码拥有者。而这一切,都是运营商挖的坑!

最最关键的是,它不是没有解决策略,并且它的解决策略相当简单。只需要运营商开放客户手机号开户时间API,这样,第三方系统在登录/注册等功能环节,只需要拿手机号注册时间和系统用户注册时间比较一下:晚于系统注册时间的,肯定是二次放号用户;反之为正常用户。

然并卵,你觉得哪个运营商会鸟你?

聊聊应用系统的安全控制_第3张图片

密码加密

室友又买了一斤豌豆,突然发现有点尿急,给完钱把三斤羊腿一起放在老板那,跟老板打了声招呼说回头来拿就直奔粪坑而去。

结局很现实,一斤豌豆和三斤羊腿丢了。老板也不知道是谁拿走了,总之就是有人拿走了。室友和老板吵了许久,无果,只能自认倒霉。他们的争吵也不是没有结论,最后老板妥协的和他约法数章

要是室友下次再到老板这买菜需要寄存服务,老板给他提供口令服务,必须说对了和老板约定的口令,才能拿走东西

东西买的多,老板提供更安全的密码寄存服务,老板在事先准备的专用纸张写上室友说出的取菜码,把专用纸张给室友保存,必须纸张和口令都对了,老板才让他取走。

室友虽然有点脑残,但脑洞那也是无限巨大,又写了一条附加条款

寄东西的时候,老板也需要留个口令给他,免得认错人

室友的脑洞巨大那是后话,虽然这场景有些傻逼,但是他的思想确实有那么点道理。万一我认错人了,万一我又不记得我寄存了啥,那我不是还是有可能会搞错啊!

上面的这些场景,延伸到现代密码学和互联网系统,说的就是密码验证的演变过程。从最开始没有密码验证的方式,到简单的明文口令加密,再到密文加密(只验证客户),再到双向加密验证(客户/服务器双向验证),体现了密码强度和验证方式的变迁,这过程之中更重要的是,人为了一己私心,世风日下的悲凉。

验证码

后来,据说老板的寄存服务很火爆,大有垄断菜场的趋势。这一情况也给老板带来太多烦恼,里三层外三层全是来取菜的人,一看尼玛总共存在他这的也就2斤羊腿。

老板烦的要死,天天就被一群据说是取菜的人骚扰,每个人就来报个数,都说羊腿是自己的,但是说对口令的人硬是没有。老板看出来了,这群人都丫的投机倒把分子,粗暴的来用随机密码学挑战老板的底线。

那天以后,老板寄存台子前面多了一张纸和笔,纸上写着几个极难书写的古代文字。谁要想报口令拿东西前,必须先抄一遍那几个变态的中文。

老板的策略很有成效,第二天来投机倒把的人就没剩几个。本来就是碰碰运气的事情,太费劲的话,那些搞小聪明的大爷大妈明显就不是那么愿意了。

这就是应用系统或者现代密码学中间,经常使用的验证码机制:增加攻击者破解密码/试探系统的门槛和难度,从而屏蔽掉绝大部分嫌麻烦的攻击者。在系统逻辑中增加了验证码,使用机器自动破解的门槛大大提高,从而阻挡了绝大部分的攻击者。

提权攻击

有一天,老板觉得每个人都说不同的密码太麻烦,因为自己的智商早就已经欠费,完全记不住所有人的口令。他偷了个懒,给了所有人同样的口令,瞬间觉得自己的智商甩了隔壁老板好几条街。

结局还是很现实,直到有一天室友再次光顾了老板的菜摊,又丢了一斤豌豆和三斤羊腿,然后两人又大吵了一架。

很显然,有人的确在老板这里寄存了一些东西,但是这人再次用自己的口令从老板这把东西取走时,也顺走了室友的一斤豌豆和三斤羊腿。室友很生气,后果很严重,结果就是他当天用我的黑钻VIP卡把老板的菜一扫而光。

这样的场景,就是应用系统设计中很容易碰到的一个安全漏洞--权限设计漏洞。攻击者其实也是系统的用户,但是攻击者作为用户登录后,通过某些手段篡改发送数据(比方说把账号改成马云的),直接从系统查出了非自身的数据信息。

这就是所谓的提权攻击,避免的方法是在系统后端,始终需要对用户的身份和数据关联进行检查。

重放攻击

自从室友第二次在同一个老板这丢了三斤羊腿,老板再也没敢对所有客户使用同一口令。他春风满面,看着风生水起的寄存生意,嘴角露出装逼的笑。

结局很现实,当室友第三次丢了三斤羊腿时,老板这生意算是再也做不下去了。老板很是迷糊,明明所有客户都是不同口令了,明明加了屌炸天的中文签到验证码,为毛东西还是被别人拿走了?

第二天,老板十分谨慎,最终在菜摊台子角落发现了一只不属于自己的录音笔。原来丫通过录音笔录下来他和客户约定的口令密码,等到取货时放出来取走了室友的三斤羊腿。

室友的羊腿丢的很值,至少他又学会了一招做人的招式。现代应用系统中重放攻击很常见,他常常和中间人攻击并肩出现。比如你在商场连上了名为youpassword的wifi,你所有网络传输的数据都是通过这个wifi进行,攻击者很容易就拿到你的账号和密文密码,这个时候攻击者只需要重新使用你的账号和密码进行登录,分分钟转走你的账户余额。

一般可以通过结合时间戳和Token加密生成密文的方式,来避免密码重放攻击。

跨站脚本攻击

自从室友第三次丢了羊腿后,老板便宣布停止了寄存服务,可惜室友并没有即时获得这一消息。这也直接导致了他第四次把三斤羊腿弄丢在了菜市场。

这次的经历很精彩,可以入选本年度菜场最佳演员奖。

室友拿着三斤羊腿去老板那寄存时,发现老板换了人。他出于对于这个摊位的执着,想都没想就把羊腿摔在了老板怀里,回来的路上他死活想不起来和老板约定的口令密码,等到丢了羊腿才发现,丫老板根本就没有给他密码。

结局和现实,而且残酷。之前的老板不知所踪,摊位上还是前三次丢羊腿时的那个老板。室友一问,才知道老板刚刚去上了个大号,根本就不应该有人在摊位上。

很显然,有人冒充了老板,同时仿造了他的寄存服务,刚好有个智障过来,丢给假老板三斤羊腿。结局很显然,室友再次入坑,算算到今天他刚好丢了12斤羊腿,刚好够组合一个十二生肖。

这就是跨站脚本攻击常常发生的场景,攻击者通过服务器的漏洞(服务器没有对请求数据过滤,如伪装者通过请求参数以JS输出到页面,进行页面重定向到钓鱼网站),伪造成正规的服务提供商,诱骗用户进行数据交互,从而窃取用户数据。这一场景中,正是因为服务器端提供了给攻击者可以利用的漏洞,才导致有可乘之机让攻击者伪装成正经服务提供商,从而进行信息窃取。

屏蔽手段是过滤javascript等敏感字符等。当然现在主流前后端分离框架(如angular,backbone,vue),前端都采用异步的方式,从架构和交互本身已经基本杜绝了跨站攻击的可能。跨站攻击常出现在JSP、PHP、ASP等服务器动态变异语言场景居多。

写在最后

估计应该很难有人能用心看到最后吧,如果你认真看完了全文并且对我认可,记得给我留言互动转发,同时也推广给你的朋友们,现在的时间是周末凌晨1:30,号主很忙空闲时间不多,你们的支持才是我最大动力。

我的心愿是,世界和平!

- THE END -

聊聊应用系统的安全控制_第4张图片

你可能感兴趣的:(聊聊应用系统的安全控制)