4 ms·
Totally agreed on everything! Let's do the HN Top 10. my suggestions (in no particular order): SQL injection, XSS, CSRF, force browsing, improper authorizatio
by daeken 14y ago
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?
- tptacek 14y agoMy 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.
- tedunangst 14y agoI 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.
- rdl 14y agoObviously 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).