-
1. Re: alter the oracle form elements from the user end
Oleh Tyshchenko May 17, 2019 10:38 AM (in response to Eng. Tawfik Einea)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.
-
2. Re: alter the oracle form elements from the user end
Holger.Lehmann May 17, 2019 11:05 AM (in response to Oleh Tyshchenko)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.
-
3. Re: alter the oracle form elements from the user end
Eng. Tawfik Einea May 17, 2019 12:16 PM (in response to Oleh Tyshchenko)It is! Plz try the same steps and tell me your feedback
-
4. Re: alter the oracle form elements from the user end
Holger.Lehmann May 17, 2019 12:34 PM (in response to Eng. Tawfik Einea)Eng. Tawfik Einea is it possible to change the content of the input items too with JS enabled? that could be even more dangerous :-(
-
5. Re: alter the oracle form elements from the user end
Oleh Tyshchenko May 17, 2019 12:44 PM (in response to Holger.Lehmann)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
-
6. Re: alter the oracle form elements from the user end
Eng. Tawfik Einea May 17, 2019 1:18 PM (in response to Eng. Tawfik Einea)I do not think but i will try
-
7. Re: alter the oracle form elements from the user end
Eng. Tawfik Einea May 17, 2019 1:21 PM (in response to Eng. Tawfik Einea)If interested with these ideas, you may reveiw the classes in frmall.jar
-
8. Re: alter the oracle form elements from the user end
Christian Erlinger May 17, 2019 8:47 PM (in response to Eng. Tawfik Einea)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:
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
-
9. Re: alter the oracle form elements from the user end
Oleh Tyshchenko May 17, 2019 9:37 PM (in response to Christian Erlinger)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:
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.
-
10. Re: alter the oracle form elements from the user end
Eng. Tawfik Einea May 17, 2019 10:27 PM (in response to Christian Erlinger)you are correct. After knowing the possibility of doing that, we need to consider it in our programs and expect all possible scenarios of alteration by the super users. It is very similar to design a web page knowing that it can be altered by the user