[WEB SECURITY] Re: [Webappsec] opinion on obscuring object names in client code

["Rohit Lists" <rklists@xxxxxxxxx>]

Nitchi,

What you're describing is actually a named pattern in the J2EE/JEE
world - "Command and Controller" [See Core J2EE Patterns, Alur, Crupi
and Malks]. The idea is to take a URL string parameter and translate
the parameter into an instance of the Command [See Design Patterns,
Gang of Four] design pattern. The command is then executed and the
appropriate resulting view is dispatched back to the client.

Developers see this as an elegant solution since the intent of the
parameter is clear (especially important in debugging and trouble
shooting). The fact that it's a documented best practice is proof of
its pervasiveness.

The feeling you're getting is probably stemming from your years of
experience as a security person: there is a real possibility that the
developers are neglecting to perform authorization based on the value
of that command parameter. The problem is that some of the popular
authorization strategies (e.g. declarative role-based authorization)
don't really account for this, and unless the application design is
sophisticated enough to account to offer some sort of programmatic
authorization there is a chance that end users can use
parameter-manipulation to perform an action they shouldn't be able to.

What probably raised your concern was the fact that you saw a
CRUD-type action as the parameter name; even a non-skilled attacker
might try and change the value from "edit" to "delete" (for instance).
What the other people on the list are saying, and I'd concur with, is
that the real problem is not the naming of the parameter but whether
or not they have sufficient authorization. I also agree with Arian
that raising the issue with developers is not the best approach unless
there really is a vulnerability.

I find this all very interesting and timely, since I'm putting
together a security analysis of the Core J2EE Patterns for a class
that I'm developing.

Cheers,

Rohit
-- 
Rohit Sethi
Security Compass
http://www.securitycompass.com



On Tue, Aug 19, 2008 at 7:43 PM, Nitchi DaMon <nitchimon@xxxxxxxxx> wrote:
>
> They've given me a massive hard time because "they don't like having someone TELL them and WATCH OVER them".  but that is normal.
> In my days as a developer...  I hated it also.   Kinda gives me a different approach "having been there". (but thats normal)
>
> I see and take all suggestions... heck have fun with what I am saying.  If after 20+ years with computers and tons of languages, one does not have a thick skin and a sense of humor....  go work for the postal system.
>
> Security by obscurity.. no no no.. never in the classic sense.  But twisting a few things here and there can be a good thing. BUT its not the main defense.. if it is.. turn in your security badge of honor and take the 50 foot bungee jump with 100 foot of bungee cord.
>
> Open Source software is what it is.  This however is internal code that has an external hook for handling web interface.
> Yeah, I know...  its all the same...
>
> I'm looking at the application and  I can't quite put my finger on WHY this bothers me so much.  I ran manual and automated tests (commercial and open source) against it and it still rubs me the wrong way.
> Being a hardware and software person with extensive penetration testingn behind me, I've learned that IF something "rubs me the wrong way", I've overlooked something more serious.  Its the perverbial "hair standing up on your neck".  Thus asking opinions.
>
>
> As for asking a rewrite, ONLY if I can prove this nagging feeling. So far.. no.  thus I have no intention of going forward with this.. yet.
>
> I know that when we first started down this road together, the developers absolutely HATED having to get their applications and code approved.
> It was the typical "my software is secure so there!" attitude.  When proven wrong... oh my !  Who threw a hornets nest at their head!
> This was above and beyond, way beyond a typical response that I've had in the past.  Label this one venomous.
>
> the second app.. no big deal.. this third app,  I started to see that they were trying to write code to satisfy pen tests and throw a lot more "false positives".  Maybe I'm not saying this right.  I got the feeling that they are trying to write code to navigate around white and black box tests.
>
> Again, their initial response was to blow off the clients policies and procedures and say "they don;t know what they are doing, we do and we'll do it our way"... which got them in trouble, APP-SEC wise.
>
> ok.. I'm off subject here...
>
> So most "opinions" so far state its "no big deal" to have the internalmodule:instance variable  used within a form.
>
> I like the idea of asking them for a list of other actions that the module can do and test each.  Ok good idea.
>
>
> I still can't put my finger on why this bothers me so much though.
>
>
> more opnions... more !!! :)
>
> thanks everyone...  have humor in your responses, I'm looking for opinions.
>
> thanks!!!
>
> Nitch.
> --- On Tue, 8/19/08, Brian Shura <bshura73@xxxxxxxxx> wrote:
>
>> From: Brian Shura <bshura73@xxxxxxxxx>
>> Subject: Re: [Webappsec] opinion on obscuring object names in client code
>> To: "Arian J. Evans" <arian.evans@xxxxxxxxxxxxxx>
>> Cc: nitchimon@xxxxxxxxx, webappsec@xxxxxxxxxxxxxxx, "websecurity@xxxxxxxxxxxxx" <websecurity@xxxxxxxxxxxxx>
>> Date: Tuesday, August 19, 2008, 6:33 PM
>> I agree with all of Arian's advice here except for the
>> second number 5 -
>> "Get a WAF".  If you don't know of any way to
>> actually exploit the issue
>> you're describing, then why put a WAF in place to try
>> to mitigate it?
>>
>> You're going to be fighting an uphill battle with the
>> developers to get them
>> to "fix" it and remove the internal module names
>> from the HTML source.  And
>> later on when you find real, exploitable issues that need
>> to be fixed
>> they're going to give you a hard time.
>>
>> -Brian
>>
>> On Tue, Aug 19, 2008 at 4:37 PM, Arian J. Evans
>> <arian.evans@xxxxxxxxxxxxxx>wrote:
>>
>> > First off -- humor aside, there is nothing wrong
>> > with due diligence and due care. You are
>> > exercising caution and concern and came
>> > to this list looking for answers, and that is
>> > a completely fair approach.
>> >
>> > (though fair won't stop me from having a
>> > bit of humor at someone else's expense)
>> >
>> > There are many reasons I think your main
>> > concern is not a big deal, but more so that
>> > your solution idea is bad. Here's why:
>> >
>> > 1. Don't piss off business owners. Making
>> > them change things that can negatively
>> > impact an application for no positive
>> > demonstrable result is dangerous.
>> >
>> > 2. Keep developers on your side. Work
>> > with them to come up with solutions that
>> > they understand & buy in to. You'll get
>> > more mileage this way.
>> >
>> > 3. Secure software does not need to be
>> > obscure. See Open Source Software.
>> >
>> > 4. Obscure software does not mean it
>> > is secure. Google "cell phone network"
>> > or "telecom software" +
>> "weaknesses"
>> >
>> > 5.  You can change the underlying
>> > architecture to remove decision-making
>> > bits from being stored stateless on the client.
>> >
>> > You could store them in session memory
>> > or in a database, flat file, etc. server side.
>> > Each of these has costs in terms of both
>> > implementation and performance. I have
>> > found the cost usually outweighs the benefit.
>> >
>> > 6. You could take an approach, much like
>> > Microsoft did with .NET View-state, and
>> > slap a checksum on your values and be
>> > done. Unless you are fiddling with them
>> > client side with scripting languages,
>> > they shouldn't change and this will work.
>> >
>> > 5. Get a WAF. Yes, I said it. I don't know
>> > who today has a truly functional engine
>> > to allow you to auto-checksum key bits
>> > easily. They all say they do, but I do not
>> > trust most of the vendors and I have not
>> > tried to do this recently.
>> >
>> > A colleague using Imperva just told
>> > me it is very hard to do and not worth
>> > it with their WAF. I cannot speak for
>> > the rest but this is worth investigating.
>> >
>> > You are on the right path. Just don't
>> > comfort yourself that a dash of Caesar
>> > Cipher and a splash of confusion is
>> > going to buy you much of anything
>> > at the end of the day.
>> >
>> > Either bake some real security into
>> > the app, buy a bandaid like a WAF
>> > and protect it, or let it go until you
>> > find a measurable, exploitable
>> > vulnerability (or something that
>> > measurably raises the attack surface)
>> >
>> >
>> > I hope you don't mind -- but I'm going
>> > to add another list to this discussion
>> > so you can get second opinions from
>> > a much bigger list membership of folks
>> > that are smarter than me.
>> >
>> > I would throw all your questions at
>> > both lists and see what people say.
>> >
>> > ciao
>> >
>> >
>> > --
>> > --
>> > Arian J. Evans.
>> > Software. Security. Stuff.
>> >
>> >
>> >
>> > On Tue, Aug 19, 2008 at 10:58 AM, Nitchi DaMon
>> <nitchimon@xxxxxxxxx>
>> > wrote:
>> > > so then the opinion is that using internal
>> application modules and
>> > instance variables is no big deal ?
>> > >
>> > > I would think that someone would see this as a
>> way to attack .
>> > >
>> > > its that little bit of internal information about
>> an application that
>> > "could" be used for attack.
>> > >
>> > >
>> > > I see and know what you has been said.  If one
>> can change the variable to
>> > be another command and it responds as it should, I
>> would think that someone
>> > "could" figure out that this module controls
>> what some input and through
>> > various manipulations might be able to
>> "delete" records from the database as
>> > well.
>> > >
>> > > Delete didn;t work in some forms that I tried.
>> But others did.
>> > >
>> > > I would think that knowing the internal module
>> name and knowing that I
>> > could send various things to it and it either responds
>> or gets ignored...
>> > then I should be able to send it things that
>> "might" trip other problems.
>> > >
>> > >
>> > > Paranoid ?  yes in some ways, but show me a
>> security person that isn't
>> > and I'll show you someone that doesn;t take this
>> all that seriously.
>> > >
>> > > I don't like giving out *any* information
>> about how an application runs
>> > or operates, especially internal module names and
>> instance variables.  To me
>> > this is a disaster in the making.  Maybe no big deal
>> today....  but
>> > somewhere down the road it might be figured out how to
>> break the app.
>> > >
>> > > how would I justify requesting them to change
>> this ?
>> > > Probably show them how I can send various
>> variables to it to get it to do
>> > someone on the front page that should not be done
>> until somewhere else OR
>> > should not be done at all.
>> > >
>> > > <shrugs>
>> > >
>> > >
>> > >
>> > > thanks again for the opinion.   I'm taking
>> the opinions and twisting the
>> > logic around to see all sides of this before I submit
>> my suggestions.
>> > > I want to make sure I'm not being overly
>> paranoid here....
>> > >
>> > > nitch.
>> > >
>> > > --- On Mon, 8/18/08, Arian J. Evans
>> <arian.evans@xxxxxxxxxxxxxx> wrote:
>> > >
>> > >> From: Arian J. Evans
>> <arian.evans@xxxxxxxxxxxxxx>
>> > >> Subject: Re: [Webappsec] Fw: opinion
>> > >> To: nitchimon@xxxxxxxxx
>> > >> Cc: "Stephen de Vries"
>> <stephen@xxxxxxxxxxxxxxxxxx>,
>> > webappsec@xxxxxxxxxxxxxxx
>> > >> Date: Monday, August 18, 2008, 9:34 PM
>> > >> I agree with Stephen's first response.
>> > >>
>> > >> Security through obscurity is a pain in the
>> ass
>> > >> and will get you ignored by developers and
>> > >> hated by business owners if you cannot
>> > >> demonstrate clear, concrete value.
>> > >>
>> > >> If you are this paranoid about the relative
>> > >> attack surface of your application, why not
>> > >> just require that they create a state token
>> > >> as a marker and keep all variables in
>> > >> memory server-side? or make a round trip
>> > >> to the DB to fetch them each
>> request/response?
>> > >>
>> > >> Alternately you could encode, encrypt, or
>> > >> checksum the values, each being possibly
>> > >> lighter weight in use depending on the actual
>> > >> implementation and use case. Checksums
>> > >> are a light, easy starting place.
>> > >>
>> > >> All of the above suggestions will solve.
>> > >>
>> > >> Solving a problem that does not exist does
>> > >> not solve much. Neither does ROT13.
>> > >>
>> > >> If VIEW can be changed to GODMODE
>> > >> (or whatever) then after you fire the
>> > >> developer who created the problem
>> > >> she can just as easily change WJFX
>> > >> to HPENPEF and your ship is still sunk.
>> > >>
>> > >> Cheers
>> > >>
>> > >> --
>> > >> --
>> > >> Arian J. Evans.
>> > >> Software. Security. Stuff.
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>
>> > >> On Mon, Aug 18, 2008 at 5:42 PM, Nitchi DaMon
>> > >> <nitchimon@xxxxxxxxx> wrote:
>> > >> >
>> > >> >
>> > >> >
>> > >> > --- On Mon, 8/18/08, Stephen de Vries
>> > >> <stephen@xxxxxxxxxxxxxxxxxx> wrote:
>> > >> >
>> > >> >> From: Stephen de Vries
>> > >> <stephen@xxxxxxxxxxxxxxxxxx>
>> > >> >> Subject: Re: [Webappsec] Fw:
>> opinion
>> > >> >> To: nitchimon@xxxxxxxxx
>> > >> >> Cc: webappsec@xxxxxxxxxxxxxxx
>> > >> >> Date: Monday, August 18, 2008, 12:14
>> PM
>> > >> >> On Aug 18, 2008, at 6:05 PM, Nitchi
>> DaMon wrote:
>> > >> >> >
>> > >> >> > <input
>> > >> name="internalmodulename:action"
>> > >> >> blah blah blah>
>> > >> >> >
>> > >> >> > Now when the application send
>> the completed
>> > >> form back
>> > >> >> to the
>> > >> >> > application for processing, it
>> sends
>> > >> something similar
>> > >> >> to:
>> > >> >> >
>> > >> >> >
>> > >> >>
>> > >>
>> xx=40&aa=10&internalmodulename:action=edit&varx=70
>> > >> >>   etc
>> > >> >> >
>> > >> >> > the tag uses a colon
>> ":" and this
>> > >> can be an
>> > >> >> indication of an SQL
>> > >> >> > INJECTION attack.
>> > >> >> >
>> > >> >> > Now to me, this is a blatant
>> disclosure of an
>> > >> internal
>> > >> >> module name
>> > >> >> > which can be used to attack the
>> application
>> > >> and get it
>> > >> >> to perform
>> > >> >> > something outside of the scope
>> of the
>> > >> internal module
>> > >> >> (if possible).
>> > >> >>
>> > >> >> Don't agree with this -
>> there's no
>> > >> indication that
>> > >> >> SQL injection is
>> > >> >> possible.  And even though the
>> module name is
>> > >> disclosed,
>> > >> >> this isn't a
>> > >> >> huge issue IMO unless you can
>> actually call other
>> > >> >> unauthorised
>> > >> >> "actions" on it.  E.g.
>> have you tried
>> > >> >> action=view, action=delete,
>> > >> >> action=add, etc.  Having a look at
>> the code will
>> > >> speed
>> > >> >> things up :)
>> > >> >>
>> > >> >
>> > >> > They refuse the code.  Had to manually
>> and auto test
>> > >> this app and found it both ways to be an SQL
>> injection.
>> > >> > now, I did not send the rest of the URL
>> variable
>> > >> string.  By manipulation, the
>> internalmodulename:action=
>> > >> edit, view, etc  works.  The other part of
>> the URL string
>> > >> had  =edit%27%20  and other encoded
>> characters.  It was
>> > >> accepted and while I could not get it to
>> actualy dump the
>> > >> database, the application acted a little
>> differently with
>> > >> each change in the various escaped chrs.
>> > >> >
>> > >> >
>> > >> >
>> > >> >> >
>> > >> >> > But is this too strong of a
>> stance to take?
>> > >> I mean it
>> > >> >> *is* and
>> > >> >> > *can* be dangerous to openly
>> use module
>> > >> instance
>> > >> >> variables as input
>> > >> >> > form names.
>> > >> >>
>> > >> >> Even if that internal module
>> isn't properly
>> > >> protected,
>> > >> >> the correct fix
>> > >> >> wouldn't be to hide the module
>> name, it would
>> > >> be to
>> > >> >> protect it
>> > >> >> properly with access control.
>> > >> >
>> > >> >
>> > >> > no access control on this, its a public
>> viewing
>> > >> application.
>> > >> > My feeling is that at no time shoudl
>> they expose the
>> > >> internal module names  (ex:
>> internalmodulename:action=)
>> > >> > What IF I was able to  change the
>> "action"
>> > >> to something else?
>> > >> >
>> > >> > My opinion is that the
>> internalmodulename : instance
>> > >> should not be used because it
>> "could" become a
>> > >> play toy for someone who "could"
>> figure out how to
>> > >> get the internal module to do something else.
>> > >> >
>> > >> > My feelings is that all variable names
>> in a form
>> > >> should ONLY be used
>> > >> > for a variable name for that form ONLY.
>> Internal to
>> > >> the application the variable name should be
>> something else.
>> > >> Why?
>> > >> > break the chain of variable names from
>> being guessed.
>> > >> >
>> > >> > if external the variable name is
>> "frmfldx"
>> > >> and internal its converted and scrubbed to
>> become
>> > >> "address" or whatever, then it
>> creates another
>> > >> level of complexity/obscurity in guessing
>> internal
>> > >> variables.
>> > >> >
>> > >> >
>> > >> > Thanks for the reply!
>> > >> >
>> > >> > Nitch.
>> > >> >
>> > >> >
>> > >> >
>> > >> >> regards,
>> > >> >> Stephen
>> > _______________________________________________
>> > Webappsec mailing list
>> > Webappsec@xxxxxxxxxxxxxxx
>> > https://lists.owasp.org/mailman/listinfo/webappsec
>> >
>
>
>
>
> _______________________________________________
> Webappsec mailing list
> Webappsec@xxxxxxxxxxxxxxx
> https://lists.owasp.org/mailman/listinfo/webappsec
>

----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA