[Owasp-sydney] The Top 10, Developers, and You.
Corneliu I. Tusnea
corneliu at acorns.com.au
Tue Jul 2 11:25:28 UTC 2013
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
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
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
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.
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 :)
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Owasp-sydney