一、XSS攻击
什么是 XSS 攻击?
XSS 全称是 Cross Site Scripting(即跨站脚本)，为了和 CSS 区分，故叫它XSS。XSS 攻击是指浏览器中执行恶意脚本(无论是跨域还是同域)，从而拿到用户的信息并进行操作。
这些操作一般可以完成下面这些事情:
- 窃取Cookie。
- 监听用户行为，比如输入账号密码后直接发送到黑客服务器。
- 修改 DOM 伪造登录表单。
- 在页面中生成浮窗广告。
XSS 类型
XSS 可以分为多种类型，但是总体上我认为分为两类：持久型和非持久型。
- 持久型也就是攻击的代码被服务端写入进数据库中，这种攻击危害性很大，因为如果网站访问量很大的话，就会导致大量正常访问页面的用户都受到攻击。
举个例子，对于评论功能来说，就得防范持久型 XSS 攻击，因为我可以在评论中输入以下内容
这种情况如果前后端没有做好防御的话，这段评论就会被存储到数据库中，这样每个打开该页面的用户都会被攻击到。- 非持久型相比于前者危害就小的多了，一般通过修改 URL 参数的方式加入攻击代码，诱导用户访问链接从而进行攻击。
防范措施
- 千万不要相信任何用户的输入！无论是在前端和服务端，都要对用户的输入进行转码或者过滤。
- 利用 CSP（Content-Security-Policy）白名单
CSP，即浏览器中的内容安全策略，它的核心思想就是服务器决定浏览器加载哪些资源，具体来说可以完成以下功能:- 限制其他域下的资源加载。
- 禁止向其它域提交数据。
- 提供上报机制，能帮助我们及时发现 XSS 攻击。
CSP实现方式： - 一种是通过 HTTP 头信息的
Content-Security-Policy的字段。
- 另一种是通过网页的标签。
<meta http-equiv="Content-Security-Policy" content="script-src 'self'; object-src 'none'; style-src cdn.example.org third-party.org; child-src https:">
<!--上面代码中，CSP 做了如下配置
* 脚本：只信任当前域名
* <object>标签：不信任任何URL，即不加载任何资源
* 样式表：只信任cdn.example.org和third-party.org
* 框架（frame）：必须使用HTTPS协议加载
* 其他资源：没有限制
-->
- 利用 HttpOnly
很多 XSS 攻击脚本都是用来窃取Cookie, 而设置 Cookie 的 HttpOnly 属性后，JavaScript 便无法读取 Cookie 的值。这样也能很好的防范 XSS 攻击。
总结
二、CSRF攻击
什么是CSRF攻击？
CSRF(Cross-site request forgery), 即跨站请求伪造，指的是黑客诱导用户点击链接，打开黑客的网站，然后黑客利用用户目前的登录状态发起跨站请求。
- 举个例子, 你在某个论坛点击了黑客精心挑选的小姐姐图片，你点击后，进入了一个新的页面。
那么恭喜你，被攻击了:）
CSRF攻击一般会有三种方式:
自动 GET 请求
自动 POST 请求
诱导点击发送 GET 请求。- 和XSS攻击对比，CSRF 攻击并不需要将恶意代码注入用户当前页面的html文档中，而是跳转到新的页面，利用服务器的验证漏洞和用户之前的登录状态来模拟用户进行操作。
防范措施
1、GET请求不对数据修改
2、不让第三方网站访问Cookies：利用Cookie的SameSite属性
CSRF攻击中重要的一环就是自动发送目标站点下的 Cookie,然后就是这一份 Cookie 模拟了用户的身份。因此在Cookie上面下文章是防范的不二之选。
设置Cookie 的SameSite字段
SameSite可以设置为三个值，
Strict、Lax和None。
- a. 在Strict模式下，浏览器完全禁止第三方请求携带Cookie。比如请求sanyuan.com网站只能在sanyuan.com域名当中请求才能携带 Cookie，在其他网站请求都不能。
- b. 在Lax模式，就宽松一点了，但是只能在 get 方法提交表单况或者a 标签发送 get 请求的情况下可以携带 Cookie，其他情况均不能。
- c. 在None模式下，也就是默认模式，请求会自动携带上 Cookie。
3、阻止第三方网站请求接口：验证来源站点
这就需要要用到请求头中的两个字段: Origin和Referer。
其中，Origin只包含域名信息，而Referer包含了具体的 URL 路径。
当然，这两者都是可以伪造的，通过 Ajax 中自定义请求头即可，安全性略差。
4、请求附带验证信息：CSRF Token / 验证码
Django作为 Python 的一门后端框架，如果是用它开发过的同学就知道，在它的模板(template)中, 开发表单时，经常会附上这样一行代码:
{% csrf_token %}
这就是CSRF Token的典型应用。那它的原理是怎样的呢？
首先，浏览器向服务器发送请求时，服务器生成一个字符串，将其植入到返回的页面中。
然后浏览器如果要发送请求，就必须带上这个字符串，然后服务器来验证是否合法，如果不合法则不予响应。这个字符串也就是CSRF Token，通常第三方站点无法拿到这个 token, 因此也就是被服务器给拒绝。
三、点击劫持
什么是点击劫持
点击劫持是一种视觉欺骗的攻击手段。攻击者将需要攻击的网站通过
iframe嵌套的方式嵌入自己的网页中，并将iframe设置为透明，在页面中透出一个按钮诱导用户点击
防御措施
1、X-FRAME-OPTIONS
X-FRAME-OPTIONS 是一个 HTTP 响应头，在现代浏览器有一个很好的支持。这个 HTTP 响应头 就是为了防御用iframe 嵌套的点击劫持攻击。
该响应头有三个值可选，分别是
- DENY，表示页面不允许通过 iframe 的方式展示
- SAMEORIGIN，表示页面可以在相同域名下通过 iframe 的方式展示
- ALLOW-FROM，表示页面可以在指定来源的 iframe 中展示
2、JS 防御
对于某些远古浏览器来说，并不能支持上面的这种方式，那我们只有通过 JS 的方式来防御点击劫持了。 通过判断顶层窗口的方式来进行防御
<head>
<style id="click-jack">
html {
display: none !important;
}
</style>
</head>
<body>
<script>
//当通过 iframe 的方式加载页面时，攻击者的网页直接不显示所有内容了
if (self == top) {
var style = document.getElementById('click-jack')
document.body.removeChild(style)
} else {
top.location = self.location
}
</script>
</body>
第9篇:HTTPS为什么让数据传输更安全？
谈到HTTPS, 就不得不谈到与之相对的HTTP。HTTP的特性是明文传输，因此在传输的每一个环节，数据都有可能被第三方窃取或者篡改，具体来说，HTTP 数据经过 TCP 层，然后经过WIFI路由器、运营商和目标服务器，这些环节中都可能被中间人拿到数据并进行篡改，也就是我们常说的中间人攻击。
为了防范这样一类攻击，我们不得已要引入新的加密方案，即 HTTPS。
HTTPS并不是一个新的协议, 而是一个加强版的HTTP。其原理是在HTTP和TCP之间建立了一个中间层，当HTTP和TCP通信时并不是像以前那样直接通信，直接经过了一个中间层进行加密，将加密后的数据包传给TCP, 响应的，TCP必须将数据包解密，才能传给上面的HTTP。这个中间层也叫安全层。安全层的核心就是对数据加解密。
接下来我们就来剖析一下HTTPS的加解密是如何实现的。
对称加密和非对称加密
概念
首先需要理解对称加密和非对称加密的概念，然后讨论两者应用后的效果如何。
对称加密是最简单的方式，指的是加密和解密用的是同样的密钥。
而对于非对称加密，如果有 A、 B 两把密钥，如果用 A 加密过的数据包只能用 B 解密，反之，如果用 B 加密过的数据包只能用 A 解密。
加解密过程
接着我们来谈谈浏览器和服务器进行协商加解密的过程。
首先，浏览器会给服务器发送一个随机数client_random和一个加密的方法列表。
服务器接收后给浏览器返回另一个随机数server_random和加密方法。
现在，两者拥有三样相同的凭证: client_random、server_random和加密方法。
接着用这个加密方法将两个随机数混合起来生成密钥，这个密钥就是浏览器和服务端通信的暗号。
各自应用的效果
如果用对称加密的方式，那么第三方可以在中间获取到client_random、server_random和加密方法，由于这个加密方法同时可以解密，所以中间人可以成功对暗号进行解密，拿到数据，很容易就将这种加密方式破解了。
既然对称加密这么不堪一击，我们就来试一试非对称加密。在这种加密方式中，服务器手里有两把钥匙，一把是公钥，也就是说每个人都能拿到，是公开的，另一把是私钥，这把私钥只有服务器自己知道。
好，现在开始传输。
浏览器把client_random和加密方法列表传过来，服务器接收到，把server_random、加密方法和公钥传给浏览器。
现在两者拥有相同的client_random、server_random和加密方法。然后浏览器用公钥将client_random和server_random加密，生成与服务器通信的暗号。
这时候由于是非对称加密，公钥加密过的数据只能用私钥解密，因此中间人就算拿到浏览器传来的数据，由于他没有私钥，照样无法解密，保证了数据的安全性。
这难道一定就安全吗？聪明的小伙伴早就发现了端倪。回到非对称加密的定义，公钥加密的数据可以用私钥解密，那私钥加密的数据也可以用公钥解密呀！
服务器的数据只能用私钥进行加密(因为如果它用公钥那么浏览器也没法解密啦)，中间人一旦拿到公钥，那么就可以对服务端传来的数据进行解密了，就这样又被破解了。而且，只是采用非对称加密，对于服务器性能的消耗也是相当巨大的，因此我们暂且不采用这种方案。
对称加密和非对称加密的结合
可以发现，对称加密和非对称加密，单独应用任何一个，都会存在安全隐患。那我们能不能把两者结合，进一步保证安全呢？
其实是可以的，演示一下整个流程：
浏览器向服务器发送client_random和加密方法列表。
服务器接收到，返回server_random、加密方法以及公钥。
浏览器接收，接着生成另一个随机数pre_random, 并且用公钥加密，传给服务器。(敲黑板！重点操作！)
服务器用私钥解密这个被加密后的pre_random。
现在浏览器和服务器有三样相同的凭证:client_random、server_random和pre_random。然后两者用相同的加密方法混合这三个随机数，生成最终的密钥。
然后浏览器和服务器尽管用一样的密钥进行通信，即使用对称加密。
这个最终的密钥是很难被中间人拿到的，为什么呢? 因为中间人没有私钥，从而拿不到pre_random，也就无法生成最终的密钥了。
回头比较一下和单纯的使用非对称加密, 这种方式做了什么改进呢？本质上是防止了私钥加密的数据外传。单独使用非对称加密，最大的漏洞在于服务器传数据给浏览器只能用私钥加密，这是危险产生的根源。利用对称和非对称加密结合的方式，就防止了这一点，从而保证了安全。
添加数字证书
尽管通过两者加密方式的结合，能够很好地实现加密传输，但实际上还是存在一些问题。黑客如果采用 DNS 劫持，将目标地址替换成黑客服务器的地址，然后黑客自己造一份公钥和私钥，照样能进行数据传输。而对于浏览器用户而言，他是不知道自己正在访问一个危险的服务器的。
事实上HTTPS在上述结合对称和非对称加密的基础上，又添加了数字证书认证的步骤。其目的就是让服务器证明自己的身份。
传输过程
为了获取这个证书，服务器运营者需要向第三方认证机构获取授权，这个第三方机构也叫CA(Certificate Authority), 认证通过后 CA 会给服务器颁发数字证书。
这个数字证书有两个作用:
服务器向浏览器证明自己的身份。
把公钥传给浏览器。
这个验证的过程发生在什么时候呢？
当服务器传送server_random、加密方法的时候，顺便会带上数字证书(包含了公钥), 接着浏览器接收之后就会开始验证数字证书。如果验证通过，那么后面的过程照常进行，否则拒绝执行。
现在我们来梳理一下HTTPS最终的加解密过程:
认证过程
浏览器拿到数字证书后，如何来对证书进行认证呢？
首先，会读取证书中的明文内容。CA 进行数字证书的签名时会保存一个 Hash 函数，来这个函数来计算明文内容得到信息A，然后用公钥解密明文内容得到信息B，两份信息做比对，一致则表示认证合法。
当然有时候对于浏览器而言，它不知道哪些 CA 是值得信任的，因此会继续查找 CA 的上级 CA，以同样的信息比对方式验证上级 CA 的合法性。一般根级的 CA 会内置在操作系统当中，当然如果向上找没有找到根级的 CA，那么将被视为不合法。
总结
HTTPS并不是一个新的协议, 它在HTTP和TCP的传输中建立了一个安全层，利用对称加密和非对称加密结合数字证书认证的方式，让传输过程的安全性大大提高。