Account Takeover via Access Token Leakage

Hello guys! My name is Tuhin Bose (@tuhin1729). I am currently working as a Chief Information Security Officer and Infosec trainer at DSPH. In this write-up, I am going to share one of my interesting findings. So without wasting time, let’s start:

大家好!我的名字是 Tuhin Bose (@tuhin1729)。我目前在卫生和公共卫生部担任首席信息安全官和信息安全培训师。在这篇文章中,我将分享我的一个有趣的发现。所以,不要浪费时间,让我们开始:



Basically the target was a marketing automation website where you can automate your marketing stuffs efficiently. Let’s call it I have already found more than 10 bugs on the target and earned $$$$ from there.

基本上目标是一个营销自动化网站,在那里你可以有效地自动化你的营销工作。我们就叫它 吧。我已经在这个目标上发现了10多个 bug,并从中获得了 $$。

Now while testing the profile update feature, I came across with this interesting request:


PUT /api/account/general-info/ HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/json
accessToken: 795b74eXXXXXXXXXXcba9abd3beaa3ec40b5d3ed
Content-Length: 213
DNT: 1
Connection: close
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site{"company":"DSPH","domain":"","cellphone":"+91-83xxxxxx36","companySize":"2","businessSector":20,"logo":{"height":0,"base64":"","square":true,"width":0}}

They are using accessToken header for changing the profile details (For other authenticated actions, there is no such header). I quickly changed the value of accessToken header with my 2nd account and my 2nd account’s details were changed. I tried to add the accessToken header in other authenticated requests and it got successful and 2nd account’s details were changed. While doing more research on this, I have discovered that the value of accessToken is static i.e. accessToken is same even after logout. That means, if somehow I can get the accessToken of victim, I would be able to takeover his complete account. But the value of accessToken header is non-guessable so I thought to find a way to get victim’s accessToken. But at that time, I was unable to do so. After 3 – 4 days of hunting, I forgot about that and started hunting on other functionalities.

他们使用 accessToken 头更改配置文件详细信息(对于其他经过身份验证的操作,没有这样的头)。我很快用我的第二个账户更改了 accessToken 头部的值,我的第二个账户的详细信息也被更改了。我尝试在其他认证请求中添加 accessToken 标头,成功了,第二帐户的详细信息被修改了。在对此做了更多的研究之后,我发现 accessToken 的价值是静态的,也就是说 accessToken 即使在注销后也是一样的。这意味着,如果我能以某种方式获得受害者的辅助戒指,我就能够接管他的全部账户。但 accessToken 头部的值是不可猜测的,所以我想找到一个获取 accessToken 的方法。但当时,我无法这样做。经过3-4天的搜索,我忘记了这一点,开始搜索其他功能。

Getting Victim’s accessToken


In the website, under email marketing, there is a section where we can make our own email templates. While testing that feature, I tried to upload an image file in the email. There are 2 ways to do so either from my device or via an image url. I tried some DoS, SSRF, XSS and file upload tricks. But it seems that they have a strong file type validation. Also they are fetching the image from client side so SSRF is not possible. Now when I tried to use my burp collaborator’s link to see the request, I noticed an interesting thing:

在网站的电子邮件营销下,有一个部分,我们可以制作自己的电子邮件模板。在测试这个功能的时候,我尝试在邮件中上传一个图片文件。有两种方法可以做到这一点,或者通过我的设备或通过一个图像的网址。我尝试了一些 DoS,SSRF,XSS 和文件上传技巧。但是他们似乎有一个强大的文件类型验证。而且他们正在从客户端获取图像,所以 SSRF 是不可能的。现在,当我试图使用我的 burp 合作者的链接查看请求时,我注意到一件有趣的事情:


Then accessToken is getting leaked in the Referrer header via the token parameter.

然后 accessToken 通过令牌参数在 referer 头中获得泄漏。

So what would be the attacking scenario?


Attacking Scenario


  1. Victim is creating a manual template.
  2. 受害者正在创建一个手动模板。
  3. Victim adds an image to his template from 3rd party website.
  4. 受害者从第三方网站的模板中添加了一张图片。
  5. The 3rd party website owner (or employees) gets victim’s access token (from their logs) and can able to takeover their complete account.
  6. 第三方网站所有者(或员工)获得受害者的访问令牌(从他们的日志) ,并能够接管他们的完整帐户。



I quickly made a POC and send it to them. After one week, they replied me:

我很快做了一个 POC 发给他们,一周后,他们回复我:




06/05/21 — Reported Vulnerability


14/05/21 — Replied with the bounty email


Follow me on Twitter: @tuhin1729_


Thanks for reading. I hope you enjoyed this blog.