Community
Participate
Working Groups
Build ID: 1.2M6 There is a browser independent XSS vulnerability with the startup parameter in RAP. Tested on Jetty and Tomcat deployments. Steps To Reproduce: 1. Access a RAP application using this string: (Obviously hostname, servletname, entrypoint need to be specified) https://hostname/servletname?startup=entrypoint%3c%2fsCrIpT%3e%3csCrIpT%3ealert('Howdy')%3c%2fsCrIpT%3e For example: http://rap.eclipse.org/rapdemo/rms?startup=rms%3C%2fsCrIpT%3E%3CsCrIpT%3Ealert('Howdy')%3C%2fsCrIpT%3E Will allow the javascript to run. This is usually flagged as a critical security hole. We are working on a patch.
Created attachment 134849 [details] patch to address XSS vulnerability Patch to encode the startup parameter when it could be presented to the user and executed by the browser.
Another example URL that prompts the user for a password and would still allow that site to function. http://rap.eclipse.org/rapdemo/rms?startup=rms");prompt("Howdy!%20Enter%20your%20password
Thank you very much for pointing this out. I committed the parts of the patch. Changes are in CVS HEAD I am unsure whether it is necessary to encode the exception messages in BrandingManager and EntryPointManager and therefore left these changes out for now. I would rahter assume that the error reporter (e.g. Tomcats or Jettys error page mechanism) is in charge of sending a 'safe' error page. Moreover with the changes to LifeCycleServiceHandlerConfigurer and BrowserSurvey, I could not inject Javascript any more. Do you know of a way to break the app with only these changes?
(In reply to comment #3) Rüdiger, After testing your proposed changes, I believe you are correct. I think we were just erring on the side of caution by encoding the exceptions. If we come up with anything else we will let you know.
(In reply to comment #4) Austin, thanks for verifying this. I will then close this bug. Please re-open or file a new one if you find further issues.
