[Esapi-user] Couple of questions about AbstractAuthenticator / getting started with ESAPI
daniel.studds at gmail.com
Tue Aug 14 01:44:30 UTC 2012
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
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.
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).
What's the risk involved with allowing GET requests to retrieve the user
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?
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.
On 14 August 2012 11:22, Kevin W. Wall <kevin.w.wall at gmail.com> wrote:
> Comments in-line, below.
> On Mon, Aug 13, 2012 at 8:50 PM, Daniel Studds <daniel.studds at gmail.com>
> > Hi all
> > I'm just trying to get started with ESAPI. I'm using 2.0m.
> What is 2.0m? I don't recall labeling release candidates that
> way so I'm wonder what the 'm' version refers to (unless that's a typo).
> The latest version is 2.0.1. Are you referring to ESAPI for Java (at
> > I'm working on an
> > AJAX app and don't know much about security, so rather than try to roll
> > something quick and dirty, I thought I'd try to use this. I've set up a
> > WebFilter to make sure users are logged in for all requests. The login
> > request is a POST. Subsequent requests are a mixture of GET (static
> files eg
> > issues while setting this up:
> > AbstractAuthenticator has references to DefaultUser throughout - should
> > these be pointing to the User interface?
> Yes; in fact, someone mentioned that before and they may even be a Google
> Issue open up for it. If not, there should be.
> > AbstractAuthenticator.login() validates that all requests are POST
> > even if the user is already logged in and the retrieved from the
> session: is
> > this the intended behaviour?
> I only took a very quick look at
> but I don't see that in the code off-hand. Course I could have overlooked
> If it indeed is doing that, I would be surprised it it is intentional. I
> do see
> where it makes sure you are using a secure connection though (which is
> probably determined via a property setting in ESAPI.properties). That at
> least makes sense.
> However, let me say that I think that most of use who worked on ESAPI
> consider POST to be more suited to security than GET. There's less chance
> of accidental information disclosure. GETs are logged with all the query
> parameters and can leave your site via Referer [sic] headers. With POST,
> all you get is the base URL, but no parameters.
> > I've more-or-less just duplicated the FileBasedAuthenticator, and I
> > the AbstractAuthenticator with my own implementation updated with the
> > changes above as a quick-and-dirty hack to get it working. My plan from
> > is to migrate away from the FileBaseAuthenticator to my own authenticator
> > backed by the DB as I have time...
> That would be the plan. As you have surmised, the FileBasedAuthenticator
> is just a toy reference implementation and certainly not something that is
> scalable to any degree. Not really intended for prime-time as they say.
> > Does anyone have any hints/tips about the two questions above, or
> > else?
> Only that if you feel led, please consider contributing your DB version of
> Authenticator to the 'contrib' section of ESAPI. If you are interested in
> that, let me know off-list.
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Esapi-user