token | 易学教程

Jmeter接口测试实战-数据传递

阅读更多关于 Jmeter接口测试实战-数据传递

Jmeter接口测试实战-数据传递接口与接口之间没有关联的测试是缺乏意义和没有灵魂的,只有数据在不同接口之间传递才能勾画出业务场景重要的链路. 我们用较为通用的http/https协议,接口普遍返回json方式为例. 举例场景: 比如电商平台,用户登录后产生令牌token, 其他接口拿着这个token判断用户是否登录才能进行相关操作, 当用户将商品加入购物车支付完成后,系统按照规则生成订单号, 同时会在该用户的全部订单列表中查到全部订单和相应状态. 要点分析: 1. login接口登录后生成token 2. pay支付接口拿到token正确的情况下,支付完成后生成订单号 3. orderList 订单列表接口需要有token和订单号等为入参必填项,查出该用户的所有订单状态有了Idea就开始动手吧! 手头有三个接口,来模拟上面场景,同时也为了演示方便 login登录 //生成token 创建用户 //生成用户id 删除用户 //拿到创建用户接口id, 并删除该用户前提条件: 需要使用Json取样器, Jmeter默认没有提供, 可用plugin-manager安装, 也可以去jmeter官网把jar包下载后放在%jmeter_home%/lib/ext/目录下,重启jmeter生效. 第一步: 在线程组内新建三个sampler 登录接口入参方式采用json,

Spring Security JWT

阅读更多关于 Spring Security JWT

首先需要创建2个过滤器. JwtLoginFilter 和 JwtAuthenticationFilter . JwtLoginFilter 用来处理用户登录请求. JwtAuthenticationFilter 用来处理JwtToken的验证解析. /** * @author: 阮胜 * @date: 2018/7/10 8:42 */ public class JwtLoginFilter extends AbstractAuthenticationProcessingFilter { private static final String POST = "POST"; private AuthenticationSuccessHandler successHandler = new JwtLoginSucessHandler(); private AuthenticationFailureHandler failureHandler = new JwtLoginFailureHandler(); public JwtLoginFilter(AuthenticationManager authenticationManager) { super(new AntPathRequestMatcher("/user/login", "POST"));

ThinkPHP5使用jwt进行会话验证

阅读更多关于 ThinkPHP5使用jwt进行会话验证

以往，没有做过前后端分离的项目之前，都是服务器渲染的模板，然后用cookie和session进行账号的权限验证或者是登录状态的管理。后来接触了vue和小程序之后，在进行前后端分离的时候，就会遇到权限验证和登录会话保存。因为HTTP协议是开放的，可以任人调用。所以，如果接口不希望被随意调用，就需要做访问权限的控制，认证是好的用户，才允许调用API。 JWT优点 1：服务端不需要保存传统会话信息，没有跨域传输问题，减小服务器开销。 2：jwt构成简单，占用很少的字节，便于传输。 3：json格式通用，不同语言之间都可以使用。 jwt由三部分组成：头部（header) 载荷（payload) 包含一些定义信息和自定义信息签证（signature) 所以这里就会用到bearer的令牌访问，就是jwt；定义：为了验证使用者的身份，需要客户端向服务器端提供一个可靠的验证信息，称为Token，这个token通常由Json数据格式组成，通过hash散列算法生成一个字符串，所以称为Json Web Token（Json表示令牌的原始值是一个Json格式的数据，web表示是在互联网传播的，token表示令牌，简称JWT) 首先我们从GitHub处用 composer require firebase/php-jwt 下载firebase/php-jwt，怎么用composer我就不累述了

JWT token心得

阅读更多关于 JWT token心得

token的组成 token串的生成流程。 token在客户端与服务器端的交互流程 Token的优点和思考参考代码：核心代码使用参考，不是全部代码 JWT token的组成头部（Header），格式如下： { “typ”: “JWT”, “alg”: “HS256” } 由上可知，该token使用HS256加密算法，将头部使用Base64编码可得到如下个格式的字符串： eyJhbGciOiJIUzI1NiJ9 1 有效载荷（Playload）： { “iss”: “Online JWT Builder”, “iat”: 1416797419, “exp”: 1448333419, ……. “userid”:10001 } 有效载荷中存放了token的签发者（iss）、签发时间（iat）、过期时间（exp）等以及一些我们需要写进token中的信息。有效载荷也使用Base64编码得到如下格式的字符串： eyJ1c2VyaWQiOjB9 1 签名（Signature）：将Header和Playload拼接生成一个字符串str=“eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyaWQiOjB9”，使用HS256算法和我们提供的密钥（secret,服务器自己提供的一个字符串）对str进行加密生成最终的JWT，即我们需要的令牌（token），形如：str.”签名字符串”。

