hello大家好啊，前几篇文章给大家教了pikachu靶场的搭建，我们今天步入正题，来透彻研究下XSS（基础）

上号

XSS（跨站脚本）概述Cross-Site Scripting 简称为“CSS”，为避免与前端叠成样式表的缩写"CSS"冲突，故又称XSS。一般XSS可以分为如下几种常见类型：
1.反射性XSS;
2.存储型XSS;
3.DOM型XSS;

XSS漏洞一直被评估为web漏洞中危害较大的漏洞，在OWASP TOP10的排名中一直属于前三的江湖地位。
XSS是一种发生在前端浏览器端的漏洞，所以其危害的对象也是前端用户。
形成XSS漏洞的主要原因是程序对输入和输出没有做合适的处理，导致“精心构造”的字符输出在前端时被浏览器当作有效代码解析执行从而产生危害。
因此在XSS漏洞的防范上，一般会采用“对输入进行过滤”和“输出进行转义”的方式进行处理:
输入过滤：对输入进行过滤，不允许可能导致XSS攻击的字符输入;
输出转义：根据输出点的位置对输出到前端的内容进行适当转义;

壹·反射型xss(get)

打开靶场可以看见有一个文本框可以输入内容，旁边的按钮是提交，我们输入666来试试

发现URL ?message=666

判断message为输入内容

放上去一个简单的JS语句看看

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

第一次尝试直接输入文本框

发现有字符限制，我们就写到URL里试试

抬走下一位

贰·反射型xss(post)

get和post有些人分不清，这个是别人的区分

3-1 GET请求在浏览器刷新或者回退的时候是无害的。POST的话数据会被重新提交。
3-2 GET可以被书签收藏，POST不行
3-3 GET可以存在缓存中。POST不行
3-4 GET 会将数据存在浏览器的历史中，POST不会
3-5 GET 编码格式只能用ASCII码，POST没有限制
3-6 GET 数据类型urlencode,POST是URLENCODE，form-data
3-7 可见性 参数在URL用户可以看见，POST的参数在REQUSET BODY中不会被用户看见
3-8 安全性 GET相对不安全 POST相对安全些
3-9 长度 参数一般限制2048（和WEB服务器相关），参数无限制。

我这里用CTF web的一个基础练习来引入下

url写?a=1,提交get

post可以用burp也可以用firefox的hackbar，我喜欢用hackbar一点

OK啊，直接是显示flag了好吧，所以大概就是这个意思

我们来讲正题吧

随便输入用户名密码发现不在URL里，所以没法在URL嵌入恶意链接，我们用post

里面提示admin 123456，登录进去是这样的

输入<script>alert(document.cookie)</script>

OK抬走下一位

叁·存储型xss

这种我多半在什么在线留言、提交留言的地方见过

<script>alert(document.cookie)</script>

还是来一句，直接报cookie

等等，还没完，你猜他为什么要叫做存储型

我们从其他地方打开试试

任何地方任何人任何时间都会弹这个，说明存储型XSS能危害所有访问受影响页面的用户

抬走下一位

肆·DOM型xss

进去一个输入框啊

我们看下源码ctrl+f

搜一下链接“what do you see?”

芜湖

分析一下啊，构造一个

a href='#' onclick="alert(666)"> '>what do you see?</a>

payload就是#' onclick="alert(666)">

抬走下一位

伍·讲一下过滤，其他的我过几天讲吧，困了

随便输入一些内容，提交之后发现页面有回显输入的内容，url中也有输入的内容

然后离开就没，get型

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

直接插，结果给我过滤了

我直接盲猜符号，符号一个个试过了没问题，于是想到了绕过的<script>

在 html 里啊。这个 Onload 关键字就是一个事件，其他的所有标签都没有这个属性，但是 Body 标签是

有的。但是，有一定的局限性，如果 onload 事件在你的代码之前已经被处理了。那就不会触发了。。不

过我们可以继续看看 onerror 事件处理。

<IMG SRC="" onerror="alert('XSS')">

直接插

抬走，没了~拜拜