Web Application Security Professionals Survey (Jan. 2007)

Update 01/18/2007
The results are in and the people have spoken! Our goal was to capture the “thoughts” of the crowd and boy did it ever! The 59 (4 less than Dec 06) respondents shared their battleground views of web application security and in doing so presented interesting perspectives and great insights of a larger world. There is a huge amount of data inside and I couldn’t be more pleased with the results. We also unexpectedly created a database of the most popular vulnerability assessment tools and knowledge resources. Thank you to everyone who took the time to submit.

My Observations

1. Most already predicted 2007 as the year of XSS, CSRF, and Web Worms. The survey validates this message. (Q5) (Q13) (Q15) Virtually all those who are webappsec savvy say the vast majority websites have serious security vulnerabilities (Q6), web browser security sucks (Q10), and believe most security professionals don’t realize it or understand why (Q4). Clearly we have some challenges ahead.
2. An uncanny number of people identically answered “My Brain” as their top tool for finding vulnerabilities (Q12). Unsurprisingly the open source proxies are among the most popular software in the webappsec arsenal. And we have some real characters in the crowd that’s for sure. (Q14)
3. Half of the web application security community has a background in software development (me too) and the other half is IT/NetworkSec (Q3). This is an interesting pairing as traditionally these two groups never really had cause to communicate with one another, let alone forced to work together. Such is the state of web application security. This is probably an unpopular opinion, but software developers seem to have a hard time respecting any solution beyond the code. While IT/NetworkSec types understand the best results come from a collection of risk mitigating solutions. We all should try to keep an open mind when new concepts and ideas arrive.
4. There is split between how people view the impact or involvement of Ajax technology on website security (Q8). Half say Ajax opens some new attack vectors; the other side says it increases the attack surface. I’m of the opinion the Ajax In-Security discussion has more to do with a semantic debate rather than a misunderstanding of the technology. This is fine when we speak amongst ourselves in the webappsec community, but it causes a lot of confusion for those outside circle seeking education.
5. People are cautiously optimistic of web application firewalls (Q9). Stopping attacks without having to fix the code certainly has its allure. To say nothing of the prospects of defense-in-depth. There are many out there though who’ve been soured by a bad experiences with crappy and/or older WAFs.

Its official, RSnake’s blog is the most popular place among the webappsec crowd (Q11). *applause* He’ll be making an appearance at the WASC meet-up during RSA to sign autographs. *grin*

Description
This monthly survey has become a really fun project. It's receiving great reviews and right when you think you know something, the answers to a couple questions reveal something unexpected. That's what we're really going for here. Exposing various aspects of web application security we previously didn't know, understand, or fully appreciate. From the last survey people said really enjoyed the "thoughts" from the crowd in the bonus question. We'll try to capture more of those this time around.

As always, the more people who submit data, the better the information will be. Please feel free to forward this email along to anyone that might not have seen it.

Guidelines

• Survey is open to anyone working in or around the web application security field
• Answer the questions in-line and if a question doesn’t apply to you, leave it blank
• Comments in relation to any question are welcome. If they are good, they may be published
• Email results to jeremiah __at__ whitehatsec.com
• To curb fake submissions please use your real name, preferably from your employers domain
• Submissions must be received by January 17, 2007

Publishing & Privacy Policy

• Results based on aggregate data collected will be published
• Absolutely no names or contact information will be released to anyone, though feel free to self publish your answers anywhere you’d like

Last Survey Results
December 2006


Questions

1) What type of organization do you work for?

a) Security vendor / consultant (60%)
b) Enterprise (9%)
c) Government (9%)
d) Educational institution (5%)
e) Other (14%)
No Answer (2%)

• Agribusiness
• My own webdevelopment company.
• Health Care
• I'm not telling. It's a publicly-held company, though.
• Independant research and training
• I work for none right now.

2) How would you rate your technical expertise in web application security?

a) Guru (21%)
b) Expert (47%)
c) Intermediate (28%)
d) Novice (2%)
e) I am Nessus (0%)
No Answer (2%)

• Homestar says, "sewiousleeeee!"

3) What was your background before entering the web application security field?

a) Software Development (53%)
b) IT (16%)
c) QA (0%)
d) Product/Project Management (2%)
e) I'll never tell! (2%)
f) Other (please specify) (23%)
No Answer (2%)

• technical sales in IT security
• Penetration Tester
• Information System Auditor
• Network Penetration Testing
• Network Security Engineer
• New Hampshire mafia hitman/enforcer
• An Electrical Engineering major, which i still am
• Professional slacker/self taught
• Before I started with the webappsec stuff I was a apprentice and there I had much to do with web development/design and IT at all.

4) From your experience, how many security professionals "get" web application security?


a) All or almost all (0%)
b) Most (19%)
c) About half (26%)
d) Some (49%)
e) None or very few (7%)

• "To my experience the traditional "network security" guys still see WebAppSec as primarily a pet project or an oddity, at least in the government space. For example I am the only full time app sec engineer for a agency of about 8,000. If i had a staff of 10 we would still keep busy. "
• "Most get web, since that's half of what the internet is (the other half is email). It's everything beyond the web that they don't get."

5) What are your thoughts about the Universal XSS vulnerability in Adobe’s Acrobat Reader Plugin?

a) Really bad (53%)
b) Bad (37%)
c) Never heard of it (2%)
d) Nothing new here, move along (5%)
e) Please stop with the FUD! (2%)

• "It is certainly bad. Especially the bit with local file system access. But like all XSS vulnerabilities they have a high exploitability potential they are not that difficult to individually remediate (systematically is a whole different ball of wax)."
• "What is really bad is the recommendations going around about how to fix this. Telling people to "upgrade their Acrobat" isn't the way to protect users NOW. Additionally, half the recommendations don't even account for the fact the information after a # sign in a URL is NOT sent back to the server, so the server side URL filtering jive isn't going to fix anything when it boils down to PDFs. In fact, this vulnerability is similar to just entering in "javascript:alert('xss')" in the address field of the browser -- the script runs, but it obviously would not be mitigated by running server side validation. The best approach I've seen is to change the MIME type sent back from the server from "pdf/application" to "pdf/octet" and also to add a "Content-Disposition: Attachment" header for outbound PDFs which prompts the user to download the PDF rather than running it in the browser."
• "truly the best candidate for the most widespread worm to utilize"
• "(I think its bad, and was a great find for 07. Really surprised it wasn't found any sooner)"

6) During your web application vulnerability assessments, how many websites where that DID NOT have at least one relatively severe vulnerability?


a) All or almost all (2%)
b) Most (2%)
c) About half (2%)
d) Some (19%)
e) None or very few (74%)



7) What's your preferred acronym for Cross Site Request Forgery?


a) CSRF (58%)
b) XSRF (19%)
c) Neither, I prefer Session Riding (7%)
d) No preference (16%)

• "Sea Surf!!!"
• "We really need to stop using Cross Site for EVERYTHING."
• "I don't care, though I like to say "sea-surf," I use "XSRF" in documentation because it is more consistent with XSS."
• "After much gnashing of teeth over this question I had to come down on the side of the term that I believe best describes the attack. Plus, people will never agree on whether to use "C" or "X", so why not eliminate that problem? (fwiw, I prefer XSRF over CSRF just so it's consistent with XSS)"
• "...how about one click attack?"

8) Does using Ajax technology open up new website attacks?

a) Yes (9%)
b) Yes, it adds some new things (35%)
c) No, but it increases the attacks surface (40%)
d) Nothing new here, move along (5%)
e) Other (9%)
No Answer (2%)

• "Sorta. It makes developers more prone to make mistakes while the "attack surface" isn't really that much bigger the likleyhood of some of the same or old issues is greater. For example i find that AJAX developers have i higher tendency to use client side validation only. Not making the realization that AJAX is just like form submission just with a slicker front end. A POST is a POST people!"
• "People extending their website to use AJAX does provide new potential entry points, I don't see how anyone can deny that. But using AJAX to create a complex attack could be done without AJAX using images to create GET requests and iframes to create POST requests."
• "It's something that would otherwise be done server-side by PHP/ASP and thus closed source - so developers lose their security through obscurity."
• "I think it will eventually, possibly as applications provide more features in order be used offline and with caching features. Innovation in this area (and thus new forms of attacks) are mainly coming from startups and non-enterprise companies, most of who do not have a process or funds for proper web application testing."
• "It can increase the attack surface, but more importantly, Ajax technologies are being used to create better exploits. Focusing on whether using Ajax technologies creates new vulnerabilities is causing many people to look the wrong way when crossing the road."
• "Adds more attack surface, and doesn't give you any new vuln types, but it does expose more general application logic/architecture nuances which an attacker could use to better infer inner app workings (and thus problem areas)."

9) Your recommendation about using web application firewalls?


a) Two thumbs up (21%)
b) One thumb up (47%)
c) Thumbs down (12%)
d) Profane gesture (9%)
No Answer (5%)

