views:

246

answers:

8

This is a shameless information gathering exercise for my own book.

One of the talks I give in the community is an introduction to web site vulnerabilities. Usually during the talk I can see at least two members of the audience go very pale; and this is basic stuff, Cross Site Scripting, SQL Injection, Information Leakage, Cross Site Form Requests and so on.

So, if you can think back to being one, as a beginning web developer (be it ASP.NET or not) what do you feel would be useful information about web security and how to develop securely? I will already be covering the OWASP Top Ten

(And yes this means stackoverflow will be in the acknowledgements list if someone comes up with something I haven't thought of yet!)

It's all done now, and published, thank you all for your responses

+1  A: 

Defensive programming as an archetypal topic which covers all the particular attacks, as most, if not all, of them are caused by not thinking defensively enough.

Make that subject the central column of the book . What would've served me well back then was knowing about techniques to never trust anything, not just one stop tips, like "do not allow SQL comments or special chars in your input".

Another interesting thing I'd love to have learned earlier is how to actually test for them.

Vinko Vrsalovic
+4  A: 

First, I would point out the insecurities of the web in a way that makes them accesible to people for whom developing with security in mind may (unfortunately) be a new concept. For example, show them how to intercept an HTTP header and implement an XSS attack. The reason you want to show them the attacks is so they themselves have a better idea of what they're defending against. Talking about security beyond that is great, but without understanding the type of attack they're meant to thwart, it will be hard for them to accurately "test" their systems for security. Once they can test for security by trying to intercept messages, spoof headers, etc. then they at least know if whatever security they're trying to implement is working or not. You can teach them whatever methods you want for implementing that security with confidence, knowing if they get it wrong, they will actually know about it because it will fail the security tests you showed them to try.

devinmoore
Actually that's pretty much where I'm going (so thanks for confirming I'm on the right route). The first real chapter will be an introduction to fiddler *grin* Each chapter will start with "Here's some code, here's the attack, here's the formal name", then a discussion and how to correct it.
blowdart
A: 

Foxes

Jeff
Arf; but it's .net, not ruby, so I must use armadillos.
blowdart
+1  A: 

I think all vulnerabilities are based off of programmers not thinking, either momentary lapses of judgement, or something they haven't thought of. One big vulnerability that was in an application that I was tasked to "fix up", was the fact that they had returned 0 (Zero) from the authentication method when the user that was logging in was an administrator. Because of the fact that the variable was initialized originally as 0, if any issues happened such as the database being down, which caused it to throw an exception. The variable would never be set to the proper "security code" and the user would then have admin access to the site. Absolutely horrible thought went into that process. So, that brings me to a major security concept; Never set the initial value of a variable representing a "security level" or anything of that sort, to something that represents total god control of the site. Better yet, use existing libraries out there that have gone through the fire of being used in massive amounts of production environments for a long period of time.

stephenbayer
+1  A: 

I would like to see how ASP.NET security is different from ASP Classic security.

Jason Baker
Hmm that's interesting considering classic ASP had very little *grin*
blowdart
Back in the days we had HtmlEncode in ASP classic. We didn't use it, but is was there :-)
Steven
A: 

Good to hear that you will have the OWASP Top Ten. Why not also include coverage of the SANS/CWE Top 25 Programming mistakes.

jm04469
Because I only have 200-350 pages. I want it as a gentle introduction and kept reasonably generic. Plus the SANS mistakes duplicate themselves a lot, and aren't web specific.
blowdart
A: 

I always try to show the worst-case scenario on things that might go wrong. For instance on how a cross-site script injection can work as a black-box attack that even works on pages in the application that a hacker can’t access himself or how even an SQL injection can work as a black box and how a hacker can steal your sensitive business data, even when your website connects to your database with a normal non-privileged login account.

Steven
"It's all done now, and published, thank you all for your responses". Oeps.. a bit late I was :-)
Steven
A: 

How to make sure your security method is scalable with SQL Server. Especially how to avoid having SQL Server serialize requests from multiple users because they all connect with the same ID...

R.MacLean