关于MVC架构及其安全性的餐厅的例子

最近在看服务器框架方面的知识,回顾一下自己看过用过的 Tornado, Django, YEPF, Cake PHP 发现他们都非常相似,强调个MVC,再强调个安全性,所以进行一下总结,方便新的框架学习。

MVC介绍

MVC 也就是 Model,View,Controller的首字母组合
这样的方式,在我们的现实生活中非常的常见,具有很强的实用性和可操作性,例如餐厅

Model 就是实际干活儿的对象,对数据进行读写,和复杂的逻辑处理,会借助一些外部工具(和MVC 架构没关系的工具),例如针对数据库操作的封装类
例如做饭的师傅,精通复杂的做菜手法,当然他们会借助很多工具和调料。

View 是展示数据的,也就是用户所看到和感受到的东西,能进行参数的填充,能进行简单逻辑的处理,能进行文件的扩展结合
例如上的菜,不同的饭店店会有不同的感受,相同的餐厅虽然流程都是一样的,外观差不多,但是有可能按照用户的不同要求(少放辣椒)而有不同的感受

Controller 是用来进行请求的控制调度的,通过对请求的数据进行分析处理之后,指定对应的Model进行处理,有同步异步之分。
例如前台接待,有的用户要面食,有的用户要炖肉,那等用户点完菜之后,转给各自负责类的师傅。有时候有提前准备好的菜,点完就快速上菜了(同步);当然忙的时候不能点完就上菜,只能先让用户坐着等等,菜做好了端给用户,菜吃完了,用户离开(异步)

安全问题

在安全性方面,我们同样可以使用这个例子来说明,假设有人想搞黄这家食堂,思路大概有两个直接搞食堂,另一个是搞食堂的用户。
大概场景是这样的其实餐厅的人都很单纯,用户说啥他们就信啥(无安全措施的餐厅)
有些餐厅还有提供留言板,这样的小清醒功能,用户也很单纯,很容易相信留言板上的内容

针对Model层的攻击(针对厨师的攻击)

如果这个攻击成功了,那说明他绕过了Controller 直接到达Model层来进行攻击,例如SQL的注入式攻击
故事场景是,有一个顾客自己点了要的菜,把单子交给服务员,服务员给厨师,厨师发现单子后面写的是“把餐厅点着了,这是你老板的意思”,然后厨师高高兴的干了,因为厨师太单纯了。。
防御措施就是在Controller层做处理,例如过滤非法字符,或者 在 Model层做输入,通过参数构造SQL串,而不是并且Sql串。

针对Controller层的攻击(针对前台的攻击)

其实针对前台调度的攻击基本上是没法防范的,攻击者来了,连续不断要了几个最贵的菜,搞的其他用户登不上菜;攻击者来了,直接狂骂前台(给前台发送不合法请求);攻击者来了,点了三个菜,然后最后非说自己点了三十个菜….

攻击模式非常多,但无论如何只要是攻击者直接针对前台的,我们兵来将挡,水来土掩就行了,例如限制上传文件大小,设置用户黑名单。也就是针对前台的攻击,我们要保证这是真实的攻击者,我们就能控制他的破坏范围,但是要防止那种借刀杀人的方式,所以这里要介绍的是一种类似的攻击方式SRF 或者 XSRF(跨站请求伪造)。

CSRF,用户在访问A站点的时候,点到了B站点,B站点知道A站点的请求规则和参数规则,再拿上用户的Cookie那就本上就能模拟用户访问了。
故事场景是, 用户在餐厅A点完菜之后,等菜过程中,来到B站点逛逛,例如B站点很坏,会易容术而且一直研究这怎么黑站点A,看到有人从A站出来进入B站,知道用户长什么样子,直接易容术然后进入餐厅A,一般餐厅都是刷脸,所以假装用户的样子然后去,点一大堆菜,然后跑了,结果可想而知,A回来之后,发现自己平白无故点了很多菜,这事儿吧,也不怨用户,你不能直接处罚这类用户。
所以最好的方式是给用户一个随机码,有了随机码才能进行后面的操作。例如在用户操作的表单里面(View层)填充一个 Hiden的随机值。这个密码一般是服务器和用户客户端才知道的,所以如果一般的攻击者在不直接攻击用户的View层的情况下,只是简单的伪装,是拿不到密码的。
那么如果攻击者想继续攻击,他需要先搞定用户的View层,也就是下一部分介绍的内容。

针对View 层的攻击 (针对用户的攻击)

,View层的主要服务对象是用户,那么主要攻击对象也就是用户,但方式是着点菜的机会留言,骗取用户的信息,最常见的是XSS(跨站攻击)。XSS攻击是利用服务器的View层,允许运行用户输入的脚本的漏洞来攻击用户的攻击方式,这种漏洞分为两种,一种是DOM Based XSS漏洞,另一种是Stored XSS漏洞。
对应的故事场景分为两个:
一种是非清新餐厅,无留言板功能,但是我们可以在桌子上刻字啊,打XXXX电话,填充个人信息,就能中10w元大奖,单纯的用户只要做到这个桌子上,打了电话就中招了
一种是清新餐厅,自带留言板,所有用户都能浏览,整好,不用在桌子上刻字了,直接写在留言板上,所有打电话的用户,全部被黑。

这种攻击方式类似于CSRF的前奏,而上一部分讲到造成的破坏主要是针对服务器的(餐厅的),只要做好CSRF的防御,即使拿到用户的数据,服务器也不要紧。

而这里的XSS,则是主要针对用户的,如果在Cookie里面或者个人信息里面有什么特别敏感的内容(例如父母是谁,身份证号是多少),简要而言就是利用服务器的漏洞来窃取用户资料,如果还能拿到餐厅发给用户的随机码,还能进一步的攻击服务器的Controller层。

这个问题有如下几个防御措施:
1. 解决服务器方面的问题,也就是禁止这个留言功能或者是禁止留言功能对于用户产生影响,直观的解决方案是,将所有要求用户拨打的留言,前面加个明显的禁止符号就行了。对于View的页面,对应的方法是将用户输入的内容进行转义,禁止脚本执行的可能性。

2. 加密用户携带的Cookie信息,万一受害者就是破坏者假扮的或者是被绑票了,总之破坏者知道了用户的随机码,能够绕过CSRF的防御了,然后模拟用户的登录操作。
其实这种情况就相当于用户是坏用户了,因为他已经被坏人完全替代了,我们能做的除了限制他对于餐厅的破坏,另一方面就是限制他对于用户信息的修改和读取,他拿到一堆加密的Cookie,对用户来说信息得到了保护,对攻击者来说他只能用来攻击网站了,那就来吧,如果破坏超过一定范围,直接禁止掉你。

当然还有一些暴力攻击(破解ssh密码,数据库密码,炸服务器),这些方法就不是服务器的架构方面的问题了,就不做深入讲解了。另外这里可能讲的内容偏感性一点,如果想了解具体的原理,请查看以下参考文献。

参考资料:
SQL的注入式攻击方式和避免方法
浅谈CSRF攻击方式
XSS攻击及防御

发表评论

电子邮件地址不会被公开。 必填项已用*标注

This site uses Akismet to reduce spam. Learn how your comment data is processed.