RE: Client/Server application that does not authenticate users

["Dinis Cruz" <dinis () ddplus net>]

I knew of an web app that got the username for the user variable "Username"

Guess what would happen in you typed in the client workstation "Set
Username=Admin" :)

For guidelines check out the OWASP documents: Top 10
(http://www.owasp.org/documentation/topten.html), Testing guide
(http://www.owasp.org/documentation/testing.html), the ISO 17799 Project
(http://www.owasp.org/standards/iso17799.html) and the app sec FAQ
(http://www.owasp.org/documentation/faq.html)

Hope this helps

Best regards

Dinis Cruz
.Net Security Consultant
DDPlus


> -----Original Message-----
> From: Brian Erdelyi [mailto:brian_erdelyi () yahoo com]
> Sent: 13 August 2004 11:58
> To: Dinis Cruz; pen-test () securityfocus com
> Subject: RE: Client/Server application that does not authenticate users
>
> I am working with the vendor on this.  Unfortunately,
> I was assured by the cendor that the application does
> authenticate users and uses accesscontrol lists to
> assign permissions.  They claimed I was was using an
> uncommon interpretation of the term "authentication".
> The next level of support disagreed with my use of the
> term "vulnerability".
>
> The server does ask for a username (the client
> automatically forwards the Windows username of the
> currently logged on computer) but no password is
> requested or sent at any point.  This is by design of
> the application (which from my perspective is
> seriously flawed for an application that allows users
> to sell and trade millions of dollars worth of bonds).
>
> I will give the vendor some time to analyse the
> description I have provided to them and respond.
>
> I'd like to provide some very specific suggestions and
> guidance on how other applications are designed and
> coded to authenticate users.
>
> Is there an RFC on secure programming?
>
>
>
> --- Dinis Cruz <dinis () ddplus net> wrote:
>
> > Quite common.
> >
> > The other major mistake that most do is to rely on
> > the Client's GUI to
> > enforce the 'security boundaries' of the client
> > application (for example:
> > they rely on the fact that the user's GUI doesn't
> > have the functionality to
> > change passwords (including the administrators), so
> > if such a request is
> > made it must be from a valid source....)
> >
> > But, the big question is: "what happens next?"
> >
> > Are they going to tell their customers that their
> > data could had been (or
> > was) compromised?
> >
> > Dinis Cruz
> > .Net Security Consultant
> > DDPlus
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail is new and improved - Check it out!
> http://promotions.yahoo.com/new_mail