high难度下，对于xss的防护主要有后端的白名单过滤+重定向，它的漏洞主要在前端的location.herf.substring强制截取url的所有内容，++而url中 # 后的内容是不会发送给后端服务器的（这是url的规则，详情可以去学习一下url的各部分组成和作用），++ 但是会由操作被前端读取，也就是绕过了后端，加上document.write这个及其危险的操作使得可以让 # 和后面的危险代码执行
payload： #<script>alert('xss')</script>
总结：high的后端没有问题，是前端的location.herf.substring强制截取url + document.write危险执行导致的xss漏洞
其实再早一点的版本 靠属性逃逸+手动闭合 '></option><script>alert('xss')</script> 这个payload也是可以的（ '> 用来闭合前面的<option value:' </option>来闭合前面的<option>，这样<script>标签就可以执行了，要不然在<option>标签里所有的内容都会被视为这个标签的内容而不是一个标签去执行），但是后来版本更新后后端过滤特殊符号更加严格了，所以就只能靠 # 绕过后端了
而impossible与high相比其实只有两个主要的地方不同（因为版本问题可能还有由更多的不同操作处理的更加彻底，我只是介绍我这个版本的不同，其他版本的一些其他操作我会在最后说）
1.impossible的后端是没有任何有效代码的
它后端不需要做任何事情，防护都在客户端。
2.也就是它的前端，其实只有一个地方不同
这是两个难度的前端代码
其实impossible和high前端代码一样只是impossible在下图这个地方没有对lang变量进行decodeURI
也就是你的payload里的<>还是编码后的状态，没有decodeURI解码被视为<option>的纯文本无法执行
就像payload： #<script>alert('xss')</script> 的<>都是编码状态不会被识别
还有在index.php里对于impossible难度，会直接把default置空或者直接重定向，所以burp发明文也不行