...
As with input validation, normalize data before sanitizing for malicious characters. Properly encode all output characters other than those known to be safe to avoid vulnerabilities caused by data that bypasses validation. See IDS01-J. Normalize strings before validating them for more information.
Noncompliant Code Example
This noncompliant code example uses the model-view-controller (MVC) concept of the Java EE–based Spring Framework to display data to the user without encoding or escaping it. Because the data is sent to a web browser, the code is subject to both HTML injection and XSS attacks.
Code Block | ||
---|---|---|
| ||
@RequestMapping("/getnotifications.htm") public ModelAndView getNotifications(HttpServletRequest request, HttpServletResponse response) { ModelAndView mv = new ModelAndView(); try { UserInfo userDetails = getUserInfo(); List<Map<String,Object>> list = new ArrayList<Map<String,Object>>(); List<Notification> notificationList = NotificationService.getNotificationsForUserId(userDetails.getPersonId()); for (Notification notification: notificationList) { Map<String,Object> map = new HashMap<String,Object>(); map.put("id",notification.getId()); map.put("message", notification.getMessage()); list.add(map); } mv.addObject("Notifications",list); } catch(Throwable t){ // Log to file and handle } return mv; } |
Compliant Solution
This compliant solution defines a ValidateOutput
class that normalizes the output to a known character set, performs output sanitization using a whitelist, and encodes any nonspecified data values to enforce a double-checking mechanism. Note that required whitelisting patterns may vary according to the specific needs of different fields [OWASP 2008].
...
Also, see the method weblogic.servlet.security.Utils.encodeXSS() for more information on preventing XSS attacks.
Applicability
Failure to encode or escape output before it is displayed or passed across a trust boundary can result in the execution of arbitrary code.
Related Vulnerabilities
The Apache GERONIMO-1474 vulnerability, reported in January 2006, allowed attackers to submit URLs containing JavaScript. The Web-Access-Log viewer failed to sanitize the data it forwarded to the administrator console, thereby enabling a classic XSS attack.
Bibliography
[OWASP 2008] | How to Add Validation Logic to HttpServletRequest XSS (Cross Site Scripting) Prevention Cheat Sheet |
[OWASP 2011] | Cross-site Scripting (XSS) |
...