[WEB SECURITY] code review techniques for when you don't trust your developers or testers

Mat Caughron mat at phpconsulting.com
Fri Aug 14 12:17:10 EDT 2009


Anyone seen an insider threat in client-side javascript?

Are powerless application languages a powerful mitigation against
insider threat?*

The social contract of SaaS means that you get to see what runs on
your client.  Apparently the whole "push to cloud" movement seems
uniquely situated to address the insider threat problem space,
unlikely but high impact as it is.

The more code we push openly into the client, and the less we trust
the client, the harder it is for a malicious backdoor, even on the
server side.  I argue this from the following:
  SaaS when done right is being built for client distrust, even
distrust extending to whether the clients can inter-communicate
  error handling and failure modes controlled by server side can be
standardized for the whole cloud, therefore more auditable
  access control components built entirely into server-side code
likewise can be standardized and enforced in a unified way
  public involvement provides threat modeling and risk identification
in real-time
  response and incident management is now centralized  (reference Joe
White's appsec forensics thought leadership)

Of course arbitrary code in the cloud or database breaks this whole
beautiful theory.

If Atwood's law** kicks in, it will push the insider threat issue
closer to the database, and correct me if I'm wrong here, but the
database audit space is more mature than the application audit space.
 Usually fewer lines anyway.



Mat Caughron
(408) 910-1266


* http://www.w3.org/2001/tag/doc/leastPower.html
** http://www.codinghorror.com/blog/archives/000913.html




On Fri, Aug 14, 2009 at 1:40 AM, Jim Manico<jim at manico.net> wrote:
>> Comparing reality (ie: evil insider coder) to your world of
>> personal fantasy (wormholes and Orges) is not fair
>>>>
>>
>> This is the best quote I have ever read in 4 years on this list!
>
> * takes a bow* Thank you!
>
>> Seriously? Bill's most excellent Ogre comparison make your point? HA!
>
> Look, if we call the insider evil coder a unlikely but high impact risk, and
> mitigate such a risk (when appropriate) through change management,
> seperation of duties,  java policy, egress filtering, manual/peer code
> review, expert manual pen testing, static analysis and yes, even black-box
> testing - even SaaS black box testing - and whoa - suddenly we have evidence
> that we are dealing with the risk in some way.
>
> But if you compare the risk of an insider evil coder to "magic and fantasy"
> you are doing your customers a great dis-service, IMO.
>
> - Jim
>
> ----- Original Message ----- From: "Hoffman, Billy" <billy.hoffman at hp.com>
> To: "Jim Manico" <jim at manico.net>; "Bill Pennington"
> <bill.pennington at whitehatsec.com>
> Cc: "Steven M. Christey" <coley at linus.mitre.org>; <kuznetso at alum.mit.edu>;
> "Mat Caughron" <mat at phpconsulting.com>; <websecurity at webappsec.org>
> Sent: Thursday, August 13, 2009 7:57 PM
> Subject: RE: [WEB SECURITY] code review techniques for when you don't trust
> your developers or testers
>
>
>>>>
> Comparing reality (ie: evil insider coder) to your world of
> personal fantasy (wormholes and Orges) is not fair
>>>
>
> This is the best quote I have ever read in 4 years on this list!
>
> Seriously? Bill's most excellent Ogre comparison make your point? HA!
>
> Billy Hoffman
> --
> Manager, Web Security Research Group
> HP Software
> Direct: 770-343-7069
>
>
> -----Original Message-----
> From: Jim Manico [mailto:jim at manico.net]
> Sent: Thursday, August 13, 2009 8:18 PM
> To: Bill Pennington
> Cc: Steven M. Christey; kuznetso at alum.mit.edu; Mat Caughron;
> websecurity at webappsec.org; Hoffman, Billy
> Subject: Re: [WEB SECURITY] code review techniques for when you don't trust
> your developers or testers
>
>> Totally agree on the total disaster one event can do but so can a
>
> direct hit from an asteroid, a wormhole opening under the office or a
> hoard of Ogres...
>
> Comparing reality (ie: evil insider coder) to your world of personal fantasy
> (wormholes and Orges) is not fair - and clearly illustrates my conjecture
> that of the greatest failings of modern risk analysis is to ignore
> incredibly low likelihood but high impact risks.
>
>> but a  failure of modern risk analysis is spending a lot of time, effort
>> and  money protecting against rare high impact events, and ignoring the
>> common everyday ones.
>
> By the same token, this second comment is right on the money, too.
>
> - Jim
>
>
> ----- Original Message ----- From: "Bill Pennington"
> <bill.pennington at whitehatsec.com>
> To: "Jim Manico" <jim at manico.net>
> Cc: "Steven M. Christey" <coley at linus.mitre.org>; <kuznetso at alum.mit.edu>;
> "Mat Caughron" <mat at phpconsulting.com>; <websecurity at webappsec.org>;
> "Hoffman, Billy" <billy.hoffman at hp.com>
> Sent: Thursday, August 13, 2009 1:49 PM
> Subject: Re: [WEB SECURITY] code review techniques for when you don't trust
> your developers or testers
>
>
>> Answers inline...
>>
>> On Aug 13, 2009, at 4:42 PM, Jim Manico wrote:
>>
>>>> I would love to see data on the frequency of bad evil programs  doing
>>>> stuff in code. I would be somewhat shocked if that was a  bigger
>>>> problem than coder introduces SQLi for the 900th time.
>>>
>>> One of the greatest failings of modern risk analysis is to ignore
>>> incredibly low likelihood but high impact risks.
>>>
>>> An insider senior coder who is evil can take you down, easily.
>>>
>>> - Jim
>>
>> Totally agree on the total disaster one event can do but so can a  direct
>> hit from an asteroid, a wormhole opening under the office or a  hoard of
>> Ogres...
>>
>> I have seen developers go bad, I know they do from time to time but a
>> failure of modern risk analysis is spending a lot of time, effort and
>> money protecting against rare high impact events, and ignoring the  common
>> everyday ones.
>>
>> Can we not get data on the frequency of occurrence and does that not
>> impact the time, effort and money we put towards solving the problem?
>>
>>>
>>> ----- Original Message ----- From: "Bill Pennington"
>>> <bill.pennington at whitehatsec.com
>>> >
>>> To: "Steven M. Christey" <coley at linus.mitre.org>
>>> Cc: "Jim Manico" <jim at manico.net>; <kuznetso at alum.mit.edu>; "Mat
>>> Caughron" <mat at phpconsulting.com>; <websecurity at webappsec.org>;
>>> "Hoffman, Billy" <billy.hoffman at hp.com>
>>> Sent: Thursday, August 13, 2009 1:01 PM
>>> Subject: Re: [WEB SECURITY] code review techniques for when you  don't
>>> trust your developers or testers
>>>
>>>
>>>> The only 2 insider evil coder forensics investigations I ever did
>>>> where of the business logic type. Both where so subtle that you  would
>>>> be highly unlikely to detect them. The only reason they  where detected
>>>> is the bad guys had made verbal comments to others  that lead them to
>>>> hand review every check-in these people had  done. Even then they did
>>>> not catch it until 4 different developers  had reviewed it. I have not
>>>> seen a case where people are just  randomly making network connections
>>>> but I will readily admit my  data set is small.
>>>>
>>>> I would love to see data on the frequency of bad evil programs  doing
>>>> stuff in code. I would be somewhat shocked if that was a  bigger
>>>> problem than coder introduces SQLi for the 900th time.
>>>>
>>>>
>>>> ---
>>>> Bill Pennington
>>>> SVP Services
>>>> WhiteHat Security Inc.
>>>> http://www.whitehatsec.com
>>>>
>>>> On Aug 13, 2009, at 3:14 PM, Steven M. Christey wrote:
>>>>
>>>>>
>>>>> On Thu, 13 Aug 2009, Jim Manico wrote:
>>>>>
>>>>>> This is a pain to get right, even more of a pain to maintain -
>>>>>> especially since the tools to manage Java policy are poor, at  best.
>>>>>> But
>>>>>> I think it's our best defense in protecting an enterprise against  the
>>>>>> insider evil coder.
>>>>>
>>>>> There may be techniques for finding the "insider evil coder" doing
>>>>> things
>>>>> that don't make sense like executing an external program and sending
>>>>> results across a hard-coded network connection - Veracode did a   paper
>>>>> on
>>>>> back door detection about a year ago.  To get any depth at all,
>>>>> though,
>>>>> you'd need a well-developed model of what the application is   supposed
>>>>> to
>>>>> do, especially with respect to its interfaces with the OS,  downstream
>>>>> components, etc.
>>>>>
>>>>> That still won't address intentionally-introduced "business logic"
>>>>> issues
>>>>> (with a narrower use of the term than perhaps Jeremiah's), or the   use
>>>>> of
>>>>> legitimate interfaces to create covert channels.  In these cases, it
>>>>> requires full human understanding of what the code is supposed to  be
>>>>> doing
>>>>> with *simultaneous* expert understanding of the domain.  Consider  an
>>>>> odd
>>>>> divide-by-zero error that can only occur in a certain time zone  on
>>>>> one day
>>>>> of a 30-year cycle with several other factors at play.  If you  could
>>>>> do
>>>>> that type of analysis, then you would also probably have the  ability
>>>>> to
>>>>> detect and produce a bug-free system.  The theorists throw around  the
>>>>> "undecidable" term a lot when it comes to proving that code  doesn't
>>>>> have
>>>>> any bugs, and the evil-developer problem may be an alternate
>>>>> expression of
>>>>> that.
>>>>>
>>>>> In other words, I think it's impossible to prove that modern web- based
>>>>> applications are correct from a security perspective (even with
>>>>> respect to
>>>>> only one layer of source code and ignoring the environment), and   this
>>>>> is
>>>>> even more impossible if you care about business-logic correctness  on
>>>>> top
>>>>> of the injection side of the spectrum.
>>>>>
>>>>> - Steve
>>>>>
>>>>>
>>>>> ----------------------------------------------------------------------------
>>>>> 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
>>>>>
>>>>
>>>
>>
>>
>
>
>

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



More information about the websecurity mailing list