博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
[深入学习Web安全](2)安全杂谈
阅读量:6908 次
发布时间:2019-06-27

本文共 3415 字,大约阅读时间需要 11 分钟。

hot3.png

作者:万年死宅
首发:i春秋社区
注明:转载请务必注明i春秋社区(bbs.ichunqiu.com)
0x00 目录
目录
0x01 安全本质
0x02 信任域与信任边界
0x03 如何判断安全问题
0x04 道哥的白帽子兵法
0x01 安全本质
在真正进入Web安全的学习中之前,我们最好来了解一些安全方面的知识。首先,我们来看安全的本质。
根据道哥在《白帽子讲Web安全》中所说:“安全问题的本质是信任的问题”,我们举个例子:
有一天,蛋总去上班,其他人,比如“七百斤的猴子”,认识蛋总,所以,认为蛋总不是ISIS的恐怖分子,不会炸掉i春秋的大楼,所以就允许蛋总进去了。(这就是“信任”,我们试想,如果在“信任”的前提下,蛋总去炸i春秋的大楼,成功率有多高?这就是安全问题。。。)
上面的例子说的是现实生活的例子,但是在真正的“战场”上也是如此,我们只所以认为一个东西、一个机制安全,仅仅是因为“信任”。也就是说,我们建立的一切针对与安全问题的解决方案都是基于信任的。
就像我们通过验证Refer来防御CSRF,就是因为我们相信JavaScript无法控制Refer,但是仅仅因为JavaScript无法控制Refer,我们就能完全放心了吗?虽然“JavaScript无法控制Refer”为我们的解决方案提供了“信任”这个解决方案的前提。
但是,我们试想,虽然“JavaScript无法控制Refer”,所以我们得到的Refer一定是正确的,但是在这个解决方案上出现问题呢?
我就来举两个我曾经遇到过的这种问题(虽然验证了Refer,但是依然可以CSRF):
1.百度的一个CSRF:
111319mjcws5j9hql4j5jp.png 
这个CSRF就是这种问题,他的验证机制存在问题,我们如果正常操作他什么也不返回,但是我们如果修改了Refer他就会返回Error。但是,即使他返回Error我们的操作也成功了,因为他的验证机制如下(自己YY的,比一定说就一定是这样):
111325m0g6hkkhan76e6gp.png 
我们可以看到,在最后的这里:

[Python] 纯文本查看 复制代码

1

2

3

if Retn!=True:

        print 'Attack!!!!!!'

SetName(1)

这就是造成这样一个CSRF的原因,是的,这个解决方案确实是可行的,但是在实现的过程中却出现了问题,例如,我们原本要求的Refer是,但是实际上是如下情况:
111624qge5g23icclil4vt.png 
我们可以看到,当我们的Refer为I am P0werZh4i的时候,确实,程序返回了Attack!!!!!也就是说他确实判断了这样一次攻击,但是我们可以看到此时VerficRefer函数返回了False,然后我们的if语句进行判断,确实也发现这是不能操作的,但是问题就在这里了:

[Python] 纯文本查看 复制代码

1

2

3

4

if Retn!=True:[/size][/font]

[font=微软雅黑][size=4]print 'Attack!!!!!!'[/size][/font]

[font=微软雅黑][size=4]SetName(1)[/size][/font]

[font=微软雅黑][size=4]

我们虽然if了,并且输出了Attack!!!!,但是,我们要知道,这个语句继续执行下去还是会修改我们的数据,我们也可以看到最后,name的值已经被改为了0。
也就是说针对与这个解决方案,我们就找到了一个bug。这样一个bug,是逻辑上的问题,程序员以为只要判断了就不会操作数据了,但是事实上却不是。
那么我们应该怎么修复这个问题呢?,当然是这样,只需要增加一行代码:
112236sfx944c48n4hc8z8.png 
在哪里呢?嘿嘿,既然你没看到我就在说一下吧:

[Python] 纯文本查看 复制代码

1

2

3

4

if Retn!=True:

        print 'Attack!!!!!!'

        exit()

SetName(1)

嘿嘿,其实就是判断到攻击之后,不止要返回数据,还要立即终止操作。不信我们来看:
112523ck631b5k22aqzizs.png 
可以看到,确实成功了,但是这个解觉方案都还可以突破,如下:
112659t4rez1agbprg2a3x.png 
可以看到,我们又攻击成功了,只要将Refer改为“”,就能成功的将name改为0,这次又是为什么呢?
这是因为我们判断Refer的方式有错,我们来看VerficRefer函数的定义:

[Python] 纯文本查看 复制代码

1

2

3

4

5

def VerficRefer(Refer):

    CorrectURL=''

if Refer.find(CorrectURL)!=-1:

        return True

        return False

