XSS、CSRF、点击劫持、web应用安全实施

教IT的小王A

于 2024-08-27 11:00:00 发布

阅读量1.8k

点赞数 48

文章标签：前端 xss csrf

本文链接：https://blog.csdn.net/A_991128a/article/details/141498170

版权

XSS

XSS全称为 Cross Site Scripting ，中文叫做跨站点脚本攻击。

💡
Tips：跨站点的含义指的是，发起该攻击的攻击者不是在自己的站点上对用户发起的攻击，而是通过一些方式将脚本置入到目标站点发起的攻击，或者是利用目标站点自己的脚本攻击目标站点。

XSS攻击目的

最终目的一般是以被攻击用户的身份对目标站点发起敏感的请求，比如：以用户的身份发起银行转账。（还有可能利用目标站点用户来发起对目标站点的流量攻击、干扰用户操作）
常规可能有以下方式：

拿到用户的token或包含用户认证信息的cookie，将这些东西通过ajax发送到自己的服务器，在自己的服务器伪造请求发给目标站点的服务器。
在用户已经登录的目标站点的页面直接发起ajax请求，这种请求一般直接就是敏感的操作。

XSS攻击方式

利用目标站点的用户输入数据未验证的漏洞，将攻击脚本数据保存至目标站点的后端数据库。如：常规的论坛网站的富文本，攻击者通过在目标站点注册账号，并发布一些文章，这些文章常规是以富文本保存在数据库的，再由前端去解析这些富文本，攻击者的文章可能就被他置入了攻击脚本，只要站点用户点击进入他的文章浏览，攻击就成立了。
利用目标站点的url地址栏解析操作的漏洞，使用各种方式诱使目标站点用户点击可以发起攻击目标站点的链接。如：某网站有一个页面的实现是通过url地址栏带上操作参数和指令，在页面的自带脚本中去解析url地址的参数和指令发起合法的敏感请求，攻击者就利用这个漏洞，将编辑好的链接发布出去，如果用户在目标网站已经登录了，用户点击该链接就会被攻击。
直接篡改目标站点页面的内容置入攻击脚本。
1. 目标站点只使用http，没有使用https，那站点的内容就可能被中间人给篡改。
2. 目标站点的用户使用了恶意的浏览器，或者安装了一些恶意浏览器插件。
3. 目标站点用户的电脑本身有病毒。

XSS防御

后端服务器对所有的用户输入数据进行校验过滤，防止脚本保存到后端数据库。（可以只校验需要在页面解析渲染的数据，但是最后所有数据都校验，万一哪一天要将之前没有校验的数据放在前端页面来解析渲染又搞忘了之前没有做XSS脚本校验了，那不就出问题了）
页面不能做对地址栏的指令和入参解析然后发起敏感操作这种事，最多只能是查询请求的解析。
使用https防止中间人篡改页面。
用户发起的敏感操作要有校验步骤。如：输入手机短信验证码、输入用户密码、或者确认授权等操作。但是也要重点注意现在不能让用户在页面输入敏感信息了，比如输入用户密码和确认授权等操作就不能由页面来输入或确认，因为页面可能被置入了脚本，这已经是不可信任的客户端了，我们要让这种确认操作来自可信安全的客户端（如站点自己的App），让用户到这些可信安全的客户端去执行确认操作。手机短信验证码一般可以让用户直接在页面输入，因为这东西虽然敏感，但是只关联一次操作，用了就没了，就算被页面脚本获取到也是废数据。
http响应头中加上content-security-policy或者返回的html中加上。
1. content-security-policy简称csp，csp策略可以配置哪些源的请求是被允许的，是否允许内联脚本、内联css等。

CSRF

csrf全称为 Cross-site request forgery ，中文叫做跨站点请求伪造

💡 Tips：csrf的跨站点的含义与xss的跨站点有所不同，是用户在恶意站点上浏览页面在无意识的情况下对目标站点发起了跨域攻击。

CSRF攻击目的

以用户的身份在用户无感知的情况下发起敏感的跨站请求，比如在csrf.com网站发起bank.com站点的转账请求。

💡
Tips：相对于xss不同之处是，请求操作是在恶意站点页面内发起的，且csrf不需要知道和获取用户的认证信息，是利用用户在目标站点已经登录的认证信息，以及利用浏览器的一些机制，比如目标站点已经登录的会话cookie，浏览器在对目标站点发起请求时会自动在请求中带上cookie。

CSRF攻击方式

页面嵌入目标站点的表单请求，诱导用户填写信息并点击表单提交。
页面直接动态脚本执行目标站点的请求。（第一条和第二条其实底层的攻击原理基本相同，第一条的情况是恶意站点不知道某些需要填写的信息，然后就伪造成目标站点，让用户填写一些必要信息再让用户自己点击提交，如短信验证码等）
html标签的属性请求，如img的src、script的src、video的src等。

