I am Developing a Web Application Currently, in which users can Make a Profile and Fill out the User's information, In this i have also kept a Section for Profile Picture, in that i have used a logic that No Users shall be Upload any Image to the Profile picture just for Testing and instead of that i am showing Images like <div style="background-image: url("http://example.com/image.jpg")></div>

In this i have made a Input for user to place the path of jpg image from any site he likes and I directly display the image from that site only, which is http://example.com/image.jpg in our case.

I want to consider the worst situation here, I haven't placed check nor whitelisted any domains into the example.com/image.jpg. I placed a URL like http://stackoverflow.com/index.html it shows me blank, I tried many PHP scripts like http://attacker.com/omg.php and it doesn't run the script on my domain.

Is there any possibility of attack vector here? If yes, kindly suggest me. And also is CORS or SOP Bypass possible here, I have CSP protection of the domain.

Note: In the URL Section, i am making First validating check at scheme of URL where http:// , // and https:// are WhiteListed & in the Image section i have ONLY whitelisted Numbers + Alphabets and special characters like ., - & / .Rest else are blocked

  • 1
    what if put http://example.com/image.jpg")></div><script>alert('XSS')</script><div> in input
    – Sravan
    Commented Jun 28, 2016 at 13:22
  • @Sravan i have Whitelisted only Letters and Numbers and "/", ".", "-", The above one won't even work as it contains special characters Commented Jun 28, 2016 at 17:19

2 Answers 2


i tried many php scripts like http://attacker.com/omg.php and it doesn't runs the script on my domain ..

The problem here would not be a server side vulnerability but more of a reflective XSS vulnerability that runs on the browser not on the server which is why the php file did not work.

Taken from OWASP (see here):

Reflected Cross-site Scripting (XSS) occur when an attacker injects browser executable code within a single HTTP response. The injected attack is not stored within the application itself; it is non-persistent and only impacts users who open a maliciously crafted link or third-party web page. The attack string is included as part of the crafted URI or HTTP parameters, improperly processed by the application, and returned to the victim.

If I attached a file (lets call it script.html) and had Javascript execute there then any one viewing the "image" will run the Javascript on their browser.

For example:

I am a user on your website and I attach a profile picture with the link http://mymalicouswebsite.com/script.html and in the script.html file I have the following code:

...Some HTML...
    window.onload = function(){
        //Anything I put here will run on any viewers browser
...Some HTML...

This can be even worse, the attacker can do the following:

  • Replace your whole html body with any content he wants (he can load an iframe which is a phishing page)
  • He can steal users cookies and send it to his page using AJAX
  • Redirect the user to a drive by where a virus will be downloaded and the user will think its coming from your website

Now, Is there any Possibility of Attack vector here, If yes, kindly suggest me. And also is CORS or SOP Bypass possible here, I have CSP protection of the domain.

CORS is when an HTTP request comes from a script which is not this case. What you are doing is as if you are loading an iframe.

About CSP: I would have to see your setting that are set to see if an attack can be made...

  • 4
    And simple yet effective: the attacker can configure his server so its returns a 403 error message when requested for the image. Result: while browsing the profile page (which can be protected with SSL and all you like), depending on his browser (Firefox at least is vulnerable to this) the user will be prompted for his credentials. Chances are that he will fill his actual credential (there is a lock, therefore its secure, isn't it? ;) ). Commented Jun 24, 2016 at 9:43
  • @WhiteWinterWolf also a possibility ;-) Commented Jun 24, 2016 at 9:45

The risk isn't that a script such as http://attacker.com/omg.php runs on your domain, it is that a user manages to break out of the

<div style='background-image: url("http://example.com/image.jpg")'></div>

context where the URL is written to the page. Note the code has been corrected from your question (single quotes used for HTML attribute to make things clearer).

PHP is server-side, however because you are displaying a client-side image there is no server-side risk.

Even if //example.com/evil.js was entered, the script won't execute on the browser because it is requested in the context of an image, not a script.

Back to the problem: To mitigate the user managing to break out of the context where the URL is written, you need to mitigate against XSS (Cross-site scripting).

For that, see rule #4 here: "CSS Escape And Strictly Validate Before Inserting Untrusted Data into HTML Style Property Values".

Not doing so may allow the user to enter something like


as their image URL which would render

<div style='background-image: url("")'><script>alert('xss')</script>")'></div>

on the page and execute the script. Here it is just showing an alert box, however XSS vulnerabilities can be used to compromise the whole user session.

The rule to make this safe is as follows:

Except for alphanumeric characters, escape all characters with ASCII values less than 256 with the \HH escaping format.

This should be done on output to the page.

As a second line of defence, you could also validate on input that the URL entered starts with http://, // or https:// and ask the user to correct it if not. This would be an extra check against javascript: URLs, however you still need the proper encoding to prevent CSS and attribute context breakouts.

  • I don't think XSS should be possible here, as i have whitelisted only letters and Numbers along with "/" , "." & "-" . Nothing else would work :) ...And i check that the URL belongs to http:// or // or https:// rest all are blocked.. Commented Jun 28, 2016 at 17:21
  • In your case this seems fine on first read. I would be tempted to drop in the proper encoding though on output as a defence-in-depth measure. If there are no other aspects to your question then I can't see any attack here because you are referencing it as an image and not a script or HTTP link. Commented Jun 29, 2016 at 9:11

You must log in to answer this question.

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