Hacker News new | comments | show | ask | jobs | submit login

I wonder if we should tighten that first recommendation up: learn C before you learn Ruby or Python.

I've had a lot of trouble bringing people into C that have a strong background in (say) Python, but I don't remember C being all that hard for me --- but that might be because I didn't have any other options, besides Borland Turbo C, when I was getting started.

Also: wow do I hate the OWASP Top 10. Can we just rattle off an HN Top 10 right here? It'll be better.




Totally agreed on everything! Let's do the HN Top 10. my suggestions (in no particular order): SQL injection, XSS, CSRF, force browsing, improper authorization, command injection, arbitrary file reads/writes, remote file inclusion. What else?


My list:

1. DOM Corruption / Javascript Injection

2. CSRF / Clickjacking / Reframing

3. SQL / db-metacharacter Injection

4. Authorization/Forced-Browsing

5. Unauthenticated Encryption and Bad Block Cipher Mode Handling

6. Filesystem/Backend Storage Path Sanitization

7. Exposed Admin/Diagnostic Functionality

8. Memory Corruption Vulnerabilities in Native Code Extensions (cext gems, &c)

9. Shell-out Command Injection

10. Insecure Password Hashes

I feel like mass assignment, resource exhaustion, filter return code mistakes, and wildcard routes all belong somewhere, but they feel too Rails-y for a generic list.


I would love at some point to hear your thoughts on CSRF/clickjacking/etc. From a traditional security background, "validate all input" goes a long way towards making a program secure. But web apps have this little thing called the browser actively conspiring against you. All the inputs are valid in a traditional sense.

Imagine if someone said to write a secure program for some computer. But, btw, there's going to be an attacker logged in via VNC at all times you'll need to defend against. I'd just throw up my hands and walk away.


Obviously this is all appsec. It would be interesting to do a consolidated appsec/infrastructure list, with (obviously you need to do all of them, but there are some infrastructure items which cause security and availability issues, and are thus likely to be exposed even before you are attacked).




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: