|
Brought to you by:
Suppliers of:
|
|
|
| |
| This advisory shows how almost any script that uses cookie session/login data to validate CGI forms can be exploited if the users can post images. |
| |
Credit:
The information has been provided by Chris 'stallion' Lambert, John Percival, Ben Gollmer and David Dreezer.
|
| |
Known vulnerable:
* Ultimate Bulletin BoardT version 6.04e (and prior)
* ezboard 6.2, WWW Threads PHP 5.4
* vBulletin 2.0.0 Release Candidate 2 and before (later versions are safe)
Immune systems:
* Ultimate Bulletin BoardT version 6.04f
Allowing users to post inline images is potentially a bad thing. Having the user authentication based solely on cookies is another potentially bad thing. When you put them together, it gets a whole lot worse. We will explain this problem with reference to a typical forum system, but naturally, it can be extended to almost any other CGI script, not just limited to PHP scripts.
What is the problem? Well, by using an [img] (or HTML <img> or <iframe> or <script src="">) tag, the user is having anyone who views the thread access that image - that is perform an HTTP GET on the URL specified for the image. Even if it's not an image, it still can be accessed, but will display a broken image. This means that the user can put a CGI script inside [img] tags. This script will be called by whoever views that thread. When used maliciously, it could force the user to: unknowingly update their profile, respond to polls in a certain way, post new messages or threads, email a user with whatever text they want, the list goes on. This would be particularly worrying for a 'worm' to spread through a forum, filling it with rubbish posts.
For example, if a user posted something along these lines:
[img]http://your.forums/forums/newreply.cgi?action=newthread&subject=aaa&bod
y=some+naughty+words&submit=go[/img]
Then the post would go through, under the name of whoever viewed the image. This is of particular danger when an administrator views an image, which then calls a page in an online control panel - thus granting the user access to the control panel.
How can it be fixed? Well, there are a couple of ways to stop it, but the easiest (in PHP at least) seems to be to have most of the variables used by scripts be used through $HTTP_POST_VARS. So instead of checking for $action in a script, $HTTP_POST_VARS['action'] would be checked. This forces the user to use a POST request, not a GET. Alternatively, the sessionid could be required to come with the GET/POST request variables, rather than by cookie. Finally, in the specific case of [img] tags, the use of ? or & in the img URL can be disabled by some regexes.
If the software that you run is not secure, we recommend that you disable HTML and/or [img] tags, until the fixes have been implemented.
Possible workaround:
Verifying that a valid image was posted, for example test for its image size, and reject it if it is invalid:
<?php
//quick sample code follows
//$imagePath is the URL provided; doesn't matter if its via GET or POST
$imageInfo = getImageSize($imagePath);
if(!$imageInfo)
{
print("Sorry, image cannot be opened or is not a valid image type.");
}
elseif($imageInfo[0] >= 800 || $imageInfo[1] >= 600)
{
print("Sorry, image too big");
}
//and so on
?>
|
| Subject:
|
how does cross site scripting dorks in web application |
Date: |
30 Apr. 2006 |
| From: |
speed_virusmailyahoo.com |
| i want to know cross site scripting process and wish to make our office website preventing it so I'm so curious to about it please help me |
|
| Subject:
|
GET should be idempotent |
Date: |
19 Feb. 2007 |
| From: |
maht |
If you have GET doing actions then you deserve it for straying from the specs.
|
|
| Subject:
|
Maht: bit confused, my friend |
Date: |
21 Jul. 2007 |
| From: |
Grgl |
| This problem has nothing to do with the app developer misusing GET. |
|
|
|
|
|
|