💡
Tips：所有这些攻击方式都依赖于用户已经在目标站点登录，并且记录登录认证信息的会话cookie没有过期，依赖于浏览器请求目标站点时自动带上该站点的cookie的机制。

CSRF防御

服务器配置同源策略。
1. 一般浏览器发起跨域请求时会先发送一个options的请求来预检查服务器是否支持当前域的请求，如果不支持，就不会发送真正的请求，一定程度上能避免跨域请求，但是依赖于浏览器的实现，万一浏览器的预检机制有问题，可能导致请求成功，因为一般浏览器是一定支持丢弃跨域的请求的。所以get请求成功了，丢弃了就没问题，但是post、put、delete等请求成功了可能就会造成问题。
正向方式，引入csrf-token，在发起敏感请求的同时将csrf-token一起带过去，后端服务器验证session会话登录认证信息的同时还要验证csrf-token。

CSRF-TOKEN

虽然配置同源策略、csp等一定程序上都能防止csrf，但是crsf-token是一种正向的思考方式去做防止csrf这件事，所以要引入csrf-
token，其他的配置做辅助。
常规的web应用，我们都会以session的方式记录当前用户的当次会话，前端以cookie的形式存储，如果用户已经登录，本次会话就会关联上用户的认证信息（存储在服务端），如果没有做csrf的预防措施，就会被恶意网站利用浏览器在发起对应域的请求时会自动带上对应域的cookie的机制来伪造已经登录了的用户的请求。

CSRF-TOKEN存储方式与安全性分析

放cookie里面
- 优点：可以给cookie设置上httponly和secure属性，表示不能被脚本读取和只允许https的请求携带，这样可以避免xss脚本获取csrf-token和cookie在http上裸奔。
- 缺点：同前面说的session一样了，是由浏览器的机制自动携带，如果没配置对同源策略等，还是会有csrf风险，就算配置了同源，如果同源的策略是允许当前域的子域访问的，但是子域允许了其他域的跨域，这样还是扩散了csrf风险。
放页面中（表单中隐藏项）
- 优点：没有cookie的自动携带缺点了。
- 缺点：只要没有不允许读取，就有被xss脚本读取获取的风险
放session storage中
- 优点：没有cookie的自动携带缺点了。
- 缺点：只要没有不允许读取，就有被xss脚本读取获取的风险。同时只存在于单个会话页面，如果用户退出浏览器页面或关闭页面重进就没办法满足保存用户登录状态的需求了。
放local storage中
- 优点：没有cookie的自动携带缺点了。
- 缺点：只要没有不允许读取，就有被xss脚本读取获取的风险。

总结

如果放cookie要配置上httponly和secure属性，这样就防止了xss，同时其他的同源策略要多多考虑。
如果选择其他方式，就要着重考虑防止xss。

点击劫持

点击劫持指的是你的站点被恶意站点以iframe的方式嵌入到它的页面中去了，并将其调整为透明的，其下面又包含一些诱导点击的东西诱导用户去点击那个东西，但是用户实际点击的是iframe中的内容。比如：微博的帖子的点击引流。

防御措施

在页面的响应头中加上X-Frame-Options，值为拒绝或者同源。
csp限制同源或者指定源。

安全防御方案总结

必须使用csrf-token，使用cookie存储，使用httponly和secure属性。
每个域名入口必须配置指定域能跨域，不能写通配符。
响应的html内容必须加上csp策略（响应头和meta标签形式均可），只允许本源或指定源，配置不允许内联脚本、内联css。
响应的html响应头必须加上X-Frame-Options，配置允许同源或者指定源。
所有请求必须在https下。
不允许页面脚本解析url地址与参数，并发起修改插入删除等操作的接口，只允许发起查询请求的接口。
后端针对入参做对应的xss过滤。

CSRF-TOKEN实施

通常登录认证页面由后端认证中心返回，页面中在登录表单项中要加上csrf-code隐藏项，登录提交操作要将csrf-code以表单参数的形式传到后端用于验证，防止csrf。
登录接口验证成功后session生成一个csrf-token，以cookie（httponly、secure）的形式响应给前端。会话cookie也要httponly和secure。
敏感操作（或者说修改删除新增的操作）要验证csrf-token。
csrf-token要定期更新，更新方案可以为前端定期来请求更新csrf-token的接口，该接口当然同样要验证当前的csrf-token是否有效，如果前端异常没有及时来更新csrf-token，那就采用让用户下线的方式了（当然还可以考虑其他方式）。