payload

云中树莓派（3）：通过 AWS IoT 控制树莓派上的 Led 云中树莓派（1）：环境准备 云中树莓派（2）：将传感器数据上传到AWS IoT 并利用Kibana进行展示 云中树莓派（3）：通过 AWS IoT 控制树莓派上的Led 云中树莓派（4）：利用声音传感器控制Led灯 1. Led 连接与测试 在某宝上买了几样配件，包括T型GPIO扩展板、40P排线、亚克力外壳、400孔面包板、若干杜邦线。现在我的树莓派长得这个样子了： 不由得感谢神奇的某宝，这些东西每一样都不超过三四块钱。 1.1 接线 以下几个简单步骤就完成了接线： 将排线一头插在树莓派的40个pin脚上，将另一头插在扩展板上。要注意方向，多试几次。还要注意在树莓派关机时候再插入。 把扩展板插在面包板上。 把Led 的长脚（正极）插在面包板第6行的任何一个孔内（对应GPIO18），将其短脚（负极或接地）插在第7行的任何一个孔内（对应GND）。 简单说下面包板。刚拿到手时还有点不知所措，稍微研究一下后就简单了。面包板为长方形，长边的两边是为了接电源的，每个长边都是联通的；中间区域内，每行内是联通的。 1.2 简单测试 下面的 python 能让led 灯每两秒钟亮一次： import RPi.GPIO as GPIO import time PIN_NO=18 GPIO.setmode(GPIO.BCM) GPIO

Vuex 是什么？？？？ 如果用官方的话说，是以下这段： Vuex 是一个专为 Vue.js 应用程序开发的状态管理模式。它采用集中式存储管理应用的所有组件的状态，并以相应的规则保证状态以一种可预测的方式发生变化。Vuex 也集成到 Vue 的官方调试工具 devtools extension ，提供了诸如零配置的 time-travel 调试、状态快照导入导出等高级调试功能。 但是当我真的入门 Vuex的时候他主要难的地方是 在5个应用中不断的使用； 五个应用分别为：State，Getter，Mutation，Action，Module 这五个应用~ 接下来我就带大家来一起写一次简单的使用方法； 首先就是得下载 Vuex； npm i vuex -S 其次我们要在 vue-cli中创建好自己的项目目录 😁 然后跟我一样 在 src 中创建 一个主🐖目录（容器） 起名叫 store；因为每个 Vuex 应用的核心就是 store （仓库的意思）； Vuex 的状态存储是响应式的。当 Vue 组件从 store 中读取状态的时候，若 store 中的状态发生变化，那么相应的组件也会相应地得到高效更新。 然后在 store的目录下 创建一个 store.js 用来接受之后各个应用的返回的东西~ 👍 然后把 这个 store 注册到 main.js 中 成为 vue的属性 弄好了之后呢，

XSS 介绍 XSS，全称Cross Site Scripting，即跨站脚本攻击，某种意义上也是一种注入攻击，是指攻击者在页面中注入恶意的脚本代码，当受害者访问该页面时，恶意代码会在其浏览器上执行，需要强调的是，XSS不仅仅限于JavaScript，还包括flash等其它脚本语言。根据恶意代码是否存储在服务器中，XSS可以分为存储型的XSS与反射型的XSS。 DOM型的XSS由于其特殊性，常常被分为第三种，这是一种基于DOM树的XSS。例如服务器端经常使用document.boby.innerHtml等函数动态生成html页面，如果这些函数在引用某些变量时没有进行过滤或检查，就会产生DOM型的XSS。DOM型XSS可能是存储型，也有可能是反射型。 XSS利用的常见用途： 盗取用户 cookies 劫持会话 流量劫持 网页挂马 DDOS 提升权限 ... 本次先介绍反射型XSS： Reflected Cross Site Scripting 反射型XSS，非持久化，需要欺骗用户自己去点击带有特定参数的XSS代码链接才能触发引起（服务器中没有这样的页面和内容），一般容易出现在搜索页面。 Low Security Level <?php // Is there any input? if( array_key_exists( "name", $_GET ) && $_GET[

