Hello, I am trying to modify the link from: http://www.ja-sig.org/wiki/display/UPC/MS+Exchange but I can not get it to work.
Problem: My username and password are both 'null' after outlook.jsp finishes execution and I can't authenticate to my mail server. My security.properties: root.ldap.cache=org.jasig.portal.security.provider.CacheSecurityContextFactory root=org.jasig.portal.security.provider.UnionSecurityContextFactory root.cas=org.jasig.portal.security.provider.cas.CasFilteredSecurityContextFactory root.simple=org.jasig.portal.security.provider.SimpleSecurityContextFactory root.ldap=org.jasig.portal.security.provider.SimpleLdapSecurityContextFactory As you can see, I am authenticating with CAS through LDAP. Any hints? Thanks, Rick -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of William G. Thompson, Jr. Sent: Tuesday, October 16, 2007 2:51 PM To: [email protected] Subject: [uportal-dev] Security Notification: XSS Vulnerability Proxy Exploit *** WiscMail warning: attached executable file was renamed *** * * Attached to this message is an executable file or an archive * that contains an executable file. The attachment has been * renamed for your protection. * * The file was scanned by the WiscMail anti-virus scanners and * no threat was found. However, executable files should be * treated with great caution. It's possible for viruses to * slip through undetected in the minutes before anti-virus * definitions are published. * * Please confirm with the sender that the file was sent * intentionally, and that the file is safe to run before * renaming the file by removing the "_renamed" from the end of * the filename. * * For more information and support, please visit the following * link to the DoIT Help Desk * * http://kb.wisc.edu/wiscmail/page.php?id=6056 * *** end of warning *** Security Notification: XSS Vulnerability Proxy Exploit This is a public notification of an identified uPortal security vulnerability and workaround. Summary: uPortal ships with a proxy configuration that allows illicit cross-site scripting. The Adversary can introduce arbitrary JavaScript into a user's portal render cycle if he or she can get the end user's web browser (e.g. via a hyperlink or a redirect) to open a cleverly crafted portal URL. The kinds of things the Adversary could accomplish with this JavaScript include capture of the user's otherwise secure session cookie, thereby allowing session hijacking. Versions Affected All versions prior to uPortal 2.6.0, including 2.1, 2.2, 2.3, 2.4, 2.5. Issue: HttpProxyServlet: uPortal ships with a proxy servlet allowing it to proxy over SSL content that would otherwise be vended in the clear so that the annoying "Mixed content" browser advisory message can be avoided. While some (many?) uPortal deployments are not intentionally making productive use of this servlet, its default configuration is to be nonetheless latently available and so available for exploit using a cleverly crafted URL. You can turn off the feature of proxying resources via the portal.properties property "org.jasig.portal.serialize.ProxyWriter.resource_proxy_enabled" but this will not turn off the vulnerability. When this feature is deliberately used, its use involves detecting URLs needing to be re-written via a SAX filter and re-writing them to point at the proxy servlet which then proxies the originally intended content. CWebProxy: The web proxy channel's proxying of URLs specified at runtime is already throttled by configuration parameters added to address a previous security vulnerability (that of illicitly proxying local files). Portal administrators should configure each web proxy channel instance as restrictively as possible, such that only trusted content is included within the scope of allowable proxies. Web proxy channels configured such that they will proxy arbitrary content provided by the Adversary can in theory be exploited to execute cross-site-scripting attacks. Resolution: Http proxy servlet The uPortal Http proxy servlet will no longer proxy any content other than elements with a mime type of image. Two changes are involved: 1. org.jasig.portal.serialize.ProxyWriter: Summary: Applets, IFrames and Scripts are no longer rewritten by the serializer to use the proxy servlet. Description: When uPortal serializes its response to the browser it passes the response through a filter (org.jasig.portal.serialize.ProxyWriter) which inserts additional URL path elements as configured by the property, org.jasig.portal.serialize.ProxyWriter.resource_proxy_rewrite_prefix. In the past the ProxyWriter class operated on 6 elements: "image","img","script","input","applet","iframe". The patched version will operate on three element types only: image, img and input. Although it may be convenient to proxy other elements to avoid the mixed content message, this vulnerability response opts for a simpler approach of avoiding entirely these other types of content proxying. This change comports the proxy writer behavior with the now-more-restricted scope of the HttpProxy servlet -- this change to ProxyWriter does not itself secure anything, as the nature of the exploit is to generate proxy servlet instructions by means other than the proxy writer. 2. org.jasig.portal.HttpProxyServlet Summary: HttpProxyServlet will respond with an error code (404) and no content for all objects that do not have a MIME type that begins with: "image". Description: This internal proxy handles requests for the proxied embedded content as the browser renders the response. Previously, the proxy servlet would proxy most anything. With this change, the proxy servlet will proxy only images. Returning only elements with proper mime type of image the browser is able to protect itself from illicitly proxied scripts -- in order for the servlet to proxy, the content must appear to have a mime type of "image", which will discourage the web browser from executing the content. Alternative solutions for resource proxy: Deployments not using the HttpProxyServlet should remove the class file (in WEB-INF/classes) and servlet declaration (in web.xml) from their portals entirely as an unnecessary security vulnerability surface. uPortal deployers should consider running the proxy on a host other than the portal or other application host, such that if the proxy is exploited to proxy JavaScript, the JS will appear to be coming from an unrelated domain and so in-brower cross-site-scripting protections will apply. uPortal deployers should consider running external standalone web proxy solutions, such as Squid. External dedicated proxy solutions have their own security issues and configuration needs, but these tend to be well documented and worked through by a larger community dedicated to the problems of proxying. uPortal 2.6.0 GA ships with a fix similar to the attached patches, pre-applied. An alternative to patching an existing install to deal with this issue is therefore a full upgrade to uPortal 2.6. Configuration to block the exploit in Web Proxy and CGenericXSLT channels The uPortal Web Proxy and CGenericXSLT channel includes features for restricting the URLs a channel instance will proxy, as implemented in a previous security fix. uPortal deployments must configure all web proxy and CGenericXSLT channel publications with a maximally restrictive match prefix. For example, if a web proxy instance proxies a remote application at http://www.myschool.edu/apps/dining_hall_signup/startpage.html that links to other parallel paths like http://www.myschool.edu/apps/dining_hall_signup/pick_a_plan.html but not like http://www.myschool.edu/other_cool_stuff/dining_menus.html An appropriate URI match prefix would be: "http://www.myschool.edu/apps/dining_hall_signup/"; This would prevent the channel from proxying content at http://www.bad.com/exploitive_javascript_bearing_page even if a user were to be convinced by the Adversary to click an external link illicitly instructing the channel to proxy that URL. Patching: Source Replacement Replace HttpProxyServlet.java and ProxyWriter.java in your local uPortal source tree with the attached files. Rebuild and re-deploy your uPortal. Rebuilding your uPortal class files with this updated source is the recommended way to address this exploit in your local uPortal environment. Binary Replacement Replace HttpProxyServlet.class and ProxyWriter.class with the attached .class files intended for use in uPortal 2.5.x. When using this approach, you'll need to also fix the issue in your local build environment (e.g. by replacing the .java files as described previously) so that when you perform a new build, the exploit remains fixed. Previous patch If you applied a previous patch for this issue, you will first need to undo the steps you performed in applying that patch before applying these steps and this patch. -- You are currently subscribed to [email protected] as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to [email protected] as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