• "modsecurity has saved me from several stupid bugs in third-party stuff"
• "Obfuscation rules all firewall/ids. They sure do make alot of money for vendors tho. Spend it on secure software practices and training instead."
• "I think it can add a layer of defense, but certainly does not fix the problem in our testing."
• "In any for-profit business, it certainly makes financial sense to use them. The depth of defense they add far outweighs the setup cost and power usage."
• "Most seem to be best used only as a learning tool to help you find how they can be improved and/or how your skills at detecting such attacks can happen and how you can prevent them from happening before turning to a firewall for protection."
• "for now they are not so useful. During my security audits I developed some hacker methods to evade webapp firewalls (mod_security in particular) and I plan to write an article about it. They need to be improved."
• "oh look this IDS will protect me against 0hday, oh shit wait we've just lost our file server due to RPC what?"
• "I'm some what neutral on this. I think they can add to a defense in depth posture, but in most cases, time and resources are better spent going back up to the application level and training developers on how to write secure code, or by performing code reviews and blackbox testing. I may recommend these more as they become more advance and mature, but my experience is that they are not yet the best way to spend your resources."
• "Up what? ;)"
• "Unfortunately, many tend to assume WAF can fix bad code, but they cannot. Also, many think WAF alone are a sufficient counter measure to vulnerable and badly designed web applications, and they are not."

10) How would describe the current state of web browser security?


a) Rock solid (2%)
b) Could be better (51%)
c) Swiss cheese, fix it! (44%)
No Answer (2%)

• "While browsers facilitate some web based attacks they really aren't to blame for a bunch of things. App developers should be responsible for their own work and not rely on browsers for their security. Anytime you "outsource" your security model is just asking for trouble."
• "is there even any cheese left anymore? all i see is holes.."
• "browsers are the least secure, most dangerous software we use, due primarily to the execution of "content-controlled" code. It will be a "big deal" for computer security as a whole if we manage to secure this platform."
• "Things are in a pretty bad and scary state. "the browser is the operating system" so maybe there's no way to avoid it, but the frequency and number of vulnerabilities should be much lower for such a critical piece of software."
• "The amount of functionality the average user expects of its web browser has increased remarkably along the past years. As a result, vendors made it more easy to extend the functionality of their products by use of third party software. Unfortunately, most of these have never been sufficiently reviewed from a security perspective. And, being vulnerable to security issues which have been long fixed in the core products, they reintroduce just these and taint the security level of the entire product. As long as plugins and widespread extensions reintroduce vulnerabilities into the commonly used web browsers, and they are widely used, the security of plain web browsers do not matter much."

11) Name your Top 3 web application security resources.
(Listed in order of popularity)
RSnake's Blog
OWASP
Jeremiah Grossman's Blog
The Web Security Mailing List
sla.ckers.org forum
Web Application Security Consortium
Security Focus Web Application Security List
GNUCITIZEN
cgisecuritySecurity Focus
Hacking Exposed Web Applications, 2nd Edition (Joel Scambray, Mike Shema, Caleb Sima)
Full Disclosure
Google
BugTraq
XSS (Cross Site Scripting) Cheat Sheet
SecuniaSylvan von Stuppe
BlackHat
Schneier on Security
PaulDotCom
Professional Pen Testing for Web Applications (Andres Andreu)
del.icio.us (webapp security)
FrSIRT
IEEE S&P
OSSTMM
(IN)SECURE Magazine
Software Security (Gary McGraw)
19 Deadly Sins of Software Security -(Michael Howard, David LeBlanc, John Viega)
SecuriTeam
qasec
WhiteHat Security
http://www.security.nnov.ru
Web Security Threat Classification
http://www.securityfocus.com/archive/107
How to Break Web Software (Mike Andrews, James A. Whittaker)
Microsoft
Security Focus Penetration Testing
SearchAppSecurity
National Vulnerability Database
ComputerWorld
Safari Bookshelf

12) What are your Top 3 tools to find vulnerabilities in websites? (NO BROWSERS!)
(Listed in order of popularity)

• Paros
• Burp Suite
• By Hand / My Brain
• Proprietary Tools
• Nikto
• WebScarab
• Web Developer Toolbar
• WebInspect / SPI Proxy
• Tamper Data
• CLI-based HTTP tools (wget, curl, netcat, lynx, links, elinks, LWP, etc)
• Fiddler
• Watchfire AppScan
• Firebug
• Nessus
• RSnake's XSS Cheat Sheet
• Watchfire HTTP Proxy
• Achilles
• nmap
• Grabber
• Acunetix
• XSS Assistant
• Live HTTP Headers
• Ruby
• Fierce
• RFuzz
• CAL9000
• HTMangLe
• Cenzic Hailstorm
• Sensepost Crowbar
• ISS
• Wireshark
• AnEC
• Ethereal
• Perl
• Wikto

13) What are the Top 3 types of website attacks we're most likely to see a lot more of in 2007?
(Listed in order of popularity)