喜接新项目往往预示的会出一堆问题。解决问题的同时往往也就是学到更多东西的时候，这也许就是学习到新东西最直接最快速的方法吧！ 小编经过努力，新项目终于过测试了，可是被苹果大大给拒了，好苦啊，最近的审核真的是没有谁了。这回被拒是因为项目中存在私有api，下图为被拒信息。 这就坑了啊，这么大一个项目，我如何定位呢？ 如果是代码里面运用到私有api，那就简单了，直接 command+Shift+F ，就可以定位了！ prefs:root= 就是原来代码里面的，小编找到后果断删除了！ 最麻烦的就是在第三方SDK中的私有api( com.apple.springboard.lockcomplete )，实在不知道如何定位了。在被拒消息中也提示了我们如何定位，百度+Google走一波，学习了一下，随便写个笔记。好记性不如烂笔头嘛！ 方法1：strings检测 这个方法是我在被拒信息中看到的苹果大大建议的方法，步骤如下： 1、获取release的ipa包，打包是选择的方式为：App Store 2、将 .ipa 修改为 .zip，减压，获取到两个文件夹Payload、Symbols 3、打开命令行，cd 到 Payload 里面的 app，然后使用 strings 命令进行查找 strings - -a -arch armv7 "工程名" | grep com.apple.springboard

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

一、JWT JSON Web Token（JWT）是目前最流行的跨域身份验证解决方案。虫虫今天给大家介绍JWT的原理和用法。 1.跨域身份验证 Internet服务无法与用户身份验证分开。一般过程如下。 1.用户向服务器发送用户名和密码。 2.验证服务器后，相关数据（如用户角色，登录时间等）将保存在当前会话中。 3.服务器向用户返回session_id，session信息都会写入到用户的Cookie。 4.用户的每个后续请求都将通过在Cookie中取出session_id传给服务器。 5.服务器收到session_id并对比之前保存的数据，确认用户的身份。 这种模式最大的问题是，没有分布式架构，无法支持横向扩展。如果使用一个服务器，该模式完全没有问题。但是，如果它是服务器群集或面向服务的跨域体系结构的话，则需要一个统一的session数据库库来保存会话数据实现共享，这样负载均衡下的每个服务器才可以正确的验证用户身份。 例如虫虫举一个实际中常见的单点登陆的需求：站点A和站点B提供同一公司的相关服务。现在要求用户只需要登录其中一个网站，然后它就会自动登录到另一个网站。怎么做？ 一种解决方案是听过持久化session数据，写入数据库或文件持久层等。收到请求后，验证服务从持久层请求数据。该解决方案的优点在于架构清晰，而缺点是架构修改比较费劲，整个服务的验证逻辑层都需要重写，工作量相对较大

一、 MQTT 简介 MQTT 协议（ Message Queuing Telemetry Transport ）（消息队列遥测传输）是一种基于发布 / 订阅 模式 的 “轻量级”消息协议，是 IBM 公司于 1999 年提出的，由 Andy Stanford-Clark （ IBM ）和 Arlen Nipper （ Eurotech ，现为 Cirrus Link ）于 1999 年开发 。 MQTT 是一个基于 TCP 的发布订阅协议，设计的初始目的是为了 适用于极有限的内存设备和低带宽的不可靠网络 通信，非常适合物联网通信。 MQTT 协议目前在 IoT （ Internet of things ，物联网）、小型设备应用、移动应用等方面有较广泛的应用。 二、协议原理 与 HTTP 及其请求 / 响应范例相比， MQTT 协议使用发布 / 订阅体系结构。发布 / 订阅是事件驱动的，可以将消息推送到客户端。中央通信点是 MQTT 代理，它负责调度发送者和合法接收者之间的所有消息。向代理发布消息的每个客户端都在消息中包含一个主题。主题是代理的路由信息。每个想要接收消息的客户端都订阅某个主题，并且代理将具有匹配主题的所有消息传递给客户端。 MQTT 协议提供一对多的消息发布，可以解除应用程序耦合，信息冗余小。该协议需要客户端和服务端，而协议中主要有三种身份：发布者（

