如何测试XSS漏洞
XSS跨站漏洞分为大致三种:储存型XSS,反射型XSS,和DOM型XSS,一般都是由于网站对用户输入的参数过滤不严格而调用浏览器的 *** 而产生的。
储存型XSS:
一般是构造一个比如说"scriptalert("XSS")/script"的 *** 的弹窗代码进行测试,看是否提交后在页面弹窗,这种储存型XSS是被写入到页面当中的,如果管理员不处理,那么将永久存在,这种XSS攻击者可以通过留言等提交方式,把恶意代码植入到服务器网站上, 一般用于盗取COOKIE获取管理员的信息和权限。
反射型XSS:
一般是在浏览器的输入栏也就是urlget请求那里输入XSS代码,例如:127.0.0.1/admin.php?key="scriptalert("xss")/script,也是弹窗 *** 代码。当攻击者发送一个带有XSS代码的url参数给受害者,那么受害者可能会使自己的cookie被盗取或者“弹框“,这种XSS一次性使用,危害比储存型要小很多。
dom型:
常用于挖掘,是因为api代码审计不严所产生的,这种dom的XSS弹窗可利用和危害性并不是很大,大多用于钓鱼。比起存储型和反射型,DOM型并不常用。
跨站脚本攻击(Cross Site Scripting),为了不和层叠样式表(Cascading Style Sheets, CSS)的缩写混淆,故将跨站脚本攻击缩写为XSS。恶意攻击者往Web页面里插入恶意Script代码,当用户浏览该页之时,嵌入其中Web里面的Script代码会被执行,从而达到恶意攻击用户的目的。
XSS攻击分成两类,一类是来自内部的攻击,主要指的是利用程序自身的漏洞,构造跨站语句,如:dvbbs的showerror.asp存在的跨站漏洞。
Web前端新手应该如何防御XSS攻击
今天小编要跟大家分享的文章是关于Web前端新手应该如何防御XSS攻击。作为 *** 系工程师接触最多的漏洞我想就是XSS漏洞了,然而并不是所有的同学对其都有一个清晰的认识。今天我们分享一下XSS漏洞攻击,希望能帮助到大家。下面我们来一起看一看吧!
一、什么是XSS攻击
XSS(Cross-SiteScripting)又称跨站脚本,XSS的重点不在于跨站点,而是在于脚本的执行。XSS是一种经常出现在Web应用程序中的计算机安全漏洞,是由于Web应用程序对用户的输入过滤不足而产生的。
常见的XSS攻击有三种:反射型、DOM-based型、存储型。其中反射型、DOM-based型可以归类为非持久型XSS攻击,存储型归类为持久型XSS攻击。
1、反射型
反射型XSS一般是攻击者通过特定手法(如电子邮件),诱使用户去访问一个包含恶意代码的URL,当受害者点击这些专门设计的链接的时候,恶意代码会直接在受害者主机上的浏览器执行。
对于访问者而言是一次性的,具体表现在我们把我们的恶意脚本通过URL的方式传递给了服务器,而服务器则只是不加处理的把脚本“反射”回访问者的浏览器而使访问者的浏览器执行相应的脚本。反射型XSS的触发有后端的参与,要避免反射性XSS,必须需要后端的协调,后端解析前端的数据时首先做相关的字串检测和转义处理。
此类XSS通常出现在网站的搜索栏、用户登录口等地方,常用来窃取客户端Cookies或进行钓鱼欺骗。
整个攻击过程大约如下:
2、DOM-based型
客户端的脚本程序可以动态地检查和修改页面内容,而不依赖于服务器端的数据。例如客户端如从URL中提取数据并在本地执行,如果用户在客户端输入的数据包含了恶意的JavaScript脚本,而这些脚本没有经过适当的过滤和消毒,那么应用程序就可能受到DOM-basedXSS攻击。需要特别注意以下的用户输入源document.URL、location.hash、location.search、document.referrer等。
整个攻击过程大约如下:
3、存储型
攻击者事先将恶意代码上传或储存到漏洞服务器中,只要受害者浏览包含此恶意代码的页面就会执行恶意代码。这就意味着只要访问了这个页面的访客,都有可能会执行这段恶意脚本,因此储存型XSS的危害会更大。
存储型XSS一般出现在网站留言、评论、博客日志等交互处,恶意脚本存储到客户端或者服务端的数据库中。
整个攻击过程大约如下:
二、XSS攻击的危害
XSS可以导致:
1、攻击劫持访问;
2、盗用cookie实现无密码登录;
3、配合csrf攻击完成恶意请求;
4、使用js或css破坏页面正常的结构与样式等;
三、防御 ***
1、XSS防御之HTML编码
应用范围:将不可信数据放入到HTML标签内(例如div、span等)的时候进行HTML编码。
编码规则:将"'/转义为实体字符(或者十进制、十六进制)。
示例代码:
_unction_ncodeForHTML(str,_wargs){
__return(''+_tr)
___.replace(//g,'')
___.replace(/,'')__//_EC=_EX=_ntity=
___.replace(//g,'')
___.replace(/"/g,'"')
___.replace(/'/g,''')_//'_煌萍觯蛭辉_TML规范中
___.replace(/\//g,'/');
_};
HTML有三种编码表现方式:十进制、十六进制、命名实体。例如小于号(
2、XSS防御之HTMLAttribute编码
应用范围:将不可信数据放入HTML属性时(不含src、href、style和事件处理属性),进行HTMLAttribute编码
编码规则:除了字母数字字符以外,使用HH;(或者可用的命名实体)格式来转义ASCII值小于256所有的字符
示例代码:
_unction_ncodeForHTMLAttibute(str,_wargs){
__let_ncoded='';
__for(let_=0;____let_h=_ex=_tr[i];
___if(!/[A-Za-z0-9]/.test(str[i])_tr.charCodeAt(i)____hex=''+_h.charCodeAt(0).toString(16)+';';
___}
___encoded+=_ex;
__}
__return_ncoded;
_};
3、XSS防御之JavaScript编码
作用范围:将不可信数据放入事件处理属性、JavaScirpt值时进行JavaScript编码
编码规则:除字母数字字符外,请使用xHH格式转义ASCII码小于256的所有字符
示例代码:
_unction_ncodeForJavascript(str,_wargs)_
__let_ncoded='';
__for(let_=0;____let_c=_ex=_tr[i];
___if(!/[A-Za-z0-9]/.test(str[i])_tr.charCodeAt(i)____hex='\\x'+_c.charCodeAt().toString(16);
___}
___encoded+=_ex;
__}
__return_ncoded;
_};
4、XSS防御之URL编码
作用范围:将不可信数据作为URL参数值时需要对参数进行URL编码
编码规则:将参数值进行encodeURIComponent编码
示例代码:
_function_ncodeForURL(str,_wargs){
__return_ncodeURIComponent(str);
_};
5、XSS防御之CSS编码
作用范围:将不可信数据作为CSS时进行CSS编码
编码规则:除了字母数字字符以外,使用XXXXXX格式来转义ASCII值小于256的所有字符
示例代码:
_unction_ncodeForCSS(attr,_tr,_wargs){
__let_ncoded='';
__for(let_=0;____let_h=_tr.charAt(i);
___if(!ch.match(/[a-zA-Z0-9]/)_
____let_ex=_tr.charCodeAt(i).toString(16);
____let_ad='000000'.substr((hex.length));
____encoded+='\\'+_ad+_ex;
___}_lse_
____encoded+=_h;
___}
__}
__return_ncoded;
_};
后记
在任何时候用户的输入都是不可信的。对于HTTP参数,理论上都要进行验证,例如某个字段是枚举类型,其就不应该出现枚举以为的值;对于不可信数据的输出要进行相应的编码;此外httpOnly、CSP、X-XSS-Protection、SecureCookie等也可以起到有效的防护。
XSS漏洞有时比较难发现,所幸当下React、Vue等框架都从框架层面引入了XSS防御机制,一定程度上解放了我们的双手。
但是作为开发人员依然要了解XSS基本知识、于细节处避免制造XSS漏洞。框架是辅助,我们仍需以人为本,规范开发习惯,提高Web前端安全意识。
以上就是小编今天为大家分享的关于Web前端新手应该如何防御XSS攻击的文章,希望本篇文章能够对正在从事web前端工作的小伙伴们有所帮助。想要了解更多web前端相关知识记得关注北大青鸟web培训官网。最后祝愿小伙伴们工作顺利!
作者:公子
链接:#/a/1190000017057646
发现XSS漏洞的一般做法有哪些?
关于发现时间,要具体到是检测什么目标了。找google的,和找腾讯的时间肯定不会一样。 至于“你们一般都是如何发现xss漏洞的?” 不同类型的XSS漏洞,可能不尽相同。
1.对于反射型XSS以及一些DOM XSS,一般建议是开发一些自动化的扫描工具进行扫描,并辅以手工分析。 另外一方面,搜索引擎也是快速寻找具有缺陷参数的好办法。
2.对于存储型XSS,
1) 对于单纯的输入-存储-输出点 的情况 (输入与输出点关系:一个地方输入,会有多个地方输出;不同地方输入,同一地方输出。绕了点 T T ...)。常规测试是正向直接输入内容,然后在输出点查看是否未过滤,当然你也可以先大胆假设输出点未过滤,反向寻找在何处进行输入,进而测试。
2)对于富文本,则需要对过滤器进行fuzz测试(人脑+自动化)了,正好乌云drops上有乌乌发了一篇:fuzzing XSS filter
3)第三类,就是一些WEB应用中所出现的DOM-存储型XSS,即输出点的无害内容,会经过js的一些dom操作变得危险(本质上和 第1点里的dom xss成因是一样的)。这一类的挖掘 *** ,个人觉得不太好总结。 其一,需要熟悉WEB应用的功能,其二,知道功能所对应的 *** 代码有哪些,其三,凭直觉猜测程序员会在哪些功能出现可能导致XSS的过滤遗忘或过滤错误(直觉是唬人的,其实就是你知道某些功能会需要某些代码实现,而这些代码常常容易出错),其四,需要有较好的代码阅读跟踪能力( *** 一大坨。。还是蛮难读的.... 有些代码被混淆过,十分不易阅读,就会涉及到如何下断点进行调试的小技巧)。 我想,挖掘这一类的前提可能是需要有不错的前端开发经验,写多了,才会有足够的嗅觉。
其实吧,有时候专门去找漏洞会很累的,大什么怡情,小什么伤身,因此,我们还不如开心的敲敲代码,听听歌,静待生命中那些意外的收获。 这些收获经常来自身边的人发给你的一些事物。
最后,不论如何,基础很重要吧,内力不足,招式再多也没用,反之,草木竹石皆可为剑。
xss漏洞如何防御?
1、基于特征的防御。XSS漏洞和著名的SQL注入漏洞一样,都是利用了Web页面的编写不完善,所以每一个漏洞所利用和针对的弱点都不尽相同,这就是给XSS漏洞防御带来的困难,不可能以单一特征来概括所有XSS攻击。
传统的XSS防御在进行攻击鉴别时多采用特征匹配方式,主要是针对JavaScript这个关键词进行检索,但是这种鉴别不够灵活,凡是提交的信息中各有JavaScript时,就被硬性的判定为XSS攻击。
2、基于代码修改的防御。Web页面开发者在编写程序时往往会出现一些失误或漏洞,XSS攻击正是利用了失误和漏洞,因此一种比较理想的 *** 就是通过优化Web应用开发来减少漏洞,避免被攻击:
①用户向服务器上提交的信息要对URL和附带的HTTP头、POST数据等进行查询,对不是规定格式、长度的内容进行过滤。
②实现Session标记、CAPTCHA系统或者HTTP引用头检查,以防功能被第三方网站所执行。
③确认接收的内容被妥善的规范化,仅包含最小的、安全的Tag,去掉任何对远程内容的引用,使用HTTP only的cookie。
3、客户端分层防御策略。客户端跨站脚本攻击的分层防御策略是基于独立分配线程和分层防御策略的安全模型。它建立在客户端,这是它与其他模型更大的区别。之所以客户端安全性如此重要,客户端在接受服务器信息,选择性的执行相关内容。这样就可以使防御XSS攻击变得容易,该模型主要由三大部分组成:
①对每一个网页分配独立线程且分析资源消耗的网页线程分析模块;
②包含分层防御策略四个规则的用户输入分析模块;
③保存互联网上有关XSS恶意网站信息的XSS信息数据库。
什么是XSS攻击
XSS攻击又称为跨站脚本,XSS的重点不在于跨站点,而是在于脚本的执行。XSS是一种经常出现在Web应用程序中的计算机安全漏洞,是由于Web应用程序对用户的输入过滤不足而产生的,它允许恶意web用户将代码植入到提供给其它用户使用的页面中。
常见的XSS攻击有三种:反射型XSS攻击、DOM-based型XSS攻击、存储型XSS攻击。
之一种:反射型XSS攻击
反射型XSS攻击一般是攻击者通过特定手法,诱使用户去访问一个包含恶意代码的URL,当受害者点击这些专门设计的链接的时候,恶意代码会直接在受害者主机上的浏览器执行。此类XSS攻击通常出现在网站的搜索栏、用户登录口等地方,常用来窃取客户端Cookies或进行钓鱼欺骗。
第二种:DOM-based型XSS攻击
客户端的脚本程序可以动态地检查和修改页面内容,而不依赖于服务器端的数据。例如客户端如从URL中提取数据并在本地执行,如果用户在客户端输入的数据包含了恶意的JavaScript脚本,而这些脚本没有经过适当的过滤或者消毒,那么应用程序就可能受到DOM-based型XSS攻击。需要特别注意以下的用户输入源document.URL、location.hash、location.search、document.referrer 等。
第三种:存储型XSS攻击
攻击者事先将恶意代码上传或者储存到漏洞服务器中,只要受害者浏览包含此恶意代码的页面就会执行恶意代码。这意味着只要访问了这个页面的访客,都有可能会执行这段恶意脚本,因此存储型XSS攻击的危害会更大。此类攻击一般出现在网站留言、评论、博客日志等交互处,恶意脚本存储到客户端或者服务端的数据库中。
版权声明
本文仅代表作者观点,不代表本站立场。
本文系作者授权发表,未经许可,不得转载。