网络安全那些事

DOM-XSS

用一句话来总结所有DOM XSS的场景，就是：不可控的危险数据，未经过滤被传入存在缺陷的JavaScript代码处理，最终触发DOM XSS漏洞。

未知攻焉知防——XXE漏洞攻防

无论是WEB程序，还是PC程序，只要处理用户可控的XML都可能存在危害极大的XXE漏洞，开发人员在处理XML时需谨慎，在用户可控的XML数据里禁止引用外部实体。

WAF之SQL注入防御思路分享

关键字防护

SQL注入最简单、粗暴但实用的方式就是检测一些关键字，通过把这些能造成影响的关键字加入黑名单，可以阻断大部分的利用代码。这类关键字主要包含几种：

SQL语句的关键保留字，如select from，union select，drop table，into outfile等。

MySQL等DBMS的内建函数，如version(),load_file()，sleep()，benchmark()等

MySQL等DBMS内建变量，如@@version等。

MySQL所识别的内联注释，如/!union/ /!select/或/!50000union/等

真假条件防护

上述的关键字方法能过滤掉很多的利用代码，但还不全。SQL注入技术中有一种是通过利用注入条件的真假的方式来获取相关信息的，例如CGI：http://host/SQLi.php?id=1对应的SQL语句为select * from t_table where id=1。则通过注入:

http://host/SQLi.php?id=1 or 1=1   => select* from t_table where id=1 or 1=1

http://host/SQLi.php?id=1 and 1=2  =>select *from t_table where id=1 and 1=2

通过判断真假来获取MySQL的相关信息。对于这种方式如果通过简单的添加关键字会造成误报而影响业务的情况。这种情况下我们需要分析此类型的应用，例如：

op a = b

- op可以是and，or，<，>=，||，&&等

- 分隔符可以是空格，/**/注释等

- a与b可以是数字，字符串，表名，函数，sql语句结果等等

通过穷举此类应用方式来阻断相关的利用

绕过防护

URL编码

浏览器中输入URL是会由浏览器进行一次URL编码，而攻击可能会通过多次编码来对WAF进行绕过，例如：

Id.php?id=1%2520union//select 解码后实际为Id.php?id=1 union//select

如果只经过一次解码，则变成Id.php?id=1%20union/**/select

可能绕过正则表达式的检测

通过循环多次URL解码解决此类问题

特殊字符

%00如果直接URL解码，结果是C语言中的NULL字符。如果WAF使用string等数据结构来存储用户的请求，则解码之后会截断字符串，造成后面的内容不经过检测。例如

Id.php?id=1%20union/**/select

解码后可能变成：

Id.php?id=1[NULL]%20union/**/select

后面的%20union/**/select就躲过了WAF的检查，从而绕过WAF。解决方式：

1、对% 00进行特殊处理

2、不要使用string等存储用户的请求内容

%a0是不换行空格，用于在字处理程序中标示禁止自动换行。使用正则表达式的\s无法匹配到这个字符，但在mysql中%a0与普通的空格一样，可以当成分隔符来使用。即对于Mysql来说，如下请求经过URL解码之后是一样的

Id.php?id=1%20union/**/select

Id.php?id=1//union//select

Id.php?id=1%a0union/**/select

对于这种字符，可以进行特殊处理后再进行匹配

%0b是垂直制表符，%09是水平制表符。在正则表达式中，\s与\t均可匹配%09水平制表符，但匹配不了% 0b（%和0b之间没有空格，编辑需要）垂直制表符，需要使用\v匹配。如果正则表达式中，mysql的分隔符没有考虑到这种情况，也存在绕过的风险

半个中文字符。RE2等正则引擎默认使用UTF8编码，UTF8编码是3-4字符的编码，如果出现%e4等半个中文，即1个字符的时候，UTF8解码不出，用正则表达式的任意匹配符（.）是匹配不出来的。针对这种字符，可以考虑特殊处理或者变更引擎的编码。

畸形HTTP请求

当向Web服务器发送畸形的，非RFC2616标准的HTTP请求时，Web服务器出于兼容的目的，会尽可能解析畸形HTTP请求。而如果Web服务器的兼容方式与WAF不一致，则可能会出现绕过的情况。例如

