In our development team, we have to build a component. This component is a full client side one written in Javascript.

A client web application wishing to embed this component will call it like below:

<iframe id="fullScreenIframe" src="http://my-server.com/component?param1=val1&param2=..."></iframe>

The problem

One of the parameters accepted by the component make some of us nervous. The origin parameter is used to generate a link to take the user back to the client web application.

Here is how the component manage this parameter:

$(document).ready(function() {
    var origin = urlParameters["origin"];// Dynamically built from the current document url

    if(origin != undefined){
        // The link to take the user back...

        // Another link in the breadcrumb using the same `origin` parameter
        $("#simulationPage").attr("href", "index.html"+"?origin="+origin);

    // ...

What we already told him

  • Website phishing

Even if the origin parameter is passed to jQuery, any website can be use in a phishing scam. A user can be asked to (re)enter its credentials thinking she is on a real site. The hole here will be the component.

  • Whitelist with valid values

The valid values of origin can be stored remotely in a whitelist. The component would check the whitelist first before generating the link. A default link can be generating if an unexpected value is found.

Those two arguments didn't convince him. He wants to be demonstrated that the origin parameter can be a security hole. So you guys, what would you tell him?

By the way, I'm looking for a good PoC demonstrating the weakness of the origin parameter.

  • I do not really understand what you are asking. – Neil Smithline Dec 3 '15 at 21:01
  • security.stackexchange.com/questions/79728/… <- related to your conundrum – Ohnana Dec 4 '15 at 14:55
  • I'm not really clear what you believe the security risk is here. In your scenario how is the attacker able to modify the contents of the Origin parameter? Right now I'm agreeing with the developer in question that you need to clarify what the threat is. – Steve Sether Dec 7 '15 at 15:52
  • @SteveSether The component accepts anything from outside without sanitization. This is the threat. Check the accepted answer for details. – Stephan Dec 7 '15 at 16:00
  • @Stephan I'm not sure you understand my question. It accepts anything from where, your own server? What is it that you're trusting? The specific threat is important here. If you're vulnerable to a XSS attack I wouldn't really bet that input validation in Javascript is going to save you, since an attacker can input their own javascript using XSS. – Steve Sether Dec 7 '15 at 16:06

As long as you're relying on incoming user information, you'll never be fully protected/safe. Anything can be spoofed, altered, modified; and, subsequently, your component is now compromised.

If you want to go the route of retaining some trust, it would make sense to whitelist. However, going a step further may be more ideal--you issue tokens in lieu of specifying domains (think of how Google Analytics uses a UA-XXX number over mysite.com). Push administration back on their web admin and the possibility of faulty domains/security vulnerabilities is now their responsibility.

To further elaborate what I'm referring to, instead of having a whitelist, setup a database of tokens:

id       # Primary Key
token    # Unique generated token

Then, have a 1:* relationship where valid origins can be defined for that key:

id       # Primary key
token_id # Forieign Key, tokens.id
origin   # origin (e.g. google.com)

Then create a token for a specific client (whomever is going to include your component on their page). For example, let's say we have the token abc123def456:

<iframe src="http://server.com/component?key=abc123def456"></iframe>

Here, your component would perform a server-side lookup against your tokens table and validate. You could also add additional checks against the Referer header, but that's up to you (and realizing Referer could be spoofed anyways). Default bahvior would be to deny *, so you'd show a page saying "No origins specified, please configure" (or something of the sort).

Next, they login to the admin page and add "abc.com". Now, the widget becomes:

<iframe src="http://server.com/component?key=abc123def456&origin=abc.com"></iframe>

Now, server side, you're validating key along with the origin (against your compiled whitelist in origins table (associated to that key). If a hacker were to try to use this (or modify it) an invalid origin (with respect to the key) would bounce and show an error page.

If they decide not to specify origin, you could also configure a default origin so anytime you include just /component?key=abc123def456 it assumes the default origin.

Or something like that

  • "their web admin", "their responsibility" ... who is "their"? – Stephan Dec 4 '15 at 8:44
  • The owner/webmaster of the page bringing in the control via Iframe – Brad Christie Dec 4 '15 at 12:01
  • Can you shade a light, in your post, on this point: "think of how Google Analytics uses a UA-XXX number over mysite.com" ? – Stephan Dec 4 '15 at 12:40
  • Basically, instead of defining origin=www.site.com you specify key=abc123def456. Then, in your configuration, have the user specify what origin means (within the context of the widget). Otherwise, (coupled with the key) allow them to continue specifying origin (but check it against sites defined for that key). You can also introduce security measures (such as checking referrer is valid against sites defined for that token). – Brad Christie Dec 4 '15 at 13:35

When I hear about whitelists, it takes me back to the history of firewalls.

When firewalls were first used, they operated on a "accept everything by default except what is blacklisted". This created A LOT of problems for early firewalls and sys admins since they had to proactively keep on top of threats and add them to the blacklist.

When the industry realised the problem and switched to the current system of "block everything by default except what is whitelisted", then this drastically reduced the threat landscape and the pressure on the sys admin teams.

Use this analogy when faced with this again. This should convince most people.


Finally, I found a PoC for an XSS attack. The component is vulnerable when it is called like below:


It proves a malicious script can potentially run once the user clicks on the link generated by the component.

Finally our team mate has accepted to strengthen the component.

Instead of a whitelist, he chose to check that origin value is a valid url.

  • If you've answered your question, you should "accept" an answer and remove this question from the queue. Good to hear your teammate has come round! :) – Ohnana Dec 4 '15 at 14:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.