[Esapi-user] Couple of questions about AbstractAuthenticator / getting started with ESAPI

Kevin W. Wall kevin.w.wall at gmail.com
Tue Aug 14 02:27:54 UTC 2012


On Mon, Aug 13, 2012 at 9:44 PM, Daniel Studds <daniel.studds at gmail.com> wrote:
> Hi Kelvin
>
> Thanks for the quick reply.
>
> By 2.0m I meant 2.0GA (misremembered.) I'm downloading it using maven, but I
> might change to having a local copy of the source as from what I've
> discovered so far, I suspect I'll need to patch some of the classes.
>
> I couldn't find a Google issue for the DefaultUser thing - should I raise
> one?

Yes; please do. I know someone brought it up once before, but must not
have had a Google Issue created then and it fell through the cracks. Let's
not let that happen again. Thanks!

> Just for now, I've changed to 2.0.1 (still on maven - I'll pull the source
> dist later). I'm looking at line 215, where it asserts that it's a secure
> connection. Currently, I've set up my filter to log the user in for every
> request, including GET. What I want to happen is for password logins or
> logins from remember tokens to insist on POST, but logins from session to be
> OK with GET.

OK; I don't know how I missed that. Was staring right at the line, but didn't
look at the comment. Duh!

Anyhow, I can see how one might want it both ways. If your using a JavaEE
servlet filter that processes ALL requests, then you this is probably not
what you want. If your filter only processes POSTs, then what is there is
fine.

I think it would make sense to only call

    ESAPI.httpUtilities().assertSecureChannel(ESAPI.currentRequest());
instead of
    ESAPI.httpUtilities().assertSecureRequest(ESAPI.currentRequest());
if the request type is not a POST and there is some particular property
set (would be a new property) that would explicitly allow it. That way,
we would not break backward compatibility.

Please feel free to create a Google Issue requesting something like
that as a new feature. That will allow the ESAPI developers to discuss
the merits of it. Certainly it would not be that difficult to do. Coming up
with some new test cases probably would be the most tedious thing.
But that would allow things like ESAPIFilter to be used with GET and POST.

> I could change my filter so that for the static resources (JS, CSS etc) the
> user isn't logged in, but I figure that creates an opportunity for me to
> stuff up (and also means that anyone can access the static resources).

Personally, I think that is a good idea anyhow. Where I work, we have a
much more elaborate JavaEE servlet filter that will ignore a comma separate
list of anything in a comma-separated list of suffixes which we generally set
to
    .jpg,jpeg,gif,png,css,js
as well as a URL prefix (e.g., /unprotected) list.  If you don't do that,
you *really* take a performance hit.  I had thought of doing something
like that for the ESAPI filters, but to do it right would take a bit
of refactoring
b/c you'd probably want that behavior in more than one filter. And frankly,
It's just not been that high on my priority list yet.

> What's the risk involved with allowing GET requests to retrieve the user
> from session?

I don't think there is a risk as long as you don't then place it on a
query parameter.
At least I can't think of one off the top of my head. (You watch, no
sooner will I
post this than there will be 20 replies telling me why I'm wrong. LOL.)

> What are the key points in creating an authenticator that's "ready for prime
> time"? I'm very green when it comes to security! Are there better examples I
> could look at?

Well, let's start with some basics:
1) They have to be thread safe.
2) They need to be very scalable in terms of both # of users (at last tens of
     thousands of concurrent users and support a user base of hundreds of
     thousands) and in terms of request throughput (sat at least hundred per
     second). Will have to have a high degree of concurrency and possibly some
     serious caching to support that.
3) They need to be able to run across clusters. (User authenticated at one
     application server and later routed to a different one must still
be considered
     authenticated.)
4) Must be immune from all the standard OWASP Top 10 attacks (SQLi, XSS,
    CSRF, etc.).

That should be enough to get you started. ;-)

> I'd be happy to share the authenticator, assuming I can make it reasonably
> decoupled. I'm using neo4j at the moment, but that may change.

Ha! What's one more dependency amongst friends! :)
Seriously, that's not so much of an issue--if it even is at all--with 'contrib'
stuff. Just describe the dependency or include it or reference it via
Maven or whatever. The 'contrib' section is more the "look what I did
with ESAPI; I hope you find this useful too" section.

Hope that helps,
-kevin
-- 
Blog: http://off-the-wall-security.blogspot.com/
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We *cause* accidents."        -- Nathaniel Borenstein


More information about the Esapi-user mailing list