View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0020956 | mantisbt | security | public | 2016-05-26 12:43 | 2016-08-15 09:02 |
Reporter | kacperszurek | Assigned To | dregad | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 1.2.19 | ||||
Target Version | 1.2.20 | Fixed in Version | 1.2.20 | ||
Summary | 0020956: CVE-2016-5364: Reflected XSS inside manage_custom_field_edit_page.php | ||||
Description |
Also There are two ways to exploit this issue. First using accesskey inside hidden input field - see http://blog.portswigger.net/2015/11/xss-in-hidden-input-fields.html. Second using | ||||
Steps To Reproduce | XSS will be visible for Administrator and needs user interaction. http://mantis/manage_custom_field_edit_page.php?field_id=1&return=" accesskey="X" onclick="alert(1) or http://mantis/manage_custom_field_edit_page.php?field_id=1&return=javascript:alert(%27XSS%27); | ||||
Additional Information | If issue is valid please credit me as: Kacper Szurek | ||||
Tags | No tags attached. | ||||
Attached Files | 0001-Fix-XSS-in-custom-fields-management.patch (2,764 bytes)
From c7f760f5e38723cd3ffdc9e8b269863bbd97bf92 Mon Sep 17 00:00:00 2001 From: Damien Regad <dregad@mantisbt.org> Date: Fri, 27 May 2016 11:39:58 +0200 Subject: [PATCH] Fix XSS in custom fields management Kacper Szurek (http://security.szurek.pl/) discovered an XSS vulnerability in Custom fields management pages, caused by unescaped output of 'return URL' GPC parameter. His report describes two ways to exploit this issue: 1. using 'accesskey' inside hidden input field (see [1]) reflects XSS to the administrator in manage_custom_field_edit_page.php when the keyboard shortcut is actioned 2. using 'javascript:' URI scheme executes the code when the user clicks the [Proceed] link on manage_custom_field_update.php after updating a custom field This commit fixes both attack vectors: - properly escape the return URL prior to printing it on the hidden form field - let html_operation_successful() sanitize the URL before displaying it, just like html_meta_redirect() does. In this case, if the string contains an URI scheme, it will be replaced by 'index.php' [1] http://blog.portswigger.net/2015/11/xss-in-hidden-input-fields.html Fixes #20956 --- core/html_api.php | 2 +- manage_custom_field_edit_page.php | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/core/html_api.php b/core/html_api.php index b8a3ac3..55696e3 100644 --- a/core/html_api.php +++ b/core/html_api.php @@ -647,7 +647,7 @@ function html_operation_successful( $p_redirect_url, $p_message = '' ) { } echo lang_get( 'operation_successful' ).'<br />'; - print_bracket_link( $p_redirect_url, lang_get( 'proceed' ) ); + print_bracket_link( string_sanitize_url( $p_redirect_url ), lang_get( 'proceed' ) ); echo '</div>'; } diff --git a/manage_custom_field_edit_page.php b/manage_custom_field_edit_page.php index 008d457..b29cfd6 100644 --- a/manage_custom_field_edit_page.php +++ b/manage_custom_field_edit_page.php @@ -73,7 +73,7 @@ $t_definition = custom_field_get_definition( $f_field_id ); <legend><span><?php echo lang_get( 'edit_custom_field_title' ) ?></span></legend> <?php echo form_security_field( 'manage_custom_field_update' ); ?> <input type="hidden" name="field_id" value="<?php echo $f_field_id ?>" /> - <input type="hidden" name="return" value="<?php echo $f_return ?>" /> + <input type="hidden" name="return" value="<?php echo string_attribute( $f_return ); ?>" /> <div class="field-container"> <label for="custom-field-name"><span><?php echo lang_get( 'custom_field_name' ) ?></span></label> <span class="input"><input type="text" id="custom-field-name" name="name" size="32" maxlength="64" value="<?php echo string_attribute( $t_definition['name'] ) ?>" /></span> -- 1.9.1 0001-Fix-XSS-in-custom-fields-management-12x.patch (4,057 bytes)
From 5068df2dcf79c34741c746c9b27e0083f2a374da Mon Sep 17 00:00:00 2001 From: Damien Regad <dregad@mantisbt.org> Date: Tue, 7 Jun 2016 00:25:37 +0200 Subject: [PATCH] Fix XSS in custom fields management Kacper Szurek (http://security.szurek.pl/) discovered an XSS vulnerability in Custom fields management pages, caused by unescaped output of 'return URL' GPC parameter. His report describes two ways to exploit this issue: 1. using 'accesskey' inside hidden input field (see [1]) reflects XSS to the administrator in manage_custom_field_edit_page.php when the keyboard shortcut is actioned 2. using 'javascript:' URI scheme executes the code when the user clicks the [Proceed] link on manage_custom_field_update.php after updating a custom field This commit fixes both attack vectors: - properly escape the return URL prior to printing it on the hidden form field - let html_operation_successful() sanitize the URL before displaying it, just like html_meta_redirect() does. In this case, if the string contains an URI scheme, it will be replaced by 'index.php' [1] http://blog.portswigger.net/2015/11/xss-in-hidden-input-fields.html Fixes #20956 This is a backport from master 3f2779b4c6dc8d465fb73c08cfa1d806184d2e79. --- account_prefs_update.php | 2 +- manage_config_revert.php | 2 +- manage_custom_field_delete.php | 2 +- manage_custom_field_update.php | 2 +- print_all_bug_options_update.php | 2 +- set_project.php | 2 +- 6 files changed, 6 insertions(+), 6 deletions(-) diff --git a/account_prefs_update.php b/account_prefs_update.php index 672c65b..74e5665 100644 --- a/account_prefs_update.php +++ b/account_prefs_update.php @@ -115,6 +115,6 @@ echo lang_get( 'operation_successful' ); echo '<br />'; - print_bracket_link( $f_redirect_url, lang_get( 'proceed' ) ); + print_bracket_link( string_sanitize_url( $f_redirect_url ), lang_get( 'proceed' ) ); echo '<br /></div>'; html_page_bottom(); diff --git a/manage_config_revert.php b/manage_config_revert.php index 8c2d029..69bc0bd 100644 --- a/manage_config_revert.php +++ b/manage_config_revert.php @@ -65,7 +65,7 @@ <div align="center"> <?php echo lang_get( 'operation_successful' ).'<br />'; - print_bracket_link( $t_redirect_url, lang_get( 'proceed' ) ); + print_bracket_link( string_sanitize_url( $t_redirect_url ), lang_get( 'proceed' ) ); ?> </div> diff --git a/manage_custom_field_delete.php b/manage_custom_field_delete.php index 62c56fb..75325e1 100644 --- a/manage_custom_field_delete.php +++ b/manage_custom_field_delete.php @@ -58,7 +58,7 @@ <div align="center"> <?php echo lang_get( 'operation_successful' ) . '<br />'; - print_bracket_link( $f_return, lang_get( 'proceed' ) ); + print_bracket_link( string_sanitize_url( $f_return ), lang_get( 'proceed' ) ); ?> </div> diff --git a/manage_custom_field_update.php b/manage_custom_field_update.php index d56dbfb..befbc06 100644 --- a/manage_custom_field_update.php +++ b/manage_custom_field_update.php @@ -64,7 +64,7 @@ echo lang_get( 'operation_successful' ) . '<br />'; - print_bracket_link( $f_return, lang_get( 'proceed' ) ); + print_bracket_link( string_sanitize_url( $f_return ), lang_get( 'proceed' ) ); echo '</div>'; diff --git a/print_all_bug_options_update.php b/print_all_bug_options_update.php index ab1a1d4..bec71e0 100644 --- a/print_all_bug_options_update.php +++ b/print_all_bug_options_update.php @@ -79,6 +79,6 @@ } echo '<br />'; - print_bracket_link( $f_redirect_url, lang_get( 'proceed' ) ); + print_bracket_link( string_sanitize_url( $f_redirect_url ), lang_get( 'proceed' ) ); echo '<br /></div>'; html_page_bottom(); diff --git a/set_project.php b/set_project.php index e09155d..aeed92b 100644 --- a/set_project.php +++ b/set_project.php @@ -109,7 +109,7 @@ <?php echo lang_get( 'operation_successful' ).'<br />'; - print_bracket_link( $t_redirect_url, lang_get( 'proceed' ) ); + print_bracket_link( string_sanitize_url( $t_redirect_url ), lang_get( 'proceed' ) ); ?> </div> -- 2.7.4 | ||||
Thank you Kacper for reporting this security issue in a detailed, professional way. I confirm that the vulnerability also exists in 1.3.x branch, up to latest HEAD. The accesskey attack vector is easy to fix, calling string_attribute() when echoing the form variable. According to git blame, unescaped echoing was introduced in 1.0.0 (MantisBT master 81ad05d4; MantisBT master 51f52b67 escaped one occurence, but missed the other). The second one requires sanitizing the URL when generating the [Proceed] link, to make sure we don't process javascript URI schemes. Taking this one step further, we should apply the same logic used for redirection URLs (see also 0017648 and 0017648). I will post a patch shortly, and would appreciate if you could take the time to test and confirm it correctly addresses the vulnerability you reported. |
|
Feedback received by e-mail ---------- Forwarded message ---------- Hi! Those changes looks good for 1.3 rc version. Did you plan to make fix for 1.2.19 ? Cheers, 2016-05-29 14:26 GMT+02:00 Damien Regad wrote: |
|
Yes I will backport it. I'll request a CVE and make the issue public next week as time allows. You will get proper credit of course. |
|
Attached proposed backport to fix the issue in 1.2.x branch. |
|
CVE request http://thread.gmane.org/gmane.comp.security.oss.general/19762 |
|
CVE-2016-5364 was assigned |
|
MantisBT: master 11ab3d6c 2016-05-27 01:39 Details Diff |
Fix XSS in custom fields management Kacper Szurek (http://security.szurek.pl/) discovered an XSS vulnerability in Custom fields management pages, caused by unescaped output of 'return URL' GPC parameter. His report describes two ways to exploit this issue: 1. using 'accesskey' inside hidden input field (see [1]) reflects XSS to the administrator in manage_custom_field_edit_page.php when the keyboard shortcut is actioned 2. using 'javascript:' URI scheme executes the code when the user clicks the [Proceed] link on manage_custom_field_update.php after updating a custom field This commit fixes both attack vectors: - properly escape the return URL prior to printing it on the hidden form field - let html_operation_successful() sanitize the URL before displaying it, just like html_meta_redirect() does. In this case, if the string contains an URI scheme, it will be replaced by 'index.php' [1] http://blog.portswigger.net/2015/11/xss-in-hidden-input-fields.html Fixes 0020956 |
Affected Issues 0020956, 0021090 |
|
mod - core/html_api.php | Diff File | ||
mod - manage_custom_field_edit_page.php | Diff File | ||
MantisBT: master-1.2.x 5068df2d 2016-06-06 14:25 Details Diff |
Fix XSS in custom fields management Kacper Szurek (http://security.szurek.pl/) discovered an XSS vulnerability in Custom fields management pages, caused by unescaped output of 'return URL' GPC parameter. His report describes two ways to exploit this issue: 1. using 'accesskey' inside hidden input field (see [1]) reflects XSS to the administrator in manage_custom_field_edit_page.php when the keyboard shortcut is actioned 2. using 'javascript:' URI scheme executes the code when the user clicks the [Proceed] link on manage_custom_field_update.php after updating a custom field This commit fixes both attack vectors: - properly escape the return URL prior to printing it on the hidden form field - let html_operation_successful() sanitize the URL before displaying it, just like html_meta_redirect() does. In this case, if the string contains an URI scheme, it will be replaced by 'index.php' [1] http://blog.portswigger.net/2015/11/xss-in-hidden-input-fields.html Fixes 0020956 This is a backport from master 3f2779b4c6dc8d465fb73c08cfa1d806184d2e79. |
Affected Issues 0020956 |
|
mod - account_prefs_update.php | Diff File | ||
mod - manage_config_revert.php | Diff File | ||
mod - manage_custom_field_delete.php | Diff File | ||
mod - manage_custom_field_update.php | Diff File | ||
mod - print_all_bug_options_update.php | Diff File | ||
mod - set_project.php | Diff File |