Details
-
Type: Improvement
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 3.2
-
Fix Version/s: 3.3
-
Component/s: Framework, ICE-Components
-
Labels:None
-
Environment:icecore / compat
-
Assignee Priority:P1
-
Salesforce Case Reference:
Description
When using client-side state saving, component property values are populated from data received from the client. Thus the possibility exists for a maliciously constructed request to give properties hostile values. It's unrecommended for ICEfaces applications to use client-side state, for this security reason, as well as performance reasons, given the network load of transmitting data during frequent AJAX requests.
As well, applications could conceivably have bugs where bean values used for some component properties may accidentally be tied into an input component's value, so that maliciously constructed requests could affect the application in inadvertent ways.
Due to the above possibilities, static analysis scanning software, such as Veracode, show that setEventPhase's use of a component property, to specify the parameters to Class.forName, is potentially unsafe, as that could lead to a malicious class being class loaded, which could cause its static block code to execute. This would probably require having the malicious code already on your classpath, so again is not an expected scenario. Best to remove all possibility though.
As well, applications could conceivably have bugs where bean values used for some component properties may accidentally be tied into an input component's value, so that maliciously constructed requests could affect the application in inadvertent ways.
Due to the above possibilities, static analysis scanning software, such as Veracode, show that setEventPhase's use of a component property, to specify the parameters to Class.forName, is potentially unsafe, as that could lead to a malicious class being class loaded, which could cause its static block code to execute. This would probably require having the malicious code already on your classpath, so again is not an expected scenario. Best to remove all possibility though.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion