Fogfighters Hungary

Top-Ten Countries visiting Fogfighters Hungary

1	United States
2	China
3	Viet nam
4	Russian Federation
5	France
6	Hungary
7	unknown
8	Ukraine
9	Canada
10	United Kingdom
11	Germany
12	Netherlands
13	Poland
14	Italy
15	Taiwan, Province of China
16	Seychelles
17	Australia
18	Romania
19	Indonesia
20	India
21	Thailand
22	Sweden
23	Brazil
24	Japan
25	South Africa
26	Lithuania
27	Argentina
28	Spain
29	Iran, Islamic Republic of
30	Chile
31	Luxembourg
32	Turkey
33	Moldova, Republic of
34	Korea, Republic of
35	Belarus
36	Malaysia
37	Venezuela
38	Switzerland
39	Singapore
40	Colombia
41	Hong Kong
42	Mexico
43	Mongolia
44	Czech Republic
45	Belize
46	Greece
47	Honduras
48	Estonia
49	Latvia
50	Bulgaria
View MS-Analysis

PHP-Nuke: Management and Programming

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:

">&lt;script&gt;evil_code;&lt;/script&gt;

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