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

John Kinsella jlk at thrashyour.com
Thu Aug 20 16:29:44 EDT 2009


Hey guys - 2 thoughts:
  * (topic-creeping a little, but...) On the education aspect, I think  
there's a decent bang-for-buck to a development org by trying to move  
towards a secure SDLC.  Getting the devs to think about SQLi is nice,  
but if the resources are there, start thinking about security a little  
earlier in the game.
  * Regarding Mike's point on VCS...I think I'd have a hard time doing  
a code audit of a cilent who didn't have the basic pieces like that in  
place.  That's the sign (to me) of a hugely immature organization  
that, quite frankly, I don't think would benefit from a review.  I  
guess, looking from a maturity model, I think of code reviews coming  
higher up the curve.  That does sound like a flaw in my thinking  
compared to the previous bullet, but...comments?

OK, one more thought...I think a mix of static+dynamic will provide  
the best results - when I've pointed out flaws in a web app's source  
and the client is trying to tell me that the web server is configured  
so that will never happen...very nice to be able to have scan results  
to see if that's truely the case...think about a medium-large sized  
organization where you're delivering a report to a engineering  
manager, his developers are saying one thing and you're saying  
another...nice to have a bit more ammo behind your report when  
possible.  Kinda circles back to the issue of management/developer  
trust...

John

On Aug 20, 2009, at 1:07 PM, Mike Duncan wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Mat Caughron wrote:
>> All:
>>
>> Have we all attained the realization that static analysis is where  
>> the
>> real work of appsec gets done?
>
> Oh yeah. I find it hilarious that most security firms rely solely on
> dynamic scans to this day to give them a complete picture of  
> application
> pitfalls.
>
>>
>> I'll argue that source review (automated, manual) and enlightened  
>> DBA's
>> are broadly better at solving the insider threat problem than dynamic
>> techniques.
>
> I would argue the same with the additional caveat that without regular
> training, the tools can only provide so much, so a developer's
> protection (the tool and their knowledge combined) blanket is limited.
>
>>
>> Would love to hear from others who have been successful at  
>> uncovering an
>> insider threat with source code review/static analysis.
>> Specifically: what worked, what didn't?  How helpful, or not, was
>> version control or other typical controls around the development  
>> process?
>
> Primarily, as a developer for a long time and now a AppSec  
> specialist, I
> found that development from project to project brought about limited
> scope to the developer for the said specific project. So, an outside
> developer or auditor should always be used for application reviews.
>
> Additionally, as I stated above, training is a must for all  
> developers.
> Relying on the tool(s) to do all the work will never fully protect the
> applications/systems because the tools really lag behind on most of
> their scans. Fortify for example, will do a great job telling you that
> something is not sanitized properly, but then fail to tell the  
> developer
> that they are properly authorizing the user for a specific zone of the
> application. Tools have limited knowledge of the business and project
> requirements.
>
> The auditor, although not a developer for this project, must be a
> developer or have been one in the past really. I have found in my time
> as an auditor there are too many people whom don't know the language
> constructs, libraries/dependencies, and/or technologies being used to
> effectively provide audit information. They often rely solely on the
> tool to provide all the information and we all know what that will  
> lead
> too.
>
> Also, and I know I am rambling here but, the auditor should be  
> familiar
> with the project and business requirements for it. The auditor should
> know about the technologies being used before the first audit so they
> can effectively drive the developer(s) in a more secure fashion from  
> the
> beginning. All too often the development begins, the auditor then is  
> put
> up against a business objective (deadline) and everyone then starts to
> blame security for being the reason for development time-line  
> failures.
>
> It is a lot easier for application patching as well if the  
> developer(s)
> are using proper source control. The auditor can then just look to
> changes from a good/gold version of the code. Also, the auditor will  
> be
> able to decrease the time for the audit, knowing the language and
> constructs behind the project, because the changes are arguably much
> smaller. I have found personally, that patches/updates to existing  
> code
> is much easier and does not require a complete source code review  
> using
> a tool at all most of the time. But, I do complete [bi-]annual code
> audits to ensure that (forgotten) projects are protected against newer
> threats. If the changes to the code are great, requiring a major  
> version
> numeric change, then I will use tools as well.
>
> Great topic. Thanks Mat.
>
> Mike Duncan
> Application Security Specialist
> National Climatic Data Center, NOAA, US DoC
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkqNrRMACgkQnvIkv6fg9hZgiwCfW8BlzvdjKA2E13K2AatNf9sj
> a9kAnA+GKbkkWZywRZkXIR/0AjUJlr0k
> =DIlF
> -----END PGP SIGNATURE-----
>
> ----------------------------------------------------------------------------
> 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