Are you reading OWASP Top 10 2007? Just curious since you list the index
numbers for these topics that do not match the 2010 list.

Anyways, in simple terms,

A3 Broken Authentication and Session Mgmt - Authentication exists but can
be easily circumvented to gain access to a protected resource
A8 Failure to Restrict URL Access - No Authentication present, anonymous
users can gain access to the resources w/o being challenged.

Please refer to the most updated list.

[ ~ Prasad |  @prasadshenoy  ~]

On Wed, Jun 6, 2012 at 3:47 AM, dhirajsmahajan@gmail.com <
dhirajsmahajan@gmail.com> wrote:

The first would be authentication or session management that can be
easily bypassed.  For example, a website that simply sets a cookie
with a member ID to validate a session.  An attacker can simply inject
a cookie into their browser with whatever member ID they want and
become any user on the site to bypass authentication.  Mitigation
would include using complex/random session identifiers that change
each time the user is authenticated and are passed as secure cookies
over SSL to prevent session hijacking.

The second would be resources such as an administrative control panel
that sit behind an authentication system of some kind, but do not
actually verify that the user is authenticated.  For example, a login
page redirects to an admin panel which can be bookmarked or shared and
anyone with the URL can access it without going through
authentication.  Mitigation would include ensuring that all pages
which require security actually check for the session token and verify
that the token is valid before allowing access.

-Justin

On 06.06.2012 11:47, dhirajsmahajan@gmail.com wrote:

The difference is the same as the difference between authentication and
authorization (authC and authZ).
In brief, authC ensures that you're really the guy who you say you are
(think about checking your passport and seeing if its not fake and that
the photo actually matches your face). As HTTP is stateless, web
applications use special tokens to do authentiaction. If the token could
be forged and you can trick web app to thinking you're not the one you
really are (e.g. admin instead of plain user), this is an example of
broken authC.

AuthZ (access control), on the other hand, happens after authentication
and verifies that you actually have the rights to do what you requested.
In lots of cases the access is not properly restricted: you can issue a
successful direct request for the privileged operation. In OWASP Top 10
there are 2 issues concerning AuthZ: A8 and A4, which is somewhat
confusing because the difference between them is merely technical.

The explaination is rather simplified, but I hope it helps.