Today In this post, I will be sharing a unique writeup on SQL injection with
Authorization Headers token.
A little bit intro to Authorization Tokens,
=> An Authorization token is generated and signed by the servers and is used to
verify the users by unique tokens.
=> After the successful login, the server sends an authorization token, and
web developers often store it in the browser's local storage or session
=> Modern Websites use JWT(JSON Web Tokens) for User Authorization. It doesn't
mean that each Authorization token is JWT. It depends on the backend and the
Framework that the website uses,
Without wasting time, let's jump into the story
I am not a regular Bug Bounty hunter. You can say I am a seasonal Bug bounty hunter. I was bored and tried to search for some private bug bounty programs through
google dorks, And Randomly selected a program for hunting. I did not do basic recon like Subdomain enumeration or any Dorking as I started with the main target.
For me, it was a typical day. I just fired up the Burp suite and opened the
target site. as per the company policy, I am unwilling to reveal the target.
With the help of the Wappalyzer Plugin, I have noticed that the target runs on
PHP. For me, PHP is vulnerable by nature. As a Web developer, I have plenty of
experience building websites in PHP and fixing vulnerabilities.
While attacking targets, I have a practice of directory brute-forcing and
checking the robots.txt file at the initial stage of my recon process.
I used Dirsearch to find the hidden directories, but no luck. I did not get
anything fishy other than the admin page.
I tried Opening the admin page by visiting target/admin/
But No Luck it throws an error 403 Forbidden
I did not give up too quickly, again tried to Fuzz inside the admin page using
Dirsearch. This time events page got 200 responses.
Without any delay, I have opened the page target/admin/events/
I have noticed that the page is a regular login page, where it has two ways to
log in, one for the author and another for the super admin
Exploitation Starts here
As I said, there are two links for login pages, One for author and another for
admin, I have choose the first one, and It redirected me to
and it pops up for username and password, I have started giving wrong
credentials and observed the response from the server, and after playing for a
while, I have supplied the username and password as 1'
Luckily it displayed the SQL error.
I tried to reproduce it, but it doesn't work, and the login popup is wholly
gone. Even after refreshing the page, the error message is displayed there, as
I thought it might be some backend error.
I have gone to the burp proxy history and noticed no regular
POST form data sent or JSON data.
I was gone blank for a while and later opened the link in Incognito mode, and
the popup appeared for login. Again observed the request and response.
Found Nothing :P
Later, I noticed a Header Value Authorization with a token.
As a web developer, I know How the Authorization tokens work, and I Have good
Knowledge of PHP, MERN stack and a bit of Django Framework. I can easily guess
the tokenization developers use
The Header Looks as follows.
Authorization: Basic Base64Values
You might often see this Header in Modern Web applications.
Authorization: Bearer <TOKEN>
Pro Tip: On the backend side, in most cases, the Bearer is ignored, and
developers match the token with the issued token. If that was a JWT, then
developers often decode it instead of verifying that's where Improper Access
Control, Account takeover occurs.
Let's continue the story
I have sent the request to the repeater, selected the Token and decoded it
using the Burp decoder, as I guessed the encryption type by its length and nature. It was not a JWT, but the base64 value of 1':1'
I quickly remembered the Sqlmap tool, captured the entire request, and saved
it to a text file.
And tried to run sqlmap, but the problem occurs at base64 encoding. Though sqlmap supports base64 encode, the scenario is there was a colon : between the
as the application behaves as follows
It takes the username and passwords and encodes the values with base64 with
the separation of :
Though I was good at manual SQL injection exploitation, there
was a live mode of base64 encoding and applying the payload in the repeater. For that, I tried
to find the Number of columns for the target.
and supplied the payload for username and password as: 1' Order By 1-- -:1' Order By 1-- -
The Authorization payload is as follows.
base64 encoded and sent, no SQL error and a regular unauthorized error was
tried to increment those columns, but error throws. I came to know that there
was only one column and tried injecting the union statements.
While injecting the payload:
1' Union Select 1-- -:1' Union Select 1-- -
I was successfully logged in to the admin panel and able to modify the content
Sorry I have to blur some info,
here is the POC without blur
I hope you guys liked this write up, follow us for more such unique writeups
Post a Comment