Fix #13272: Hardcoded table name mantis_config_table in install.php

This issue applies only to 1.2.x, as it had already been fixed in master as
part of commit c8f355d04fb5120545d890ea2a7b2e2b6afc9b6c
Correct naming of attachments column

Commit 97b67e4bbb2f2df5f6fb24eea5b4bb37e1c28acd introduced some changes to the
BugData class: the 'attachment' column was renamed to 'attachment_count'. This
change was not cascaded everywhere, which resulted in the column not being
displayed by default (as the now-invalid column named 'attachment' was
automatically removed)

This then hid the fact that $g_show_attachment_indicator was actually not
working as advertised, i.e. the attachments column is always displayed; when
ON the field contains the paperclip bitmap, and when OFF the actual number of
attachments for the corresponding issue.

Affects issue #13276

This commit also removes some trailing whitespace
Update list of standard columns in config_defaults_inc.php

The list now matches what is actually available in the manage columns pages
Removed obsolete comment

file_can_view_bug_attachments does check for allow_view_own_attachments
Fix #13282, #13283: bug_actiongroup_ext_page.php LFI and XSS

High-Tech Bridge SA Security Research Lab reported 2 issues with the
'action' parameter to bug_actiongroup_ext_page.php

Issue #13282

XSS issue with require_once() call failures returning an unescaped
user-supplied filename. There has been a fair amount of recent public
talk about PHP error messages being a source of XSS issues. This is an
example.

Issue #12283

Local file inclusion/path traversal vulnerability on web servers that
allow translations like:
http://example.com/directory/file.htm/../file2.htm ==>
http://example.com/directory/file2.htm

Vulnerable (default configuration): Apache
Not vulnerable (default configuration): nginx

This issue has _SEVERE_ consequences for people using web servers which
don't check each segment of a path from top to bottom for validity. It
shouldn't be possible to include the contents of config_inc.php to
retrieve MantisBT database passwords because
require_once('config_inc.php') will parse the document as a PHP script
(echoing nothing). However it may allow attackers to view private files
accessible to the web server user account. It also allows an attacker to
guess the file structure of a server (existence of installed software,
user accounts, etc).

nginx will produce a 404 error when it determines that file.htm is not a
directory. This makes too much sense, doesn't it?
Revert "Fix #13282, #13283: bug_actiongroup_ext_page.php LFI and XSS"

This reverts commit a7eacc181185eff1dd7bd8ceaa34a91cf86cc298.

Paul fixed this in a better way with commit
a908cc61362059025910e2437d55bedc31863139 (to be backported to 1.2.x
after this older commit is reverted).
Rework the bug action group api such that we can easily convert this to an object in the future, and to validate calls to require once.

This leads to a security issue identified by IBM's Appscan program, whereby calls to require_once are not validated.
Depending on webserver configuration, this is a file inclusion vulnerability.

There will be a follow up commit to config api - probably:
-		if( $g_project_override != null ) {
+		if( $g_project_override != null && $p_project == null ) {

At the moment, the action group API calls config_get with a project parameter to use. This is ignored, due to project_override being set - so we either need to:
a) change project override within the command list function
b) modifify config api to only use the project override *if* it is attempting to look up information on the default project.

Backported from master-1.2.x branch. Note that this commit relies upon
commit 6dc35105064e5a2533fb4e1de54426ea17d2ef36 from the master branch
(that hadn't been backported to 1.2.x).

Conflicts:
  bug_actiongroup_ext.php
  bug_actiongroup_ext_page.php
  bug_actiongroup_page.php
  core/bug_group_action_api.php

Signed-off-by: David Hicks <d@hx.id.au>
Fix #11481: Don't show bug group actions that can't be used

Currently the bug action group dropdown list on view_all_bug_page.php
shows (almost) every available option, even if the current user isn't
authorised to use those options.

This patch implements checking to see which options are available to the
user for the issues which are currently shown on view_all_bug_page.php.
Options are only displayed in the dropdown list if the user is able to
use the option on at least one of the bugs displayed.

Additionally, the logic behind when selection checkboxes are shown
alongside a bug has been improved. Checkboxes won't display next to bugs
that the user cannot perform group actions on.

Backported from master branch because it's needed to resolve an LFI/XSS
issue in bug_actiongroup_ext.php.
Fix issue introduced previously whereby php_Self is now used unchecked.

introduced previously by john attempting to fix symlinks. Since we now use php 5.2, we can make use of filter_var.

This is a simpler version of what we were trying to do previously aka http://git.mantisforge.org/w/mantisbt.git?a=commitdiff;h=5ac1fdf32717d0c82cca7e7660dd4fd316a6a1b8

Depending on server/mantis config this can lead to XSS issues

David: Backported from master branch and removed unreachable code branch.

Signed-off-by: David Hicks <d@hx.id.au>
Project override should only apply if $p_project hasn't been explicity set.

For the most part, we use config_get(var) to get information for the current project [or overriden project]

If we are explicity passing in a project ID, we should use this ID instead, and not override.

Signed-off-by: David Hicks <d@hx.id.au>
Issue #13281: Fix Projax XSS issues (unescaped value attributes)

Projax sucks. This is why it was replaced with jQuery in the master
branch. However master-1.2.x still uses the older Projax code. The
Projax library doesn't attempt to escape values before dumping them in
HTML output, thus leading to XSS issues.

The easiest workaround is to pass in already-escaped values to the
Projax functions.

This issue was reported by High-Tech Bridge SA Security Research Lab as
part of their advisory #HTB23045, available at
https://www.htbridge.ch/advisory/multiple_vulnerabilities_in_mantisbt.html
Allow more control over the excel api's output

The following changes have been made:

- allow declaration of Spreadsheet styles to control the appearance of
  rows and cells
- allow setting of attributes on individual cells

The actual output of the excel export is unchanged.

The API changes are completely backwards compatible.

Fixes #13290: Allow more control over excel export format
Correct access_has_any_project checks in print_column_selection

The access_has_any_project method call takes a user, not a project
parameter.
Remove use of filter_var(...) for master-1.2.x

Robert Munteanu correctly mentioned on the mailing list that the
master-1.2.x branch needs to work with PHP 5.1. The filter_var(...)
function is not available in PHP <5.2 and therefore we can't use it in
the master-1.2.x branch.

We can achieve similar results by removing all null characters from the
string (\0). This is OK for our use case which is the use of
$_SERVER['SCRIPT_NAME'] - a value that is set by the server and cannot
be manipulated by remote users (like PHP_SELF).
Bump version to 1.2.8 and update release notes
Fix #13141: Incorrect parameters to config_get function

Thanks to Todd Whitesel for finding this problem in filter_api.php and
to Roland Becker for providing further assistance.

I have grepped the source code and reviewed all other calls to
config_get to ensure they correctly use parameters. There was one
additional bug discovered in bug_report_page.php.
Fix #13140: Incorrect permissions check during bug reporting and cloning

Todd Whitesel reported an issue with incorrect permissions checks being
performed when cloning issues. The steps to reproduce this bug were
provided by Todd:

------
Fresh 1.2.5 install.

Create two users, a Developer and an Updater.
Create a private project.
(Actually create a couple more projects so you can see the project
selector.)
Add both users to the private project AS MANAGERS.
Login as Developer, select the private project, and create an issue.
Login as Updater, select All Projects, and attempt to clone that issue.
It fails with ACCESS DENIED error #13. Also note that your access level
was Manager while editing the cloned issue, but in the error screen your
access level is back to your global access of Updater.

As Updater, Select the private project, create an issue. Then select All
Projects, and attempt to clone that issue. It succeeds, apparently
because you are cloning your own issue.

Create a public project and attach the private project as a subproject
of it. Retry the above cloning tests with the public parent project
instead of All Projects -- the results are the same whether you select
All Projects or the parent project.
------

The problem was that the current project (from the project selector
dropdown) was used as the basis for config_get calls, thus leading to
incorrect permissions and settings being used within bug_report.php. We
need to instead switch (temporarily) the current project to either the
master issue (when cloning) or the specified project_id (when creating a
new issue via bug_report_page.php).

Thanks again to Todd for the discovery and debugging of this problem, the
detailed bug report and initial patch (that has been extended to resolve
the second project_id issue from bug_report_page.php).
Fix #12361: Private bug visibility leak in my_view/view_all_bug_page

In the My View / View Issues screens, private bugs in public projects
(and probably private projects too) appear to ignore the
private_bug_threshold value of their project unless you select it. When
some projects have tighter security on viewing private bugs than others,
this creates a situation where a user who should not be able to see a
bug can still discover its existence in My View and View Issues. Viewing
it fails with 'access denied', but if the summary had confidential
information in it then the security leak has already happened.

I don't consider giving All Projects the tighter security to be a usable
workaround, because then you can't find bugs in the projects that use
normal security for private bugs, until you select one of them, but then
you can only see the subproject hierarchy you just went into.

Steps to reproduce:
------
On a fresh 1.2.2 install try this:

Create a public project.
In the project, edit thresholds so that you need manager to view private
bugs.
Submit a private bug to that project.

Login as a different user with global access of developer. View All
Projects.

You can see the bug in MyView / ViewIssues but then when you click on it
you get an Access Denied screen. If you select the bug's project, then
it correctly disappears.
------

Signed-off-by: David Hicks <d@hx.id.au>
Fix #13191: Prevent further XSS issues relating to PHP_SELF

Silvia Alvarez (Debian package manager for MantisBT) has performed
additional testing of patch d00745f5e267eba4ca34286d125de685bc3a8034
and discovered that the XSS problems surrounding the use of
$_SERVER['PHP_SELF'] have not been fully fixed.

The form_action_self() function also used $_SERVER['PHP_SELF']
(retrieving the basename() component of the file name). Callees of this
function did not escape this file name prior to printing it in the
'action' attribute of <form> elements.

This patch swaps out PHP_SELF for SCRIPT_NAME (much safer as end users
have no control over the value) and also applies escaping to the
'action' attribute of relevant <form> elements.

Refer to Debian bug report #640297 [1] and dicussion on the mantisbt-dev
mailing list for further details.

Thank you Sils for the detailed analysis of the problem, detailed
report, proposed solutions and extensive testing of patches for the
latest round of vulnerabilities discovered.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640297
Fix #13280: Incorrect queries logged when sorting by custom field having accented chars

The offsets returned by preg_match are byte-based, which causes issues with
UTF-8 characters as the subsequent calls to utf8_substr operate on the wrong
part of the string; this results in logging of invalid SQL queries when
$g_show_queries_list = ON.

This commit fixes the problem by realigning the offsets prior to performing the
query parameter substitution.

It also simplifies the code by removing parenthesis in the regexp pattern,
which is not necessary since we are only matching a single element, this way
there is no need to deal with a multi-dimentional array.