XSS 是跨站脚本攻击(Cross Site Scripting)的简写,但是从首写字母命名的方式来看,应该取名 css,但这样就和层叠样式表(Cascading Style Sheets,CSS)重名了,所以取名为 XSS。
XSS 攻击,一般是指攻击者通过在网页中注入恶意脚本,当用户浏览网页时,恶意脚本执行,控制用户浏览器行为的一种攻击方式。
XSS 攻击按是否把攻击数据存进服务器端,攻击行为是否伴随着攻击数据一直存在,可分为 非持久型 XSS 攻击 和 持久型 XSS 攻击。
XSS 攻击按攻击方式又可分为 反射型 XSS、dom 型 XSS、存储型 XSS,其中 反射型 XSS 和 DOM 型 XSS 算是 非持久型 XSS 攻击,而 存储型 XSS 算是 持久型 XSS 攻击。
攻击者诱导用户访问一个带有恶意代码的 URL 后,服务器端接收数据后处理,然后把带有恶意代码的数据发送到浏览器端,浏览器端解析这段带有 XSS 代码的数据后当做脚本执行,最终完成 XSS 攻击。
因为这个过程就像一次反射,故称为反射型 XSS。
攻击步骤:
1、攻击构造出特殊的 URL ,其中包含恶意代码。
2、用户被诱导打开带有恶意代码的 URL,服务器端将恶意代码从 URL 中取出当做参数处理,然后返回给用户带有恶意代码的数据。
3、用户浏览器接收到响应解析执行,混在其中的恶意代码也被执行。
4、恶意代码窃取用户敏感数据发送给攻击者,或者冒充用户的行为,调用目标网站接口执行攻击者指定的操作。
DOM 型 XSS 形成原因是通过修改页面的 DOM 节点形成的 XSS。
DOM 型 XSS 攻击中,取出和执行恶意代码都由浏览器端完成,属于前端自身的安全漏洞。
攻击步骤:
1、攻击者构造出特殊的 URL,其中包含恶意代码。
2、用户被诱导打开带有恶意代码的 URL。
3、用户浏览器接收到响应后解析执行,前端 JavaScript 取出 URL 中的恶意代码并执行。
4、恶意代码窃取用户数据并发送到攻击者的网站,或者冒充用户的行为,调用目标网站接口执行攻击者指定的操作。
存储型 XSS 跟 反射型 XSS 的区别是:存储型 XSS 的恶意代码存在服务器上,反射型 XSS 的恶意代码存在 URL 里。
存储型 XSS 攻击时恶意脚本会存储在目标服务器上。当浏览器请求数据时,脚本从服务器传回并执行。它是最危险的一种跨站脚本,比反射性 XSS 和 DOM 型 XSS 都更有隐蔽性,因为它不需要用户手动触发。任何允许用户存储数据的 Web 程序都可能存在存储型 XSS 漏洞。若某个页面遭受存储型 XSS 攻击,所有访问该页面的用户都会被 XSS 攻击。
攻击步骤:
1、攻击者把恶意代码提交到目标网站的服务器中。
2、用户打开目标网站,网站服务器端把带有恶意代码的数据取出,当做正常数据返回给用户。
3、用户浏览器接收到响应解析执行,混在其中的恶意代码也被执行。
4、恶意代码窃取用户敏感数据发送给攻击者,或者冒充用户的行为,调用目标网站接口执行攻击者指定的操作。
HTTP X-XSS-Protection 响应头是 Internet Explorer,Chrome 和 Safari 的一个功能,当检测到跨站脚本攻击(XSS)时,浏览器将停止加载页面。
他可以设置4个值:
X-XSS-Protection: 0
禁止XSS过滤。
X-XSS-Protection: 1
启用XSS过滤(通常浏览器是默认的)。 如果检测到跨站脚本攻击,浏览器将清除页面(删除不安全的部分)。
X-XSS-Protection: 1; mode=block
启用XSS过滤。 如果检测到攻击,浏览器将不会清除页面,而是阻止页面加载。
X-XSS-Protection: 1; report=<reporting-uri>
启用XSS过滤。 如果检测到跨站脚本攻击,浏览器将清除页面并使用CSP report-uri指令的功能发送违规报告。
这种浏览器自带的防御功能只对反射型 XSS 有一定的防御力,其原理是检查 URL 和 DOM 中元素的相关性,但这并不能完全防止反射型 XSS,而且也并不是所有浏览器都支持 X-XSS-Protection。
在 XSS 攻击中,攻击者主要是通过构造特殊字符来注入脚本,所以对用户的输入进行检测就很有必要,并且需要在客户端与服务端都进行输入检测,然后对用户输入的数据进行转义。
主要就是对输入所包含的特殊字符进行转义,如 <,>,&,",',来防止 XSS 攻击。
下面是一个用于转义的方法:
function escapehtml(str) {
if (!str) return '';
str = str.replace(/&/g, "&");
str = str..replace(/</g, "<");
str = str..replace(/>/g, ">");
str = str..replace(/"/g, """);
str = str..replace(/'/g, "'");
return str;
};
在富文本中因为需要保留 HTML ,所以我们不能使用转义的方法防御 XSS 攻击,这里使用过滤的方式防御 XSS 攻击,也就是通过只使用白名单允许的 HTML 标记及其属性,来防御攻击。
这里推荐一个名为 XSS 的组件 ,这就是一个根据白名单过滤 HTML,防止 XSS 攻击的组件。
内容安全策略(Content Security Policy,CSP),实质就是白名单制度,开发者明确告诉客户端,哪些外部资源可以加载和执行,大大增强了网页的安全性。
两种方法可以启用 CSP。一种是通过 HTTP 头信息的 Content-Security-Policy 的字段。
Content-Security-Policy: script-src 'self';
object-src 'none';
style-src cdn.example.org third-party.org;
child-src https:
另一种是通过网页的 <meta> 标签。
<meta http-equiv="Content-Security-Policy" content="script-src 'self'; object-src 'none'; style-src cdn.example.org third-party.org; child-src https:">
上面代码中,CSP 做了如下配置。
启用后,不符合 CSP 的外部资源就会被阻止加载。
XSS 攻击的本质就是输入的内容被当做程序执行了,所以我们对于用户输入的内容不能完全的信任,需要考虑如何避免其被当做程序执行。
没有调用远程平台,用web接收cookie ,图片创建script节点,链接远程第三方JS,总的来说,details详细信息展开时触发,往往是被忽略的一个点.三个点:标签、属性、事件代码。
谷歌正在移除其 Chrome 网络浏览器中已经存在 9 年的一个功能,该功能可以帮助避免一些潜在的在线攻击。不过,别担心——优化的保护方案也即将出台。XSS Auditor 是 2010 年推出的一个内置 Chrome 函数,用于检测跨站点脚本 (XSS) 漏洞。
在开始本文之前,我们先提出一个问题,请判断以下两个说法是否正确: XSS 防范是后端 RD(研发人员)的责任,后端 RD 应该在所有用户提交数据的接口,对敏感字符进行转义,才能进行下一步操作。所有要插入到页面上的数据,都要通过一个敏感字符过滤函数的转义,过滤掉通用的敏感字符后,就可以插入到页面中。
(XSS)攻击是一种注入类型,其中恶意脚本被注入到其他良性和可信赖的网站中。那么Angular怎么防御xss攻击?当攻击者使用Web应用程序将恶意代码(通常以浏览器端脚本的形式)发送给不同的最终用户时,就会发生XSS攻击。
CSRF:需要用户先登录网站A,获取 cookie。XSS:不需要登录。CSRF:是利用网站A本身的漏洞,去请求网站A的api。XSS:是向网站 A 注入 JS代码,然后执行 JS 里的代码,篡改网站A的内容。
前端一般会面临 XSS 这样的安全风险,但随着 React 等现代前端框架的流行,使我们在平时开发时不用太关注安全问题。以 React 为例,React 从设计层面上就具备了很好的防御 XSS 的能力
XSS/跨站脚本攻击,是一种代码注入网页攻击,攻击者可以将代码植入到其他用户都能访问到的页面(如论坛、留言板、贴吧等)中。如今,XSS 攻击所涉及的场景愈发广泛。越来越多的客户端软件支持 html 解析和 JavaScript 解析,比如:HTML 文档、XML 文档、Flash、PDF、QQ
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!