I have a scenario with 2 sites. Site 1 is mysite.com and Site 2 is secondurl.com.

Site 1 is using Wordpress. There, I did a Javascrit/jQuery routine that checks if a given url parameter comes in. If the parameter "p" exists on the query string, I do a replacement on all URLs on my homepage that point to Site 2, now, passing this give value that came in through query string, like this:

<a href="secondurl.com">Link </a>


<a href="secondurl.com?p=value">Link </a>

"Value", as I mentioned before, is what comes via query string, when Site 1 is visited. Like:


I don't treat the query string, I just get the value of p and generate the second url with that parameter. Both sites are on the same server, Site 1 is using wordpress and Site 2 pure PHP.

Does this url replacement using jQuery opens any vulnerability on my server that has both sites? If yes, is it possible that someone could place python or php scripts on my server using that vulnerability?

  • What function do you use to update your links? It's a surprisingly important details, since some methods provide protection by default, and some don't. Commented Dec 4, 2019 at 23:33
  • Hi Conor, I was just getting the p value and adding "?p=value" on the second url. Not using any kind of treatment on the Site 1 side. Only on the Site 2 side. There, I treat the GET parameter with PHP. I use functions like htmlspecialchars, strip_tags, and before I communicate with the database I use mysql_real_escape_string with prepared statements. Does this still opens a vulnerability?
    – churros
    Commented Dec 5, 2019 at 11:58
  • Yes, but how do you add ?p=value? That's the part that's importance. As for those other things, that's a completely different question, and won't be easy to answer in comments. Using prepared statements is the important part for preventing SQLi, so if you are using those you don't actually need mysql_real_escape_string Commented Dec 5, 2019 at 13:37

2 Answers 2


tl/dr: Whether or not you have a reflected XSS vulnerability depends on the exact method you use to append the data. Therefore you should specifically check your chosen method to make sure it is safe. Modern javascript frameworks typically take care of these things automatically for you, but jQuery doesn't, so attention to detail is critical.

You don't specifically have to worry about the interaction between site 1 and site 2. The reason is because site 2 needs to be secure in all the normal ways anyway (use prepared queries, etc...). A malicious user wouldn't use site 1 to attack site 2 (in this case), because if they wanted to they could just go attack site 2 directly.

So the main question here is whether or not site 1 is vulnerable. To be clear, the concern would be over the possibility of a reflected XSS attack (which is what ExecutionByFork mentions in their answer). To give a simple example, what happens if a user visits this URL:


If the way you add the p parameter to all other links implicitly treats its contents as HTML, then you will end up injecting an actual script tag into the page, executing the attackers javascript in a classic reflected XSS attack.

So the question is: do you append the p parameter in a way that potentially treats the data as HTML (creating a vulnerability), or do you append it in a safe way? The answer to that question comes down to the specific methods you use to append the data. Let me give two examples:

Largely safe: .prop()

Using the jQuery .prop method is safe because it falls back on setting the property of the corresponding DOM node. By doing it this way there is no opportunity to escape the property context. In essence, whatever you send in to the .prop method will only ever be treated as a string, with no opportunity for execution. So code like this is safe from a reflected XSS attack:

var link = $('a').first();
old_href = link.prop('href');
link.prop('href', old_href + '?p=' + injected_data))

However this would not be safe if the user had full control of the final href (if for instance you didn't append, but instead set the href based exclusively on the user input). In that case the user could switch the link to execute javascript like so:


Which would cause a vulnerability for code like this:

link.prop('href', injected_data))

As long as you are appending data to something that is already there, this is impossible. However, if the href tag is previously empty, you can end up with a vulnerability (although it will only fire if the user clicks the link: not just by loading the page).

Of course, even this doesn't guarantee safe-ness, since potentially malicious data is hiding around in your application to cause problems. You may forget that the href now contains user data, and if some other javascript grabs the href out of a link and tries to do something with it, it may cause trouble. Also, keep in mind that this malicious data will be passed along to Site 2 when someone clicks the link, so Site 2 needs to properly secure itself (which was true before anyway, so that's not really anything you didn't already know).

Not safe: .replaceWith()

However, many other javascript methods will allow your string to be treated as HTML, which will result in reflected XSS. In fact, there are probably more dangerous methods than safe one, so you should probably verify that whatever method you are using is actually safe. Still, to pick an example, .replaceWith() will evaluate your string as HTML. So something like this would be dangerous:

link = $('a').first();
old_href = link.prop('href');
link.replaceWith('<a href="' + old_href + '?p=' + injected_data + '">click here</a>');
  • I see.. Let me show you how I was generating my new URL, it's something like this: code var link = $('a[href="secondurl.com"]'); const urlParams = new URLSearchParams(window.location.search); const p = urlParams.get('p'); if(p != null){ link.attr({ href: 'secondurl.com/?p=' + p }); } code Is it vulnerable to XSS?
    – churros
    Commented Dec 5, 2019 at 19:16
  • @churros The best way to find out if you are secure is by using a payload to see if you can trigger XSS (although that isn't always effective, since XSS payloads can be tricky). However, .attr works just like .prop - I would expect this to be okay. Commented Dec 5, 2019 at 19:23
  • Ok @conor. I don't know what a XSS payload is, but I will learn about that and give it a try. Your answer gives me more tranquility. Thanks!
    – churros
    Commented Dec 5, 2019 at 19:27
  • @churros ExecutionByFork and I both had examples of XSS payloads to get you started. This URL should be a good starting place: http://mysite.com?p="><script>alert(1)</script> Commented Dec 5, 2019 at 19:56
  • Ohh I see.. I will try those.. Thanks both of you!
    – churros
    Commented Dec 5, 2019 at 20:22

Your website may be vulnerable to a reflected XSS attack (It depends upon how you are setting that value and how the data is interpreted). For example, imagine if I access the following URL:

mysite.com?p="></a><script>malicious_code()</script><a href="

If your site converts this:

<a href="secondurl.com">Link </a>

into this:

<a href="secondurl.com?p="></a><script>malicious_code()</script><a href="">Link </a>

And then if the user's browser parses the updated HTML, the malicious_code() will be immediately executed in their browser. Please be aware that this is not the only method of performing XSS. Ultimately, it depends upon how your site takes the user data and adds it to the href attribute, so even if <script> tags don't work in this specific scenario, other methods easily could. Take a look at OWASP's XSS filter evasion cheat sheet for examples.

This is why it is important to make sure data coming from a user always sanitized when it is included in data that is later interpreted as code. If user input never utilized as instructions, then it's usually safe to not sanitize that data. However, be aware that injection could happen anywhere downstream. It's easy to forget data which isn't coming directly from a user may not be sanitized.

Can this compromise your server? Not directly, but it's still a gaping security hole which should be patched. Using XSS, an attacker could send you a link to execute javascript on your machine. If you happened to be logged in, they could then steal your session cookie and use it to access the wordpress site as if they were you. This would give them access to any administration panels that you normally have access to, and they could escalate their privileges from there.

Note: Another thing you should consider is how you are using the parameter that is getting passed to secondurl.com. This is another vector which might allow access to your site, as it is ultimately controlled by the user.

  • It's not a given that there is a vulnerability, because it depends on exactly what javascript method is used to update the url. Some are safe, some aren't Commented Dec 4, 2019 at 23:34
  • For instance if OP is using the prop method, input sanitization may actually be counter productive. stackoverflow.com/questions/10604320/… Commented Dec 5, 2019 at 2:36
  • I see. I do the sanitize process on the Site 2 side, where I use the p parameter value. I use functions like htmlspecialchars, strip_tags, and I even compare what the value is with an array of possible values for the p that comes on the GET. If it's not part of the array, nothing happens. If I don't sanitize on the Site 1, I'm still vulnerable? Does this vulnerability have the power to inject python or php scrips on my server?
    – churros
    Commented Dec 5, 2019 at 12:10
  • @ConorMancone I've updated my answer and addressed your comments. Please remove your down vote. Commented Dec 5, 2019 at 16:07
  • 1
    @churros No, XSS does not have the power to alter server side resources on its own. Because javascript execution happens only in the browser (aside from nodejs), it can only effect an end user's machine. This said though, I would still patch it. XSS can be used as a foothold like I mentioned in my answer. Additionally, if your site has users and logins, bad actors could leverage this XSS vuln to steal other user's session cookies and gain access to their accounts. Users of your site would see the malicious URL goes to a known site and are therefore more likely to click on it. Commented Dec 5, 2019 at 16:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .