Hi all,
Does Laserfiche detect and block potential SQL Injection and Cross-Site Scripting (XSS) attacks?
Does Laserfiche has a mechanism that validate and process which includes filtering of meta characters?
Hi all,
Does Laserfiche detect and block potential SQL Injection and Cross-Site Scripting (XSS) attacks?
Does Laserfiche has a mechanism that validate and process which includes filtering of meta characters?
Laserfiche products use prepared statements, which is the industry-standard strategy to avoid SQL corruption bugs/attacks.
You can apply any constraint you want to limit the contents of any particular field, but we don't have any "illegal" characters that are automatically prohibited.
1) Yes. 2) You can apply constraints but by default any text is legal in a field.
Can you please elaborate to both questions?
Laserfiche products use prepared statements, which is the industry-standard strategy to avoid SQL corruption bugs/attacks.
You can apply any constraint you want to limit the contents of any particular field, but we don't have any "illegal" characters that are automatically prohibited.
@████████ I am not entirely sure that is correct. I have seen errors in Forms sometimes where a form was submitted, but caused an error in the event logs about illegal characters.
Landed on one today w/ a Forms post. It passed the form validation, then presented the user with an error. It didn't tell them which field nor could they go back to their submission to see what they had done. The user had to input everything from scratch again.
The event viewer showed more detail which pinpointed the field and value:
[2111]: One or more form fields contains illegal character combinations (e.g., "&# or '<' next to (a-z, /, ?, !)"). Please resubmit the form without these characters. [LFF2111-RequestValidationException]
Details:
URL: /Forms/Form/Submit
Error: RequestValidationException
Date: 7/19/2017 6:02:48 PM (Central Standard Time)
HTTP Status Code: 400
Business Process ID: 20
User: domain\account
IP: 172.18.11.51
Browser: Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko
Business Process Name: IT - Change Recording
Stack Trace:
Caught exception: Laserfiche.Forms.CommonUtils.Exceptions.LFFormsException
Message: One or more form fields contains illegal character combinations (e.g., "&# or '<' next to (a-z, /, ?, !)"). Please resubmit the form without these characters. [LFF2111-RequestValidationException]
at E_Forms.Controllers.FormController.Submit(FormCollection collection)
at lambda_method(Closure , ControllerBase , Object[] )
at System.Web.Mvc.ReflectedActionDescriptor.Execute(ControllerContext controllerContext, IDictionary`2 parameters)
at System.Web.Mvc.ControllerActionInvoker.InvokeActionMethod(ControllerContext controllerContext, ActionDescriptor actionDescriptor, IDictionary`2 parameters)
at System.Web.Mvc.Async.AsyncControllerActionInvoker.<BeginInvokeSynchronousActionMethod>b__39(IAsyncResult asyncResult, ActionInvocation innerInvokeState)
at System.Web.Mvc.Async.AsyncResultWrapper.WrappedAsyncResult`2.CallEndDelegate(IAsyncResult asyncResult)
at System.Web.Mvc.Async.AsyncControllerActionInvoker.EndInvokeActionMethod(IAsyncResult asyncResult)
at System.Web.Mvc.Async.AsyncControllerActionInvoker.AsyncInvocationWithFilters.<InvokeActionMethodFilterAsynchronouslyRecursive>b__3d()
at System.Web.Mvc.Async.AsyncControllerActionInvoker.AsyncInvocationWithFilters.<>c__DisplayClass46.<InvokeActionMethodFilterAsynchronouslyRecursive>b__3f()
at System.Web.Mvc.Async.AsyncControllerActionInvoker.AsyncInvocationWithFilters.<>c__DisplayClass46.<InvokeActionMethodFilterAsynchronouslyRecursive>b__3f()
at System.Web.Mvc.Async.AsyncControllerActionInvoker.EndInvokeActionMethodWithFilters(IAsyncResult asyncResult)
at System.Web.Mvc.Async.AsyncControllerActionInvoker.<>c__DisplayClass21.<>c__DisplayClass2b.<BeginInvokeAction>b__1c()
at System.Web.Mvc.Async.AsyncControllerActionInvoker.<>c__DisplayClass21.<BeginInvokeAction>b__1e(IAsyncResult asyncResult)
Inner exception: System.Web.HttpRequestValidationException
Message: A potentially dangerous Request.Form value was detected from the client (Field25="...ost to be <blank>").
at System.Web.HttpRequest.ValidateString(String value, String collectionKey, RequestValidationSource requestCollection)
at System.Web.HttpValueCollection.EnsureKeyValidated(String key)
at System.Web.HttpValueCollection.Get(String name)
at E_Forms.Models.ViewModels.Form.Submit.GetFieldDataFromForm(HttpRequestBase request)
at E_Forms.Models.ViewModels.Form.Submit.RetrieveDataFromForm(HttpRequestBase request, FormDataSet formdata, Boolean SaveAll)
at E_Forms.Controllers.FormController.Submit(FormCollection collection)
Laserfiche Forms Professional Version 10.2.1.157
If Forms sees these as illegal characters, why does it not prevent them being entered to begin with?
You're right, for the constraints part of my answer I was thinking more about metadata fields in the repository. I'll pass your comments on to the Forms team.
The validation is performed by ASP.NET with the default requestValidationMode of 4.0 to prevent field data contains HTML, Forms side get this error and wrap it up with a more friendly error to end user. The validation in ASP.NET can be turned off by adding following settings in the web.config:
<location path="Form/Submit">
<system.web>
<httpRuntime requestValidationMode="2.0"/>
</system.web>
</location>
Forms will enhance the experience by adding front end validation to give error directly under the field after user enter the illegal characters.
We have a client experiencing this issue under certain circumstances, so we'd like to turn off the validation as you describe. There are a few different web.config files under the Laserfiche Forms folders, so I'm assuming we make this change to the web.config file found in C:\Program Files\Laserfiche\Laserfiche Forms\Forms?
Also, I noticed that there is an existing block in that file referencing location path for authorizing users:
<location path=".">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>
Should we add this new block just below that one?
Thanks - Jim
It is the web.config under C:\Program Files\Laserfiche\Laserfiche Forms\Forms and you can just add the new block below that one.
Thank you!
Hello Xiuhong,
Can you please elaborate on your answer. If I turn off ASP.NET validation, forms will add a front end validation directly under the field? Or do I need to add a new block for that to happen?
Thank you,
Mui
In Forms 10.4.1, we added the front end validation for illegal characters and it will display error as following:
Hi Xiang -
We added the new block to our client's web.config file (they are on Forms 10.3.1), but they are still getting the same error when submitting. Do they need to be on 10.4.1 to bypass the error altogether, or should 10.3.1 bypass the error but just not display the verbiage under the field?
Thanks - Jim
Thanks Xiuhong! That's great news. Now I don't have to add java to disallow characters.
Hi Xiang -
My client still gets the error even after adding the verbiage to the web.config file; as I said above, they are on Forms 10.3.1 - should this work, or do they need to be on 10.4.1?
Thanks - Jim
With Forms 10.3.1, they should be able to turn off the validation by adding following settings to the end of web.config under C:\Program Files\Laserfiche\Laserfiche Forms\Forms before "</configuration>".
With Forms 10.4.1, there is front end validation which will prevent entering illegal chars in the single line/multi-line fields except for rich text field. You can't turn off the validation by changing the validation level in the web.config any more. If you want user to enter such characters in fields, you should use rich text field to collect the data.
You can still turn off the validation by changing the validation level in the web.config since Forms 10.4.2 as Forms will disable the front end validation if detect the changes in the web.config.
Hi Brian,
Can you please tell me about the mechanism in place for the SQL injection and XSS attacks?
Thanks
Hi Shiela,
What information is missing?
Laserfiche products use prepared statements, which is the industry-standard strategy to avoid SQL corruption bugs/attacks.
If you are unfamiliar with the terminology "prepared statements", there are many resources available online, such as this stackoverflow post and the OWASP cheat sheet for SQL injections.