alter the oracle form elements from the user end

I'm shocked. If I understood everything correctly from this video now we can't trust data received from Forms client anymore. Everything I disabled as a developer can be undone by a user via javascript.

me, too shocked. changing the whole forms logic with javascript. ok it has to be enabled and has to be executed, but this could be treated as a sort of virus/ fishing.

Eng. Tawfik Einea is it possible to change the content of the input items too with JS enabled? that could be even more dangerous :-(

I guess here is an explanation why all this happens: Invoking Applet Methods From JavaScript Code And I think currently nothing stops you from calling any method under oracle.ewt.*, i.e. setText method for an instance of VTextField

Well, IMHO the security problem in your example is not that the button can be enabled via JS on the client, but that the button that is supposed to validate the password does not validate it. Instead validation happens somewhere else where the user has the possibility to circumvent this validation.

Very similar problem to this one:

https://www.reddit.com/r/ProgrammerHumor/comments/44l93o/how_only_relying_on_javascript_for_html_form/

Put the validation logic of your password in the WHEN-BUTTON-PRESSED Trigger of your button, and - poof - security problem gone.

The same goes for whatever else validation of whatever else data you might think of.

Bottom line: you need to validate user inputs in places where (malicious) users have little to no chance to interfere with it. For data input validation (other than password verification) the last resourt must be the data model of your database. If you can't input corrupt data via plain simple DML commands then your client application written in whatever tool you like can't input corrupt data. Or maybe hide your tables from the client at all and give them access to a PL/SQL API. You can't temper with PL/SQL from client side JavaScript .

Data Validation on the client side has (IMHO) one main purpose: to make the users life easier. Reading constraint violation errors when e.g. trying to delete a record which has child records isn't pretty, and I wouldn't bother the user with this. Instead prior deleting you could check if there are child records. But this check doesn't make the constraint obsolete. Same goes for your example: you can put the password validation logic in a POST-ITEM Trigger (or whatever else) for use comfort - but when it has to be decided wheter to continue processing or not based on a correct password - that's where you need to put your logic in any case. IMO this is not the POST-ITEM trigger.

Nice thinking though. I wonder how many Forms Applications you could bring to accept corrupt data with this method .

cheers

Christian Erlinger wrote:

 

Well, IMHO the security problem in your example is not that the button can be enabled via JS on the client, but that the button that is supposed to validate the password does not validate it. Instead validation happens somewhere else where the user has the possibility to circumvent this validation.

 

Very similar problem to this one:

 

https://www.reddit.com/r/ProgrammerHumor/comments/44l93o/how_only_relying_on_javascript_for_html_form/

 

 

 

 

Put the validation logic of your password in the WHEN-BUTTON-PRESSED Trigger of your button, and - poof - security problem gone.

Generally agree. But I have always though that everything I've disabled inside the Forms code just can't be enabled outside of it. So too often I consider disabling as part of validation logic. Stupid me.

Christian Erlinger wrote:

 

Bottom line: you need to validate user inputs in places where (malicious) users have little to no chance to interfere with it.

The problem a little bit broader. Using this technique a user can show hidden items or even turn secure item into plain one.