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

Corneliu I. Tusnea corneliu at acorns.com.au
Tue Jul 2 11:25:28 UTC 2013


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-sydney/attachments/20130702/171756d7/attachment.html>


More information about the Owasp-sydney mailing list