[Owasp-sydney] The Top 10, Developers, and You.

Steven Rebello srebello at gmail.com
Thu Jul 4 14:10:24 UTC 2013


Having come from a development background as well, I agree with your
approach and you're spot on about engaging devs with code examples and war
stories rather than just reciting the OWASP Top Ten issues and their
definitions. I've attended a couple of 'trainings' of the latter variety
myself and the yawns around the room were evidence of the interest or lack

When I subsequently switched from being part of the audience to being the
trainer, I found that demonstrating a realistic exploit helps drive home
the point. For example, some trainers demo an XSS attack but stop at the
"alert('XSS')" prompt and the audience goes "so what". But if you take that
forward and capture the session ID, send it to a member of the audience and
get her/him to impersonate the victim user - that gets the message across.

To add to your excellent points, depending on the audience, it may be
useful to walk through 'secure by design' principles, specially if there
are technical leads or solution designers in the room. Writing secure code
is important but its also important to have the right frameworks and
standards in place at design phase - this will ultimately make it easier
for the developers to write secure code. And by that I mean things like,

- Defining non-functional requirements with the business and other stake
holders at the start, tracked all the way to production release
- Selection of the appropriate frameworks and libraries to form the core of
the validation routines e.g. Apache Commons validator. Avoids each
developer going and writing their own little routines to validate input, a
nightmare to maintain
- Integration of static and/or dynamic security testing tools into build
cycle e.g. I used to use findbugs with customised rules, Google Skipfish
etc. there are many more available now. The aim here is early detection and
hence less effort and $$ to fix
- Independent security testing before go-live. At most companies, this is
the first time the dev team interacts with security teams or pen testers,
which is too late and it costs a lot more to fix.
- Environment security - harden your servers before UAT starts, that way
there are fewer surprises when moving into a hardened production
....many more but will stop boring you all now :-)

Writing secure code is hard and developers focus more on functionality (as
they should) so whatever can be done to bake security into the application
code from the beginning makes it that much easier for the developers to
produce a secure application.

My 2 cents...


PS: Corneliu, some of those demos you mention sound interesting, would be
great to understand how you prepare those. Hope to chat with you at one of
the meetings.

On Tue, Jul 2, 2013 at 9:25 PM, Corneliu I. Tusnea
<corneliu at acorns.com.au>wrote:

> Hi Norman,
> This list is a bit quiet at times ... all the time :)
> I recently delivered some training about OWAPS TOP 10 from a .Net
> Developers perspective. (I'm a developer that entered the security space so
> I see everything from the code perspective)
> I had a demo for each of the top 10 and shown how the attack works, why,
> how to fix it through code, how to improve the code to avoid those
> scenarios.
> It went very well, heaps of questions and very good feedback.
> My take from this:
>    1. Deliver the top 10 in reverse order. You can actually build nice
>    demos of a CSRF attack combined with a invalid redirect. Then you can build
>    a SQL injection via a CSRF and so on.
>    2. Add more stuff than top 10. E.g. No 9 for 2013 is using components
>    with known vulnerabilities. You can't spend 1h on that topic but you can
>    include the previous top 9 (2010-2012), Insufficient Transport Layer
>    protection and you can make a good demo of that. If you have access to a
>    wireless during the demo and have all the tools at hand you can demo a
>    proper BEAST attack on your own IIS by asking someone to connect to your
>    missconfigured IIS then do the protection.
>    3. Attacking and penetration is cool, way cool, for us who do that for
>    a living or for fun, however developers and testers will NEVER connect past
>    the "cool" stuff and it's hard for them to try to learn how to do a
>    penetration. Instead focus on what they can be left with: How can they
>    write more secure code. Yes, I like to demo penetration but at the end they
>    are left with a nice demo and no solutions.
>    4. What I really want them to know exactly WHAT and WHERE to look for
>    vulnerabilities in their code, patterns to see them, patterns to avoid
>    them, and any framework level changes they can do to avoid them.
>    5. Developers connect to code so code shall they get. They connect to
>    code. They look at code and say "Hey, we are doing that. OMG, we should fix
>    it!".
>    6. Ask them to always engage with fellow team members when they see a
>    piece of code done wrong and work together to improve and and not do it
>    again.
>    7. Show them pieces of code that can help them be better and faster. I
>    made a SecureRedirect method that does a check for local urls or
>    white-listed urls. 20 lines of clean code you can plug in your system to
>    avoid no 10. But how do we make sure that method is always called?
>       1. Use specialized static analysis tools (and maybe demo that).
>       Unfortunately most teams won't do it as it's too much trouble or too
>       complicated or too intrusive on their processes.
>       2. Ctrl+Shift+F (Find All in Files) or Find References (to the
>       original Redirect). It takes 2 minutes before a release. If you find
>       someone used the wrong method do and work with them (see point 6) and fix
>       it together. The team will improve together over time.
> And more importantly, make it fun. Show cats through demos. The work well.
> E.g. An CSRF goes great when you show some cats and the click is an attack
> in the background. Tell war stories about stuff that you found or famous
> bugs. E.g. The Sammy is my hero attack on MySpace or other famous attacks.
> People love stories and they teach them more then your demo.
> My training was about 5h only but I think that's enough for OWASP for .Net
> as some of the attacks are not directly impacting .Net developers.
> I'm now working to add 3h extra for other security related training
> specific for .Net developers mostly around how to secure SQL Server and how
> to do secure deployments.
> Enjoy,
> Corneliu.
> On Sun, Jun 30, 2013 at 12:58 AM, Norman Yue <norman.yue at owasp.org> wrote:
>> Hey all,
>> I've noticed the list is generally a bit quiet, so I'm going to start
>> adding content. Feel free to do the same if you come across some
>> interesting stuff!
>> Recently, I had the opportunity to lead a small workshop. Usually,
>> workshops of this sort would go for a day or so, and cover the OWASP Top
>> 10. This time, I tried something different - instead of talking about the
>> Top 10 and the difference between dom-based and reflected xss, I showed
>> people how awesome it was to put '">lolol; into all their web app fields.
>> To cut a long story short, it seemed to work (and no-one seemed to want to
>> jump out of a window by the day's end).
>> It got me thinking - have we been doing it wrong all this time, by
>> talking to developers about the OWASP Top 10 (all the training
>> courses/workshops I've seen, especially run by security consulting firms,
>> follow this approach), but not equipping developers with the
>> tools/confidence to actually identify these vulnerabilities in their own
>> web apps?
>> Does anyone else take this kind of approach when it comes to web app
>> security training/workshops/etc?
>> Does anyone have any thoughts on how to make learning about web app
>> security more engaging, especially from a developer's pov?
>> What do you guys think is more important from a practical standpoint,
>> helping people build more secure web apps?
>> Discussion welcome etc :)
>> Norman
>> PS. Building a firefox pentesting plugin that's built around the
>> principle of quickly and easily identifying low-hanging fruit and
>> presenting the information in a useful manner, ping me if you have any
>> ideas.
>> PPS. Surely you guys have some cool projects in the works that you'd
>> totally like to talk about at the next owasp meetup, right? *wink wink
>> nudge nudge*
>> _______________________________________________
>> Owasp-sydney mailing list
>> Owasp-sydney at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-sydney
> _______________________________________________
> Owasp-sydney mailing list
> Owasp-sydney at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-sydney
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-sydney/attachments/20130705/688b5dce/attachment.html>

More information about the Owasp-sydney mailing list