[Owasp-cincinnati] [Owasp-webgoat] WebGoat 5.2, data layer access control fix

Marco M. Morana marco.m.morana at gmail.com
Sat Aug 2 10:03:44 EDT 2008


Yan

I think you are right and you've got my point, if these client parameters
are checked at API (server) level before processing you are OK.  

On the other hand if you want to be conservative you can also enforce RBAC
at the SQL level. In security the concept of being redundant is referred as
security in depth (also multi layer security) and is applied as a way to
mitigate threats at different trust boundaries (e.g. client, server,
middle-tier components, backend)

Regards

Marco

p.s. I congratulate you as being you one of the most prolific and engaged
members of the list, to the next meeting, please come forward, I have some
OWASP goodies for you (pen, CD, pins )

-----Original Message-----
From: Zhou, Yan [mailto:yzhou at medplus.com] 
Sent: Friday, August 01, 2008 3:54 PM
To: Marco M. Morana
Subject: RE: [Owasp-webgoat] WebGoat 5.2, data layer access control fix

Thanks Marco. 

I see your point, it is certainly a good one. 

But with WebGoat, the user id is the authenticated user (not available
through URL parameter), and subjectUserId: is the employee the
authenticated user wants to change (passed in through parameter). 

One may change parameter to operate on a different employee, but the API
would ensure that a user only change employees that he is authorized,
too. 

I think that the API and the SQL following it both do the same thing,
either one would work, but having both is redundant.

Thanks, 
Yan Zhou

-----Original Message-----
From: Marco M. Morana [mailto:marco.m.morana at gmail.com] 
Sent: Monday, December 01, 2008 9:28 PM
To: Zhou, Yan
Subject: FW: [Owasp-webgoat] WebGoat 5.2, data layer access control fix

Yan

Please find herein my comments to your email, sorry being late.

1). The solution from WebGoat suggests the following for fixing data
layer access control.  However, I thought that only one of them is
sufficient,  either the function call or the SQL access would do the
job, not both. Am I missing
something?
[Morana, Marco M] as I look at the code you have a check for
authorization controls on the code that processes the query. Here you
pass parameters to the API:" isAuthorizedForEmployee". The potential
problem could be on how these parameters are passed to the function. If
these are under control of a user via the client it can be potentially
be changed to elevate the privileges. The typical example could be of
such parameters being URL parameters and captured from the client via a
web proxy and changed. I put the emphasis on potentially because really
depends on how these parameters are passed to the API.
So here you need to make sure that validation of these parameters is
performed on the server side outside the API call

More specifically you ask if you also need a control on the SQL access.
You can certainly restrict on the DB access to the tables depending on
the userIDs. Typically this is good for security because adds another
layer of control. The problem is often times not feasible for
administration pursposes, setting RBAC for each user accessing a table
is a huge administration burden. Typically it can be done by setting
permissions to store procedures for a limited set of accounts (e.g.
fuctional IDs) so there is a limited set of changes required by the DBA.
 

                  if (isAuthorizedForEmployee(s, userId, subjectUserId))

                  {     ...

                        //String query = "SELECT * FROM employee WHERE
userid = " + subjectUserId;

                        String query = "SELECT * FROM employee,ownership
WHERE employee.userid = ownership.employee_id and "
+"ownership.employer_id = " + userId + " and ownership.employee_id = " +
subjectUserId;      // STAGE 4 - FIX
[Morana, Marco M] The problem of this concatenated query is also SQL
injection!

                        ...

                  }     

                  else

                  {

                        throw new UnauthorizedException();

                  }

 

2) How can I get SQL access to the data model, I was not able to find
any instructions on browsing through the database tables directly. 
[Morana, Marco M] Good question, not sure the DB schema is available I
would direct the question to Webgoat mailing list.

 

Thanks, 

[Morana, Marco M] 
Regards, Marco

 











Confidentiality Notice: The information contained in this electronic
transmission is confidential and may be legally privileged. It is
intended
only for the addressee(s) named above. If you are not an intended
recipient,
be aware that any disclosure, copying, distribution or use of the
information contained in this transmission is prohibited and may be
unlawful. If you have received this transmission in error, please notify
us
by telephone (513) 229-5500 or by email (postmaster at MedPlus.com). After
replying, please erase it from your computer system.



_______________________________________________
Owasp-webgoat mailing list
Owasp-webgoat at lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-webgoat











Confidentiality Notice: The information contained in this electronic
transmission is confidential and may be legally privileged. It is intended
only for the addressee(s) named above. If you are not an intended recipient,
be aware that any disclosure, copying, distribution or use of the
information contained in this transmission is prohibited and may be
unlawful. If you have received this transmission in error, please notify us
by telephone (513) 229-5500 or by email (postmaster at MedPlus.com). After
replying, please erase it from your computer system.





More information about the Owasp-cincinnati mailing list