XSS prevention in JSP Servlet web application

Question

How can I prevent XSS attacks in a JSP Servlet web application

User · Answer

Managing XSS requires multiple validations  data from the client side     Input Validations  form validation  on the Server side  There are multiple ways of going about it  You can try JSR 303 bean validation hibernate validator   or ESAPI Input Validation framework  Though I ve not tried it myself  yet   there is an annotation that checks for safe html   SafeHtml   You could in fact use Hibernate validator with Spring MVC for bean validations -  Ref Escaping URL requests - For all your HTTP requests  use some sort of XSS filter  I ve used the following for our web app and it takes care of cleaning up the HTTP URL request - http   www servletsuite com servlets xssflt htm Escaping data html returned to the client  look above at  BalusC explanation

User · Answer

There is no easy  out of the box solution against XSS  The OWASP ESAPI API has some support for the escaping that is very usefull  and they have tag libraries   My approach was to basically to extend the stuts 2 tags in following ways    Modify s property tag so it can take extra attributes stating what sort of escaping is required  escapeHtmlAttribute  true  etc    This involves creating a new Property and PropertyTag classes  The Property class uses OWASP ESAPI api for the escaping  Change freemarker templates to use the new version of s property and set the escaping    If you didn t want to modify the classes in step 1  another approach would be to import the ESAPI tags into the freemarker templates and escape as needed  Then if you need to use a s property tag in your JSP  wrap it with and ESAPI tag   I have written a more detailed explanation here   http   www nutshellsoftware org software securing-struts-2-using-esapi-part-1-securing-outputs   I agree escaping inputs is not ideal

User · Answer

My personal opinion is that you should avoid using JSP ASP PHP etc pages  Instead output to an API similar to SAX  only designed for calling rather than handling   That way there is a single layer that has to create well formed output

User · Answer

I had great luck with OWASP Anti-Samy and an AspectJ advisor on all my Spring Controllers that blocks XSS from getting in   public class UserInputSanitizer        private static Policy policy      private static AntiSamy antiSamy       private static AntiSamy getAntiSamy   throws PolicyException            if  antiSamy    null                policy   getPolicy  evocatus-default                antiSamy   new AntiSamy                      return antiSamy              public static String sanitize String input            CleanResults cr          try               cr   getAntiSamy   scan input  policy             catch  Exception e                throw new RuntimeException e                     return cr getCleanHTML               private static Policy getPolicy String name  throws PolicyException           Policy policy                Policy getInstance Policy class getResourceAsStream   META-INF antisamy     name     xml             return policy             You can get the AspectJ advisor from the this stackoverflow post  I think this is a better approach then c out particular if you do a lot of javascript

User · Answer

I would suggest regularly testing for vulnerabilities using an automated tool  and fixing whatever it finds  It s a lot easier to suggest a library to help with a specific vulnerability then for all XSS attacks in general   Skipfish is an open source tool from Google that I ve been investigating  it finds quite a lot of stuff  and seems worth using

User · Answer

XSS can be prevented in JSP by using JSTL  lt c out gt  tag or fn escapeXml   EL function when  re displaying user-controlled input  This includes request parameters  headers  cookies  URL  body  etc  Anything which you extract from the request object  Also the user-controlled input from previous requests which is stored in a database needs to be escaped during redisplaying  For example   lt p gt  lt c out value  quot   bean userControlledValue  quot  gt  lt  p gt   lt p gt  lt input name  quot foo quot  value  quot   fn escapeXml param foo   quot  gt  lt  p gt   This will escape characters which may malform the rendered HTML such as  lt    gt    quot     and  amp  into HTML XML entities such as  amp lt    amp gt    amp quot    amp apos  and  amp amp   Note that you don t need to escape them in the Java  Servlet  code  since they are harmless over there  Some may opt to escape them during request processing  as you do in Servlet or Filter  instead of response processing  as you do in JSP   but this way you may risk that the data unnecessarily get double-escaped  e g   amp  becomes  amp amp amp  instead of  amp amp  and ultimately the enduser would see  amp amp  being presented   or that the DB-stored data becomes unportable  e g  when exporting data to JSON  CSV  XLS  PDF  etc which doesn t require HTML-escaping at all   You ll also lose social control because you don t know anymore what the user has actually filled in  You d as being a site admin really like to know which users IPs are trying to perform XSS  so that you can easily track them and take actions accordingly  Escaping during request processing should only and only be used as latest resort when you really need to fix a train wreck of a badly developed legacy web application in the shortest time as possible  Still  you should ultimately rewrite your JSP files to become XSS-safe  If you d like to redisplay user-controlled input as HTML wherein you would like to allow only a specific subset of HTML tags like  lt b gt    lt i gt    lt u gt   etc  then you need to sanitize the input by a whitelist  You can use a HTML parser like Jsoup for this  But  much better is to introduce a human friendly markup language such as Markdown  also used here on Stack Overflow   Then you can use a Markdown parser like CommonMark for this  It has also builtin HTML sanitizing capabilities  See also Markdown or HTML  The only concern in the server side with regard to databases is SQL injection prevention  You need to make sure that you never string-concatenate user-controlled input straight in the SQL or JPQL query and that you re using parameterized queries all the way  In JDBC terms  this means that you should use PreparedStatement instead of Statement  In JPA terms  use Query   An alternative would be to migrate from JSP Servlet to Java EE s MVC framework JSF  It has builtin XSS  and CSRF   prevention over all place  See also CSRF  XSS and SQL Injection attack prevention in JSF

