Return Authorization Module (RMA)

[dw08gm]

Re: zen_output_string_protected

The function has to do with averting "sql-injection" and "XSS vulnerability" in Zen Cart.

The function is still widely used in 151 on both admin and catalog sides, including a small number of header_php.php and tpl_whatever_default.php files on catalog side, including tpl_account_history_info_default.php.

However I remain unsure whether it should be applied to the RMA files, or any form-producing files for that matter, but suspect it should where inputs are extracted from or written to the database by the form files, or where other interacting files or mod, such as tpl_account_history or Email_Archive_Manager, are involved. However, its presence does not seem to affect the processing of the forms.


I found this thread dating from 25 October 2008, although it is unclear to me whether the parts highlighted are relevant to RMA.
http://www.zen-cart.com/showthread.p...ring_protected
Post 3 Dr Byte

If the customer has entered text information for an attribute field such as a filename or a text-input field, if that information is to be displayed again for verification/edit, you certainly want that information sanitized before it's displayed.

Would the redisplay of inputs (eg info inserted into RMA form fields from database, eg oID, name), say in going from the account_history_info_default to the RMA page, or proceeding from input to error checking to error correction in the RMA page, constitute a "displayed again for verification/edit" case?

Post 7 Dr Byte

I would think that the output-protected approach should be run anytime the content of user-collected data is being re-displayed, so that if any sql-injection or other attack would be averted.

Would the redisplay of inputs (eg info inserted into RMA form fields from database, eg oID, name), say in going from the account_history_info_default to the RMA page, or proceeding from input to error checking to error correction in the RMA page, constitute an "output-protected approach should be run anytime the content of user-collected data is being re-displayed" case?

Post 9 Dr Byte

Will have to do some further investigation. Here's a related post: http://www.zen-cart.com/forum/showthread.php?t=64115

This last thread dates from 25 April 2007 and specifically refers to XSS vulnerability in and provides fixes for Zen Cart 1.3.7 (and prior versions).


Re: error messaging
I found displaying error messaging within the form, as opposed to displaying same within a message stack, disrupts the layout of the form - with longer error messages causing greater disruption - which can make the overall form difficult to rescan for errors or alterations.

As online forms and associated error message stacks have been around for ages, I am sure the majority of internet users are quite familiar with navigating their way through them. So from my long experience, displaying error messaging within the form is just a change for change sake.

Let us not lose sight of the fact that we are only talking about a Returns form that is applied post-purchase. Sure, it may be convenient for customer relations, but displaying error messaging within a form does not provide for greater sales.

cheers