[Esapi-user] Couple of questions about AbstractAuthenticator / getting started with ESAPI
Kevin W. Wall
kevin.w.wall at gmail.com
Tue Aug 14 01:22:13 UTC 2012
Comments in-line, below.
On Mon, Aug 13, 2012 at 8:50 PM, Daniel Studds <daniel.studds at gmail.com> wrote:
> 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 requests,
> 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 it.
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 replaced
> the AbstractAuthenticator with my own implementation updated with the
> changes above as a quick-and-dirty hack to get it working. My plan from here
> 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 anything
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 doing
that, let me know off-list.
"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