Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 1.7.1
-
Component/s: Framework
-
Labels:None
-
Environment:All
-
Support Case References:
Description
[2 of 53] Link Injection (facilitates Cross-Site Request Forgery)
Severity: Medium
Test Type: Application
Vulnerable URL: http://edsdev.blueweb.bcbsma.com:81/dmreg/block/send-receive-updates
(Parameter = ice.focus)
Remediation Tasks: Filter out hazardous characters from user input
Variant 1 of 132 [ID=15343]
The following changes were applied to the original request:
? Set parameter 'ice.focus's value to '%22%27%3E%3CIMG+SRC%3D%22%
2FWF_XSRF.html%22%3E'
Validation In Response:
? Fix.start('mainForm:
_id35:0:historyPopup','/dmreg/xmlhttp/blank');Ice.Focus.setFocus('"'><IMG
SRC="/WF_XSRF.html">');//-269488648]]></content></update></updates>
Reasoning:
The test response contained a link to the file "WF_XSRF.html, which proves that the Cross-Site
Request Forgery attempt was successful
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Deryk, please assign this bug. I don't believe it is an immediate vulnerability (due to the double cookie mechanism) but it is still important to fix.
The ICEfaces double-cookie submission mechanism works as follows:
When ICEfaces submits a form to the server, the JSESSIONID is passed as a cookie and the ICEfacesID is passed as a serialized value within the form. Any submissions not containing the ICEfacesID are rejected.
To understand how this protects against Cross-Site Request Forgery, consider how such an attack functions:
The attacker assumes (or hopes) that the user is currently logged in to the web application and sends them a URL (perhaps in an email message) valid for that application, such as
http://host/application/transfermoney.do?amount=all&destination=evilhacker.com
If the user clicks on the link, their browser is activated and a GET request for the link is issued. Since the user is currently logged in to the application, the GET request has the users cookies applied and the attacker's operation runs as the logged in user. Note that the attacker does not know the user's JSESSIONID.
However, if the application requires that the JSESSIONID is also provided within the request (double cookie submission), the attacker's forged request will be rejected and the attack will fail. Note that it is important that the session ID is not guessable.
ice.focus should be checked for JSF ID syntax before being serialized, and be discarded if it fails:
– They must start with a letter (as defined by the Character.isLetter() method) or underscore (_).
– Subsequent characters may be letters (as defined by the Character.isLetter() method), digits as defined by the Character.isDigit() method, dashes 
, and underscores (_).
Verify element IDs before moving focus. Verifying ice.focus parameter before submission is not possible when GET requests ( like http://......?ice.focus=<img src="....">) are initiated by the browser and not by the bridge.
Revert changes since it causes regression ICE-3619.
In focus.js, change this method:
Ice.isValidID = function(id)
{ return /^\w[\w\-\:]*$/.test(id); };
Make regex expression local.
The value of ice.focus is written back to the page, but when it contains quote characters, such as
"'><IMG SRC="% 2FWF_XSRF.html">
the hidden input field is abnormally terminated and arbitrary HTML can be written to the page.
ICEfaces uses double cookie submission, so it is likely that the Cross-Site Request Forgery aspect of this attack is not possible. However, it should also not be possible to corrupt the page, so the rendering of ice.focus should be either filtered (for JSF component id syntax) or escaped.
Similar hidden fields should be investigated.