View Issue Details

WikiRelated ChangesetsJump to Notes
IDProjectCategoryView StatusDate SubmittedLast Update
0009999mantisbtbugtrackerpublic2008-12-24 00:302009-04-20 09:49
Reporterarul_k_kumar Assigned Tojreese  
PrioritynormalSeveritymajorReproducibilitysometimes
Status closedResolutionfixed 
PlatformWAMPOSWindowsOS VersionServer 2003
Product Version1.1.5 
Target Version1.1.7Fixed in Version1.1.7 
Summary0009999: APPLICATION ERROR #2800 - While submit a new bug
Description

My configuration:
Mantis: Version 1.1.5
PHP: Version 5.2.6
SQL: MySQL Version 5.0.51b
Platform: Windows Server 2003 Enterprise edition
Browser version: IE 6 and 7

When i submit a new bug item in the tracker, below error are popedup

APPLICATION ERROR #2800
Invalid form security token. Did you submit the form twice by accident?

Please use the "Back" button in your web browser to return to the previous page. There you can correct whatever problems were identified in this error or select another action. You can also click an option from the menu bar to go directly to a new section.

Please advice

TagsNo tags attached.
Attached Files
0001-Fix-9999-allow-form-security-to-be-disabled-for-si.patch (3,566 bytes)    
From 276d9e6974822db4ad1e6639271b0e97b17445f5 Mon Sep 17 00:00:00 2001
From: John Reese <jreese@leetcode.net>
Date: Fri, 27 Mar 2009 14:16:51 -0400
Subject: [PATCH] Fix #9999: allow form security to be disabled for sites that use 'bad' proxy servers.

---
 config_defaults_inc.php |   10 +++++++++-
 core/form_api.php       |   20 ++++++++++++++++++++
 2 files changed, 29 insertions(+), 1 deletions(-)

diff --git a/config_defaults_inc.php b/config_defaults_inc.php
index d551adc..bf372eb 100644
--- a/config_defaults_inc.php
+++ b/config_defaults_inc.php
@@ -230,6 +230,14 @@
 	 */
 	$g_session_validation = ON;
 
+	/**
+	 * Form security validation.
+	 * This protects against Cross-Site Request Forgery, but some proxy servers may
+	 * not correctly work with this option enabled because they cache pages incorrectly.
+	 * WARNING: Disabling this IS a security risk!!
+	 */
+	$g_form_security_validation = ON;
+
 	/**************************
 	 * Configuration Settings *
 	 **************************/
@@ -243,7 +251,7 @@
 	$g_global_settings = array(
 		'_table$', 'cookie', '^db_', 'hostname', 'allow_signup', 'database_name', 'show_queries_count', 'admin_checks', 'version_suffix',
 		'_path$', 'use_iis', 'language', 'use_javascript', 'display_errors', 'show_detailed_errors', 'stop_on_errors', 'login_method', '_file$',
-		'anonymous', 'content_expire', 'html_valid_tags', 'custom_headers', 'rss_key_seed', 'plugins_enabled', 'session_',
+		'anonymous', 'content_expire', 'html_valid_tags', 'custom_headers', 'rss_key_seed', 'plugins_enabled', 'session_', 'form_security_',
 	);
 
 	/****************************
diff --git a/core/form_api.php b/core/form_api.php
index 776d6bd..31dc5b9 100644
--- a/core/form_api.php
+++ b/core/form_api.php
@@ -36,6 +36,10 @@
  * @return string Security token string
  */
 function form_security_token( $p_form_name ) {
+	if ( OFF == config_get_global( 'form_security_validation' ) ) {
+		return;
+	}
+
 	$t_tokens = session_get( 'form_security_tokens', array() );
 
 	# Create a new array for the form name if necessary
@@ -62,6 +66,10 @@ function form_security_token( $p_form_name ) {
  * @return string Hidden form element to output
  */
 function form_security_field( $p_form_name ) {
+	if ( OFF == config_get_global( 'form_security_validation' ) ) {
+		return '';
+	}
+
 	$t_string = form_security_token( $p_form_name );
 
 	# Create the form element HTML string for the security token
@@ -78,6 +86,10 @@ function form_security_field( $p_form_name ) {
  * @return string Hidden form element to output
  */
 function form_security_param( $p_form_name ) {
+	if ( OFF == config_get_global( 'form_security_validation' ) ) {
+		return '';
+	}
+
 	$t_string = form_security_token( $p_form_name );
 
 	# Create the GET parameter to be used in a URL for a secure link
@@ -96,6 +108,10 @@ function form_security_param( $p_form_name ) {
  * @return boolean Form is valid
  */
 function form_security_validate( $p_form_name ) {
+	if ( OFF == config_get_global( 'form_security_validation' ) ) {
+		return;
+	}
+
 	$t_tokens = session_get( 'form_security_tokens', array() );
 
 	# Short-circuit if we don't have any tokens for the given form name
@@ -142,6 +158,10 @@ function form_security_validate( $p_form_name ) {
  * @param string Form name
  */
 function form_security_purge( $p_form_name ) {
+	if ( OFF == config_get_global( 'form_security_validation' ) ) {
+		return;
+	}
+
 	$t_tokens = session_get( 'form_security_tokens', array() );
 
 	# Short-circuit if we don't have any tokens for the given form name
-- 
1.6.1.2
0001-Fix-9999-allow-form-security-to-be-disabled-for-si.patch (3,566 bytes)   

Relationships

has duplicate 0010293 closedjreese APPLICATION ERROR #2800: Invalid form security token. 
has duplicate 0010467 closedjreese Application Error #2800 

Activities

vboctor

vboctor

2008-12-24 03:28

manager   ~0020479

This is fixed in 1.1.6, please upgrade and confirm that the problem is fixed.
yop

yop

2008-12-24 05:39

reporter   ~0020481

Still getting the same error in 1.1.6
This doesn't happen to everyone but each user reporting this is using IE 6.
The have been instructed to use the Ctrl-F5 workaround.

*I have posted the same note in 0009698 but since this is open I thought I 'd repost it.
ga_acad

ga_acad

2009-02-09 11:55

reporter   ~0020823

Just installed 1.1.6 last week. Same issue here. Does not happen to all users. Does not seem to matter which browser we use - firefox or IE (all recent versions). Mantis has become useless to us if we cannot enter bugs. What is this cntrl-F5 workaround ? Please help.
yop

yop

2009-02-10 02:49

reporter   ~0020829

Before entering the report (while you are in the "Report Issue" screen) press Ctrl+F5. This is a full reload of the page (see 0009698).
augur

augur

2009-02-10 08:07

reporter   ~0020831

Hi.

We get the same problem in a similar linux enviroment with 1.1.6
With 1.1.1 we upgrade from, we did not get the error. In that case I think, we have to downgrade.
skay

skay

2009-02-13 05:25

reporter   ~0020839

We have the same problem! We have updated a 1.1.1 installation to 1.1.6. After clearing the browser cache we still get error 2800 when submitting a second bug.
jreese

jreese

2009-02-13 11:21

reporter   ~0020840

Are any of you using a proxy server?
augur

augur

2009-02-13 11:27

reporter   ~0020841

Yes, the problem can only repoduced with a connection over a proxy server.
skay

skay

2009-02-13 14:28

reporter   ~0020842

Yes, we are behind a proxy.
skay

skay

2009-02-17 12:05

reporter   ~0020873

What is the current status? We need a solution for this problem!
thegisguy

thegisguy

2009-02-19 11:09

reporter   ~0020897

Last edited: 2009-02-19 11:11

Similar issue here. I upgraded from 1.1.2 to 1.1.6 on a "Development" version of Mantis. Things are fine for the first reported issue, but I get the APPLICATION ERROR #2800, for the second one. Doesn't matter who reports the second issue. Happens in Firefox or IE6. Force Refresh doesn't seem to help.
jreese

jreese

2009-03-27 14:22

reporter   ~0021237

Last edited: 2009-03-27 14:23

I've attached a patch that allows you to disable the form security validation. Note that this is a security risk for any public-facing website, but should fix the #2800 errors with proxy servers that are not caching pages appropriately.

If anyone with this problem that uses a proxy server could test this patch along with adding "$g_form_security_validation = OFF;" to their config_inc.php, that would be appreciated. If it works to solve the problem, then I'll commit this to the upcoming 1.1.7 and 1.2.x development trees.

Cheers.
skay

skay

2009-03-27 18:09

reporter   ~0021239

Hello jreese, thanks for the patch. I'll test it during the next week and give you a feedback. The security risk is not really relevant for us, because we use the system only in the intranet.
jreese

jreese

2009-03-27 19:16

reporter   ~0021241

Do note that you are still at risk of this attack from an external source, even when your installation is not available to the internet; it would only require someone to have knowledge of your site's existence and base URL. Granted this is a much more remote attack possibility; see http://en.wikipedia.org/wiki/CSRF for more information.
augur

augur

2009-03-28 04:53

reporter   ~0021243

Hi.

As an idea...would it easily possible to add an dummy parameter (as an GUID) in every get request (every link) like view.php?id=999&dummy=4582n4b2g4k56b3k ?

So the cache of the proxy should not cache the page, if the parameter changes every time and we can use the security validation.

thx
Nils
skay

skay

2009-03-28 05:57

reporter   ~0021245

I have tested the patch and the #2800 problem is solved with this patch. But with the version 1.1.6 and your patch I have a new problem. In one project I can't create a new bug entry. I always get the error #11, but all fields are filled out. And when I rollback to version 1.1.1 everything works fine. Is this a known problem?
Chi-Yu

Chi-Yu

2009-03-30 04:17

reporter   ~0021270

We are not using a proxy and we have the same problem. It seems that upgrading to version 1.1.6 was a bad idea since Mantis is pretty much unusable right now.
jreese

jreese

2009-03-30 08:47

reporter   ~0021280

skay, check that you don't have any custom fields defined that are required, but aren't set up to show on the bug report page. That would cause the behavior you mentioned.

Chi-Yu, if you are not using a proxy, then you shouldn't be receiving these errors. Have you clearing the browser's cache or tried using Ctrl+F5 to reload the bug report page?
Chi-Yu

Chi-Yu

2009-03-30 17:01

reporter   ~0021300

Forget it. It seems it was a problem on our side.
skay

skay

2009-03-31 09:09

reporter   ~0021340

@jreese: I have checked the "error 11" behaviour again. There is no "invisible" custom field and also no custom field which is not filled with data by submitting the bug. With version 1.1.1 it works fine, but with version 1.1.6 and your patch I alsways get error 11.
jreese

jreese

2009-04-13 14:51

reporter   ~0021500

Fix committed to master-1.1.x and master branches.

skay: I was unable to reproduce your error; I think it may be the result of an incorrect patching issue with 1.1.x, as I had to manually resolve conflicts when porting the patch to the 1.1.x branch. If you could test a nightly build of 1.1.7 via http://www.mantisbt.org/builds/ that would be appreciated. Otherwise, we'll be releasing 1.1.7 shortly with the patch included.

Cheers

Related Changesets

MantisBT: master 10040dee

2009-03-27 14:16

jreese


Details Diff		 Fix 0009999: allow form security to be disabled for sites that use 'bad' proxy servers. Affected Issues
0009999
mod - core/form_api.php Diff File
mod - config_defaults_inc.php Diff File

MantisBT: master-1.1.x 72235214

2009-03-27 14:16

jreese


Details Diff		 Fix 0009999: allow form security to be disabled for sites that use 'bad' proxy servers. Affected Issues
0009999
mod - core/form_api.php Diff File
mod - config_defaults_inc.php Diff File