横向越权纵向越权安全漏洞的解决

阅读更多关于横向越权纵向越权安全漏洞的解决

一.什么是横向越权和纵向越权. 　　1.横向越权：攻击者想访问与他权限相同的用户，例如：在忘记密码回答问题成功后，会跳到重设密码的页面，这个时候如果用户随意填用户名和密码，而且数据库也刚刚好存在这个用户时，那么就会修改其他用户的密码，这就是横向越权　　2.纵向越权：低级别攻击者想访问高级别用户的资源。二.怎么解决　　1.横向越权：在回答问题时，成功的时候，会在服务端根据用户名生成一个token（随机数和用户名的映射）保存在本地缓存里，具体如下： 1 　//这段代码是在检查回答问题的答案的接口里面的，也就是在回答问题时生成这个token，标志这个用户名　　　　　　　 String forgetToken = UUID.randomUUID().toString(); 2 TokenCache.setKey(TokenCache.TOKEN_PREFIX+username,forgetToken); 3 return ServerResponse.creatBySuccess(forgetToken); 　　这里使用Guaua本地缓存，用来保存token，这个token会定期失效具体代码如下： public class TokenCache {　　 //前缀 public static final String TOKEN_PREFIX = "token_"; private

Pikachu漏洞练习平台实验——CSRF（三）

阅读更多关于 Pikachu漏洞练习平台实验——CSRF（三）

概述 CSRF 是 Cross Site Request Forgery 的简称，中文名为跨域请求伪造在CSRF的攻击场景中，攻击者会伪造一个请求（一般是一个链接）然后欺骗目标用户进行点击，用户一旦点击了这个请求，这个攻击也就完成了所以CSRF攻击也被称为“one click”攻击攻击场景例子 lucy想要在购物网站上修改购物地址，这个操作是lucy通过浏览器向后端发送了请求。这个请求里面包含了lucy的新有货地址，如果是通过GET提交的，那么会以URL传参的方式的方式将新的地址提交给后台，类似上图中的URL，相当于点了链接就能修改个人信息。如果这时候攻击者想要修改lucy的信息怎么办？那么他需要取得lucy的账号，获得登录权限。这时候他可以将修改个人信息的请求伪造一下，构造类似下图中的URL，引诱lucy在登录状态下进行点击，这样攻击就成功了。 CSRF攻击需要条件 ① 目标网站没有对修改个人信息修改的请求进行防CSRF处理，导致该请求容易被伪造因此，判断一个网站有没有CSRF漏洞，其实就是判断对关键信息（密码等）的操作（增删改）是否容易被伪造 ② lucy点击伪造的请求链接时有登录状态（已经登陆了目标网站），如果lucy没有登录，那么即便lucy点击了链接也没有作用从CSRF的利用条件来看，CSRF的利用难度会大一些

pikachu的csrf攻击

阅读更多关于 pikachu的csrf攻击

一、get型csrf 1.首先登陆一下，lucy：123456 发现能够登陆 2.我们尝试修改一下个人信息并提交，同时利用BurpSuite抓包查看修改个人信息的请求内容，我们改一下地址从提交的请求来看，后台没做CSRF token，同时也是通过GET请求来提交修改信息，我们拿到这个，修改一下，然后让lucy点击就好，我们构造的URL中把地址add改为hacker。lucy一点击就修改了地址。 3.GET请求修改个人信息，所有的参数都在URL中体现，这种方式使比较好利用的，我们只要能够伪造出来这个链接，把对应的参数内容修改成为我们需要的值，让带有登录态的用户去点击就完成了我们的攻击。二、post型csrf 1、如果是POST型的，所有参数在请求体中提交，我们不能通过伪造URL的方式进行攻击这里的攻击方式跟XSS中POST类型是一样的，攻击者可以搭建一个站点，在站点上做一个表单，诱导lucy点击这个链接，当用户点击时，就会自动向存在CSRF的服务器提交POST请求修改个人信息。在自己的机子上编写一个html文件 <html> <head> <script> window.onload = function() { document.getElementById("postsubmit").click(); } </script> </head> <body> <form

