Fabric forms - HTML and PHP code is allowed???

[CyberFabrik]

Hello guys,

been playing with Fabrik and some public web forms (simple contact us form). I was trying to break Fabrik when i realised that the users are freely allowed to enter any HTML or PHP code which actually passes through and gets stored in the database. So i guess when displaying tables with the recorded data this code could essentially be activated.

I would have thought that entering HTML code or any other form of code in the text fields should not be allowed in the first place by default. Am I right to assume that allowing PHP code to be entered would be a good recipe for injection vulnerabilities?

Of course, to be honest, I know that Fabrik is simply the means to creating Forms and should not really be expected to do the work of a web developer. However, since Fabrik (and especially Fabrik 2.0) seems to follow Joomla development i would think that it would be nice to have by default built-in input escaping and filtering simply by copying the series of code checks and validations that the Joomla boys do (and maybe have an extra field option in admin area to allow code entries as per element).

In general what custom validation rules do you guys use for your forms (especially the public ones)? It seems to me that the 3 (not empty, email, isalphanumeric) validation rules are far from enough for building robust forms.

Please correct me if i am wrong !

Many thanks.

 

[CyberFabrik]

pumping up the volume on this one a little bit

 

[cheesegrits]

Yup. I meant to post this morning. Very much taken under advisement.

2.0 already uses J!'s filtering. 1.x is safe from SQL injection, but seems that scripts can be injected (one of the reasons for the PHP5 announcement today, as I want to run the www.htmlpurifier.org library in the longer term). Look for some SVN changes soon with some basic bandaids.

As for validations - you can create any kind of regex validation you want in 1.x or 2.x (which could get rid of any <> tags), and in 2.x you also have the option for PHP validations (as plugins).

But we should de-fang input at a basic level to prevent XSS attacks and the like, as a default option which would have to be explicitly turned off. And I thought we already did, but apparently not, LOL!

MNWTIN (More News When There Is News).

-- hugh

 

[aplouviez]

what kind of validation rules ?
Essentially tests on the content
- date between this and that
- country (drop =list) in/out Europe
- comparison of 2 fields

but also conditional rules :
- not empty if this field is set on xxx

does it help you ?

AP

ps : in fact, I really need this at this time, and I try to make it, but I don't know how in the current version...

 

[cheesegrits]

Not sure how your post relates to the thread subject, which is de-ganging form input to get rid of attempted hacking.

Are you just listing some validations you would find useful?

-- hugh

 

[chip]

I very much would like to see something written up on how to use the validation rules. I for one see how vulnerable Fabrik is to injection -- simply fire up 'tamper data' and insert the values you want anywhere you want and they get passed straight to the backend database. The entire database structure is revealed before ones eyes in 'tamper data.' It's a scary thing and quite frankly doesn't make the Fabrik forms very usable except as static text.

Now... if some effort could be put into using validation rules and such and putting it out there so others could understand it and use, that is quite a different story. But so far it seems far from happening and is saddening to me since I've put a lot of effort into building an app. in Fabrik only to see that it will be torn to shreds when it goes online.

 

[rob]

Explain to me how you can use tamper to perform a successful SQL injection from a fabrik form?

An SQL injection attack is when someone tries to enter data which corrupts the insert statement allowing them to run additional statements.

So lets say we have a form with one field called name and we enter this text:

rob"; drop jos_users;

If we didn't deal with the input correctly our insert statement might look like this:

INSERT INTO table (`name

 

[rob]

LOL

ok - well that is another example of how SQL Injection is blocked - vbulletin just ate my post!

Looks like I might have trouble typing on the forum and explaining this - take a look at this cartoon to get the idea http://xkcd.com/327/

Suffice to say that we correctly do things to avoid SQL injection attacks

The entire database structure is revealed before ones eyes in 'tamper data.' It's a scary thing and quite frankly doesn't make the Fabrik forms very usable except as static text.

incorrect - the available fields in your form that are sent via the http request are visible - ALL forms will exhibit this behaviour. This is not a security risk in itself.

 

[cheesegrits]

I for one see how vulnerable Fabrik is to injection

As Rob says, please show us an example of a successful SQL injection attack in Fabrik, and we'll plug the hole. But as I've explained in several other responses to your concerns, we already take great precautions to prevent injections, XSS and all the other common forms of spoofing.

Basically ... please be sure of your facts before tossing phrases like that into the forums.

Bottom line, we are no more vulnerable to form based attacks than any other app, and a darn site more secure than most.

-- hugh