使用浏览器访问或调试微信公众号(跳过微信认证)

摘要:
由于大多数公众号web应用程序实际上使用用户的微信认证登录,以下主要提供了一种方法,使用PC端的任何浏览器绕过微信认证来完成登录,然后您可以在浏览器中使用或调试web应用程序。应用程序服务器需要知道谁在访问服务(登录),而在微信公众号应用程序中,登录通常使用静默oauth2。微信验证用户的真实性,并通知应用程序服务器当前用户是谁。我们可以跳过微信应用程序,让第三方模拟完成oauth2授权吗?
 
因为大部分公众号web应用实际登录都是使用用户微信认证登录,下文主要是提供一种方法使在PC端使用任意浏览器绕过微信认证完成登录,后面就可以在浏览器中使用或调试web应用。
 
 
应用服务器(我们自己的第三方应用程序)需要知道是谁在访问服务(登录),而在微信公众号应用中登录一般都是使用静默的oauth2,由微信认证用户的真实性,并通知应用服务器当前用户是哪位(openid)
 
那能不能跳过微信应用程序由第三方来模拟(模拟微信应用程序,骗过微信oauth2服务器)完成oauth2授权?
当然如果您本身就是公众号的管理者那可以直接设置自己的帐号为该公众号开发者帐号,作为开发者帐号其实这些都不要去关心,因为你可以直接使用微信开发者工具去完成授权,然后在开发者工具中进行调试
但是即便拥有公众号开发者权限,大部分基于UI的自动化测试工具无法控制微信开发者工具,基本上都是控制浏览器本身,最终也还是需要在浏览器中提供验证。
 
 
 
 使用浏览器访问或调试微信公众号(跳过微信认证)第1张
 
