[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[WEB SECURITY] Re: [Webappsec] opinion on obscuring object names in client code
- From: "Brian Shura" <bshura73@xxxxxxxxx>
- Subject: [WEB SECURITY] Re: [Webappsec] opinion on obscuring object names in client code
- Date: Tue, 19 Aug 2008 17:33:52 -0500
------=_Part_75966_22199129.1219185232840
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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@anachronic.com>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@yahoo.com>
> 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@anachronic.com> wrote:
> >
> >> From: Arian J. Evans <arian.evans@anachronic.com>
> >> Subject: Re: [Webappsec] Fw: opinion
> >> To: nitchimon@yahoo.com
> >> Cc: "Stephen de Vries" <stephen@twisteddelight.org>,
> webappsec@lists.owasp.org
> >> 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@yahoo.com> wrote:
> >> >
> >> >
> >> >
> >> > --- On Mon, 8/18/08, Stephen de Vries
> >> <stephen@twisteddelight.org> wrote:
> >> >
> >> >> From: Stephen de Vries
> >> <stephen@twisteddelight.org>
> >> >> Subject: Re: [Webappsec] Fw: opinion
> >> >> To: nitchimon@yahoo.com
> >> >> Cc: webappsec@lists.owasp.org
> >> >> 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@lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/webappsec
>
------=_Part_75966_22199129.1219185232840
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
<div dir="ltr">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? <br>
<br>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.<br>
<br>-Brian<br><br><div class="gmail_quote">On Tue, Aug 19, 2008 at 4:37 PM, Arian J. Evans <span dir="ltr"><<a href="mailto:arian.evans@anachronic.com";>arian.evans@anachronic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
First off -- humor aside, there is nothing wrong<br>
with due diligence and due care. You are<br>
exercising caution and concern and came<br>
to this list looking for answers, and that is<br>
a completely fair approach.<br>
<br>
(though fair won't stop me from having a<br>
bit of humor at someone else's expense)<br>
<br>
There are many reasons I think your main<br>
concern is not a big deal, but more so that<br>
your solution idea is bad. Here's why:<br>
<br>
1. Don't piss off business owners. Making<br>
them change things that can negatively<br>
impact an application for no positive<br>
demonstrable result is dangerous.<br>
<br>
2. Keep developers on your side. Work<br>
with them to come up with solutions that<br>
they understand & buy in to. You'll get<br>
more mileage this way.<br>
<br>
3. Secure software does not need to be<br>
obscure. See Open Source Software.<br>
<br>
4. Obscure software does not mean it<br>
is secure. Google "cell phone network"<br>
or "telecom software" + "weaknesses"<br>
<br>
5. You can change the underlying<br>
architecture to remove decision-making<br>
bits from being stored stateless on the client.<br>
<br>
You could store them in session memory<br>
or in a database, flat file, etc. server side.<br>
Each of these has costs in terms of both<br>
implementation and performance. I have<br>
found the cost usually outweighs the benefit.<br>
<br>
6. You could take an approach, much like<br>
Microsoft did with .NET View-state, and<br>
slap a checksum on your values and be<br>
done. Unless you are fiddling with them<br>
client side with scripting languages,<br>
they shouldn't change and this will work.<br>
<br>
5. Get a WAF. Yes, I said it. I don't know<br>
who today has a truly functional engine<br>
to allow you to auto-checksum key bits<br>
easily. They all say they do, but I do not<br>
trust most of the vendors and I have not<br>
tried to do this recently.<br>
<br>
A colleague using Imperva just told<br>
me it is very hard to do and not worth<br>
it with their WAF. I cannot speak for<br>
the rest but this is worth investigating.<br>
<br>
You are on the right path. Just don't<br>
comfort yourself that a dash of Caesar<br>
Cipher and a splash of confusion is<br>
going to buy you much of anything<br>
at the end of the day.<br>
<br>
Either bake some real security into<br>
the app, buy a bandaid like a WAF<br>
and protect it, or let it go until you<br>
find a measurable, exploitable<br>
vulnerability (or something that<br>
measurably raises the attack surface)<br>
<br>
<br>
I hope you don't mind -- but I'm going<br>
to add another list to this discussion<br>
so you can get second opinions from<br>
a much bigger list membership of folks<br>
that are smarter than me.<br>
<br>
I would throw all your questions at<br>
both lists and see what people say.<br>
<br>
ciao<br>
<br>
<br>
--<br>
--<br>
Arian J. Evans.<br>
Software. Security. Stuff.<br>
<br>
<br>
<br>
On Tue, Aug 19, 2008 at 10:58 AM, Nitchi DaMon <<a href="mailto:nitchimon@yahoo.com";>nitchimon@yahoo.com</a>> wrote:<br>
> so then the opinion is that using internal application modules and instance variables is no big deal ?<br>
><br>
> I would think that someone would see this as a way to attack .<br>
><br>
> its that little bit of internal information about an application that "could" be used for attack.<br>
><br>
><br>
> 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.<br>
><br>
> Delete didn;t work in some forms that I tried. But others did.<br>
><br>
> 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.<br>
><br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> how would I justify requesting them to change this ?<br>
> 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.<br>
><br>
> <shrugs><br>
><br>
><br>
><br>
> 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.<br>
> I want to make sure I'm not being overly paranoid here....<br>
><br>
> nitch.<br>
><br>
> --- On Mon, 8/18/08, Arian J. Evans <<a href="mailto:arian.evans@anachronic.com";>arian.evans@anachronic.com</a>> wrote:<br>
><br>
>> From: Arian J. Evans <<a href="mailto:arian.evans@anachronic.com";>arian.evans@anachronic.com</a>><br>
>> Subject: Re: [Webappsec] Fw: opinion<br>
>> To: <a href="mailto:nitchimon@yahoo.com";>nitchimon@yahoo.com</a><br>
>> Cc: "Stephen de Vries" <<a href="mailto:stephen@twisteddelight.org";>stephen@twisteddelight.org</a>>, <a href="mailto:webappsec@lists.owasp.org";>webappsec@lists.owasp.org</a><br>
>> Date: Monday, August 18, 2008, 9:34 PM<br>
>> I agree with Stephen's first response.<br>
>><br>
>> Security through obscurity is a pain in the ass<br>
>> and will get you ignored by developers and<br>
>> hated by business owners if you cannot<br>
>> demonstrate clear, concrete value.<br>
>><br>
>> If you are this paranoid about the relative<br>
>> attack surface of your application, why not<br>
>> just require that they create a state token<br>
>> as a marker and keep all variables in<br>
>> memory server-side? or make a round trip<br>
>> to the DB to fetch them each request/response?<br>
>><br>
>> Alternately you could encode, encrypt, or<br>
>> checksum the values, each being possibly<br>
>> lighter weight in use depending on the actual<br>
>> implementation and use case. Checksums<br>
>> are a light, easy starting place.<br>
>><br>
>> All of the above suggestions will solve.<br>
>><br>
>> Solving a problem that does not exist does<br>
>> not solve much. Neither does ROT13.<br>
>><br>
>> If VIEW can be changed to GODMODE<br>
>> (or whatever) then after you fire the<br>
>> developer who created the problem<br>
>> she can just as easily change WJFX<br>
>> to HPENPEF and your ship is still sunk.<br>
>><br>
>> Cheers<br>
>><br>
>> --<br>
>> --<br>
>> Arian J. Evans.<br>
>> Software. Security. Stuff.<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> On Mon, Aug 18, 2008 at 5:42 PM, Nitchi DaMon<br>
>> <<a href="mailto:nitchimon@yahoo.com";>nitchimon@yahoo.com</a>> wrote:<br>
>> ><br>
>> ><br>
>> ><br>
>> > --- On Mon, 8/18/08, Stephen de Vries<br>
>> <<a href="mailto:stephen@twisteddelight.org";>stephen@twisteddelight.org</a>> wrote:<br>
>> ><br>
>> >> From: Stephen de Vries<br>
>> <<a href="mailto:stephen@twisteddelight.org";>stephen@twisteddelight.org</a>><br>
>> >> Subject: Re: [Webappsec] Fw: opinion<br>
>> >> To: <a href="mailto:nitchimon@yahoo.com";>nitchimon@yahoo.com</a><br>
>> >> Cc: <a href="mailto:webappsec@lists.owasp.org";>webappsec@lists.owasp.org</a><br>
>> >> Date: Monday, August 18, 2008, 12:14 PM<br>
>> >> On Aug 18, 2008, at 6:05 PM, Nitchi DaMon wrote:<br>
>> >> ><br>
>> >> > <input<br>
>> name="internalmodulename:action"<br>
>> >> blah blah blah><br>
>> >> ><br>
>> >> > Now when the application send the completed<br>
>> form back<br>
>> >> to the<br>
>> >> > application for processing, it sends<br>
>> something similar<br>
>> >> to:<br>
>> >> ><br>
>> >> ><br>
>> >><br>
>> xx=40&aa=10&internalmodulename:action=edit&varx=70<br>
>> >> etc<br>
>> >> ><br>
>> >> > the tag uses a colon ":" and this<br>
>> can be an<br>
>> >> indication of an SQL<br>
>> >> > INJECTION attack.<br>
>> >> ><br>
>> >> > Now to me, this is a blatant disclosure of an<br>
>> internal<br>
>> >> module name<br>
>> >> > which can be used to attack the application<br>
>> and get it<br>
>> >> to perform<br>
>> >> > something outside of the scope of the<br>
>> internal module<br>
>> >> (if possible).<br>
>> >><br>
>> >> Don't agree with this - there's no<br>
>> indication that<br>
>> >> SQL injection is<br>
>> >> possible. And even though the module name is<br>
>> disclosed,<br>
>> >> this isn't a<br>
>> >> huge issue IMO unless you can actually call other<br>
>> >> unauthorised<br>
>> >> "actions" on it. E.g. have you tried<br>
>> >> action=view, action=delete,<br>
>> >> action=add, etc. Having a look at the code will<br>
>> speed<br>
>> >> things up :)<br>
>> >><br>
>> ><br>
>> > They refuse the code. Had to manually and auto test<br>
>> this app and found it both ways to be an SQL injection.<br>
>> > now, I did not send the rest of the URL variable<br>
>> string. By manipulation, the internalmodulename:action=<br>
>> edit, view, etc works. The other part of the URL string<br>
>> had =edit%27%20 and other encoded characters. It was<br>
>> accepted and while I could not get it to actualy dump the<br>
>> database, the application acted a little differently with<br>
>> each change in the various escaped chrs.<br>
>> ><br>
>> ><br>
>> ><br>
>> >> ><br>
>> >> > But is this too strong of a stance to take?<br>
>> I mean it<br>
>> >> *is* and<br>
>> >> > *can* be dangerous to openly use module<br>
>> instance<br>
>> >> variables as input<br>
>> >> > form names.<br>
>> >><br>
>> >> Even if that internal module isn't properly<br>
>> protected,<br>
>> >> the correct fix<br>
>> >> wouldn't be to hide the module name, it would<br>
>> be to<br>
>> >> protect it<br>
>> >> properly with access control.<br>
>> ><br>
>> ><br>
>> > no access control on this, its a public viewing<br>
>> application.<br>
>> > My feeling is that at no time shoudl they expose the<br>
>> internal module names (ex: internalmodulename:action=)<br>
>> > What IF I was able to change the "action"<br>
>> to something else?<br>
>> ><br>
>> > My opinion is that the internalmodulename : instance<br>
>> should not be used because it "could" become a<br>
>> play toy for someone who "could" figure out how to<br>
>> get the internal module to do something else.<br>
>> ><br>
>> > My feelings is that all variable names in a form<br>
>> should ONLY be used<br>
>> > for a variable name for that form ONLY. Internal to<br>
>> the application the variable name should be something else.<br>
>> Why?<br>
>> > break the chain of variable names from being guessed.<br>
>> ><br>
>> > if external the variable name is "frmfldx"<br>
>> and internal its converted and scrubbed to become<br>
>> "address" or whatever, then it creates another<br>
>> level of complexity/obscurity in guessing internal<br>
>> variables.<br>
>> ><br>
>> ><br>
>> > Thanks for the reply!<br>
>> ><br>
>> > Nitch.<br>
>> ><br>
>> ><br>
>> ><br>
>> >> regards,<br>
>> >> Stephen<br>
_______________________________________________<br>
Webappsec mailing list<br>
<a href="mailto:Webappsec@lists.owasp.org";>Webappsec@lists.owasp.org</a><br>
<a href="https://lists.owasp.org/mailman/listinfo/webappsec"; target="_blank">https://lists.owasp.org/mailman/listinfo/webappsec</a><br>
</blockquote></div><br></div>
------=_Part_75966_22199129.1219185232840--
Brought to you by http://www.webappsec.org
Search this site
|