Taking down the SSO, Account Takeover in 3 websites of Kolesa due to Insecure JSONP Call

InfoSec Write-ups – Medium–

Taking down the SSO, Account Takeover in the Websites of Kolesa due to Insecure JSONP Call

Hello, this post is about how I could take-over any account of Kolesa’s websites using Single Sign-On. There was an insecure JSONP call which could break the security of the entire SSO mechanism.

What is JSONP?

JSONP is a method for sending JSON data to other domain.

  • Can load an external JavaScript object
  • Does not use the XMLHttpRequest object
  • Less secure
  • Bypassed SOP in browsers
Example of JSONP request/response

Single Sign-On

Information gathering revealed that Kolesa websites use SSO, the authentication server was:


The websites used SSO were:

  1. https://market.kz
  2. https://krisha.kz
  3. https://kolesa.kz

The general workflow of how SSO works:

In this authentication model since a domain can not set an authentication cookie for the others, an authentication token should be transferred between the authentication server and other domains. Considering the orange box in the image above, each site should save a cookie after verifying the authentication token. In addition, authentication server also saves its cookie, so after a couple of HTTP requests I found the authentication cookie name for each Kolesa website:

JSONP Call to Handle SSO

The JSONP call is used for further authentications. If a user has already logged-in in any of three websites, a JSONP call is made to authenticate the user in. The reason for this action is the ease of implementation. Since the origins of domains are different, the Kolesa websites should have implemented the Cross Origin Resource Sharing to transfer the authentication, but they’ve decided to use JSONP to avoid CORS setup.

The point is, once a user is logged in for examplekosela.kz, they have a ccid cookie in id.kolesa.kz, an authentication token to transfer the authentication, and a ssid cookie in kosela.kz. After that, if the user wants to log-in in the other websites, it happens by just a click, since id.kosela.kz has authentication cookie, it immediately generates authentication token and the user will have the corresponded authentication cookie on the website.

Based on the picture above, phase 4 shows how the JSONP call is made and how the authentication token can be turned into authentication cookie in a domain. The cause of JSONP call:

If the user has already been authenticated by id.kolesa.kz, the following response is expected:

HTTP/1.1 200 OK
Server: openresty/
Date: Mon, 19 Aug 2019 16:43:26 GMT
Content-Type: text/javascript;charset=UTF-8
Connection: close
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Backend-Server: auth-be3.alaps.kz.prod.bash.kz
X-Bug-Bounty: Please report bugs and vulnerabilities to bugs@kolesa.kz
Content-Security-Policy: frame-ancestors 'self' http://webvisor.com https://webvisor.com
Strict-Transport-Security: max-age=31536000
Content-Length: 627
window.xdm = {
sess: {
is_authenticated: 1,
token: 'xG3ROFWcb7pnXSnMr8MkaBvH01pLlCHqn0sPt0PVL6BBWYdQPdvA31tBi6dLB5njv5jhMW3y/cGBMRB9LC/69zv867wweaDhkxX6arGVzYDy2q+J52nkOQJ+62rR9wLPYJGyEpNGWeOBSp12vugXZUPq2RA6FMptbNkGQpJFjAclXSzduj7wJJgAUONMj3mkkElM1nWmIllrl5zDEz6s7077E4ibx//BvnfZ9AIC/9b2PB+QzVKOnSzzcr9wSXqta9TEDHvjopqbUd4UE2xSMRSj/zxPQlCba5632hcIXnzZB3A8fvahvf2Hm5ssuC+cwuKU8pAdE/qcGQSJKdhpYXxntGkQiLdEAliyCq+fahS4itb6HlFH/+H20RsZA+cjyaF7ntnW5tYY31vxJXovrR3oinaj9YDSzoCZYMDYPJMdk+HuZhRuxxEl8abuNlGD0aCt2GCPV7GY0J9Ma7AcPw=='

(function ($) {
"use strict";
$.xdm = window.xdm;

As it’s been seen there is an object named sess containing the two properties named is_authenticated and token. This object is responsible to transfer authentication. At this moment the user has authentication token but not authentication cookie of the current website, so the second call is made:

The JavaScript code:

Vulnerable External JavaScript Object

The question is, an arbitrary origin can extract the authentication token? of course, it can because the JSONP call bypasses the Same Origin Policy.

The vulnerability found, account takeover by a single click 🙂

The Exploitation Phase

The scenario is simple:

  1. Setting up a page calling JSONP on behalf of any user
  2. Tricking authenticated user to visit our malicious website
  3. Sending authentication token by the user to our website
  4. logging-in as the victim and doing bad stuff

The exploit code (client-side + server-side call):


Here is the video POC:


Taking down the SSO, Account Takeover in 3 websites of Kolesa due to Insecure JSONP Call was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

View original article on InfoSec Write-ups – Medium

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s