• Cross-Site Scripting
• Cross-Site Requests Forgery
• Web Worms
• XSS-Phishing (Phishing w/ Superbait)
• SQL Injection
• Web Services / XML Injection
• Ajax-based Attacks
• Logical Flaws
• UXSS
• Unknown Issues
• Denial of Service
• PHP Includes
• Browser Plug-in / Extension Hacking
• Exponential XSS
• Backdooring Media Files
• "chrome" attacks
• internationalization and charsets
• Privilege Escalation
• Authentication attacks
• Session Hi-Jacking
• Mobile Code (Flash/Java)
• Configuration issues

14) What was your information security New Year's resolution?

• Less projects, more quality
• To spend more time with my wife and less time thinking about security.
• Finding vulnerabilities in FireFox
• Start own research in a particular web app sec area.
• Get a job doing WAVA full-time (no other hats or VA work)
• 1024x768 ;-)
• Learn to demonstrate exploits.
• To say important things. If developers don't listen, it's the fault of WSJ for not defiling enough companies.
• Start working in a security company?
• White-list sites with JavaScript execution permissions
• Blog more. (is that infosec related? Blogging on infosec topics...)
• Become more involved (less of a lurker) in the web app security area.
• More champaign while doing assessments!
• Dang, go to defcon, toorcon again. Do more R + D, do some posting to the lists (I never do historically).
• Continiue the learning process.
• Keep the OWASP Kansas City chapter active and involved.
• Be better than I was last year.
• http://www.cgisecurity.com/2006/12/07
• CISSP Certification?
• To give back to the field more than i extract. i.e. to come up with new ideas or improve upon existing ones more than i learn from others' research.
• I didn't make one. I slept through New years as well.
• Not to make any more resolutions
• Research more.
• The last year was very interesting in security field and the new 2007 year
• will be also interesting and hot. There are very small amount of site which
• were security audit and every day new sites appear. So there are a lot of
• sites to look at their security
• Finally understand that after doing this since 1998, clients won't learn, it won't save the world and getting old makes you more cynical
• All your web 2.0 are belong to us ;)
• Locate at least one huge issue that wakes up the browser community out of their web application security slumber.
• Work to bring more education, awareness, and training to more developers
• and a wider audience than our standard security community.
• never do blacklisting, white listing save life
• Educate developers
• Be up to date and do more research.
• Build more tools and share knowledge - have fun :)
• Get better
• Get certified (QDSP, QPASP)
• I will not get 0wn3d.
• The booze.

15) What's the first thing you have or plan to learn/research/try/code/write in 2007?

• XSS/CSRF combo attacks
• Adding embedded Ruby support to a popular hex editor to make it the Emacs of reverse engineering.
• Universal XSS Worm, but only as a PoC and personal information gain.
• SANS course in forensics.
• Attend my local OWASP meeting
• Convince my Bose to provide more training
• A better web goat bank than web goat bank,
• Hopefully, a JavaScript functional analyzer?
• Soon to be released to the public ...
• Wish I could -- no time. Will be busy doing nothing but risk assessments on campus. Know the techniques and technologies, but I don't spent enough day-to-day doing them so I need to get more hands-on time which I should be getting.
• Researching possible vulnerabilities within the .NET Framework.
• Wrote an exploit for the UPDFXSS to scare the crap outta some execs. FUD is good for my paycheck!
• Neato stuff, I prefer to keep it a secret. I'll just say it has to do with automated attacks.
• Learn security weaknesses of web services and SOA architecture.
• .net framework 3.0 object model weaknesses
• Either a game server in PHP (not real time obviously) or a CMS built from the ground up with security and extensibility in mind.
• UIML's and fuzzers
• CISSP Certification and study up on IPS/IDS
• Intranet hacking using Google Desktop Search
• I plan learn more about buffer overflows and test for them as well as finding more ways to improve basic application errors and tactics for doing so. I will focus more on stand alone applications and less on webapp security maybe too but it all depends on
• Complete a VMWare lab for Web Application testing
• New trojan horse techniques.
• For some time already I am planning to write my own security scanner (with unique features and functionality). And I plan to developed also web version (online web security scanner), and maybe just single web version.
• I'm retiring and leaving security :0)
• Play with XSS
• Working on my webapp risk metrics and some other paperwork stuff in this field.
• I've been thinking about interesting ways to do active detection and filtering of malicious traffic.
• Working on ways to alert, help, and guide Ruby on Rails developers to write secure code.
• too many to list,....how abt inventing new way to prevent webapps ... something like integration of code review and webapp firewall.
• anti-dns pinning
• Threat modeling
• I want to code some assessment tool for firefox in xul.
• Utility to crawl Ajax driven applications, seems interesting.
• DNS pinning
• Putting (ASP).NET under the microscope.
• Not sure, I'll tell you when it's done.