Help Center Live is a `Live` help desk system written in PHP using a MySql database backend that features Live Support, Trouble Tickets and FAQ within one project. This is a very popular application, especially with webhosts and other services. Unfortunately Help Center Live is vulnerable to Sql injection, Script Injection, and Cross Site Scripting attacks, but the most serious of the vulnerabilities mentioned (The SQL Injection attacks) require magic_quotes_gpc to be set to off. Cross site scripting exists in Help Center Live. This vulnerability exists due to user supplied input not being checked properly. There are several script injection vulnerabilities in Help Center Live that allows an attacker to force a logged in operator to run malicious code in their browser.
There lies a vulnerability in all version of Invision Power Board that allow a user to spoof his/her IP address by creating a bogus X_FORWARDED_FOR HTTP Header entry. This condition can also be caused by a user unknowingly if they use a proxy to access the internet. For example, private LAN based IP's will be logged which are impossible to trace.
PHPX is vulnerable to Cross Site Scripting (XSS) due to insufficient sanitization of user-supplied input. An attacker can inject malicious JavaScript code into the application, which will be executed in the browser of an unsuspecting user.
OpenBB is prone to Cross Site Scripting in multiple files. This may allow an attacker to run code in the context of a users browser, or used to harvest sensitive information from a user such as cookie information. It may be possible for an attacker to execute arbitrary SQL queries due to user supplied input not being properly sanitized.
phpBugTracker is prone to SQL Injection in several files. Some are not so dangerous, and others I would consider a pretty high risk. The user.php, bugs.php and query.php files are vulnerable to SQL Injection attacks as the variables are passed to the query unchecked.
There are several ways to discover the full physical path of the web directory on a server running TikiWiki. One way is by calling some files directly with a null or non-existent value as seen below. banner_click.php, categorize.php, tiki-admin_include_directory.php, tiki-directory_search.php. Some files specifically prevent this by checking to see if they are called directly. I am not sure why more of the TikiWiki files do not use the same preventive measure. Also, just about anywhere that there is potential for SQL tampering (read about that later) you can leave the value null, and generate an error that will disclose the full physical path of the web server. Below are a handful of examples, but surely it is not al of them. tiki-admin_include_directory.php, tiki-directory_search.php, tiki-editpage.php, tiki-index.php, tiki-listpages.php
Altering queries is possible via two different files in phpBB 2.0.7a and earlier. The affected files are "admin_smilies.php" and "admin_styles.php" Below is what you will see if you take a look at the "admin_smilies.php" file. The problem here is that the $smilies_id variable is not sanitized before being used in the query. This allows an attacker to inject arbitrary SQL into the query.
vBulletin is prone to attack in six different files (maybe more) The files affected are "showthread.php", "forumdisplay.php", "private.php" and also the "memberlist.php" file. The "memberlist.php" and "private.php" files does not seem to be prone to the same attack I am about to talk about in versions three and later. The type of XSS that takes place though on vBulletin is what I would call a higher risk XSS issue. What I mean by that is alot of times slashes will be added to certain characters, or certain strings/characters disallowed, but in vBulletin you can eneter pretty much anything and have it execute sucessfully. This makes it a whole lot easier for an attacker to use these vulnerabilities to disclose a users information.
Phorum is a web based message board written in PHP. Phorum is designed with high-availability and visitor ease of use in mind. Features such as mailing list integration, easy customization and simple installation make Phorum a powerful add-in to any website. Phorum have pached a good number of XSS (Cross Site Scripting) issues in the past, but there is still some work to be done regarding these issues before the final release of Phorum Version 5. The first issue lies in "login.php" If you look at the HTML source code you should see two hidden variables. One called "f" which specifies the forum id, and one called "target" which specifies the location to take the user after they login. Unfortunately both of these values are taken directly from the value of HTTP_REFERER without any validation. While there is a global script in forum that checks for the <script> tag, it will allow for pretty much any thing else, and most of you know it is not hard to execute javascript inside of a tag which is allowed. This same vulnerability also exists in "register.php" And while not the exact same, a similar problem to these two exists in "profile.php" also.
phpBB is a high powered, fully scalable, and highly customisable open-source bulletin board package. phpBB has a user-friendly interface, simple and straightforward administration panel, and helpful FAQ. Based on the powerful PHP server language and your choice of MySQL, MS-SQL, PostgreSQL or Access/ODBC database servers, phpBB is the ideal free community solution for all web sites. phpBB is a great forum system used by many millions of people. It is one of the more secure of the forum systems, but has a few issues still present; both of which allow for XSS (Cross Site Scripting). This problem presents itself in two different places. One of these places is viewtopic.php and the other is viewforum.php Below are examples along with a brief explanation on how to replicate this issue. viewforum.php?f=[FNUM]&topicdays=[DNUM][XSS] FNUM is a valid forum number. DNUM is the number of days to check. If you get no results with 1 for example try 99 and so forth and so on. XSS is whatever code is injected. viewtopic.php?t=[TNUM]&postdays=[DNUM][XSS] This is nearly the same issue as above, it just happens to be present in multiple files. The only difference is TNUM is a valid topic id number. Remember, the query must display results in order for the XSS to take place. Additionally the offset (start) variable may be used to get results, but in most cases is unnecessary.
Services By CQR