xss

xss靶场练习(一)之xss.haozi.me

偶尔善良 提交于 2020-01-29 20:38:47
目录 前言 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0A 0x0B 0x0C 0x0D 0x0E 0x0F 0x10 0x11 0x12 前言 xss实战第一部曲, 实战的靶场是部署在github上的, 所以可能有些延迟(你懂的), 然后给出地址: https://xss.haozi.me/ 玩法很简单, 进行xss注入直至alert(1)成功。 fight! 0x00 首先看看布局: 看到源码什么防护都没有, 直接抛一个常规payload过了(过马路一般): <script>alert(1)</script> 0x01 看到注入点是在<textarea></textarea>标签中, 所以用上一题的方法是不会被解析的, 故需要去构造标签, 闭合<textarea></textarea>, 就可以注入了: </textarea> <script>alert(1)</script> <textarea> 或者, 利用error事件也可以: </textarea><img src="" onerror=alert(1)> 由于src是空, 所以肯定会报错, 故通过错误调用事件成功注入xss: 0x02 这题的注入点是把值转化为字符串, 然后显示在输入框内, 这样前两题的标签闭合注入也就失效了 提到闭合, 那么就好办了,

【web安全基础】可以挖哪些洞

那年仲夏 提交于 2020-01-28 23:57:07
目录 0.常见的安全事件 1.XSS 1.1 存储型 1.2 反射型 1.2 DOM型 2.CSRF 3.点击劫持 4.URL跳转 5.SQL注入 6.命令注入 7.文件操作漏洞 0.常见的安全事件 1.XSS 1.1 存储型 1.2 反射型 上图是response,下图是解析url的request直接输出到response 1.2 DOM型 浏览器通过JS(javascript)从url中提取xss脚本内容并写入DOM中触发xss 如上右击查看源代码(服务端返回浏览器的响应页面)查找xss找不到,因为DOM型xss由js触发 2.CSRF 3.点击劫持 4.URL跳转 5.SQL注入 前面全是客户端漏洞,下面全是服务端漏洞 6.命令注入 7.文件操作漏洞 来源: CSDN 作者: weixin_43435675 链接: https://blog.csdn.net/weixin_43435675/article/details/104099422

常见六大Web安全攻防解析

大兔子大兔子 提交于 2020-01-28 12:49:55
转自:https://www.cnblogs.com/fundebug/p/details-about-6-web-security.html 一、XSS XSS (Cross-Site Scripting),跨站脚本攻击,因为缩写和CSS重叠,所以只能叫XSS。跨站脚本攻击是指通过存在安全漏洞的Web网站注册用户的浏览器内运行非法的HTML标签或JavaScript进行的一种攻击 跨站脚本攻击有可能造成以下影响: 利用虚假输入表单骗取用户个人信息 利用脚本窃取用户的Cookie值,被害者在不知情的情况下,帮助攻击者发送恶意请求 显示伪造的文章或图片 XSS的原理是恶意攻击者往Web页面里插入恶意可执行网页脚本代码,当用户浏览该页之时,嵌入其中Web里面的脚本代码会被执行,从而可以达到攻击者盗取用户信息或其他侵犯用户安全隐私的目的 XSS的攻击方式千变万化,但还是可以大致细分为几种类型 1.非持久型XSS(反射型XSS) 非持久型XSS漏洞,一般是通过给别人发送 带有恶意脚本代码参数的URL ,当URL地址被打开时,特有的恶意代码参数被HTML解析、执行 举一个例子,比如页面中包含有以下代码: <select> <script> document.write('' + '<option value=1>' + location.href.substring(location

Web信息安全实践_4.0 XSS_知乎1

一曲冷凌霜 提交于 2020-01-27 15:13:09
XSS攻击即为(Cross Site Scripting), 中文为跨站脚本。 之所以它的名字不是CSS而是XSS,是为了区分CSS。 XSS攻击是发生在 目标用户的浏览器 上的,当渲染DOM树的过程中执行了 不该 执行的JS代码时,就发生了XSS攻击。跨站脚本的重点不是“跨站”,而是“ 脚本” 页面执行不该执行的JS 我们首先来看一下,页面执行不该执行的JS是什么意思。譬如我们来看这个代码: // 假设有一个自动回答网站:在框内输入一个问题,这个问题是通过$_GET['q']获取的;网站后台接收用户输入,把用户输入展示在页面上。 Hello, your question is: <?php echo $_GET['q']; ?> // 接下来攻击者可以设计这么一个URL localhost/xss.php?q=<script>alert(1);</script> 大家想一想,这个URL点开一下,效果是什么? 再换一个URL呢? http://localhost/xss.php?q=%3Cscript%3Ealert%28document.cookie%29;%3C/script%3E 因此,所谓执行不该执行的JS代码的意思就是:用户通过各种方法向网站中注入了一些JS代码,而网站没有对用户的JS代码做任何检查,就直接把它有显示在了网站的页面上。因此,导致了用户注入的JS代码的运行。