可以看到,它是这样判断的:
if Refer.find(CorrectURL)!=-1
这样的话,我们只需要满足在我们的Refer中含有就能成功操作数据。。。
好了,不能再扯下去了,我们进入第二个主题“信任域与信任边界”。
0x02 信任域与信任边界
关于信任域与信任边界,其实就是两个概念,能够让你更好的思考安全问题。
我们还是通过举例子来解决问题,这次我们来说霸总吧,话说啊,有一天啊,这个霸总来到洗手间啊,突然发现了传说中的母厕所(你懂得23333333),于是霸总毫不犹豫的回家换了套女装,准备混进去看看,嘿嘿。
但是,根据安全原则,被分成了如下这样的区域:
_________________________________
|                                                           |
|                      非信任域                      |
|                (霸总所在区域)              |
|                   ___________                    |                    
|                  |                    |                    |
|                  |     信任域    |                    |
|                  |  (mu厕所)    |                    |  
|                  |___________|                    |
|                                                           |
|                                                           |
|_________________________________|
linux画图软件不好用,所以就画字符画了,233333333333333333
我们看到,mu厕所属于信任域是高级区域,霸总所在的非信任域属于低级区域。
根据安全原则来说,低级区域流向高级区域的流量应该经过过滤,去掉恶意的流量。
所以,我们可怜的霸总,就被“过滤了”
(你TM装也装好点嘛,MD带个把还想进去,哼~~哈哈哈哈哈哈哈)
而信任与与非信任域之间的界线就是信任边界,嘿嘿。
0x03 如何判断安全问题
我们怎么知道一个问题到底算不算漏洞呢?也就是说我们怎么知道一个问题是安全问题呢?
其实很简单,道哥曾提到过的“安全三要素”就能解决这种问题,嘿嘿,辣么,所谓的“安全三要素”是哪三要素呢?
  • 机密性(Confidentiality)
  • 完整性(Integrity)
  • 可用性(Availability)
就是这三“贱”客。。。。
只要一个问题威胁到这三要素,则算是一个漏洞,即安全问题。
例如:
  • SQL注射,可以提取用户数据,即破坏了机密性(Confidentiality)
  • 在例如DDOS,可以使目标服务器拒绝服务,即破坏了可用性(Availability)
  • 例如越权删除漏洞,可以随意删除其他用户信息,级破坏了用户数据的完整性(Integrity)
0x04 道哥的白帽子兵法
_>Secure By Default原则
1.白名单与黑名单
      这个我就举个很常见的例子,比如文件上传时,使用黑名单策略,不允许上传php的文件,则我们可以使用php4来绕过。
      而如果使用白名单,则只允许jpg,png等文件上传则不会出现此类问题。
2.最小权限原则
     意思是给予管理员和所有用户更少的权限,这样的话即使我们拿到shell,危害也不大。
_>Defense in Depth原则
     这个我们就简单说下吧,因为这个要理解会设计比较多的问题,我们就以“木桶原理”来举例,一个木桶能装多少水是取决与他最短的木板有多长而不是最长的木板有多长。这也就是说安全是一个整体。。。
_>数据与代码分离原则
     这个其实很清晰吧,例如防御SQL注射,防御XSS,就是利用这种原则,几乎所有的代码注入问题,都是这样防御。也就是说由于程序把数据当作代码执行而造成的问题,都该使用这个方案。
_>不可预测性原则
     防御CSRF就是利用的这个原则,防御CSRF的一种叫验证Token的方式就是使用的这种原则。
作者:万年死宅
首发:i春秋社区
注明:转载请务必注明i春秋社区(bbs.ichunqiu.com)

转载于:https://my.oschina.net/u/2308739/blog/724659

你可能感兴趣的文章
Linux下connect超时处理【总结】
查看>>
高性能数据库集群:读写分离
查看>>
Laravel 5.5 Blade::if 简介
查看>>
centos7搭建ELK Cluster集群日志分析平台(三):Kibana
查看>>
UITextField 监听内容变更解决方案
查看>>
详解jar命令打包生成双击即可运行的Java程序
查看>>
SAMBA 与ISCSI区别
查看>>
zabbix 历史数据清理及libdata1文件过大处理
查看>>
python常用内置函数zip()
查看>>
HTML5 学习手笔二:canvas API 绘制树形图案A
查看>>
python构建一个简单的备份脚本
查看>>
ftp命令的含义和应用
查看>>
python 开发GUI应用之Dabo
查看>>
rsync 安装和使用
查看>>
socket通信中select函数的使用和解释
查看>>
MySQL order by后对其他索引的干扰,导致优化器走错索引
查看>>
记《浪潮之巅》-第一版-11.硅谷的另一面
查看>>
CloudStack升级:4.2.1升至4.3.1
查看>>
云计算有助消除贫富差距有利于发展中国家
查看>>
设置:安全锁和壁纸
查看>>