You are correct, and I will ask my hosting provider to lower the set of rules for mod_security (they offer it by themselves) but they don't disable mod_security in totallity, because it's part of their network setup.... bummer!
1 08/03/2013 12:25:22 pm
Re: Page 1 posts a postfield which gives a http 409 error (8 replies, posted in Installation)
2 08/03/2013 12:10:13 am
Re: Page 1 posts a postfield which gives a http 409 error (8 replies, posted in Installation)
It's perfectly possible to set a caption to button, and setting an other value to it, to be submitted. However, FA does submit the caption of a button because the value is not explicit set. Submitting a translated value is always a bad practice, for the sake of security AND correct functioning the application (I mean, correct functioning as, PHP code that can be relied on). The value is for each language different and such values can't be relied on > which FA does not rely on, because it does not read out the submitted value... so changing the value to something staticly (a dummy value?) is better in security AND a way to ensure there are no weird strings submitted (as is not the case with a dummy value).
The resulting HTML code of the button we are talking about:
<button id="continue" class="inputsubmit" value="Continue >>" name="continue" type="submit">
<span>Continue >></span>
</button>
The value between <span> .. </span> can be anything a translator would like * (see note below).
The value=" .. " part after 'inputsubmit', should be the same at all time. It is not best practice to be a translated label (with weird characters)
* note: a translator may go mad on his translations, but he may not include certain characters that can malform the outputted HTML in a way FA was not designed. A translator should not add HTML tags to a translated value at places where they are not supported.
I have tested, that: if a translator adds a double quote in his translated field, he can than add malicious code to his translations. This is a very serious security flaw.
I hope the translations are checked all the time, every update, every change, before they are publicly downloadable via the FA site!!! I already said that, by saying that translations should be checked against a set of rules, defined by FA or so...
3 08/01/2013 11:06:40 pm
Re: Page 1 posts a postfield which gives a http 409 error (8 replies, posted in Installation)
I discovered that my hosting company has mod_security activated by default with a large set of rules.
They offer customers the possibility to disable a set of rules that are common to occur for Joomla, WordPress and Magento,
so that these solutions will work as intended.
FrontAccounting will hopefully work too after disabling this set of rules.
I am a webdeveloper and work at a company where we develop medium scaled webshop solutions. We have the privilege to define our own rules of requirements to hosting.
That said, it would be best to not search the boundaries of security rules, even without knowing them.
It's better to build an application at a way so that most systems can comply with each other, then to give in security rules. Submitting 'greater than' characters is not quite smart at all, even more if does not have to be that way. (manual user input
not included)
Language packs should always be checked against a list of rules which the language definition files should meet, in order to be approved. That way, these problems will not rise again.
I hope, you don't think that submitting '>>>' should be a requirement of FA, because ANY value for the specific button will do. The value wasn't checked in the PHP code.
4 08/01/2013 04:13:51 pm
Re: Page 1 posts a postfield which gives a http 409 error (8 replies, posted in Installation)
Yes it is.. but what can I do about it?
It would be better to not submit form fields with characters that aren't really necessary.
Can you tell me more about the modsecurity bug? Because I couldn't get FrontAccounting to work at all at the hosting company. I get 500 errors (Method not implemented) from them....
5 07/22/2013 10:41:32 pm
Topic: Page 1 posts a postfield which gives a http 409 error (8 replies, posted in Installation)
Page 1 of the installation posts a field named 'continue'. It's value is 'Continue >>', but my hosting provider gives me this in the error log:
ModSecurity: Access denied with code 409 (phase 2). Pattern match "(< ?(?:script|about|applet|activex|chrome).*(?:script|about|applet|activex|chrome) ?>|> ?< ?(img ?src|a ?href) ?= ?(ht|f)tps?:/|" ?> ?<|" ?[a-z]+ ?<.*>|> ?"? ?(>|<)|< ?/?i?frame)" at ARGS:continue. [file "/etc/asl/10_asl_rules.conf"] [line "570"] [id "340147"] [rev "25"] [msg "Generic XSS filter"] [severity "CRITICAL"] [hostname "keep_this_secret"] [uri "/install/index.php"] [unique_id "DYAMXn8AAAEAAAgvTbYAAAA2"]
I solved this by changing the following line in file /install/index.php
submit_center('continue', _('Continue >>'));
into
submit_center('continue', _('Continue'));
The code only checks for a postfield 'continue' with isset, so the value isn't checked.
I hope this weird kind of submit values doesn't encounter me while using FrontAccount, but I'll find out soon enough.
After going through the setup, it seems all pages send this 'continue' form submit. So I had to manipulate all the forms, before sending them.