我的安全世界观5up3rh3i@gmail.com

声明

谢绝一切直播转载！

本议题均为本人个人观点，与任何公司组织无关！

前言 “ 道行”论世界观是人们对整个世界的总的看法和根本观点 , 这也是我这里说的“道行”。

社会地位不同，观察问题的角度不同，形成不同的世界观。

研究方向不同，技术技能水平不同，形成不同的角度，这决定了人的“道行”深浅。

有思考才会有道“ 道行”深浅必定引起争论或口水！

争论和科普不一定能改变谁的“道行”，但是争论和科普后的思考，一定可以提升你的“道行”！

关于本议题提到的一些观点，欢迎来 PK

从漏洞说起 恶意竞争导致“漏洞”成为敏感词一个现象：一提某公司产品“漏洞”，必定引来大量口水。

一个现象：给竞争对手养的安全研究人员。自家的东西有没有漏洞无所谓，但是对手那必须得有！ ：）

一个现象：大家都有的那不算漏洞。更无耻的是：自己的产品有漏洞，也要拿别人的产品当挡箭牌！

圈内圈外争论不休内行看门道、外行看热闹

“ 圈内”专业人士由于“道行”不同，或者“立场”、具体的“思维误区”等问题，导致对漏洞得理解也不相同。

“ 圈外”某些“专家”，也要跟你论道一番！有意思的是，他会说你“没资格”、“自以为”！！

那些争论点 是 BUG 还是漏洞（）

到底是谁的漏洞 (x)

谁应该为漏洞负责 (x)

业务与安全 (x)

√

臭虫 VS 漏洞 BUG 与漏洞是一个交集2012 年 flashsky 在《互联网用户安全峰会》上从测试与安全测试角度得到这个结论。详见：：

http://v.youku.com/v_show/id_XMzY5MTE5MjQw.html

安全漏洞的本质“ 安全问题的本质是对权限与能力的突破或泛用，所有系统的安全问题都是可以归结为对权限与能力的突破

或泛用。”

－－－来源于《南京翰海源安全测试概论》

权限与漏洞 权限突破是安全漏洞评定一个核心指标这个也是“漏洞争论战”里常常辩论的焦点，除“道行”因素外，公司的立场及当时具体的“思维误区”可能影响到

个人的判断。

垂直权限与水平权限垂直权限：基于角色的访问控制（ Role-Based Access Control ）

水平权限：基于数据的访问控制。可以理解为对数据控制的“能力”

－－－来源于《白帽子讲 web 安全》

水平权限经常被忽视对”水平权限“理解不同这也是引起争论的主要原因。

功能与漏洞 程序的目的就是为了实现某些业务功能。 程序的实现可能“顺带”完成了“额外”的“功能”。 当这些功能（预期和非预期）影响到安全时候，

那就是漏洞。 “Bug 不一定是漏洞，只有影响安全的 Bug 才有可能成为漏洞”

－－－来源于 @瘦肉丁

我们可以理解为对“功能”实现的“能力”。“影响安全”的判定是关键。

一“切”都是天意 ...

两个看上去不是漏洞的漏洞，组合完成完美逆袭。

一些启示和思考 安全是一个整体！漏洞与漏洞是可以“组合变形”的。

漏洞与 BUG 也是可以“合体”的。

概念是死的，理解还得看“道行”、“立场”、“思维” 对漏洞的认知是变化发展的！按照“权限”或“功能”的角度去评估，你会发现很多现在不认为是漏洞问题，都可以归为漏洞。

历史已经印证了多次 ......

安全（漏洞）需要看场景（条件）

安全（漏洞）与场景（条件） 思考：安全问题的触发需要什么样的场景或条件？

思考：如果有这样那样的场景或条件下，可能出现什么样的安全问题？

如果 ......就 ...... if.....then......

安全终极奥义

安全是一个条件语句！！

－－－ by yuange

漏洞里条件语句

前面的两个思考代表了两个方向：顺：从条件推结果。

逆：从结果推条件。

这两个方向是和代码审计找漏洞是相通的。顺：从变量到函数。

逆：从函数到变量。

被忽视的变量（条件）。进入函数的非常量都为“变量”。

进入函数的变量可控条件下，就形成了漏洞。

漏洞里条件语句

变量与函数是一个相对概念也就是数函数可能是另外一个函数得变量！

变量 A---->函数 A---->函数 B （这个流程里函数 A 同时是函数 B 得变量）

函数可接受多个变量来源变量 A------------------------->函数 A

｜ -------->函数 B

变量 a------------------------->数据库 [ 变量的存储与提取 ]

函数 A作为函数 B 的变量属性时，函数 A 的变量来源路径经常被忽视或漏掉。

漏洞里条件语句

什么样的函数产生什么样的漏洞。

那么我们可以逆向思考：我需要一个什么样的漏洞（函数），需要一些什么样的条件（变量）？

变量 A-------------X-------------->函数 A

｜ -----②------>函数 B(eval函数 )

变量 a-----------①-------------->数据库 [ 变量的存储与提取 ]

（ X 代表变量不可控）

路径①： 在变量 a 可控制下传递给数据库操作，现成一个 SQL注射漏洞。

很多人走到这一步就比较满足了。而我们的目标是触发 eval函数（函数 B ），那么我们可以通过sql注射漏洞直接通过联合查询方式，构造输出函数 B 所需要的变量值，最终形成代码执行漏洞。

这种方式我称之为“二次漏洞”（ 2006 年）！

漏洞里条件语句

我们继续看个流程：变量 A-------------X-------------->函数 A

｜ -----②------>函数 B(eval函数 )

变量 a-----------X-------------->数据库 [ 变量的存储与提取 ]

（原来的路径①被修补后，变为不可控）

从代码层面我们看不出可控的变量传递到函数 B......

如果 ....

如果我们取得了数据库的控制权限呢？比如我们拥有一个“ phpmyadmin＋普通的 mysql 用户密码”！！

不要忘记了“安全是一个整体！”，不过目前基本很少有人承认这是一个“漏洞” ：）

防御里条件语句

实现“漏洞”的场景各种各样，路径也可以多条！也就是要考虑的条件就越多

MS-SDL流程提出了“威胁建模”通过定义各种场景来，来识别、判断威胁及风险，进而帮助确定防御措施。

“最短路径”防御思想：“进入函数前那刹那的防御才是王道”－－－摘于我的 blog （ 2010 年）

整体表现为：纵深防御体系变量 A------------------------|]|->函数 A

｜ -------|]|->函数 B

变量 a------------------------|]|->数据库 [ 变量的存储与提取 ]

打完收工！（约架请排队）

感谢本议题里提到的那些作者及组织！