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

["Arian J. Evans" <arian.evans@xxxxxxxxxxxxxx>]

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

----------------------------------------------------------------------------
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