Hi everyone,

So I assume most of you know that you can change the HTML code in a webpage using google chrome's inspector.

Having this assumption in mind, how do you guys protect against this simple attack vector to your OutSystems websites?


What I normally do is the function that verifies if an input is disabled will also be called during a form's submission or OnChange event.
This OnChange event would verify if the particular field should be read-only and disregard the call if necessary.
The submission of a form would verify if a form input is disabled and if so use the original value and not the changed value. You can check an example of this in the attached ".oml" in the page ProperScreen.


Another possible attack is someone changing a dropdown selection by creating another <select> element, what i normally do in this case is that the selected value of a dropdown will be validated against the possible values of the dropdown, normally here I end up calling the function that originated the list in the first place.


With this background in place and the attached OML


My questions are the following:

  • Are there any Out of the Box features that will allow me to run these validations without having to explicitly create them?
  • If there aren't is there any way you have that is more generic than the solution detailed above?


Sincerely,
A guy who is tired of repeating work,
João Nunes


I guess you can't just protect fully from front end alone.

Even if you stop people from changing Dom in a particular browser, they simply can use other browsers or They have access to tools like HttpFiddler, Postman to make web request look like its coming from a geniunine place.

Worst case I guess is they can build a new browser from available open source code according to their needs

In my opinion the best option is to secure from backend.


Sorry Not aware of any out of box solutions.

Hi João,

My answers to your questions.

1. None that I am aware of.

2. No. You're asking for automatically validation of business rules. 

The best you can do is to create wrappers for your entity actions and guarantee that they are the single entry point to change your data, and proceed to validate there. You still have to manually implement it, but everyone trying to change data will be validated and it is a single point to keep.

Regarding in memory validation, for preprocess, you still have to implement your own code.

Cheers

Eduardo Jauch wrote:

Hi João,

My answers to your questions.

1. None that I am aware of.

2. No. You're asking for automatically validation of business rules. 

The best you can do is to create wrappers for your entity actions and guarantee that they are the single entry point to change your data, and proceed to validate there. You still have to manually implement it, but everyone trying to change data will be validated and it is a single point to keep.

Regarding in memory validation, for preprocess, you still have to implement your own code.

Cheers

I agree that a certain field being disabled is a business rule. I agree that the current best solution is to encapsulate those validations inside a _BL module that takes care of that logic and encapsulates data creation/update, but that has cost, verifying if a certain is disabled and using the original value, validating if a certain selection is inside the possible selections a user should have been presented with has costs.

But wouldn't it be wonderful if you didn't even have to have to check if a certain field was disabled or even if the selected value of a dropdown/radio button/checkbox is inside the option range that was actually given to the user at runtime?

It just seems to me that these are validations that everyone should be doing.
If it's something that everyone should be doing it's something that should be automated.

The input widget would look at the disabled property and if it is disabled it should just return the original value when accessed.
For selection type widgets, it would look at the original list of selections and determine if the current selection is within the original range of options.


Wouldn't you agree if you didn't have to worry about these 2 checks your code would look much cleaner in the _BL create/update actions?

One approach is to try and not use the disabled property as part of security (the Outsystems security training modules go through this), rather put an IF statement around the element so that it does not appear on the page at all, that way you can't change the DOM to view it as Outsystems won't actually render it. 

If you are disabling it because you want to see the value on the screen but not allow editing consider using an expression to display instead of an input widget. If you must use a disabled input widget then simply keep a flag in the session and if that flag is set ignore the content when submitted back 

John Williams wrote:

One approach is to try and not use the disabled property as part of security (the Outsystems security training modules go through this), rather put an IF statement around the element so that it does not appear on the page at all, that way you can't change the DOM to view it as Outsystems won't actually render it. 

If you are disabling it because you want to see the value on the screen but not allow editing consider using an expression to display instead of an input widget. If you must use a disabled input widget then simply keep a flag in the session and if that flag is set ignore the content when submitted back 

Hey John, yeah I've used that approach before but it seems more often than not UX teams and/or business requirements want the field to just look disabled and creating an expression that looks like a field takes too much work compared to with the other approach of veryfing it in the CRUD operations.