一篇补齐你的Web安全知识死角(3)

网络层DDos防御

• 网络架构上做好优化，采用负载均衡分流。
• 添加抗DDos设备，流量清洗。
• 限制单ip请求频率。
• 防火墙等防护设置禁止icmp包等
• 认真检查网络设备和主机/服务器系统的日志。只要日志出现漏洞或是时间变更,那这台机器就可能遭到了攻击。
• 限制在防火墙外与网络文件共享。这样会给黑客截取系统文件的机会，主机的信息暴露给黑客，无疑是给了对方入侵的机会。
• 加钱堆机器

网络层的DDos攻击究其本质其实是无法防御的，我们能做得就是不断优化自身的网络架构，以及提升网络带宽。

应用层 DDoS

应用层 DDoS 攻击不是发生在网络层，是发生在 TCP 建立握手成功之后，应用程序处理请求的时候，现在很多常见的 DDoS 攻击都是应用层攻击。应用层攻击千变万化，目的就是在网络应用层耗尽你的带宽，下面列出集中典型的攻击类型。

• CC 攻击：CC 攻击的原理，就是针对消耗资源比较大的页面不断发起不正常的请求，导致资源耗尽。因此在发送 CC 攻击前，我们需要寻找加载比较慢，消耗资源比较多的网页，比如需要查询数据库的页面、读写硬盘文件的等。通过 CC 攻击，使用爬虫对某些加载需要消耗大量资源的页面发起 HTTP 请求。
• DNS Flood 攻击：采用的方法是向被攻击的服务器发送大量的域名解析请求，通常请求解析的域名是随机生成或者是网络世界上根本不存在的域名，被攻击的DNS 服务器在接收到域名解析请求的时候首先会在服务器上查找是否有对应的缓存，如果查找不到并且该域名无法直接由服务器解析的时候，DNS 服务器会向其上层 DNS 服务器递归查询域名信息。域名解析的过程给服务器带来了很大的负载，每秒钟域名解析请求超过一定的数量就会造成 DNS 服务器解析域名超时。
• HTTP 慢速连接攻击：针对 HTTP 协议，先建立起 HTTP 连接，设置一个较大的 Conetnt-Length，每次只发送很少的字节，让服务器一直以为 HTTP 头部没有传输完成，这样连接一多就很快会出现连接耗尽。

应用层DDos防御

• 判断User-Agent字段(不可靠，因为可以随意构造)
• 网页中镶嵌js代码(不可靠，因为爬虫也可携带浏览器引擎，或者执行js代码)
• 针对ip+cookie，限制访问频率(由于cookie可以更改，ip可以使用代理，或者肉鸡，也不可靠)
• 关闭apache最大连接数等，合理配置中间件，缓解ddos攻击。
• 页面中添加验证码，比如搜索数据库时。
• 编写代码时，尽量实现优化，并合理使用缓存技术，减少数据库的读取操作。

应用层的防御有时比网络层的更难，因为导致应用层被dos攻击的因素非常多，有时往往是因为程序员的失误，导致某个页面加载需要消耗大量资源，有时是因为中间件配置不当等等。而应用层DDos防御的核心就是区分人与机器(爬虫)，因为大量的请求不可能是人为的，肯定是机器构造的。因此如果能有效的区分人与爬虫行为，则可以很好地防御此攻击。

05.目录遍历漏洞

目录遍历漏洞成因：服务器端，接收请求中传来的文件名称，在服务器端拼凑成文件的绝对路径，并且用输出流下载。

防御措施

• 文件ID使用随机数命名
• 文件路径保存至数据库，用户提交文件对应ID下载文件。
• 下载文件之前做权限判断。
• 记录文件下载日志。

06.业务安全

在Web系统中，除了常规的如SQL，XSS，CSRF、Ddos等web漏洞外，更重要的是其业务上的安全。

账户信息安全

账户是一个系统的入口，关系到用户最直接的利益，因而账户的安全在业务安全中占及其重要的地位。账户体系分多个层次，每个环节的漏洞，都将给用户带来极大的损失。

业务数据安全

金额数据篡改：抓包修改金额等字段，例如在支付页面抓取请求中商品的金额字段，修改成任意数额的金额并提交，查看能否以修改后的金额数据完成业务流程。

商品数量篡改：抓包修改商品数量等字段，将请求中的商品数量修改成任意数额，如负数并提交，查看能否以修改后的数量完成业务流程。

业务流程安全

顺序执行缺陷

部分网站逻辑可能是先A过程后B过程然后C过程最后D过程。

用户控制着他们给应用程序发送的每一个请求，因此能够按照任何顺序进行访问。于是，用户就从B直接进入了D过程，就绕过了C。如果C是支付过程，那么用户就绕过了支付过程而买到了一件商品。如果C是验证过程，就会绕过验证直接进入网站程序了。

最后提交新密码时修改用户ID为其他ID

跳过验证步骤、找回方式，直接到设置新密码页面

业务接口安全

在短信、邮件调用业务或生成业务数据环节中(类：短信验证码，邮件验证码，订单生成，评论提交等)，对其业务环节进行调用(重放)测试。如果业务经过调用(重放)后被多次生成有效的业务或数据结果

07.编程规范

一切输入都是有害的!!!输出也不安全!

输入：传参，cookie、session、http header、数据库……

输出：异常信息、敏感信息、xss

08.总结

程序猿们能够管理好代码隐私，注意代码安全问题，比如不要将产品的含有敏感信息的代码放到第三方外部站点或者暴露给外部用户，尤其是前端代码，私钥类似的保密性的东西不要直接输出在代码里或者页面中。也许还有很多值得注意的点，但是归根结底还是绷住安全那根弦，对待每一行代码都要多多推敲。

开发时要提防用户产生的内容，要对用户输入的信息进行层层检测

要注意对用户的输出内容进行过滤(进行转义等)

重要的内容记得要加密传输(无论是利用https也好，自己加密也好)

get请求与post请求，要严格遵守规范，不要混用，不要将一些危险的提交使用jsonp完成。

对于URL上携带的信息，要谨慎使用。

心中时刻记着，自己的网站哪里可能有危险。

作者介绍

李伟山

江湖人称：山哥，85年生产，IT届的小学生。享米高级技术总监，曾经在华为、阿里巴巴任职。

座右铭：Fake it until you make it。

（编辑：ASP站长网）