PHP-Nuke Multiple Input Validation Flaws Let Remote Users Conduct Cross-Site Scripting Attacks
SecurityTracker Alert ID: 1005403|
SecurityTracker URL: http://securitytracker.com/id/1005403
(Links to External Site)
Date: Oct 10 2002
Disclosure of authentication information, Disclosure of user information, Execution of arbitrary code via network, Modification of user information, User access via network|
Exploit Included: Yes |
Several input validation vulnerabilities were reported in PHP-Nuke. A remote user can conduct cross-site scripting attacks to gain access to user and administrator accounts.|
Several input validation flaws were reported in various sections and modules of PHP-Nuke. A remote user can insert specially crafted HTML so that, when a target user views the web site, arbitrary scripting code will be executed by the target user's browser. The code will run in the security context of that site. As a result, the code will be able to access the target user's cookies (including authentication cookies), if any, associated with the site, access data recently submitted by the target user via web form to the site, or take actions on the site acting as the target user.
PHP-Nuke's RDF/RSS parser does not filter HTML tags from user-supplied RSS files. A demonstration exploit RDF file is available at:
The software also does not properly filter user-supplied HTML in private messages. It apparently removes <script> tags, but still allows a user to inject scripted events into <a href> tags. A demonstration exploit is provided:
<a href="X" onmouseover="alert(document.cookie">x</a>
The software does not filter HTML tags in the journal.
The software does not filter or properly validate many fields in the "Your Info" section, including the following fields:
Real Name, Fake Email, Your Location, Your Interests, Your Occupation, and Signature.
The search query string also allows scripting.
The Download module accepts <a href> events in the following fields:
Program Name, File Link, Author's Name, Author's Email, and Homepage.
The Web Links module has the same flaw as the Downloads module.
The vendor has reportedly been notified.
A remote user can access the target user's cookies (including authentication cookies), if any, associated with the site running PHP-Nuke, access data recently submitted by the target user via web form to the site, or take actions on the site acting as the target user.|
No solution was available at the time of this entry.|
Vendor URL: www.phpnuke.org/ (Links to External Site)
Input validation error|
|Underlying OS: Linux (Any), UNIX (Any), Windows (Any)|
Source Message Contents
Subject: [Full-Disclosure] Multiple XSS vulnerabilites in PHPNuke|
Yes, more XSS in phpnuke...
Since Francisco Bruzi didn't bother to answer to our submissions and
e-mail, as usual, here goes the full advisory.
The obvious workaround to most of the bugs is to use "strip_tags()"
There are probably a lot more, since these are all straight forward.
Content-Disposition: attachment; filename=phppuke.txt
Content-Type: text/plain; name=phppuke.txt; charset=ISO-8859-1
Multiple XSS Vulnerabilities in PHPNuke 6.0
Summary: We have found 7 diferent cross-site-scripting
vulnerabilities in PHPNuke 6.0 which allow for anyone
to steal the authentication cookies from users and Administrators.
Some of them include several ways to insert scripting into the site,
so they're quite a few more than 7 (actually 22 input boxes).
Most of them are *VERY CRITICAL* since they are totally directed to the
Administrators, unless they view the source of the HTML page carefully.
Risk Level: To each vulnerability we gave a risk level, with
the following levels: Low , Medium, Critical. Most are Critical.
Vendor Status: Vendor notified of first two bugs on 4 Oct 2002 through PHPNuke's site.
Vendor notified of all bugs through E-Mail on 7 Oct 2002.
1] RDF/RSS Parser (Risk: medium)
PHP-Nuke's rdf/rss parser doesn't strip html tags when parsing RSS files. The <title> tag isn't stripped, so if it contains any valid
HTML or scripting, the user's browser will run the script.
As a proof of concept, go to your account on a php-nuke site, and on your prefered site just put some URL with an rdf file with an
item like this one:
<title><script>alert('cookie: '+ document.cookie)</script></title>
We have one rdf file like that one at http://www.genhex.org/php-puke.rdf
2] Private Messages (Risk: critical)
Private messages module allows for html in the body. although it
strips <script> tags, it allows for events on <a href> tags. hence,
on the message body just write:
<a href="X" onmouseover="alert(document.cookie">x</a>
I leave up to your imagination more interesting ways to explore this.
3] Journal (Risk: critical)
The journal doesn't strip html tags. period.
Put "<script> alert(document.cookie)</script>" somewhere
(in the title for better effect :)) and when someone goes
to see your journal, the script will be run.
4] Your Info (Risk: critical)
Most fields on the "Your Info" section of don't strip
html tags, or don't correctly validate input.
On Your HomePage, you can put an URL to some site. PHPNuke doesn't
correcty validate the data. You can do some "HTML Injection",
for instance, insert as your URL:
PHPNuke will turn this into: <a href="http://x/" onmouseover="alert(document.cookie)">http://x/" onmouseover="alert(document.cookie)</a>
It's not very stealthy, but most users will probably put their mouse over it
You must keep the URL as small as possible, since phpnuke will truncate the URL, thus it will not work.
The next fields don't strip tags:
These ones allow for <script> tags, thus turning the attack
completely transparent to the victim.
The "real name" and "fake email" fields are even more dangerous,
because if someone lists the users, the script will be executed.
All the others require the victim to go to the attacker's info
5] Search (Risk: Low)
This is a low risk CSS bug, since as far as we could tell
the user must put the script himself on the search field.
Anyway, the box doesn't correctly strips the query string,
altough it does if it is submited as a GET request...
6] Downloads (Risk: Critical)
This module accepts <a href> events in the fields:
Program Name, File Link, Author's Name, Author's Email,
those fields. When an Admin goes to check the download, depending
Most fields will look very suspitious, except for File Link. File Link will
look perfectly normal.
If the Admin puts his mouse over the link (or other event) by accident (or on purpose),
you can steal his cookie.
7] Web Links (Risk: Critical)
Exactly the same as the Downloads module.
Vulnerabilities discovered by Bruno Morisson <email@example.com>
and Pedro Inacio <firstname.lastname@example.org>.
This advisory, parts of it, or the information herein can be reproduced
as long as credit is given.
Full-Disclosure - We believe in it.
Go to the Top of This SecurityTracker Archive Page