XSS——跨站脚本攻击-介绍及攻击防御

介绍：本文将讲解Web会话原理及XSS的攻击原理（xsser测试平台有兴趣可自行搭建体验，搜索xsser.me即可）详细概念教程可在Sangfor学习平台获取临时免费课程进行学习。

挂个链接：深信服产业教育中心

一.常见Web会话管理方式（三种）

以下三种方式建议通过理解过程来区分

Session

1.基于服务端的Session管理，指的是用户第一次访问网站/应用时（客户端），服务器便会创建对象，在Session有效期内（一般session都会设置有效期）用户再次访问浏览器（即通过客户端发送请求给服务器），Session有效时间便会刷新

注：Session在一开始创建的时候并没有管理功能，这个由服务端创建的session是基于用户分配的唯一的一个Session ID，并通过Cookie返回给用户。

举个例子（拿账号登录举例，第一次访问并登录后获取到Session，可以理解为在Session里放了一个登录凭证，然后在一定时间内访问就会重新刷新登陆凭证的有效期，而在一定时间内未访问或者退出登录，登录凭证都会失效。）

Session优缺点：

1.优点是简化web开发和安全性好，前者可以理解为Session变量使用较之简便，后者即时效性和Session ID以及登陆凭证的双重保险作用。

2.缺点是由于Session是创建并存储在服务器中的，若访问的用户过多，则占用内存也会随之增加，并且应用在使用服务器集群部署的时候，如何实现服务器之间的Session共享也是个麻烦的问题，且当一个Session被共享给多个应用的时候，不同域之间的应用的Session共享也是个问题（跨域名使用，不同应用之间的主机配置不同等等问题）。

Cookie-based

由于Session的管理方式会增加架构的复杂性和服务器负担，所以把登录凭证放到Cookie里（这样也不用生成Session ID），直接存储在客户端里，即用户第一次访问并登录成功时就会把凭证写到Cookie里面，后续就和上述一样，访问的时候直接验证登陆凭证是否有效就行。

流程：用户发起登录请求后，服务器收到数据信息（账号密码），对应是否满足登陆条件，若满足便创建登陆凭证，并对其做数字签名（目的防止登录凭证信息被篡改），和用加密算法进行加密处理，最后再将其写入cookie（这里cookie名字必须固定，后续是根据这个名字获取cookie值的）

注：登陆凭证的数据值通常为用户id，创建时间和过期时间。

Session与Cookie的区别：

1.前者将数据（如登陆凭证）存在服务器里，后者存在客户端里

Cookie优缺点：

1.优点：实现服务端的无状态化，服务端只需创建cookie和验证登录即可，用户状态信息（登录凭证）存到客户端上，可以跨同域名下的多个网页，可以设置cookie有效期（攻击者拿到的未必是有效的cookie）。

2.缺点：Cookie有大小限制，存储不了太多用户数据；每次传送cookie，增加了请求数量，对访问性能有所影响，且跨不同域名相互读取cookie也是个问题。

Token-based

它主要是服务于移动端（比如native app等等），因为app和纯API服务都不好管理cookie，因此移动端通常使用Token-based管理方式，直接看图理解吧

注：cookie的名字在cookie-based中被称为ticket，而在Token-based中被称为Token，即服务器端接收登录请求后，登录验证是在Token中进行的。

Token优缺点：

1.优点：支持移动端，且支持无状态，与cookie一样服务端无状态，且做了数据签名和加密。

2.缺点：流量占的更多，且无法在服务器端注销（没有有效时间这个设定），存在劫持的隐患。

总体而言，三种管理方式都是比较安全的，而http劫持之类的问题这个就不是代码层面考虑的了

二.Session攻击

攻击目的：获取到Session（有效），并通过Session成功通过身份验证。

首先获取Session ID，主要分为以下三种方式：

1.预测

该方法成功率不高，类似暴力破解的猜测，而且PHP生成的Session无规律，随机生成且复杂，一般情况下不可能猜得出来。以下是例子：

2.捕获/劫持

也称会话劫持（Session hijacking），通过劫持合法用户的Session ID，利用该Session进行登录访问的劫持方式，该方法最重要的部分就是如何获取合法的用户Session ID来伪装合法用户登录。

攻击步骤：目标用户需要先成功登录目标站点，并获取到Session ID，而攻击者则用攻击手段劫持该Session ID，并利用该Session ID进行登录站点，获取用户合法会话信息。

攻击（获取Session ID）的方式：无非暴力破解和预测或者XSS攻击等，前两者基本不太可能成功（除非Session ID生成并不随机），其他攻击方式下文会补充

防御的方式：

①更改Session 名称，如PHP中的Session ID名称默认为PHPSESSID，更改名称可以在一定程度上防御（如果攻击者不分析站点便猜不到Session ID）

