Cross-site scripting with PHP-Nuke

PHP-Nuke: Management and Programming
Prev		Next

23.3.1. Cross-site scripting with PHP-Nuke

A CSS vulnerability is caused by the failure of a site to validate user input before returning it to the client s web-browser. The essence of cross-site scripting is that an intruder causes a legitimate web server to send a page to a victim's browser that contains malicious script or HTML of the intruder's choosing. The malicious script runs with the privileges of a legitimate script originating from the legitimate web server (see Cross-Site Scripting Vulnerabilities). By failing to validate user input, the vulnerable site makes it possible for a malicious user to execute ("inject") a script in the context of that site's process.

Here are some known examples of cross-site scripting with PHP-Nuke:

When a user posts messages, special characters are not stripped making it possible to inject malicious script code. The user types in a forum message
Some test text for fun <script>alert(document.cookie);</script> some more text..
the text is not checked for the presence of a script - and the script is executed in the victim's browser, who thinks it is a safe forum text from a trusted PHP-Nuke site. (see Splatt Forum Cross Site Scripting).
In a search field, the user types
<script>alert(document.cookie);</script>
The search text is displayed in the results page without being validated. The result: a script is again executed in the victim's browser (see Splatt Forum Cross Site Scripting, PHP-Nuke Cross Site Scripting).

In a forum post, a user types

<html>
<body>
<script>
<!-- Modify here -->
var address='http://www.splatt.it/gate.html?mop=modload&name=Forums&file=newtopic';
</script>
<!-- Exploit form -->
<script>
document.write("<form action="+address+" method='post' name='coolsus'>");
</script>
Forum Number: <input type=text name=forum value=1 size=3><br>
Username: <input CLASS=textbox TYPE="TEXT" NAME="username" 
           SIZE="25" MAXLENGTH="40"><br>
Password: <input CLASS=textbox TYPE="PASSWORD" NAME="password" 
           SIZE="25" MAXLENGTH="25"><br>
Subject: <input CLASS=textbox TYPE="TEXT" NAME="subject" 
          SIZE="75" MAXLENGTH="75"><br>
Message:<br><textarea name="message" rows="10" cols="75" 
        wrap="VIRTUAL"></textarea><br>
<input type=hidden name=bbcode value=0>
<input type=hidden name=smile value=0>
<input type=hidden name=notify value=0>
<b>Inject code:</b> <input type=text name=image_subject 
value='icon1.gif">HTML CODE<!-- "' size=100><br>
<input type="submit" name="submit" value=submit class="Button">
</form>
</body>
</html>

The input is not checked if it contains malicious code, the script is executed in a user's browser when viewed. Successful exploitation can result in disclosure of various information (eg. cookie-based authentication information) associated with the site running Splatt Forum or inclusion of malicious content, which the user thinks is part of the real website (see Splatt Forum Cross-Site Scripting Vulnerability).

Due to insufficient validation of user input used in an attribute inside a tag, arbitrary script code can be executed by a malicious user. The characters < and > are filtered, but PHP-Nuke neglects to filter out " characters. A malicious person can exploit this to execute arbitrary script code in a user's browser session by including it in either the profile, comments, or a private message, where one has only to type something like
<a href="http://" onclick="alert('test')">http://" onclick="alert('test')</a>
to provoke this behaviour (see PHP-Nuke Cross-Site Scripting).
By posting a forum message with a title like:
"><script>evil_code;</script>
the title will be returned by blocks/block-Forum.php as valid html or script code to the users viewing the message (see PHP-Nuke Cross-Site Scripting).
Input supplied to the $referer variable is not filtered when inserted into the backend database, which makes it possible to include arbitrary script code. When viewed by an administrator, the script code will be executed automatically in the administrator's browser session and could eg. steal the authentication cookie associated with the website, which contains the administrator's username and password (see PHP-Nuke Referer Cross-Site Scripting).

Using the following manipulated addresses

modules/Forums/bb_smilies.php?name=code
modules/Forums/bb_smilies.php?Default_Theme=code
modules/Forums/bb_smilies.php?site_font=}--></style>code
modules/Forums/bb_smilies.php?bgcolor1=">code

where "code" is a malicious code, a user can execute this code in a viewer's browser (see PHP-Nuke Cross Site Scripting).

As you can see from the above examples, the only remedy to cross-site scripting problems is to write PHP code that validates user input (or, if you are the "viewer", disable scripting altogether, although even this will not prevent the injection of malicious HTML, see Cross-Site Scripting Vulnerabilities).

Prev	Home	Next
Common PHP-Nuke security vulnerabilities	Up	SQL injection with PHP-Nuke