Form Validator - Liberty University

Download Report

Transcript Form Validator - Liberty University

Form Validator
“Hasta La Vista SQL Injection”
Their Job, Our Job, It’s Job

Chris Anley mentions Four BestPractices to Avoid SQL Injection
– Three are Sys. Admin and DBA tasks
– Only one is related exclusively to coding
– Comprehensive Input Validation

That’s what the Form Validator does!
You’re Not Saying…?!?


No, this is NOT the silver bullet for security
or even just SQL Injection.
Comprehensive Input Validation
– “Comprehensive” now may not be tomorrow.
– Your “Comprehensive” may be more than mine.

We need a foundation on which to build.
Another “Perfectly Conceived” Acronym

FDF originally stood for Form
DeFinition
– Hideously Stupid

Could stand for Form Definition File
– I Like this One

Whatever you call it, here lies the
building blocks of the Form Validator XML
Form Definition File




Built on XML
Makes use of a set of pre-defined tags
to create rules for a form and
elements on that form.
Each FDF file (after the ?XML tag)
begins with the fdf tag.
Structure of all of the tags under fdf…
From <start> to </start>

fdf
– form
– return
– group (optional)



id
required
total
– rule (optional groupid = “<group-id>”)





display
field
length
type
required
Elements Explained…

form
– Describes the name of the form which the
validator is validating.
– XML syntax – “<form>…</form>”

return
– Describes the URL of the page which
contains the above form.
– XML syntax – “<return>…</return>”
Grouped Fields


Need an “Outta”?
group
– Contains the information for a particular set of
grouped fields.
– XML syntax
<group>
<id>…</id>
<required>…</required>
<total>…</total>
</group>

Optional “groupid” Attribute
Form Validator – Ruler of the Form


The individual rules for each form element.
rule
– Contains the information for a particular form field.
– XML syntax
<rule>
<display>…</display>
<field>…</field>
<length>…</length>
<type>…</type>
<required>…</required>
</rule>
Grouped By Group ID


The “groupid” attribute can be given to a
rule to associate it to a group of rules.
For example
<group>
<id>…</id>
</group>
<rule groupid=“…”>
…
</rule>
Stick Together and We’ll Make It Through


All <group>…</group> tags must be
together before all <rule>…</rule> tags.
The format is
<group>…</group>
<group>…</group>
<rule>…</rule>
<rule>…</rule>
<rule>…</rule>
Sample FDF
<?xml version="1.0" encoding="UTF-8"?>
<fdf>
<form>frmSave</form>
<return>index.cfm?subap=Lubay&amp;action=EditItem&amp;ItemID=#ItemID#</return>
<group>
<id>group1</id>
<required>1</required>
<total>2</total>
</group>
<rule groupid=“group1”>
<display>Title</display>
<field>txtItemName</field>
<length>50</length>
<type>Char</type>
<required>1</required>
</rule>
<rule groupid=“group1”>
<display>Description</display>
<field>txtDescription</field>
<length>500</length>
<type>Char</type>
<required>1</required>
</rule>
<rule>
<display>Name</display>
<field>txtName</field>
<length>20</length>
<type>Char</type>
<required>0</required>
</rule>
</fdf>
Pause for Effect

Normal Form System Methodology
Form Posted
SQL Generated
SQL Run on DB
Pause for Effect

Form Validator System
Form Posted

Checked Against FDF
SQL Generated
SQL Run on DB
All you have to do is plug in the Form
Validator.
How to “Plug It In”





Find the file to which a form is posted
Before ANY action is taken with that data (i.e. it is dynamically
placed in a SQL query) call the Form Validator
Example Call
<cfmodule
template="/wwwAdmin/CF_tags/Validate_Form_XML.cfm"
fdf_url=“/ProDev/fdf/fdf_frmSave.xml">
If all of the data submitted is valid according to the
FDF rules, then nothing happens and the action on
the data will take place.
If any of the data submitted is not valid…
Watch Out! A Boomerang!

If any of the data submitted is not valid,
then the page pointed to by the URL in the
<return>…</return> tag in the FDF needs
to be ready to receive:
– h_’<field-name>’ hidden form fields which
contains all data fields submitted to the validator.
– err_’<field-name>’ hidden form fields which
contain an error message for each field that
failed validation.
Another Look…

Form Validator System
Form Posted
Checked Against FDF
SQL Generated
SQL Run on DB
Example Form Code
<input type="text" name="txtItemName"
<cfif isDefined("h_txtItemName")> value="#h_txtItemName#" </cfif>>
<br>
<cfif isDefined("err_txtItemName")>#err_txtItemName#</cfif>
 Steps to receive erred form data from the Form Validator
– Check for the presence of h_field-name and set the value of the form
element that equal to it.
– Check for the presence of err_field-name and output the error in some way
if it exists.
– Check for the presence of err_group-id. Whenever you have set up a
group by using the <group>…</group> tags in the FDF, the form needs to
be set up to receive errors which happen at the group level. They will be
stored in the “err_<group-id>” form field.
Form Validator Summary



Create Form Definition File
Call Form Validator before using the
Form elements
Create the Form in such a way that it
is capable of filling in the form
elements with posted data and
displaying the error messages
associated with bad fields.
Form Validator

Questions?