User · Answer

If you want to automatically escape all JSP variables without having to explicitly wrap each variable  you can use an EL resolver as detailed here with full source and an example  JSP 2 0 or newer   and discussed in more detail here   For example  by using the above mentioned EL resolver  your JSP code will remain like so  but each variable will be automatically escaped by the resolver       lt c forEach items    orders   var  item  gt     lt p gt   item name  lt  p gt     lt p gt   item price  lt  p gt     lt p gt   item description  lt  p gt   lt  c forEach gt        If you want to force escaping by default in Spring  you could consider this as well  but it doesn t escape EL expressions  just tag output  I think   http   forum springsource org showthread php 61418-Spring-cross-site-scripting amp p 205646 post205646  Note  Another approach to EL escaping that uses XSL transformations to preprocess JSP files can be found here   http   therning org niklas 2007 09 preprocessing-jsp-files-to-automatically-escape-el-expressions

User · Answer

The how-to-prevent-xss has been asked several times  You will find a lot of information in StackOverflow  Also  OWASP website has an XSS prevention cheat sheet that you should go through   On the libraries to use  OWASP s ESAPI library has a java flavour  You should try that out  Besides that  every framework that you use has some protection against XSS  Again  OWASP website has information on most popular frameworks  so I would recommend going through their site

User · Answer

If you want to make sure that your   operator does not suffer from XSS hack you can implement ServletContextListener and do some checks there    The complete solution at  http   pukkaone github io 2011 01 03 jsp-cross-site-scripting-elresolver html   WebListener public class EscapeXmlELResolverListener implements ServletContextListener       private static final Logger LOG   LoggerFactory getLogger EscapeXmlELResolverListener class          Override     public void contextInitialized ServletContextEvent event            LOG info  EscapeXmlELResolverListener initialized                        JspFactory getDefaultFactory                    getJspApplicationContext event getServletContext                     addELResolver new EscapeXmlELResolver                  Override     public void contextDestroyed ServletContextEvent event            LOG info  EscapeXmlELResolverListener destroyed                             link ELResolver  which escapes XML in String values              public class EscapeXmlELResolver extends ELResolver            private ThreadLocal lt Boolean gt  excludeMe   new ThreadLocal lt Boolean gt                   Override             protected Boolean initialValue                     return Boolean FALSE                                     Override         public Object getValue ELContext context  Object base  Object property                 try                       if  excludeMe get                              return null                                                This resolver is in the original resolver chain  To prevent                        infinite recursion  set a flag to prevent this resolver from                        invoking the original resolver chain again when its turn in the                        chain comes around                      excludeMe set Boolean TRUE                       Object value   context getELResolver   getValue                              context  base  property                        if  value instanceof String                            value   StringEscapeUtils escapeHtml4  String  value                                             return value                finally                   excludeMe remove                                      Override         public Class lt   gt  getCommonPropertyType ELContext context  Object base                return null                      Override         public Iterator lt FeatureDescriptor gt  getFeatureDescriptors ELContext context  Object base               return null                      Override         public Class lt   gt  getType ELContext context  Object base  Object property                return null                      Override         public boolean isReadOnly ELContext context  Object base  Object property                return true                      Override         public void setValue ELContext context  Object base  Object property  Object value               throw new UnsupportedOperationException                          Again  This only guards the    Please also see other answers

[java] XSS prevention in JSP/Servlet web application

Examples related to java

Examples related to security

Examples related to jsp

Examples related to servlets

Examples related to xss