Forums

Hi. I've been testing ChronoForms recently and I must say that the process of designing forms is a time saver, really nice, to the point you deserved a donation:) I would like to understand a little bit better how CF is designed regarding security and validation. After searching around I did not find a review on this subject. Let us consider a user without javascript active in his browser.

a) after building the form in the ChronoForms backend I was surprised to see that there is no quick way of doing serverside validation of simple things such as cell phone numbers, emails, required fields, etc. am I right? From a coders perspective, why it is given priority to javascript validation rather than serverside validation? Would it be easy to program CF to do the selected validations in the design process in addition to Javascript, in PHP, being these validations automatically added to the serverside validation box in the form configuration?

b) for a form without server-side validation, with a CAPTCHA, and with the option "Try to fill in the form if some error occurs" are there any major security concerns using CF (besides possibly having bogus data stored in the database and empty fields)?

Thank you!

Hi,
There is no "click'n'play" interface for serverside-validation, though there is a very simple mechanism to add your own custom code for this. Check the Validation-Tab within the Form manager, and you'll find a section named "Serverside Validation".

Regarding the RePublish-feature, there are no security issues to my knowledge. It will simply load an extra javascript responsible for assigning the various form values to the available form inputs. In the event of a failed Captcha or ServerSide Validation, no data would be saved in the database table.

/Fredrik

Hi blurpfish,

The reason for the JavaScript validation is historic. Originally there was no validation then a user (bouton - who is still credited on the tab) used the 'ReallyEasy JavaScript Validation library. Max liked it and added it to the package. In a later release he substituted the LiveValidation library.

I've never seen an easy route to PHP Validation suggested here and I suspect that by far the majority of users rely on the JavaScript library and that is probably good enough for their applications.

We do recommend that (a) you use the Joomla JRequest filters on any data received and (b) you add any extra checks that are appropriate for your data in the OnSubmit Before Code box to make sure that any data saved is cleaned and safe.

Bob

Thank you for your (helpful) answers. Just to clear out related aspects... consider the case of no server-side validation defined by the user, and the following few naive questions....

- variables are always filtered out (e.g.,htmlentities) before going to the database or Republished?
- uploaded files are checked for correct extension after they are on the server... and if they haven't correct extension, they are deleted?
- shouldn't the automatically created upload file directories have some sort of .htacess forbidden protection for the case of (an odd situation) where the server is not configured to display index.html and listing directory files?
- if the uploaded files in the forms are attached to emails, is there an automatic way to define them to be deleted from the server after the emails being sent?

Thank you once again.
R.

Hi blurpfish,

- variables are always filtered out (e.g.,htmlentities) before going to the database or Republished?

You should not rely on ChronoForms to filter incoming data. If you use the ChronoForms DB Connection then they are passed through the Joomla JRequest::get( "post" , JREQUEST_ALLOWRAW ). The Joomla default setting for JREQUEST_ALLOWRAW is 2 which does not filter. The options are

Filter bit mask.
1=no trim: If this flag is cleared and the input is a string, the string will have leading and trailing whitespace trimmed.
2=allow_raw: If set, no more filtering is performed, higher bits are ignored.
4=allow_html: HTML is allowed, but passed through a safe HTML filter first. If set, no more filtering is performed. If no bits other than the 1 bit is set, a strict filter is applied.[/quote]
It is also possible to access and save data by reading the $_POST array directly which would bypass any Joomla filtering. Conversely, the OnSubmit Before box and the server-side validation allow you pretty much complete control over your data.

- uploaded files are checked for correct extension after they are on the server... and if they haven't correct extension, they are deleted?

They are checked for the correct extension and there is no longer wild card option so case-insensitive extension filtering is applied. I've checked the code and I don't believe that that the uploade file is deleted from the tmp folder if there is an error. This could easily be added though.

- shouldn't the automatically created upload file directories have some sort of .htacess forbidden protection for the case of (an odd situation) where the server is not configured to display index.html and listing directory files?

Nothing is done at present except to write the standard Joomla index.html file to the folder that ChronoForms creates. In general I think that Max has taken the approach that the admin needs to manage any specific server protection.

- if the uploaded files in the forms are attached to emails, is there an automatic way to define them to be deleted from the server after the emails being sent?

No automatic way but it's straightforwad to do so in the OnSubmit After Code box.

Bob

Thank you for the insights... I am now using filter_var, substr and mysql_real_escape_string for sanitizing stuff before going to the DB, plus a few validations. To finish this topic, which is starting to cover too many subjects :-) I will leave other related question:
- if the "try to republish" option is active, all fields seem to be filled with sanitized data on error (for example, wrong captcha). Consider now a malicious user which has javascript disabled in his browser and decides to fill in a textarea field with tons of data... can that user fill in a textarea field to a point which causes the web application to crash when it starts to sanitize the data for republishing?
Thanks.

Hi blurpfish,

There's a 'Skip on Republish' box on the Form General tab that you can use to skip specified fields on the Republish.

I don't know the answer to the size overload part of the question though.

Bob

Hi,
Quite a few topics here now...

mysql_real_escape: This is only suitable for the actual SQL-query (not useful for js-code), and is already covered by the JTable class. Watch out for multiple backslashes (\) if you escape the data yourself.

Memory: If a malicious user would dump large amounts of data, (s)he'd only reach the memory_limit amount of allocated memory, where PHP wil simply terminate the current process, freeing the slot on the web server for a new request. Also, given that most (if not virtually all) web servers can handle thousands connections simultaneously, the impact of one malicious user would hardly make a 'dent'.

.htaccess and uploads: .htaccess is mainly an Apache feature, I'm not sure how other web servers capable of running Joomla supports the various directives. It would probably be a better idea to add these by hand, or use an upload-path not visible on the web (this would vary between web servers and hosting companies).
As Bob wrote, the current behaviour of creating an empty index.html-file, and leave any extended restrictions to the administrator is probably better.

File extensions: The upload routine in PHP uses a random name in the server temporary directory, and unless the php-script (joomla, etc) takes actions to copy/move/rename the file, it will be removed as the script end and the ile is lost.
ChronoForms check the last extension (last word after the right-most dot) of the filename against the file extensions you specify. There's one issue on apache servers with a certain configuration - it tests each extension of the filename and lok for different handlers (such as php). In this case, a file such as me.php.jpg would be considered both an image and a php-script. In that case, if php is hooked into apache 'in the wrong way', it would be executed as a php-script. If you're worried by this, simply create a file named test.php.txt add some php-code (perhaps <? echo php_info(); ?>), upload the file to the server, and view it in your browser. If you see the actual php-code, you're safe, if you see alot of php-info output, you'd be best block remote access to the uploaded files.

/Fredrik