May 14, 2025 - Finding Open Redirect

As usual the easiest and foremost simple payloads were utilized to examine the endpoint:

?destination=https://sudarshana.io
?destination=//sudarshana.io
?destination=/\sudarshana.io
?destination=\\sudarshana.io
[...]

All were blocked and responded with 400 Bad Request error. However, the following payload was discovered that bypassed the security in-place:

?destination=///sudarshana.io

This was reported and accepted by customer.

June 20, 2025 - Bypassing The Patch

The client requested a retest. The previous payload failed and all other common variations failed as well. This was the point were manual fuzzing entered the scene, and replaced wordlist-based payloads.

Instead of relying on tools alone, an Intruder attack was configured with 4 positional placeholders filled with special characters. The idea was to confuse the parser while preserving a valid redirect structure.

The following characters were used for fuzzing:

$ echo ' ,.,/,\,=,<,>,?,+,&,*,;,:,",{,},|,^,`,#' | tr ',' '\n'
 
.
/
\
=
<
>
?
+
&
*
;
:
"
{
}
|
^
`
#

This 22 letters combination when paired with 4 positions in Cluster Bomb attack configuration generated 234,256 request count. This took a while to run, but results were interesting.

The results were interesting as following was observed in throwing 302 based redirects:

• //://x redirected correctly due to the : character

• //:x//x and //x:x//x were allowed

  

  

• //x:80//x was blocked, likely due to port validation

  

Based on this observation, it was found that we can not get rid of : and no digits are allowed on right of : . Somehow after trying for a while, the emphasize was put upon how URLs support the username:password@host format. If it would be possible to smuggle sudarshana.io in the host section using this syntax, maybe redirect can be achieved. Tried: //user:pass@sudarshana.io/x and other combinations, but it didn’t work.

As performed earlier, fuzzing method was utilized and found that @ , /, # were allowed between password and @host keyword.

This time, the following characters were used for fuzzing. It contains more characters then before mentioned list to not miss on anything:

!
"
#
$
%
&
'
(
)
*
+
,
-
.
/
0
1
2
3
4
5
6
7
8
9
:
;
<
=
>
?
@
A
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
Q
R
S
T
U
V
W
X
Y
Z
[
\
]
^
_
`
a
b
c
d
e
f
g
h
i
j
k
l
m
n
o
p
q
r
s
t
u
v
w
x
y
z
{
|
}
~
 

Of all, all other characters throw ERR_INVALID_REDIRECT error, except @ hence indicating trial of double @ characters.

Surpisingly, this payload worked.

?destination=//user:pass@@sudarshana.io/x

This worked due to browser considering first instance of @ as part of password, while the other @ was assumed to be separator to mark the beginning of the domain name.