GET id.php?id=1%20union/**/select

这个请求没有协议字段，没有Host字段。但apache对这个请求的处理，默认会设置协议为HTTP/0.9，Host则默认使用Apache默认的servername

在这种情况下，可以选择：

1、尽可能与Web服务器保持一致

2、拒绝非标准的HTTP请求（在后端防护的Web服务器有多种类型时，如apache，nginx，lighthttpd等，由于每种web服务器的兼容性不一致，所以要实现1的WAF尽可能与Web服务器保持一致存在一定的困难）

主流WAF架构分析与探索

方案A：本机服务器模块模式

通过在Apache，IIS等Web服务器内嵌实现检测引擎，所有请求的出入流量均先经过检测引擎的检测，如果请求无问题则调用CGI处理业务逻辑，如果请求发现攻击特征，再根据配置进行相应的动作。以此对运行于Web服务器上的网站进行安全防护。著名的安全开源项目ModSecurity及naxsi防火墙就是此种模式。

优点：

1、 网络结构简单，只需要部署Web服务器的安全模块

挑战：

1、 维护困难。当有大规模的服务器集群时，任何更新都涉及到多台服务器。

2、 需要部署操作，在面临大规模部署时成本较高。

3、 无集中化的数据中心。针对安全事件的分析往往需要有集中式的数据汇总，而此种模式下用户请求数据分散在各个Web服务器上。

方案B：反向代理模式

使用这种模式的方案需要修改DNS，让域名解析到反向代理服务器。当用户向某个域名发起请求时，请求会先经过反向代理进行检测，检测无问题之后再转发给后端的Web服务器。这种模式下，反向代理除了能提供Web安全防护之外，还能充当抗DDoS攻击，内容加速（CDN）等功能。云安全厂商CloudFlare采用这种模式。

优点：

1、 集中式的流量出入口。可以针对性地进行大数据分析。

2、 部署方便。可多地部署，附带提供CDN功能。

挑战：

1、 动态的额外增加一层。会带来用户请求的网络开销等。

2、 站点和后端Web服务器较多的话，转发规则等配置较复杂。

3、 流量都被捕捉，涉及到敏感数据保护问题，可能无法被接受。

方案C：硬件防护设备

这种模式下，硬件防护设备串在网络链路中，所有的流量经过核心交换机引流到防护设备中，在防护设备中对请求进行检测，合法的请求会把流量发送给Web服务器。当发现攻击行为时，会阻断该请求，后端Web服务器无感知到任何请求。防护设备厂商如imperva等使用这种模式。

优点：

1、 对后端完全透明。

挑战：

1、 部署需改变网络架构，额外的硬件采购成本。

2、 如Web服务器分布在多个IDC，需在多个IDC进行部署。

3、 流量一直在增加，需考虑大流量处理问题。以及流量自然增长后的升级维护成本。

4、 规则依赖于厂商，无法定制化，不够灵活。

方案D：服务器模块+检测云模式

这种模式其实是方案A的增强版，也会在Web服务器上实现安全模块。不同点在于，安全模块的逻辑非常简单，只是充当桥梁的作用。检测云则承担着所有的检测发现任务。当安全模块接收到用户的请求时，会通过UDP或者TCP的方式，把用户请求的HTTP文本封装后，发送到检测云进行检测。当检测无问题时，告知安全模块把请求交给CGI处理。当请求中检测到攻击特征时，则检测云会告知安全模块阻断请求。这样所有的逻辑、策略都在检测云端。

我们之所以选择这个改进方案来实现防护系统，主要是出于以下几个方面的考虑：

1、 维护问题

假如使用A方案，当面临更新时，无法得到及时的响应。同时，由于安全逻辑是嵌入到Web服务器中的，任何变更都存在影响业务的风险，这是不能容忍的。

2、 网络架构

如果使用方案B，则需要调动大量的流量，同时需要提供一个超大规模的统一接入集群。而为了用户就近访问提高访问速度，接入集群还需要在全国各地均有部署，对于安全团队来说，成本和维护难度难以想象。

使用该方案时，需要考虑如下几个主要的挑战：

1、 网络延时