1、ttcp作用：检测TCP吞吐量 测试的数据是每秒传输的字节数 带宽 Mb/s 测试程序的性能指标： 传输带宽，QPS/TPS， 以及 CPU利用率，延迟等等。 2、ttcp应用层协议： 3. 尝试自己用C语言写出简单的TTCP程序 先发送一个SessionMessage包中number表示消息的条数，length表示每条消息的长度 PayloadMessage包中存放数据的长度和数据 服务端接收函数 void receive(const Options& opt) { int sockfd = acceptOrDie(opt.port); struct SessionMessage sessionMessage = { 0, 0 }; if (read_n(sockfd, &sessionMessage, sizeof(sessionMessage)) != sizeof(sessionMessage)) { perror("read SessionMessage"); exit(1); } sessionMessage.number = ntohl(sessionMessage.number); sessionMessage.length = ntohl(sessionMessage.length); printf("receive number = %d\nreceive

一、前言 为什么要先说Requests库呢，因为这是个功能很强大的网络请求库，可以实现跟浏览器一样发送各种HTTP请求来获取网站的数据。网络上的模块、库、包指的都是同一种东西，所以后文中可能会在不同地方使用不同称谓，不要迷惑哦。 结合一个实例来讲解吧。我的一个设计师小伙伴常去一些设计类网站收集素材，其中有个网站Unsplash里面美图特别多，所以想要把里面的图片都保存下来，这样咱们的小爬虫就登场了。说干就干，赶紧开始吧。 先来准备环境 二、运行环境 系统版本 我使用的是Windows10。 好多小伙伴使用的是Mac，配置上基本相同。由于我多年混迹于微软的开发平台，经常使用Visual Studio、SQL Server啥的，用Windows用习惯了（其实主要是因为Qiong穷！）。所以这个教程我就以Windows系统为例了。 Python版本 我电脑装了好多个Python版本（学一个装一个。。。），不过推荐使用Anaconda这个科学计算版本，主要是因为它自带一个包管理工具，可以解决有些包安装错误的问题。去 Anaconda官网 ，选择Python3.5版本，然后下载安装。 IDE 我使用的是PyCharm，是专门为Python开发的IDE。这是JetBrians的产品， 点我下载 。 三、requests 库的安装 使用Anaconda 版本的得小伙伴儿

概念： 竞争条件是系统中的一种反常现象，由于现代Linux系统中大量使用并发编程，对资源进行共享，如果产生错误的访问模式，便可能产生内存泄露，系统崩溃，数据破坏，甚至安全问题。竞争条件漏洞就是多个进程访问同一资源时产生的时间或者序列的冲突，并利用这个冲突来对系统进行攻击。一个看起来无害的程序如果被恶意攻击者利用，将发生竞争条件漏洞。 曾经出现过的漏洞： 网上大部分是使用转账的列子来说明的，曾经乌云提现环节就出现过这个漏洞，当时大神也是提现到账3000块，官方24小时紧急修复，承认提现有效。美滋滋，但愿乌云早日归来，仍是少年。 今天在渗透测试中，刚好碰到了此类漏洞，就简单实践下。 使用一张200块的优惠券，可以重复下单多次，达到一张优惠券，多次使用的目的。 基本方法就是，在提交订单的时候，抓取包，然后然后然后构造脚本，进行多线程并发操作。 备注：这最初一直使用burp intrude 的模块，设置如下： payloads payload type: Null payloads payloads options [Null payloads] Contunue indefinietly Options Number of threads: 20 死活测试不出来，不知道是不是因为这个模块，默认会发送一次请求包的原因。 最后构造Python脚本，成功复现此漏洞。 coupon_poc.py