The Kitchen in the Zoo - security tag

Java EE Security and Spring

Tue, 02 Jun 2009 18:30:00 GMT

Spring Security (originally ACEGI) does not seem to work out of the box with Java EE security (see here). I guess the reason is clear, namely that the people from Spring don't want you to be tied into Java EE and that makes sense because Spring something that you can use without Java EE. But instead of having to learn something new and instead of having to configure my security in a non-standard way, I wanted a way to ensure my services are only called by someone with the right authorization, exactly when they are deployed in a Java EE environment.

Since a standard web application running in a Java EE container can be configured to have security, I expected to be able to configure Spring to use the web request to check the Principal for its security roles before calling a service, but that isn't possible. So, I set to work to quickly create a little library to help me out.

The first step was to implement a Filter in the web application so that it could intercept every call and insert the web request (containing the Principal) into a ThreadLocal variable. The idea was that the ThreadLocal variable could then be used further up the call stack to query the security roles of the authenticated user. The filter implementation looks like this:

public void doFilter( ServletRequest request, ServletResponse response, FilterChain chain)

throws IOException, ServletException {

//set the request in the security thread local SecurityHelper.set((HttpServletRequest)request);

chain.doFilter(request, response);

//all done, so remove references to unwanted objects

        SecurityHelper.finished();     }