上图是展示的一个一般情况下的微信授权过程。(https://mp.weixin.qq.com/wiki?t=resource/res_main&id=mp1421140842
 
请求1:一般就是一个对公众号网页的范围,一旦我们自己的应用服务器发现这个用户授权失效(没有相应cookie,或cookie对不上),那服务器返回302,要求用户(微信APP内置 浏览器)跳转至微信授权服务器 『https://open.weixin.qq.com/connect/oauth2/authorize?appid=APPID&redirect_uri=REDIRECT_URI&response_type=code&scope=SCOPE&state=STATE#wechat_redirect』 这里有个关键信息appid,应用服务器会把appid带上,以便微信授权服务器识别是那个公众号来授权了
 
请求2,3:用户按302的指示向微信服务器进行授权,在2,3中微信用户不仅把之前的appid带上,还带上了uni(user information 正常也只在微信跟微信服务通讯中用),跟一个关键的key。(这个key值每次授权不不一样,所以保存下来重放也无效),猜测key是由微信应用程序根据用户信息,公众号信息加密合成的,外部应用程序也是很难仿照。第2步 的 appid与uin向微信服务器换取了uuid,第3步,微信返回了关键的code参数,并通知微信应用程序301到 我们的应用服务的地址。 (实际上一旦应用服务器拿到code,后面的步骤就可以不一定一定需要微信APP参与了)
 
请求4:用户带着微信返回的code请求我们的应用服务器,我们自己的应用服务器拿到code后向微信授权服务器换取网页授权access_token 『https://api.weixin.qq.com/sns/oauth2/access_token?appid=APPID&secret=SECRET&code=CODE&grant_type=authorization_code』 注意这个请求需要带上secret,即表示这个请求只能由我们的应用服务器来完成(secret不能公开)
完成请求5后我们的应用服务器已经拿到openid,access_token ,简单的应用取得openid后即已经能确定用户的身份了。如果需要用户的详细信息可以使openid,access_token用进一步向微信服务器请求
 
结束:一般应用服务器使用用户的openid标识用户,所以得到通过用户请求中的code获取到openid后即表示用户已经被认证,应用服务器此时通常在这个请求的response中加入Set-Cookie将登录信息写入微信浏览器(或者对之前的cookie的认证信息标记为有效)
 
 
通过上面简单的步骤可以看出来无论是客户端(微信)还是应用服务器都有私有的类似secret的数据,来保证各自的不可伪造性。所以无论是想要伪造谁都不是那么简单
 
但是一旦微信oauth2完成后的安全性就会变成一般浏览器的一样,应用服务器验证用户基本上都凭借请求中带的含有十分信息的cookie。也就是说我们只要能在微信公众号(服务号)应用完成认证后将相应的cookie取出并写入浏览器(或者其他调试工具),那浏览器就可以通过后面应用服务器的身份验证(无论当前网页使用怎样的域名甚至是前端人员的本地页面)
 
那现在就是2个步骤:
  • 获取网站授权完成后的cookie(cookie可能会有很多,而我们其实不用关注哪个是认证用户信息用的,全部拿过来就行了)。对于cookie的获取其实还是比较方便的,如果被设置为微信公众号的开发者可以直接使用微信web开发者工具,调试信息包括cookies也都会有,如果不是开发者无法进入调试模式也没有关系,任何针对http协议及更底层协议的抓包工具都可以查看request所携带的cookie信息。
  • 然后就是将cookies信息写入浏览器,如果是浏览器可以在Console中修改cookies,不过要求必须必须带有js执行能力的控制台的浏览器。还是一个就是通过response的head头 Set-Cookie来完成cookie的写入及修改。
 
下面接受一种更简单的步骤完上面2个步骤
使用Fiddler插件freeCookies 完成cookies的操作 (下载及使用说明: https://www.cnblogs.com/lulianqi/p/9481203.html
 
直接在手机微信上打开公众号(订阅号)页面,使用fiddler抓取指定网站任意页面请求(也可以使用PC版微信打开公众号页面)
进入free cookies 标签页(free cookies 插件下载地址 使用说明)
选择目标域名网址的任意页面请求(注意图片及js资源可能不含有cookies信息)点击Get Cookies获取cookie (如下图)
 使用浏览器访问或调试微信公众号(跳过微信认证)第2张
 
打开本地调试页面(也可以是其他域名或是同一域名)
 
使用浏览器访问或调试微信公众号(跳过微信认证)第3张
 
填写目标地址到UrlFilter,勾选Injeck Cookies,在浏览器中对该站点任意请求进行刷新操作(cookie 写入完成后建议取消勾选,或者不要勾选Inject Always)
写入cookies后就可以看到页面再与服务器的交互就已经完成了“登录”
 
使用浏览器访问或调试微信公众号(跳过微信认证)第4张
 
最后下图展示一张京东到家公众号应用直接在chrome,并完成了微信的认证登录。(实际是手机微信的登录后将cookie再写到Chrome里,这里jd需要在浏览器中修改UA,chrome本身就可以直接修改UA)
 
使用浏览器访问或调试微信公众号(跳过微信认证)第5张

以上使用到的 Fiddler插件freeCookies 说明见 https://www.cnblogs.com/lulianqi/p/9481203.html

源代码见github: https://github.com/lulianqi/FreeCookies

免责声明:文章转载自《使用浏览器访问或调试微信公众号(跳过微信认证)》仅用于学习参考。如对内容有疑问,请及时联系本站处理。

上篇前端性能优化之uniappSpring Boot + Spring Cloud 实现权限管理系统 (系统服务监控)下篇

宿迁高防,2C2G15M,22元/月;香港BGP,2C5G5M,25元/月 雨云优惠码:MjYwNzM=

相关文章

关于接入新浪微博第三方登录

  近期,做一个关于联合第三方平台的登录接入,初次接触开放平台,在此做个笔记   开发之前的准备如下:   1、注册新浪微博   2、访问新浪微博开发平台http://open.weibo.com,如果是企业,申请企业接入,并提交相关资料进行审核;如果是个人开发者,就请申请个人开发者应用,一下以开发者为例   3、使用新浪微博的开放API,就需要跟新浪申请...

chrome浏览器跨域请求cookie丢失问题(一直报验证码错误,因为未携带sessionid)

问题描述 一直报验证码错误,问题原因请求头没带sessionid 解决 打开chrome 输入 chrome://flags/ 搜索 SameSite by default cookies 找到SameSite by default cookies和Cookies without SameSite must be secure 将上面两项...

使用Flash上传应该注意的问题。

          使用Flash上传在IE是没问题的,但是在几乎所有的非IE内核浏览器几乎都会遇到一个问题,那就是处理上传的页面或代码无法获取Cookie。不过有趣的事,获取Session是没有问题的。 之前不知道这个bug,害我反反复复弄了好久。在某篇翻译过来的文档找到以下文字:            Cookies and Flash 在Flas...

Web 研发模式的演变

前不久徐飞写了一篇很好的文章:Web 应用的组件化开发。本文尝试从历史发展角度,说说各种研发模式的优劣。 一、简单明快的早期时代 可称之为 Web 1.0 时代,非常适合创业型小项目,不分前后端,经常 3-5 人搞定所有开发。页面由 JSP、PHP 等工程师在服务端生成,浏览器负责展现。基本上是服务端给什么浏览器就展现什么,展现的控制在 Web Ser...

通过Nginx设置HttpOnly Secure SameSite参数解决Cookie跨域丢失

在前面的文章中“谷歌浏览器Chrome 80版本默认SameSite导致跨域请求Cookie丢失”,我们知道 Chrome 升级到80版本后,默认限制了跨域携带cookie给后端。我们也提到了可以修改Chrome的设置或在服务端添加SameSite设置来解决,但是普通的Web框架需要升级到最新版本才支持SameSite属性,升级Web框架成本太高,因此本文...

【原】移动web页面兼容处理的思考

本月收到一份关爱里程碑的邮件,入职满3周年了,从一个懵懂的新人到从容淡定的小油条,在外辛苦打工不容易,能收到一封简单的关怀邮件也是有感欣慰,这里祝愿公司越发展越好。 进入主题,移动网页设计中,很多同学常问一个问题:这么多种移动设备,要兼容哪几类呢? 相信很多人会回答主流的系统ios、android,但是这2个系统又有多个版本,如ios就有4、5、6、7,a...