1 Topic by Cheater (edited by Cheater 07/23/2013 04:31:25 pm)

  • Registered: 07/22/2013
  • Posts: 5

Topic: Page 1 posts a postfield which gives a http 409 error

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.

  • Registered: 12/25/2007
  • Posts: 2,448

Re: Page 1 posts a postfield which gives a http 409 error

I think it should be considered as  modsecurity bug, shouldn't it?
Janusz

  • Registered: 07/22/2013
  • Posts: 5

Re: Page 1 posts a postfield which gives a http 409 error

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....

  • tm
  • Senior Member
  • Offline
  • From: Sweden
  • Registered: 05/13/2013
  • Posts: 142

Re: Page 1 posts a postfield which gives a http 409 error

I'm not sure it's a bug at all. Conflicting requirements, perhaps. Both FA and modsecurity seem to be doing just what they were intended to do.

An HTML button's caption is defined by its value, which (naturally) gets passed when the form is submitted. If modsecurity regards any form field's value as suspicious, it will give an error. It has no way of knowing how those values are used on the server, if at all.

And there is no way to guarantee that a value will not match a rule, as they can be (mis-)configured by the provider. And since strings in FA are translated, such errors might only appear on certain pages, when certain languages are used.

Besides, any application which uses brackets in button captions would be affected. Unless the issue has been raised with the developers of modsecurity, I suspect the rule in question is part of a local ruleset. In that case, it is the provider's problem. Or perhaps the end user's.

Since these rulesets (local or otherwise) are moving targets, modifying FA (and all translations) does not seem like the way forward. This time it's brackets. What if someone decides that exclamation marks are suspicious?

  • Registered: 07/22/2013
  • Posts: 5

Re: Page 1 posts a postfield which gives a http 409 error

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.

  • tm
  • Senior Member
  • Offline
  • From: Sweden
  • Registered: 05/13/2013
  • Posts: 142

Re: Page 1 posts a postfield which gives a http 409 error

The "requirement" here is being able to set the button caption to anything, even including characters that may be deemed "unsafe" by some rule. It's perfectly safe as long as the data is not passed as a command line, and in this case (as with all buttons I've ever come across) the value is completely ignored.

That the caption gets sent along with the form data, is really a problem with the way HTML buttons are defined. It may be a bit late to address that problem now, though. And modsecurity is not essential in any way. All it does is add filtering which should already be present in applications receiving form data.

Also, these rules were not exactly delivered on stone tablets. They can be changed and extended by the provider. Moving targets, again. Thus, there is no way to ensure that any particular string will not match a rule. The translations seem messy enough without introducing a build time filter (that needs constant updates) to ensure they do not trigger some "security" rule which may exist on some server somewhere.

Since I'm not the developer, I can't say whether they considered it "smart" to submit the offending characters. But I can't see it as particularly dumb either. It's actually a good visual hint for a "continue" or "next" button. The only reason it's become a problem here is that some other software tries to overrule FA's input handling. Working around such a "feature" would be a waste of time and resources.

7 Reply by Cheater (edited by Cheater 08/03/2013 12:35:25 am)

  • Registered: 07/22/2013
  • Posts: 5

Re: Page 1 posts a postfield which gives a http 409 error

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...

  • tm
  • Senior Member
  • Offline
  • From: Sweden
  • Registered: 05/13/2013
  • Posts: 142

Re: Page 1 posts a postfield which gives a http 409 error

If the translations can be executed as code, that is indeed a problem. I suggest you report it as a bug.

However, it is a different problem. It has nothing to do with this particular button. In fact, the malicious translator could add anything he wanted - including buttons.

As for this problem... Fair enough. Moving the string to a span certainly does no harm. But it doesn't solve your problem with an apache module trying to "protect" your FA instance by filtering posted data either. The "vulnerability" just isn't there as long as the posted value is ignored. And this "protection" applies to all fields, which means that local rules may block anything the provider considers suspicious. Including user supplied data. There is no way that FA can prevent that.

  • Registered: 07/22/2013
  • Posts: 5

Re: Page 1 posts a postfield which gives a http 409 error

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!