The filter is configured in the Java EE web application's web.xml like this:
    <filter>         <filter-name>maxantSpringSecurity</filter-name>         <filter-class>             uk.co.maxant.spring.security.SecurityFilter         </filter-class>     </filter>         <filter-mapping>         <filter-name>maxantSpringSecurity</filter-name>         <url-pattern>/*</url-pattern>     </filter-mapping>The filter calls the SecurityHelper which uses a ThreadLocal variable to store the web request as follows. The web request can be used to gain access to the Principal, as well as ask if the Principal has a given role.
    private static ThreadLocal tls = new ThreadLocal();

public static void set(HttpServletRequest request){ tls.set(request); } public static boolean isInRole(String role){ HttpServletRequest req = tls.get(); if(req == null){ return false; }else{ return req.isUserInRole(role); } }

The Security Helper also contains an additional method which can be called to release the reference to the request. This is important because the web request contains a reference to the session and that might be large. We don't want to be holding on to such things for a long time as they may use memory unncessarily. This method can is called as soon as all security queries are finished, and is implemented as follows. For more information on thread locals and threads that are stored in pools, see here. public static void finished(){ tls.remove(); }

The final step was to configure my Spring configuration to setup an aspect to intercept all service calls. The advice which this aspect gives is whether the current user has the role required to call the method. The required role comes from an annotation added to the service methods and the current user comes from the Principal stored in the ThreadLocal from step one, above. If the user has rights, the service method is called. If not, a simple SecurityException is thrown, providing details about the missing roles. In cases where the user is not logged in, the Security Exception is also thrown. In cases where a Service method has no annotation, then no security is checked. The aspect is configured in the Spring configuration like this:

<bean id="security"
        class="uk.co.maxant.spring.security.SecurityAspect">
        
        <property name="order" value="2" />
    </bean>

<aop:config>
        
        <aop:aspect id="securityAspect" ref="security">
            <aop:pointcut id="serviceMethod"
                expression="execution(* uk.co.maxant.gwtdemo16.server.*Service.*(..))" />
            <aop:around method="checkSecurity"
                pointcut-ref="serviceMethod" />
        </aop:aspect>
    </aop:config>

The expression in the above pointcut needs to be configured to match your package and Service naming conventions.

The aspect itself is implemented like this:
    public Object checkSecurity(ProceedingJoinPoint call)             throws Throwable {         String[] requiredRoles = null;         MethodSignature ms =                        (MethodSignature)call.getSignature();         Method m = ms.getMethod(); //lets check it for the    // RolesAllowed annotation         RolesAllowed roles = m.getAnnotation(RolesAllowed.class); if(roles != null){             requiredRoles = roles.value();             for(String role : requiredRoles){ if(SecurityHelper.isInRole(role)){                     //ok, no problem, lets continue                     //with the call requiredRoles = null; //since we can now // carry out the call break;                 }             }         }             if(requiredRoles == null){             Object returnValue = call.proceed(); return returnValue;         }else{             String rrs = "[";             for(String s : requiredRoles){                rrs += s + ", ";            }            rrs = rrs.substring(0, rrs.length() - 2) + "]";                       throw new SecurityException("To call [" +                call.getSignature().toLongString() +                "] the user must be authenticated and " +                "authorized in these roles: " + rrs);       }     }
The annotation is defined as such:
    @Retention(value=RetentionPolicy.RUNTIME)     @Target(value={ElementType.METHOD})     public @interface RolesAllowed {         String[] value();     }

The annotation is used like this, on all service methods requiring security:
    @RolesAllowed ("registered")

What I now have is a simple library which I can configure using a Filter and an Aspect. Additionally to allow the user to log in in the first place, I can use a standard Java EE security constraint in my web application. The standard steps to use this security extension of Spring would be:

Add a security constraint to the web application
Add the annotation to the service methods requiring security
Add the filter to the web application
Add the aspect to the Spring configuration
Add the library to the classpath

I understand that Spring does not want you to need a dependency on Java EE, but on the other hand if I have that dependency due to other requirements, I do not want to have to configure my application using a third party security concept (Spring) as opposed to a standard one (Java EE). Spring Security is not even part of Standard Spring - it is downloaded seperately. The more extensions you use, the more skills your developers need. The maxant Spring Security extension provides a very simple way to secure your service methods.

Download the library including source code here.

Copyright (c) 2009 Ant Kutschera

Social Bookmarks :

Cross Site Scripting (XSS) and Denial of Service (DoS) using AJAX and other Technologies

Thu, 16 Oct 2008 21:36:00 GMT

The other day I was wondering how Google Analytics works... You put a few lines of Javascript into your page and it loads another script to send data back to one of its servers. I assumed they used an AJAX XMLHttpRequest to send stats to their server. However, an XMLHttpRequest created in Javascript (or any script language for that matter) can only make calls back to the server where the browser made the original request, not where it loaded the script. So if for example a site abc.com has a page which loads a script from def.com, the script can create an XMLHttpRequest object but it can ONLY make calls to abc.com.

Hmmm... that's not entirely true. With IE 6.0.2900 and probably earlier versions of Firefox / other browsers it was possible to make the XMLHttpRequest object call any server, which would be great for a Denial of Service (DoS) attack. Imagine you have a site with millions of page views a day? And your'e feeling unfriendly and want to create a DoS attack against your foe. Easy, you put some script in a page which is frequently viewed, and unknowingly, every one of your readers viewing that page makes a call to your foe's website, stretching its abilities to relpy to all requests, resulting in the DoS attack, which might even take down the server... Or even worse, an unfriendly user of yours posts some content to a forum containing a script to perform that DoS on their own enemy!

Luckily, that security issue was fixed in IE 7 and Firefox 2 (at least the versions I tested on which included service packs). But there is another reason why it is dangerous for an AJAX client to be able to call any server: Scripts have access to cookies and the URL, which means they have access to session IDs. If scripts can send data anywhere, they can easily hijack the session ID and pass it back to a malicious server. As a reminder, a session ID works like this: a user makes a request to view a page on a server. The server checks for a session ID in a cookie or the URL. If its not present, creates a unique ID and sends it back to the user, and probably sends them the login page instead of the original page they wanted to view. Once the user sends their login credentials and the session ID back again, the server checks their credentials and remembers that the user is authenticated and only relies on the session ID being around in every call which the user makes. So anyway, a script can send the cookies and URL to a malicious server which in turn can make its own request to the original server, pretending to be that user. Such an attack is known as a cross site scripting (XSS) attack. Theoretically, the malicious server could change the password, transfer funds to its own account, make forum postings on the users behalf, etc. Whether the connection between the user and the original server is secured over SSL is irrelevant because the script is running inside the users browser.

But how does a malicious script get put on a site in the first place? Its not like the author of a site would go to those lengths, since his server has the session ID anyway, and the user is one of his customers! Well luckily, this is the hard part, and as a systems designer, you can still protect yourself against such attacks. Lets say someone has the intent to create such an attack. They need to somehow get the script into a page which other people can view. To do that, they would look for a forum or page where they can make a posting. So most corporations like banks or online shops are already protected because they don't allow such posting, although it has become trendy for customers to be able to post reviews, like on Amazon.com.

Hold on though, two paragraphs ago I said an AJAX client could NOT make calls like this, to send session info to a malicious server. But somehow, Google Analytics sends that kind of data back to its servers, and thats where it got interesting - how do they do it? I had a go at reading the Javascript which Google uses, but its been obfuscated and instead of using meaningful names for their functions, they all have simple letters for their names. I did get as far as noticing that they seem to be loading some Flash, so I assumed that Flash has a model like Java Applets in which they can send data back to the server from which they are loaded. So I wrote a tiny applet and posted it to my own site. The applet does nothing more than send a string back to the server where the applet was loaded from. Note that applets are restricted to only talking to the server from which they originated, so they cannot be used for DoS attacks. The next step was to write some Javascript which loads that applet, passing it a string parameter, which contains the URL from the browser as well as all the cookies. I then posted that script to a forum (my own I hasten to add - I'm not in the business of hacking peoples accounts!). To post the script, I logged in as myself and created a thread with an enticing name and some provocative text (I want lots of people to read it so I can steal their sessions!). As well as the provocative text, I included the Javascript to load the applet and pass it the cookies and URL. Since browsers don't show script to the user, they don't know whats happening.

I then logged in as a different user on a different browser and read the bogus posting. Indeed, the applet posted the session info back to my server. A few milliseconds after "the user" had read the provocative thread, I had their session ID. Whats more, I'd already programmed the malicious server to make a posting on behalf of the different user, telling the world that the site had been hacked :-)

I nice little experiment I thought, but let me repeat, this was all done on my own servers, in fact locally on my laptop - no ones accounts are in danger! The point is, that its VERY easy to steal session IDs, if there is a way to make a posting that contains script. So by default, my bank is NOT open to such an attack, which makes me happier about using their online services. Even if it were, they have gone to the extent of requiring me to retype parts of my password if I want to transfer funds to a different account, although as I'm writing this I don't think that't the case when I pay bills...

By far the best protection against such XSS attacks is to strip out any script and simply not allow it to be posted. Lots of big sites do that (e.g. Mediawiki doesn't even let you post HTML, they have their own format). I have read that Google even has their own parsers for stripping malicious code out of postings, which shows how important they think it is to protect the world against such attacks.

Other forms of protection I have seen as to put all postings inside an "IFrame" - a special HTML tag which loads content from a site inside a frame protecting the rest of the page from that content. In my tests, code running inside an IFrame still had access to some of the cookies from the main outer page, so if a session ID is contained in cookies, its still not safe. It was interesting to note that Firefox 2 provided some of the cookies while IE 6 didn't provide any.

The final way to protect your sites users is to get them to provide parts of their password again, when they are doing anything important, like making payments or postings. That way, a malicious script has no chance of spoofing their actions.

Copyright (c) 2008 Ant Kutschera

Social Bookmarks :