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

Jim Manico jim at manico.net
Sat Aug 15 16:02:19 EDT 2009


> Jim, I dated a few Ogres in high school, they are not "personal  fantasy" 
> I can assure you! ;-)

Bill, you're giving me some bad Shrek nightmares, man. And although I've 
never dated any "evil coders" in high school (that I know of), they still 
exist, and no one is watching them! :)

And I agree with you wholeheartedly; we have to deal with XSS and SQLi type 
issues first. Walk before you run kind of thinking.

But by the same token, there are some applications/development groups that 
have achieved a significant level of maturity: ie: strong output encoding 
and query parameterization everywhere, strong auth/access contol at an 
architectural level, already have a tight change control process, etc. Some 
of these are just the features of smart development shops, security aside. 
For these mature groups, especially those that deal with *very* high risk 
applications -  they have the luxury to think about (or more like, are 
required to think about) high impact/low likelihood threats - and for those, 
considering mitigation against evil insiders is prudent and necessary.

- Jim

----- Original Message ----- 
From: "Bill Pennington" <bill.pennington at whitehatsec.com>
To: "Jim Manico" <jim at manico.net>
Cc: "Hoffman, Billy" <billy.hoffman at hp.com>; "Steven M. Christey" 
<coley at linus.mitre.org>; <kuznetso at alum.mit.edu>; "Mat Caughron" 
<mat at phpconsulting.com>; <websecurity at webappsec.org>
Sent: Friday, August 14, 2009 8:26 AM
Subject: Re: [WEB SECURITY] code review techniques for when you don't trust 
your developers or testers


> Jim, I dated a few Ogres in high school, they are not "personal  fantasy" 
> I can assure you! ;-)
>
> I missed a smiley on my original comment, but my point still stands,  why 
> are we so gung-ho about the malicious insider issue? I have not  seen any 
> data that backs up why we should be so concerned with this  issue above 
> say the more boring XSS, SQLi and business logic issues  everyone has 
> today and we have data to back up that they are actively  get exploited 
> today. I am not saying you are wrong, I am just saying  where is the data?
>
> Also we need to expand our list of bad insiders, DBAs and sysadmins  need 
> to be watched as well since they generally have some level of  access to 
> the code. I worked a case where the sysadmin was changing  code *after* it 
> was on production, good luck finding that in dev/QA.  By far the vast 
> majority of web app incidents I have seen are all the  run of the mill 
> <outsider> used <SQLi/XSS/biz. logic> to do  <somethingbad>. I have seen 
> hundreds of those and 2 bad developer and  one bad sysadmin. I would say 
> less than 1% of the cases I have seen  involve that type of attack. I am 
> pretty sure the Verizon report backs  up my experience as well but I did 
> not read the entire report.
>
>
> ---
>
>
> Bill Pennington
> SVP Services
> WhiteHat Security Inc.
> http://www.whitehatsec.com
>
> On Aug 13, 2009, at 11:40 PM, Jim Manico 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