Environment
NetIQ Access Manager 3.2 Identity Server
Upgraded to NetIQ Access Manager 3.2 Support Pack 1 from previous 3.1.x or 3.2 release
New Identity Server installations on 3.2 Support Pack 1 do not show problem
Custom JSP pages with the Value tag in form correctly terminated not seeing the issue
Upgraded to NetIQ Access Manager 3.2 Support Pack 1 from previous 3.1.x or 3.2 release
New Identity Server installations on 3.2 Support Pack 1 do not show problem
Custom JSP pages with the Value tag in form correctly terminated not seeing the issue
Situation
NetIQ Access Manager 3.2 Support Pack 1 setup and working fine in a test environment - users can access protected resources behind the Access Gateway (AG) after having successfully authenticated at the Identity (IDP) server. This NAM system was upgraded from the original 3.2.0 release, and not based on a 3.2.1 clean install.
Before rolling product out in production, a third party security organisation did some security PEN testing on the system and revealed some access vulnerability through NAM. This Pen test revealed a XSS attack (cross-site scripting) using the following url:
https://nam32phys.lab.novell.com:8443/nidp/idff/sso?id=SNPF&sid=0&option=credential&target=https%3A%2F%2Fwww.netiq.com%2Flogin.aspx&Ecom_User_ID=ncashell><script>alert(1)</script>&Ecom_Password=novell and
https://nam32phys.lab.novell.com:8443/nidp/app/login?id=SNPF&sid=0&option=credential&Ecom_User_ID=ncashell><script>alert(1)</script>d8fca6b19b0d9e18d
The JSP pages during the test were
a) customised with branding from customers environment and
b) based on the default JSP pages shipping with 3.2.
The NAM IDP server typically sanitises all incoming HTTP requests for potential XSS attacks by filtering for certain characters visible in such an attack.
Before rolling product out in production, a third party security organisation did some security PEN testing on the system and revealed some access vulnerability through NAM. This Pen test revealed a XSS attack (cross-site scripting) using the following url:
https://nam32phys.lab.novell.com:8443/nidp/idff/sso?id=SNPF&sid=0&option=credential&target=https%3A%2F%2Fwww.netiq.com%2Flogin.aspx&Ecom_User_ID=ncashell><script>alert(1)</script>&Ecom_Password=novell and
https://nam32phys.lab.novell.com:8443/nidp/app/login?id=SNPF&sid=0&option=credential&Ecom_User_ID=ncashell><script>alert(1)</script>d8fca6b19b0d9e18d
The JSP pages during the test were
a) customised with branding from customers environment and
b) based on the default JSP pages shipping with 3.2.
The NAM IDP server typically sanitises all incoming HTTP requests for potential XSS attacks by filtering for certain characters visible in such an attack.
Resolution
Make sure that all value tags in the login (customised or default) pages include the double quote (") character in them to ensure that all XSS checks get performed. For example:
<!-- The last 2 double quotes are mandatory to prevent XSS attacks -->
<input type="text" class="smalltext" name="Ecom_User_ID" size="30" value="<%=uname%>">
...
...
<!-- The last 2 double quotes are mandatory to prevent XSS attacks -->
<input type="hidden" name="target" value="<%=target%>">
Until the 3.2 SP1 release, the 3.2 JSP login pages did not include the double quotes within the value fields, and the IDP server was therefor susceptible to the XSS issue with the default login pages. Even with the 3.2 SP1 release, customers that upgraded to that build by selecting the option to 'maintain' the custom login pages from earlier NAM versions would NOT inherit the fix - only those setups that installed and/or customised the NAM 3.2 SP1 login pages from scratch would not be open to potential XSS attacks.
Any Administrators that implemented the JSP best practices (see 'Cause' section below) and terminated the form value values correctly with double quotes would not have seen this issue.
The 3.2 SP2 documentation includes a best practice section on developing JSP pages with techniques to avoid cross site scripting.
<!-- The last 2 double quotes are mandatory to prevent XSS attacks -->
<input type="text" class="smalltext" name="Ecom_User_ID" size="30" value="<%=uname%>">
...
...
<!-- The last 2 double quotes are mandatory to prevent XSS attacks -->
<input type="hidden" name="target" value="<%=target%>">
Until the 3.2 SP1 release, the 3.2 JSP login pages did not include the double quotes within the value fields, and the IDP server was therefor susceptible to the XSS issue with the default login pages. Even with the 3.2 SP1 release, customers that upgraded to that build by selecting the option to 'maintain' the custom login pages from earlier NAM versions would NOT inherit the fix - only those setups that installed and/or customised the NAM 3.2 SP1 login pages from scratch would not be open to potential XSS attacks.
Any Administrators that implemented the JSP best practices (see 'Cause' section below) and terminated the form value values correctly with double quotes would not have seen this issue.
The 3.2 SP2 documentation includes a best practice section on developing JSP pages with techniques to avoid cross site scripting.
Cause
One needs to follow XSS
prevention techniques before adding or customizing
.jsp pages.
Refer - https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet
Some
key takeaways from the above OWASP regarding .jsp pages:
1/ Be religious about using quotes
around your attributes.
2/ Use HTML Escaping for the part of the document you
are putting untrusted data into.
e.g. All the query URL parameters should be
sanitized before setting their values in the .jsp pages.