网站安全
从从互联网发展开始，各种网络安全问题也就伴随而生。
近些年来有很多网站遭到攻击，如新浪微博遭XSS攻击，以CSDN为代表的多个网站泄露用户密码和个人信息。
特别是后者，因为影响人群广泛，部分受影响网站涉及用户实体资产和交易安全，一时成为舆论焦点。
那么新浪微博是如何被攻击的?CSDN的密码为何会泄露?如何防护网站免遭攻击，保护好用户的敏感信息呢?
常见的攻击与防御
XSS攻击，它和SQL注入攻击构成网站应用攻击最主要的两种手段，全球大约70%的Web应用攻击都来自XSS攻击和SQL注入攻击。此外，常用的Web应用还包括CSRF、Session劫持等手段。
XSS攻击
XSS攻击又称CSS,全称Cross Site Script (跨站脚本攻击)，其原理就是攻击者像有XSS漏洞的网站注入恶意HTML脚本，在用户浏览网页时，这段恶意的HTML 脚本会自动执行，从而达到攻击的目的。
常见的XSS攻击类型：
- 反射型，通过在请求地址上加入恶意的HTML代码
- dom型 ，通过一些API向网站注入恶意HTML
- 持久型，将恶意代码内容发给服务器，服务器没过滤就存储到数据库中了，下次再请求这个页面时就会从数据库中读取出恶意代码拼接到页面HTML上
1、反射型XSS攻击
攻击步骤：
1、攻击者构造出特殊的URL，其中包含恶意代码。
2、当用户打开带有恶意代码的URL时，网站服务端将恶意代码从URL中取出，拼接在HTML中返回浏览器，之后用户浏览器收到响应后解析执行混入其中的恶意代码。
3、恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户行为，调用目标网站接口执行攻击者指定的操作。
常见于通过 URL 传递参数的功能，如网站搜索、跳转等。由于需要用户主动打开恶意的 URL 才能生效，攻击者往往会结合多种手段诱导用户点击。
举个栗子：
新浪微博以前被攻击就是一种反射型XSS攻击。攻击者发布的微博中有一个含有恶意脚本的URL，用户点击该URL，脚本会自动关注攻击者的新浪微博ID，发布含有恶意脚本URL的微博，攻击就被扩散了。
现实中，攻击者可以采用XSS攻击，偷取用户Cookie、密码等重要数据，进而伪造交易、盗窃用户财产、窃取情报
2、存储型XSS攻击
攻击步骤：
1、攻击者将恶意代码提交到目标网站的数据库中
2、用户打开网站时，网站服务端将恶意代码从数据库中取出，拼接在HTML中返回浏览器
3、用户浏览器收到响应后解析执行混入其中的恶意代码，恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户行为，调用目标网站接口执行攻击者指定的操作。
常见于带有用户保存数据的网站功能，比如论坛发帖、商品评价、用户私信等等。
反射型 XSS 跟存储型 XSS 的区别是：存储型 XSS 的恶意代码存在数据库里，反射型 XSS 的恶意代码存在 URL 里。
DOM型XSS
攻击步骤：
1、攻击者构造出特殊的URL，其中包含恶意代码
2、用户打开带有恶意代码的URL，用户浏览器打开带有恶意代码的URL，之后用户浏览器收到响应后解析执行，前端JS取出URL中的恶意代码并执行
3、恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户行为，调用目标网站接口执行攻击者指定的操作。
DOM 型 XSS 跟前两种 XSS 的区别：
DOM 型 XSS 攻击中，取出和执行恶意代码由浏览器端完成，属于前端 JavaScript 自身的安全漏洞，而其他两种 XSS 都属于服务端的安全漏洞。
XSS的防御手段主要有两种：
- 消毒
- HttpOnly
XSS的防御-消毒
XSS攻击者一般都是通过在请求中嵌入恶意脚本达到攻击的目的，这些脚本是一般用户输入中不使用的，如果进行过滤和消毒处理，即对某些html危险字符转义。
如 “>” 转义为“>” 、“<”转义为 “<”等，就可以防止大部分攻击。
为了避免对不必要的内容错误转义，如“3<5”中的 “<” 需要进行文本匹配后再转义，如 “
事实上，消毒几乎是所有网站最必备的XSS防攻击手段。
XSS的防御-HttpOnly
浏览器禁止页面 JavaScript访问带有HttpOnly 属性的敏感 Cookie。
HttpOnly并不是直接对抗XSS攻击的，而是防止XSS攻击者窃取Cookie，就算完成XSS注入后也无法窃取此Cookie属性，防止冒充用户提交请求。
注入攻击
注入攻击主要有两种形式：
- SQL注入攻击
- OS注入攻击
SQL注入攻击
攻击者在HTTP请求中注入恶意SQL命令(drop table users;)，服务器用请求参数构造数据库SQL命令时，恶意SQL被一起构造，并在数据库中执行。
攻击者获取数据库表结构信息的手段：
- 开源，比如一些开源的博客数据库表是公开的，攻击者可以直接获得。
- 错误回显，如果网站开启错误回显，即服务器内部500错误会显示到浏览器上。攻击者通过故意构造非法参数，使服务端异常信息输出到浏览器端，为攻击猜测数据库表结构提供了便利。
- 盲注，网站关闭错误回显，攻击者根据页面变化情况判断SQL语句的执行情况，据此猜测数据库表结构。
预防SQL注入
- 消毒，和防XSS攻击一样，请求参数编码是一种比较简单粗暴又有效的手段。通过正则匹配，过滤请求数据中可能注入的SQL，如“drop table”、“\b(?:update\b.?\bset|delete\b\W?\bfrom)\b”等
- 参数绑定，使用预编译手段，绑定参数是最好的防SQL注入方法。目前许多数据访问层框架，如IBatis，Hibernate等，都实现SQL预编译和参数绑定，攻击者的恶意SQL会被当做SQL的参数，而不是SQL命令被执行。
除了SQL注入，攻击者还根据具体应用，注入OS命令、编程语言代码等，利用程序漏洞，达到攻击目的。
CSRF攻击
CSRF(Cross Site Request Forgery，跨站点请求伪造)，是一种劫持授信用户向服务器发送非预期请求的攻击方式，也就是以合法用户的身份进行非法操作。
攻击者会诱导受害者访问第三方网站，利用受害者获得的被攻击网站的凭证来冒充正常用户对被攻击网站进行某些操作的目的。
如转账交易、发表评论等。CSRF的主要手法是利用跨站请求，在用户不知情的情况下，以用户的身份伪造请求。
其核心是利用了浏览器Cookie或服务器Session策略，盗取用户身份
CSRF的防御
CSRF的防御手段主要是识别请求者身份，防止第三方网站进行冒充，主要有下面几种方法：
尽量POST，限制GET
GET接口太容易被拿来做CSRF攻击，看第一个示例就知道，只要构造一个img标签，而img标签又是不能过滤的数据。接口最好限制为POST使用，GET则无效，降低攻击风险。
当然POST并不是万无一失，攻击者只要构造一个form就可以，但需要在第三方页面做，这样就增加暴露的可能性。
表单Token
CSRF是一个伪造用户请求的操作，所以需要构造用户请求的所有参数才可以。
表单Token通过在请求参数中增加随机数的办法来阻止攻击者获得所有请求参数：
在页面表单中增加一个随机数作为Token，每次响应页面的Token都不相同，从正常页面提交的请求会包含该Token值，而伪造的请求无法获得该值，服务器检查请求参数中Token的值是否存在并且正确以确定请求提交者是否合法。
验证码
相对说来，验证码则更加简单有效，即请求提交时，需要用户输入验证码，以避免在用户不知情的情况下被攻击者伪造请求。
Referer check
HTTP请求头的Referer域中记录着请求来源，可通过检查请求来源，验证其是否合法。很多网站使用这个功能实现图片防盗链(如果图片访问的页面来源不是来自自己网站的网页就拒绝)。
本文转载自微信公众号「架构技术专栏」，可以通过以下二维码关注。转载本文请联系架构技术专栏公众号。