②关闭透明化Session ID，透明化ID指的是浏览器的Http请求没有使用Cookie来装Session ID，而是使用Url传递。

③设置HttpOnly，通过设置Cookie的HttpOnly为true，可以有效防止客户端脚本访问这个地址，从而有效防止XSS攻击。

④关闭所有PHPinfo类dump request信息的页面，因为PHPinfo类会dump（转储）出请求信息，其中就包含Session

⑤验证HTTP头部信息

中间人攻击（Man in the MiddleAttack，也称MITM攻击)

也是属于劫持攻击，是一种通过窃取或篡改物理通信和逻辑链路间接完成网络攻击的方法，攻击者分别与两端建立联系，并交换两端发送过来的数据，让两端认为他们是通过一个私钥在进行连接会话，实际上双方的会话都被攻击者所控制，这个被攻击者所控制的节点即“中间人”

中间人的两种常见形式：基于监听的信息获取/基于监听的身份冒认

中间人难以防御的原因如下：

①攻击者进行窃听的时候，网络正常运行，因此很多人不注意，难以主动发现

②受害者电脑上一般也不会攻击者种下木马等病毒，因此不会被杀毒软件等检查到

③虽然攻击者在进行窃取或篡改网络通信的时候会有一些蛛丝马迹，但是网络设备记录有限，因此也很难追踪

④绝大部分的网络协议依然是以对方的数据安全可靠为前提运作的，这导致攻击者能够利用的漏洞很多，进行欺骗网络设备并伪装成中间人

3.固定

这是最简单的一种方式，攻击者预先让合法用户使用其指定的Session ID进行登录，这样Web端就不会产生新的Session ID，攻击者预先设置的Session ID就成为合法桥梁

攻击步骤：

①攻击者通过某种攻击手段来重置目标用户的Session ID，然后监听用户会话状态

②目标用户携带攻击者指定的Session ID 登录站点

③成功登陆并保存Session ID后，攻击者便可使用该ID进行登录访问，获取用户会话信息

注：早期浏览器都是通过URL来传递Session ID的，若没在Cookie中看到Session ID，则可以到get或post数据中查看是否存在，若存在则使用此ID。最终若Cookie和URL中都没有，才通过系统生成一个Session ID给客户端。

三、防御XSS（跨站脚本攻击）有两种途径（输入和输出方向），即输入和输出过滤（filter）。

输入方向即对输入的数据进行强类型检查（比如长度，数据类型，格式要求，加密方式等）

输出方向则在数据输出前对数据进行编码确认，检查其是否正常编码输出。

1.输入过滤

输入过滤通常分为输入验证和输入净化两种，输入验证即强类型检查，而输入净化则为对数据进行重定义，比如删除掉数据中的空格，尖括号等敏感字符，或者将数据直接转为数字或字符串格式，保障其数据正常，不会被跨站脚本攻击或者SQL注入等攻击。

以下是输入净化的示例：

这段程序是让用户以文本形式输入一个tel即手机号码并提交的前端代码，而我们进行数据净化可以将这段代码变为数字格式，即如下代码

其中的is_numberic即确认输入的文本是否为数字符格式。

2.输出过滤

通常在输出数据到客户端（网页）时，对数据进行编码，即在保证数据的完整和正确性前提下将XSS敏感字符（,&,"等等)转换为实体，比如HTML的Unicode码（将字符包括符号都转为一种与UTF-8编码不冲突的独立编码），示例如下：

转换后可以保障网页显示这些符号，而程序不运行他们，常用htmlspecialchars()函数。

总结：最佳防御方式即输入和输出都进行过滤操作，详情如上。

以下是一些攻击案例：

案例1.在HTML中，input，color等标签往往存在动态属性（其属性值为动态内容），在对内容进行修改后往往就会出现XSS威胁：

通过修改input的value值，注入跨站脚本evil_script()。

比如在value中恶意输入一个xss οnmοuseοver=evil_script()，意为当用户鼠标光标点到input输入栏时，脚本就会触发运行。

渲染后的HTML代码为：

解决方案：将触发xss的字符中的特殊符号（<>"）通过html编码转为实体，比如恶意输入的为‘xss’；evil_script()等等。

注：注释中的/* */等符号也需要进行实体编码。

案例2：

将’GotoUrl("");'>修改为'GotoUrl("foo");evil_script("");">

从上述事件可以得知，既可以通过XSS恶意修改将onclick改为跨站脚本触发器，也可以通过特殊符号将javascript提前闭合，比如（联想恶意输入的数值）

注：若非信任数据内容既处在HTML上下位中又处在Javascript上下文中的字符，应先对字符进行HTML转化，再进行Javascript转化。这是一种转化规则。

四.XSS检测

1.通过burpsuite抓包然后选择主动扫描，即可检测是否有XSS跨站脚本

PS：burpsuite工具及其插件足以做到完整的渗透测试流程，推荐学习使用此工具。