When is it best to sanitize user input?

可紊 提交于 2020-01-26 23:55:32
问题 User equals untrustworthy. Never trust untrustworthy user's input. I get that. However, I am wondering when the best time to sanitize input is. For example, do you blindly store user input and then sanitize it whenever it is accessed/used, or do you sanitize the input immediately and then store this "cleaned" version? Maybe there are also some other approaches I haven't though of in addition to these. I am leaning more towards the first method, because any data that came from user input must

Is it possible to have CSRF if developer mitigates by referrer header

空扰寡人 提交于 2020-01-26 03:44:07
问题 After pentration testing, developer mitigates the CSRF vulnerability by using only referrer header. The application have other vulnerability like XSS. Is it possible to exploit CSRF with the help of XSS? if yes how? 回答1: Short story: Its very difficult to design effective CSRF protection when XSS is present. Mitigation of CSRF via referrer header is generally considered a weak defense - there are situations where these are stripped (by the browsers or proxies) and you would need to fail these

What is the difference between XSS and CSRF from their execution perspective?

跟風遠走 提交于 2020-01-26 01:02:52
What is the difference between XSS and CSRF from their execution perspective? https://www.quora.com/What-is-the-difference-between-XSS-and-CSRF-from-their-execution-perspective/answer/Deepthi-210 Fundamental difference is that CSRF (Cross-site Request forgery) happens in authenticated sessions when the server trusts the user/browser, while XSS (Cross-Site scripting) doesn't need an authenticated session and can be exploited when the vulnerable website doesn't do the basics of validating or escaping input. In case of XSS, when the server doesn't validate or escapes input as a primary control,

xss漏洞修复,待完善

孤人 提交于 2020-01-25 11:40:02
1.防止sql注入 /// <summary> /// 分析用户请求是否正常 /// </summary> /// <param name="Str">传入用户提交数据</param> /// <returns>返回是否含有SQL注入式攻击代码</returns> /// private bool ProcessSqlStr(string Str) { bool ReturnValue = true; try { if (!string.IsNullOrWhiteSpace(Str)) { Str = Str.Replace("/*", ""); Str = Str.Replace("*/", ""); Str = Str.ToLower(); string SqlStr = "and |exec |insert |select |delete |update |count | * |chr |mid |master |truncate |char |declare "; string[] anySqlStr = SqlStr.Split('|'); foreach (string ss in anySqlStr) { if (Str.IndexOf(ss) >= 0) { ReturnValue = false; } } } } catch { ReturnValue =

[安全相关]XSS跨站脚本攻击

我们两清 提交于 2020-01-24 15:23:33
xss定义:   xss表示Cross Site Scripting(跨站脚本攻击),它与SQL注入攻击类似,SQL注入攻击中以SQL语句作为用户输入,从而达到查询/修改/删除数据的目的,而在xss攻击中,通过插入恶意脚本,实现对用户游览器的控制。   XSS 全称“跨站脚本”,是注入攻击的一种。其特点是不对服务器端造成任何伤害,而是通过一些正常的站内交互途径,例如发布评论,提交含有 JavaScript 的内容文本。这时服务器端如果没有过滤或转义掉这些脚本,作为内容发布到了页面上,其他用户访问这个页面的时候就会运行这些脚本。 xss防范:   最简单防范xss的方法就是过滤用户输入的所有html标签,真正麻烦的是,在一些场合我们要允许用户输入 HTML,又要过滤其中的脚本。Tidy 等 HTML 清理库可以帮忙,但前提是我们小心地使用。仅仅粗暴地去掉 script 标签是没有用的,任何一个合法 HTML 标签都可以添加 onclick 一类的事件属性来执行 JavaScript。对于复杂的情况,我个人更倾向于使用简单的方法处理,简单的方法就是白名单重新整理。用户输入的 HTML 可能拥有很复杂的结构,但我们并不将这些数据直接存入数据库,而是使用 HTML 解析库遍历节点,获取其中数据(之所以不使用 XML 解析库是因为 HTML 要求有较强的容错性)。然后根据用户原有的标签属性

Preventing XSS from within HTML elements

老子叫甜甜 提交于 2020-01-24 12:53:58
问题 Is the following enough to prevent XSS from inside HTML elements? function XSS_encode_html ( $str ) { $str = str_replace ( '&', "&", $str ); $str = str_replace ( '<', "<", $str ); $str = str_replace ( '>', ">", $str ); $str = str_replace ( '"', " "", $str ); $str = str_replace ( '\'', " '", $str ); $str = str_replace ( '/', "/", $str ); return $str; } As mentioned here: - https://www.owasp.org/index.php/Abridged_XSS_Prevention_Cheat_Sheet#RULE_.231_-_HTML_Escape_Before_Inserting_Untrusted