xss

XSS跨站脚本初识

十年热恋 提交于 2020-01-03 02:18:00
跨网站指令码 ( Cross-site scripting ,通常简称为 XSS )是一种网站应用程式的安全漏洞攻击,是 代码注入 的一种。 它允许恶意使用者将程式码注入到网页上,其他使用者在观看网页时就会受到影响。 这类攻击通常包含了 HTML 以及使用者端 脚本语言 。 XSS 攻击通常指的是通过利用网页开发时留下的漏洞,通过巧妙的方法注入恶意指令代码到网页,使用户加载并执行攻击者恶意制造的网页程序。 这些恶意网页程序通常是 JavaScript ,但实际上也可以包括 Java , VBScript , ActiveX , Flash 或者甚至是普通的 HTML 。 攻击成功后,攻击者可能得到更高的权限(如执行一些操作)、私密网页内容、 会话 和 cookie 等各种内容。 -- Wiki 1.基本原理 1.xss攻击示意图 引用自XSS跨站脚本攻击剖析与防御 使用一段php代码示例 1 <html> 2 <head> 3 <title>XSS test</title> 4 </head> 5 <body> 6 <form action = "xss.php" method = "POST"> 7 Please input your name:<br> 8 <input type = "text" name = "name" value = ""></input> 9

【XSS】延长 XSS 生命期

橙三吉。 提交于 2020-01-03 02:17:31
XSS 的本质仍是一段脚本。和其他文档元素一样,页面关了一切都销毁。除非能将脚本蔓延到页面以外的地方,那样才能获得更长的生命力。 庆幸的是,从 DOM 诞生的那一天起,就已为我们准备了这个特殊的功能,让脚本拥有突破当前页面的能力。 下面开始我们的续命黑魔法。 反向注入 一个不合理的标准,往往会埋下各种隐患。 浏览器提供了一个 opener 属性,供弹出的窗口访问来源页。但该规范设计的并不合理,导致通过超链接弹出的页面,也能使用 opener。 但按理来说,只有通过脚本弹出的子页面,才能拥有 opener 属性,这样可以相互访问和操作。 然而事实上,通过超链接点开的页面居然也有!这为 XSS 打开了一扇大门 —— XSS 不仅可以操控当前页面,甚至还能传染给同源的父页面。 XSS 一旦感染到父页面里,战斗力就大幅提升了。 可以想象,只要看了一个带有 XSS 的帖子,即使立即关了,那么帖子列表页也会遭到感染。 更有趣的是,opener 这个属性不受同源策略限制。即使父页面不同源,但父页面的 opener 仍然可以访问。 我们可以顺着 opener.opener.opener... 一直往上试探,只要是和当前页面同源的,仍然能够进行操控 —— 尽管中间隔着其他不同源的页面。 网站的主页面显然比详细页更受用户的信任,停留的时间也会更长,因此攻击力可成倍的增加。 正向注入

初识xss

[亡魂溺海] 提交于 2020-01-03 02:17:16
这周学习了xss攻击,也叫做跨站脚本攻击: 找了个练习平台:http://xss-quiz.int21h.jp/ 第一级别: 可以看到要求是弹出域名, 先输入<script>alert(document.domain)</script>试试,可以看到直接弹出域名,代码中并没有添加任何过滤条件。 第二级别: 我们输入的<script>alert(document.domain)</script>变成了字符串, 所以关闭<input>标签试试,输入”><script>alert(document.domain)</script>试试,成功的弹出了域名,(以下弹窗结果不在一一截图了) 第三级别: 输入的<script>alert(document.domain)</script>中的< >分别被转义成了&lt和&gt,   接着去看查看源代码,发现有个hidden属性,那么尝试使用burpsuite抓包修改Japan的参数值为<script>alert(document.domain)</script>,成功显示了域名 (个人电脑没有安装burp,截图稍后补上,已亲自验证过) 第五级别: 允许输入的字符被限定了为15个字符,同样使用burp抓包修改请求为<scrit>alert(document.domain)</script>,可以成弹出域名(稍后补截图) 第六级别: 此级别同样对<

XSS 初识

大憨熊 提交于 2020-01-03 02:17:07
xss(跨站脚本攻击) xss是指攻击者在网页中嵌入客户端脚本,通常是javascript编写的恶意代码,当用户使用浏览器浏览被嵌入恶意代码的网页时,恶意代码将在用户的浏览器上被解析执行。重点是“脚本”这两个字,脚本主要有javascript和actionscript。 要想深入的研究xss,必须要精通javascript,javascript能做到什么效果,xss的威力就有多强大。 危害 javascript可以用来获取用户的Cookie、改变页面内容、url转跳,那么存在xss漏洞的网站,就可以盗取用户cookie、黑掉页面、导航到恶意网站,而攻击者仅仅需要向页面中注入javascript代码中。 *~盗取管理员cookie *~XSS Worm *~挂马(水坑攻击) *~键盘记录 *~利用网站重定向 *~修改网页内容 攻击场景 在各类sns、邮件系统、开源流行的Web应用、BBS、微博等社交场景中,前端攻击广泛实施与关注。主要是一些大型网站才有价值。 *~支持html解析和javascript解析的客户端,如:html文档、flash、pdf等 *~url的参数,回显到网页上 *~from表单提交的内容出现在网页上,如:昵称、邮箱、简介、留言 分类 主要分三类:反射型、存储型、DOM型(还有flash xss、mxss)。 1.反射型xss 反射型xss也被称为非持久性xss