采用把检测逻辑均放在检测云的方式，相对于A来说，会增加一定的网络开销。不过，如果检测云放在内网里，这个问题就不大，99%的情况下，同城内网发送和接收一个UDP包只需要1ms。

2、 性能问题：

由于是把全量流量均交给集中的检测云进行检测，大规模的请求可能会带来检测云性能的问题。这样在实现的时候就需要设计一个好的后端架构，必须充分考虑到负载均衡，流量调度等问题。

3、 部署问题：

该方案依然需要业务进行1次部署，可能会涉及到重编译web服务器等工作量，有一定的成本。并且当涉及到数千个域名时，问题变的更为复杂。可能需要区分出高危业务来对部署有一个前后顺序，并适时的通过一些事件来驱动部署。

关于代码审计的方法主要有两个大方向：（1）危险函数向上追踪输入；（2）追踪用户输入是否进入危险函数；这里的危险函数关于危险函数主要包括代码执行相关：eval、assert，文件包含：include、require等，命令执行：system、exec等，写文件：fwrite、file_put_contents等；

案例一：用户输入数据过滤逻辑不当

案例二：二次注入

案例三：程序升级新增逻辑导致的漏洞

案例四：漏洞修补不完善

1、一切输入都是有害的；

后台程序的用户输入相比前台主要增加了后台表单的数据，此外有些后台支持上传文件(如dz1.5的自定义sql)，上传文件的内容也属于输入；这些输入都属于用户范围。一定要做严格的控制和过滤。

2、安全意识；

其实很多漏洞的产生并不是技术问题导致的，而是我们缺乏安全意识，不重视安全而酿成的惨剧。尤其是第三个和第四个，完全不应该发生；需要对开发人员做安全宣导和基本的安全培训。

3、漏洞Review；

（1）开发人员收到漏洞后要对漏洞产生的原因做总结，并Review代码中是否有类似的问题。有些时候开发人员仅仅是修补了安全人员或白帽子提供的漏洞点，另外一处代码有类似的问题没修补继续爆出漏洞，无穷无尽。这样做还会带来更大的隐患，黑客是非常乐意并擅长总结反思的，每一个补丁其实也是给黑客拓展了思路，如果修补不完全后果很严重。

（2）开发人员修补完成后安全人员需要进行测试确认，上述的案例四就是鲜明的例子。有条件的情况下安全人员应该整理一些常见漏洞修复指引，这样也可以提高工作效率。

国内一些厂商也开始研发自己Android App自动化审计系统，其中最早的对外发布的腾讯金刚审计系统算是国内这类产品的鼻祖之一，其早期版本在功能上实现了Android App自动化静态分析与简单的动态分析，审计点包括：明文保存敏感信息，文件权限问题，日志信息泄露，组件权限问题，明文传输，拒绝服务等。



权限滥用漏洞一般归类于逻辑问题，是指服务端功能开放过多或权限限制不严格，导致攻击者可以通过直接或间接调用的方式达到攻击效果。

安全产品的自我修养

架构设计与定位

严格遵守研发流程

投入专业运维团队

数据运营与响应

产品化

策略运营

软件漏洞分析技巧分享

技巧一：快速定位JS代码调用的IE类成员函数

技巧二：通过页堆快速定位堆漏洞代码

技巧三：基于堆分配记录定位整数溢出漏洞代码

技巧四：基于条件记录断点的漏洞分析技巧

技巧五：基于JS日志的漏洞分析技巧

技巧六：通过虚拟机快照来固定堆地址

技巧七：监控堆分配释放动作来分析UAF、double free漏洞

技巧八：基于污点追踪的分析方法

独立+怀疑+渴望+打破+手痒

REFERENCE

1. 驱散前端安全梦魇——DOMXSS典型场景分析与修复指南

2. [腾讯安全应急响应中心] 基于QtWebKit的DOM XSS检测技术

3. 未知攻焉知防——XXE漏洞攻防

4. TSRC挑战赛：WAF之SQL注入防御思路分享

5. 主流WAF架构分析与探索

6. WEB代码审计与渗透测试

7. 315晚会报道的无人机是怎么被劫持的？

8. 软件漏洞分析技巧分享

9. 傅盛：深度学习是什么？