pikachu--CSRF

阅读更多关于 pikachu--CSRF

web安全实验报告实验二 CSRF 学生姓名倪文锴年级 2017级区队实验班指导教师高见一、概述 CSRF 是 Cross Site Request Forgery 的简称，中文名为跨域请求伪造在CSRF的攻击场景中，攻击者会伪造一个请求（一般是一个链接）然后欺骗目标用户进行点击，用户一旦点击了这个请求，这个攻击也就完成了所以CSRF攻击也被称为“one click”攻击（1） CSRF--（get）首先先进入登录界面点击修改个人信息，抓包得到链接从提交的请求来看，后台没做CSRF token，同时也是通过GET请求来提交修改信息，我们拿到这个，修改一下，然后让kevin点击就好，我们构造的URL中把地址add改为cn。kevin一点击就修改了地址。 192.168.141.1:88/pikachu-master/vul/csrf/csrfget/csrf_get_edit.php?sex=%E7%94%B7&phonenum=123456789&add=cn&email=7955526516%40qq.com&submit=submit GET请求修改个人信息，所有的参数都在URL中体现，这种方式使比较好利用的，我们只要能够伪造出来这个链接，把对应的参数内容修改成为我们需要的值，让带有登录态的用户去点击就完成了我们的攻击。修改网址，完成修改

pikachu-csrf

阅读更多关于 pikachu-csrf

一、get型csrf 1.首先登陆一下，lucy：123456 发现能够登陆 2.我们尝试修改一下个人信息并提交，同时利用BurpSuite抓包查看修改个人信息的请求内容，我们改一下地址从提交的请求来看，后台没做CSRF token，同时也是通过GET请求来提交修改信息，我们拿到这个，在burp suite里直接修改，把构造的URL中把地址add改为cambridge。然后grady一点击就修改了地址。 3.GET请求修改个人信息，所有的参数都在URL中体现，这种方式使比较好利用的，我们只要能够伪造出来这个链接，把对应的参数内容修改成为我们需要的值，让带有登录态的用户去点击就完成了我们的攻击。二、post型csrf 如果是POST型的，所有参数在请求体中提交，我们不能通过伪造URL的方式进行攻击这里的攻击方式跟XSS中POST类型是一样的，攻击者可以搭建一个站点，在站点上做一个表单，诱导lucy点击这个链接，当用户点击时，就会自动向存在CSRF的服务器提交POST请求修改个人信息。在自己的机子上编写一个html文件 <html> <head> <script> window.onload = function() { document.getElementById("postsubmit").click(); } </script> </head> <body> <form

认证(Authentication)与授权(Authorization)

阅读更多关于认证(Authentication)与授权(Authorization)

认证与授权漫谈认证与授权 Intro # 认证与授权一直以来都是很多人在讨论的话题，之所以想这次谈一谈认证和授权，主要是因为最近看到许多文章都把认证和授权混为一谈，把认证方式当作是授权方式。所以想写篇文章谈谈我眼中的认证与授权 Authentication # 什么是认证？认证是一个尝试解决我是谁的问题的过程。以一个 HTTP 请求为例，认证就是尝试从请求信息中获取用户信息的过程，有一点需要特别注意：认证并不等于一定有用户信息，有些文章直接把认证等同于有用户信息，再次强调，认证就是认证，一定有用户信息就相当于是要授权了，有用户信息只能说明某种认证方式认证成功了，经过某种反射光hi认证之后，还是没有用户信息，只能说明这种认证方式认证失败，认证失败并不代表授权失败。认证的方式可以多种多样，而且我们可以同时使用多种认证方式：比如说 Cookie 认证、JWT 认证以及其他自定义 Token 认证，之所以称之为认证方式，是因为他们只提供解决我是谁的解决方案，比如 Cookie 认证会尝试从 HTTP 请求携带的 Cookie 信息中获取用户信息，而 JWT 则是从 Authorization 请求头中的 Bearer Token 获取用户的信息，自定义的Token 也类似。甚至我们可以做一些扩展，做一些不一样的认证，比如说根据 Header/QueryString

订阅 token