Jump to content
Welcome to our new Citrix community!
  • 0

Advanced form checks


Amin Eideh

Question

Greetings all,

 

Was wondering if  it is really required to enable field format check  if  other checks  such as sql injection and xss are running,

 

I feel like this check  more like a complementary  rather than core, and should only be used for specific case scenarios, such as a relaxed  sql field lets say.

Am i wrong here? 

Link to comment

4 answers to this question

Recommended Posts

  • 1

I agree.  I tend to use it only where its needed to enforce a field contents where a risk is present and another security check doesn't exist for it, but also in a way it wouldn't interfere if the app does its own validation.

 

It existed before signatures existed and helped close the gap.  But now, you have signatures / sql injection / cmd injection and a few other tools.  

  • Like 2
Link to comment
  • 0
3 minutes ago, Rhonda Rowland1709152125 said:

I agree.  I tend to use it only where its needed to enforce a field contents where a risk is present and another security check doesn't exist for it, but also in a way it wouldn't interfere if the app does its own validation.

 

It existed before signatures existed and helped close the gap.  But now, you have signatures / sql injection / cmd injection and a few other tools.  

 

makes sense, how about the form field consistency, when do we usually use it?

Link to comment
  • 0

That one prevents form field tampering and hidden/read only field manipulation.

It is a category of advanced "sessionization" checks alongside cookie consistency, url closure, and csrf form tagging/referer header validation (though it has a sessionless version).

 

It mitigates attacks based on manipulating fields client side either through hidden/read-only field tampering, adding/removing fields, changing field lengths, changing field types or otherwise changing what should be immutable properties of fields to prevent client-side manipulation of a new request from affecting application behavior or logic.

So, like the other "advanced" mode checks it compares the state of "this" request based on a "prior" observed response.

 

The appfw generates a secure hash of the non-changing properties of the form's fields and encodes this and a session-free tracking mechanism into the page. Any legal interaction of the page is fine: editing text boxes, interacting with dropdowns/checkboxes/radio buttons. But the illegal modifications would be detected and the request is blocked as no longer matching the prior response provided by the server.

 

While primarily a "field" based protection, field-based attacks and url-based attacks overlap.  So, this check also prevents NEW query parameters from being employed in url manipulation that do not correspond to an observed field on the page.

 

It's generally a good protection to enable for more robust protections.  But if sections of the site use client-side generated/dynamic field generation, then those fields (or that part of the site) would  need to be exempted from protection as the fields didn't exist when the appfw reviewed the response. Examples:  shipping pages that wait for you to choose a country before rendering the necessary shipping fields through client-side code without making a new request for a new response on the server.

 

Or applications that are navigated by script and query parameters and not paths, form field consistency might not be easy to use as a lot of things get exempted (depends on the complexity of the app.)

 

Link to comment
  • 0
On 10/16/2021 at 5:05 AM, Rhonda Rowland1709152125 said:

That one prevents form field tampering and hidden/read only field manipulation.

It is a category of advanced "sessionization" checks alongside cookie consistency, url closure, and csrf form tagging/referer header validation (though it has a sessionless version).

 

It mitigates attacks based on manipulating fields client side either through hidden/read-only field tampering, adding/removing fields, changing field lengths, changing field types or otherwise changing what should be immutable properties of fields to prevent client-side manipulation of a new request from affecting application behavior or logic.

So, like the other "advanced" mode checks it compares the state of "this" request based on a "prior" observed response.

 

The appfw generates a secure hash of the non-changing properties of the form's fields and encodes this and a session-free tracking mechanism into the page. Any legal interaction of the page is fine: editing text boxes, interacting with dropdowns/checkboxes/radio buttons. But the illegal modifications would be detected and the request is blocked as no longer matching the prior response provided by the server.

 

While primarily a "field" based protection, field-based attacks and url-based attacks overlap.  So, this check also prevents NEW query parameters from being employed in url manipulation that do not correspond to an observed field on the page.

 

It's generally a good protection to enable for more robust protections.  But if sections of the site use client-side generated/dynamic field generation, then those fields (or that part of the site) would  need to be exempted from protection as the fields didn't exist when the appfw reviewed the response. Examples:  shipping pages that wait for you to choose a country before rendering the necessary shipping fields through client-side code without making a new request for a new response on the server.

 

Or applications that are navigated by script and query parameters and not paths, form field consistency might not be easy to use as a lot of things get exempted (depends on the complexity of the app.)

 

appreciate the help

 

thanks you so much

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...