XSS攻击和CSRF攻击与防范

跟風遠走 提交于 2020-01-02 20:21:41
这两个也是我个人在面试时候经常被问到的(前端较多,有的公司要你前后端都做的或者需要你对这些有所了解的也会问到你),不得不说这些东西在日常业务开发中还真是比较少机会遇到,但是也要考虑到才算周全。 什么是XSS?? 首先XSS攻击是Cross Site Scripting (跨站脚本)的变形缩写,为啥不缩写成CSS呢,因为那就会跟修饰页面的Cascading style sheets (层叠样式表CSS)搞混了,所有学过HTML的人都必学的CSS,内外联标签配上它,就可以调长宽高,设置大小,弄得漂亮。 为什么叫跨站?XSS攻击会有什么危害? 这个就是字面意思,就是心怀不轨的故意写植入代码的人在远程的机器上的web页面的HTML代码中插入恶意代码,植入成功后,所有浏览这个页面的人,都会受到这段恶意代码的影响;简单点的恶作剧,就alert弹出一些无聊的提示框,修改一些URL的链接去一些不健康的网站,伪造擅改一些页面信息等。性质恶劣一点的,就是把自己隐藏起来,在你输入账号密码等重要信息的时候通过标签拿到偷偷发一份到远端的一个接口或者网站做处理。 XSS攻击有哪几种? XSS攻击有三种:反射型XSS;存储型XSS;dom型XSS。 1.反射型(非持久性XSS攻击): 为什么叫反射型,就是像扔球一样,别人把球抹上点屎(带XSS的脏URL),你一开始没看清楚(被诱导着点了链接),拿起来扔出去

How to recover a site after an xss attack?

前提是你 提交于 2020-01-02 11:19:27
问题 Recently i was studying about the XSS attacks and how devastating they can be on a website. What surprised me was that, web ( even SO ) is full about how to prevent xss attack but there is no relevant resource on how to recover a website, after it has been attacked through xss . There are some things which i came across like : upload the backup website code back on server download the entire site and manually look for any malicious script but these doesn't sound good enough....i mean, isn't

HTMLPurifier Breaking Images

不打扰是莪最后的温柔 提交于 2020-01-02 08:03:35
问题 I'm trying to run HTMLPurifier on user input from a WYSIWYG (CK Editor) and the images are breaking. Unfiltered Input: <img alt="laugh" src="/lib/ckeditor/plugins/smiley/images/teeth_smile.gif" title="laugh"> After running through purifier with default settings: <img alt=""laugh"" src="%5C" title=""laugh""> I have tried changing the configuration settings; but I the src is never preserved. Any thoughts? 回答1: I have a suspicion that magic_quotes could be a reason..? Also did you try $config-

HTMLPurifier Breaking Images

时光总嘲笑我的痴心妄想 提交于 2020-01-02 08:03:35
问题 I'm trying to run HTMLPurifier on user input from a WYSIWYG (CK Editor) and the images are breaking. Unfiltered Input: <img alt="laugh" src="/lib/ckeditor/plugins/smiley/images/teeth_smile.gif" title="laugh"> After running through purifier with default settings: <img alt=""laugh"" src="%5C" title=""laugh""> I have tried changing the configuration settings; but I the src is never preserved. Any thoughts? 回答1: I have a suspicion that magic_quotes could be a reason..? Also did you try $config-

HTMLPurifier Breaking Images

瘦欲@ 提交于 2020-01-02 08:02:35
问题 I'm trying to run HTMLPurifier on user input from a WYSIWYG (CK Editor) and the images are breaking. Unfiltered Input: <img alt="laugh" src="/lib/ckeditor/plugins/smiley/images/teeth_smile.gif" title="laugh"> After running through purifier with default settings: <img alt=""laugh"" src="%5C" title=""laugh""> I have tried changing the configuration settings; but I the src is never preserved. Any thoughts? 回答1: I have a suspicion that magic_quotes could be a reason..? Also did you try $config-

Is Firebase Auth's local (persisted auth state) secure and safe from XSS and CSRF for browsers?

夙愿已清 提交于 2020-01-02 07:15:12
问题 I am using Firebase Auth for a web app that involves financial transactions. Thus, security is the most important thing for my app. According to this doc, Firebase can persist its token across multiple sessions by storing it somewhere. It does not mention how safe it is from XSS. Of course, I can just assume it's safe because it's Google, but I want to know more about it. We've all read articles noting how localStorage is unsafe for storing auth, and cookie + csrf token + jwt + httpOnly is