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