本文详细介绍了Web安全的各种攻击手段，包括XSS、CSRF、SQL注入、命令行注入和DDoS攻击等，分析了它们的工作原理和危害，并提供了相应的预防措施。对于XSS，强调了非持久型和持久型的区别，以及如何通过转义和验证防止攻击。CSRF部分解释了其原理和防范方法，如使用token。SQL注入部分讨论了注入的原理和防御，建议使用参数化查询。最后，探讨了DDoS攻击的类型和防御策略，包括网络层和应用层的应对措施。文章提醒开发者时刻注意安全，避免潜在的安全风险。
Web 安全的对于 Web 从业人员来说是一个非常重要的课题，所以在这里总结一下 Web 相关的安全攻防知识，希望以后不要再踩雷，也希望对看到这篇文章的同学有所帮助。今天这边文章主要的内容就是分析几种常见的攻击的类型以及防御的方法。
也许你对所有的安全问题都有一定的认识，但最主要的还是在编码设计的过程中时刻绷紧安全那根弦，需要反复推敲每个实现细节，安全无小事。 本文代码 Demo 都是基于 Node.js 讲解，其他服务端语言同样可以参考。
XSS
首先说下最常见的 XSS 漏洞，XSS (Cross Site Script)，跨站脚本攻击，因为缩写和 CSS (Cascading Style Sheets) 重叠，所以只能叫 XSS。
XSS 的原理是恶意攻击者往 Web 页面里插入恶意可执行网页脚本代码，当用户浏览该页之时，嵌入其中 Web 里面的脚本代码会被执行，从而可以达到攻击者盗取用户信息或其他侵犯用户安全隐私的目的。XSS 的攻击方式千变万化，但还是可以大致细分为几种类型。
非持久型 XSS
非持久型 XSS 漏洞，也叫反射型 XSS 漏洞，一般是通过给别人发送带有恶意脚本代码参数的 URL，当 URL 地址被打开时，特有的恶意代码参数被 HTML 解析、执行。
举一个例子，比如你的 Web 页面中包含有以下代码：
Select your language:
<select>
<script> document.write(''
+ '<option value=1>'
+ location.href.substring(location.href.indexOf('default=') + 8)
+ '</option>'
);
document.write('<option value=2>English</option>'); </script>
</select>
攻击者可以直接通过 URL (类似：xx.com/xx?default=…) 注入可执行的脚本代码。
非持久型 XSS 漏洞攻击有以下几点特征：
-
即时性，不经过服务器存储，直接通过 HTTP 的 GET 和 POST 请求就能完成一次攻击，拿到用户隐私数据。
-
攻击者需要诱骗点击
-
反馈率低，所以较难发现和响应修复
-
盗取用户敏感保密信息
为了防止出现非持久型 XSS 漏洞，需要确保这么几件事情：
-
Web 页面渲染的所有内容或者渲染的数据都必须来自于服务端。
-
尽量不要从 URL，
document.referrer，document.forms等这种 DOM API 中获取数据直接渲染。 -
尽量不要使用
eval,new Function()，document.write()，document.writeln()，window.setInterval()，window.setTimeout()，innerHTML，document.creteElement()等可执行字符串的方法。 -
如果做不到以上几点，也必须对涉及 DOM 渲染的方法传入的字符串参数做 escape 转义。
-
前端渲染的时候对任何的字段都需要做 escape 转义编码。
escape 转义的目的是将一些构成 HTML 标签的元素转义，比如
<，>，空格等，转义成<，>， 等显示转义字符。有很多开源的工具可以协助我们做 escape 转义。
持久型 XSS
持久型 XSS 漏洞，也被称为存储型 XSS 漏洞，一般存在于 Form 表单提交等交互功能，如发帖留言，提交文本信息等，黑客利用的 XSS 漏洞，将内容经正常功能提交进入数据库持久保存，当前端页面获得后端从数据库中读出的注入代码时，恰好将其渲染执行。
主要注入页面方式和非持久型 XSS 漏洞类似，只不过持久型的不是来源于 URL，refferer，forms 等，而是来源于后端从数据库中读出来的数据。持久型 XSS 攻击不需要诱骗点击，黑客只需要在提交表单的地方完成注入即可，但是这种 XSS 攻击的成本相对还是很高。攻击成功需要同时满足以下几个条件：
-
POST 请求提交表单后端没做转义直接入库。
-
后端从数据库中取出数据没做转义直接输出给前端。
-
前端拿到后端数据没做转义直接渲染成 DOM。
持久型 XSS 有以下几个特点：
-
持久性，植入在数据库中
-
危害面广，甚至可以让用户机器变成 DDoS 攻击的肉鸡。
-
盗取用户敏感私密信息
为了防止持久型 XSS 漏洞，需要前后端共同努力：
-
后端在入库前应该选择不相信任何前端数据，将所有的字段统一进行转义处理。
-
后端在输出给前端数据统一进行转义处理。
-
前端在渲染页面 DOM 的时候应该选择不相信任何后端数据，任何字段都需要做转义处理。
基于字符集的 XSS
其实现在很多的浏览器以及各种开源的库都专门针对了 XSS 进行转义处理，尽量默认抵御绝大多数 XSS 攻击，但是还是有很多方式可以绕过转义规则，让人防不胜防。比如「基于字符集的 XSS 攻击」就是绕过这些转义处理的一种攻击方式，比如有些 Web 页面字符集不固定，用户输入非期望字符集的字符，有时会绕过转义过滤规则。
以基于 utf-7 的 XSS 为例 utf-7 是可以将所有的 unicode 通过 7bit 来表示的一种字符集 (但现在已经从 Unicode 规格中移除)。 这个字符集为了通过 7bit 来表示所有的文字, 除去数字和一部分的符号,其它的部分将都以 base64 编码为基础的方式呈现。
<script>alert("xss")</script>
可以被解释为：
+ADw-script+AD4-alert(+ACI-xss+ACI-)+ADw-/script+AD4-
可以形成「基于字符集的 XSS 攻击」的原因是由于浏览器在 meta 没有指定 charset 的时候有自动识别编码的机制，所以这类攻击通常就是发生在没有指定或者没来得及指定 meta 标签的 charset 的情况下。
所以我们有什么办法避免这种 XSS 呢？
-
记住指定
<meta charset="utf-8"> -
XML 中不仅要指定字符集为 utf-8，而且标签要闭合
-
牛文推荐：drops.wooyun.org/papers/1327 （这个讲的很详细）
基于 Flash 的跨站 XSS
基于 Flash 的跨站 XSS 也是属于反射型 XSS 的一种，虽然现在开发 ActionScript 的产品线几乎没有了，但还是提一句吧，AS 脚本可以接受用户输入并操作 cookie，攻击者可以配合其他 XSS（持久型或者非持久型）方法将恶意 swf 文件嵌入页面中。主要是因为 AS 有时候需要和 JS 传参交互，攻击者会通过恶意的 XSS 注入篡改参数，窃取并操作cookie。
避免方法：
-
严格管理 cookie 的读写权限
-
对 Flash 能接受用户输入的参数进行过滤 escape 转义处理
未经验证的跳转 XSS
有一些场景是后端需要对一个传进来的待跳转的 URL 参数进行一个 302 跳转，可能其中会带有一些用户的敏感（cookie）信息。如果服务器端做302 跳转，跳转的地址来自用户的输入ÿ
最低0.47元/天 解锁文章
扫一扫
403
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
