[cgiapp] cgiapp Digest, Vol 30, Issue 9
Mark Rajcok
mrajcok at gmail.com
Tue Mar 30 22:37:25 EDT 2010
Hi Nicholas,
No need to apologize, I only visit this list a few times a month (but not
for lack of interest).
I'm not looking for CAP::Authorization functionality to be added to
CAP::Authen, I just used that as an example. I would "simply" like
CAP::Authen to have the ability to pull additional fields/data from the DB
when it is checking credentials. (The bug report you reference does not
appear to be related.)
I like your approach of getting test coverage up first, then tackling new
features.
I stumbled upon OWASP sometime in the past year (when looking at CSRF), and
was also disappointed to see the lack of Perl presence. Thank you for
stepping up.
-- Mark R.
On Sun, Mar 28, 2010 at 9:47 AM, Nicholas Bamber <nicholas at periapt.co.uk>wrote:
> Mark,
> Deepest apologies for not replying earlier.
>
> As I see it what you are asking for stretches into the
> authorization area. Cees Hek also wrote an
> CGI::Application::Plugin::Authorization module. I suspect that you are
> more familiar than I am with that module and that you can tell me why it
> does not suit your needs. The second angle of your request seems to be
> that the data obtained should be useable in the run modes. There is a
> rt bug report (https://rt.cpan.org/Public/Bug/Display.html?id=31133)
> that makes a very similar point. Beyond that I don't really have a good
> feel as yet whether this would be a good idea.
>
> I am increasingly approaching this from a slightly different angle.
> First of all I am trying to get the test coverage of the module upto
> 100%. (Possibly by actually removing deprecated features rather than
> writing test scripts). Secondly I would like to review the code
> according to OWASP standards
> (http://www.owasp.org/index.php/Top_10_2007). I suspect that a
> systematic analysis will sadly reveal a few vulnerabilities and missing
> functionality. I would really like to get that right before allowing the
> scope to creep.
>
> I would heartily recommend everyone to have a look at the OWASP
> site (http://www.owasp.org). It is an open source charitable
> organization dedicated to internet security. Shockingly hitherto it has
> nothing about perl. So I have dived in at the deep end, started an OWASP
> page on perl (http://www.owasp.org/index.php/Perl ) and I am trying to
> see how much interest in security/OWASP I can generate in the perl
> community on this subject. As far as I can see this can only be good for
> perl as a whole.
>
> Nicholas
>
>
>
> On 05/03/2010 17:00, cgiapp-request at lists.openlib.org wrote:
> > Send cgiapp mailing list submissions to
> > cgiapp at lists.openlib.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > http://lists.openlib.org/mailman/listinfo/cgiapp
> > or, via email, send a message with subject or body 'help' to
> > cgiapp-request at lists.openlib.org
> >
> > You can reach the person managing the list at
> > cgiapp-owner at lists.openlib.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of cgiapp digest..."
> >
> >
> > Today's Topics:
> >
> > 1. Re: Security, Authentication and Authorization for CGI::App
> > (Mark Rajcok)
> > 2. Re: Security, Authentication and Authorization for CGI::App
> > (Mark Rajcok)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Fri, 5 Mar 2010 11:43:55 -0500
> > From: Mark Rajcok<mrajcok at gmail.com>
> > Subject: Re: [cgiapp] Security, Authentication and Authorization for
> > CGI::App
> > To: CGI Application<cgiapp at lists.openlib.org>
> > Message-ID:
> > <e4c0aee21003050843j3d23c36di8c5b6771d4a60988 at mail.gmail.com>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > Hi Nicholas,
> >
> > I would like to see CAP::Authentication be enhanced to have the ability
> to
> > query additional database fields and make the data available to runmodes.
> > These fields need not be related to authentication. For example, the
> > ability to specify a user role/privilege field could then avoid the need
> to
> > hit the database a second time for common authorization checks.
> >
> > In my current app, I have u_state and u_privileges fields. The DB is hit
> > once for authen, and then a second time for authz. I've always wanted a
> way
> > to avoid this. I'm thinking of something like this:
> >
> > DRIVER => [ 'DBI',
> > DBH => $self->dbh,
> > TABLE => 'user',
> > CONSTRAINTS => {
> > 'user.name' => '__CREDENTIAL_1__',
> > 'MD5:user.password' => '__CREDENTIAL_2__'
> > },
> > EXTRA_DATA => [ 'u_state', 'u_privileges'] # store this data
> > somewhere
> > ],
> >
> > sub a_rm {
> > my $self = shift;
> > my $authz_data = $self->authen->extra_data; # returns a hash ref: {
> > u_state => 'active', u_privileges =>7 }
> >
> > -- Mark R.
> >
> > On Thu, Mar 4, 2010 at 5:30 PM, Nicholas Bamber<nicholas at periapt.co.uk
> >wrote:
> >
> >
> >> Brad,
> >> If you have any feedback on
> >> CGI::Application::Plugin::Authentication I would appreciate it.
> >>
> >> My priorities for it are (not in any order):
> >> 1.) Getting it to run under taint mode
> >> 2.) And making the HTML more configurable
> >> 3.) Getting test coverage up.
> >> 4.) Keeping test failures down
> >> 5.) Working through the bugs in rt.
> >>
> >> I am also thinking about the big picture on authentication but I have
> >> been working on the module for too shorter time to have any definite
> ideas.
> >>
> >>
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Fri, 5 Mar 2010 11:53:37 -0500
> > From: Mark Rajcok<mrajcok at gmail.com>
> > Subject: Re: [cgiapp] Security, Authentication and Authorization for
> > CGI::App
> > To: CGI Application<cgiapp at lists.openlib.org>
> > Message-ID:
> > <e4c0aee21003050853n7394a8by93c127e9ed0d5843 at mail.gmail.com>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > On Thu, Mar 4, 2010 at 5:56 PM, Michael Peters<mpeters at plusthree.com
> >wrote:
> >
> >
> >> On 03/04/2010 10:56 AM, Brad Van Sickle wrote:
> >>
> >>> 2) Runmode authorization is a little trickier, but still manageable. I
> >>> check the user's session in prerun and if they are not authenticated,
> >>> redirect to a "not authorized" runmode that redirects them back to the
> >>> security app (login page) Any module that needs to set security on
> >>> specific runmodes, inherits prerun and does "if" checks against the
> >>> runmode/usertype to make sure they are authorized. Anyone trying to go
> >>> somewhere they shouldn't is redirected to that same "not authorized"
> >>> runmode.
> >>>
> >> I usually generalize this by putting my prerun checking in my base class
> >> and each sub class tells the base class which run modes are restricted
> >> to which roles. Sometimes I make this a method that child classes
> >> override or sometimes I make it a parameter that's passed to new() in
> >> either a startup script or a C::A::Dispatch table.
> >>
> >>
> > Hi Brad, great discussion topic.
> >
> > I recently wrote an Authorization Plugin (it is on my todo list to get it
> up
> > on CPAN) to handle "runmode authorization". It uses attribute handles to
> > specify which runmodes require authorization:
> >
> > sub subclass_method_x :Authz(administrator) {
> > # no authorization logic here
> > ...
> > }
> > sub authz_administrator {
> > # authorization logic here
> > }
> >
> >
> > The plugin adds a prerun hook such that before subclass_method_x is
> called,
> > method authz_administrator() will now automatically get called ("authz_"
> > gets prepended to the attribute handle data to form the authorization
> method
> > name). I normally define authz_administrator() in the same (sub)class as
> > subclass_method_x().
> > If authz_administrator() determines the user is not authorized, the
> runmode
> > is changed to authz_error() -- which I define in the base class, since I
> > normally don't need custom authorization error messages. However, if a
> > custom error is needed, the authz_error() method can be overridden in the
> > subclass.
> >
> > I like this approach for a few reasons:
> >
> > 1. subclass_method_x() is clearly marked that it requires authorization,
> and
> > which type of authorization. I prefer this over something like
> > CAP::Authorization's authz_runmodes() concept. If I want to change how
> > authorization works for a method, I simply modify the method signature (I
> > don't have to scroll up to the setup() method and modify a call to
> > authz_runmodes()).
> >
> > 2. subclass_method_x() doesn't have any authorization checking code --
> > that's in another "authorization method", and multiple runmodes can call
> > that same "authorization method" when the same authorization logic is
> needed
> >
> > 3. I don't have to preconfigure the authorization mechanism in a base
> class
> > (which is the typical CAP::Authorization model). In fact, the base class
> > doesn't have to know anything about authorization -- only the subclass
> where
> > the authorization is needed has to know. So for instance, in my
> > AdminUserManager subclass, there are authorization methods for checking
> > different admin privileges. That's the only subclass that has this
> logic.
> > If I need to change how admin authorization works, the runmodes and the
> > authorization logic are all in the same file. I really like that. (But,
> I
> > guess it depends on how you view authorization... if you view it as
> cutting
> > across your application, then the base class might then be preferable.)
> >
> > 4. I can be more efficient and save the results of database queries
> > performed in authz_administrator() for later use in subclass_method_x().
> > This was one of the main reasons I decided to write an alternative to
> > CAP::Authorization. With CAP::Authorization, database hits were being
> made
> > to authorize, then I would make additional database hits in my runmode to
> > obtain more information about the user. For example, in
> > authz_administrator() I often grab the user's name out of the database at
> > the same time I'm pulling out user role/privilege info. I create and
> save a
> > User object for later use in the runmodes. (I just replied to Nicholas,
> > where I requested a similar capability for CAP::Authentication -- then
> only
> > one DB hit would be needed for Auth, Authz, and some other common user
> > info.)
> >
> > As for data authorization (e.g., filtering select queries based on user
> > roles), I don't have any good solutions. I dynamically add WHERE clauses
> > (or dynamically modify the SQL statement appropriately) like you, or I
> > filter the data after getting back query results.
> >
> > -- Mark R.
> >
> >
> > ------------------------------
> >
> > _______________________________________________
> > cgiapp mailing list
> > cgiapp at lists.openlib.org
> > http://lists.openlib.org/mailman/listinfo/cgiapp
> >
> >
> > End of cgiapp Digest, Vol 30, Issue 9
> > *************************************
> >
> >
>
> --
> *Nicholas Peter Bamber*
>
>
>
> *Email:* nicholas at periapt.co.uk <mailto:nicholas at periapt.co.uk>
> *Professional Profile
> <http://www.linkedin.com/pub/nicholas-peter-bamber/13/998/aa2>
> *
> * *
> *Periapt Technologies Ltd* <http://www.periapt.co.uk>
>
>
> Want a signature like this? <
> http://www.linkedin.com/e/sig/47231258/>
>
>
> ##### CGI::Application community mailing list ################
> ## ##
> ## To unsubscribe, or change your message delivery options, ##
> ## visit: http://lists.openlib.org/mailman/listinfo/cgiapp ##
> ## ##
> ## Web archive: http://lists.openlib.org/pipermail/cgiapp/ ##
> ## Wiki: http://cgiapp.erlbaum.net/ ##
> ## ##
> ################################################################
>
>
More information about the cgiapp
mailing list