It’s been a long while since I posted a webappsec survey, Oct 2007. So leading up to BlackHat seemed like an opportune time to hear from the community what they think about the hot button topics of the day. The questions are designed to expose various aspects of web application security industry we previously didn't know, understand, or fully appreciate – and maybe learn a thing or two about our peers in the process. As always the more people who submit data, the more representative it will be, and that means please share the link. All the past surveys have been quite revealing.
TAKE THE SURVEY
Guidelines
- Open to anyone working in, around, or near the web application security field.
- If a question doesn’t apply to you or you don’t want to answer, leave it blank.
- Comments in relation to any question are welcome. All data will be published.
- Submissions must be received by July 25, 2008 (1 week), results posted shortly thereafter.
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.
Friday, July 18, 2008
Tuesday, July 15, 2008
0wN3d by 5 characters
RSnake: My number one problem with WAFs is they don't protect against _all_ the vulns.
Jeremiah: Sure, but secure code doesn't fix all the vulns eitehr
RSnake: Depends on _how_ secure! I could easily create a peice of code that was 100% secure. You wouldn't find it fun to interact with, but it would be secure.
Jeremiah: while (1) { exit; }
RSnake: Sure, if you want to get crazy. I was thinking: exit;
Jeremiah: dammit, 5 characters.
RSnake: I rule
Jeremiah: Sure, but secure code doesn't fix all the vulns eitehr
RSnake: Depends on _how_ secure! I could easily create a peice of code that was 100% secure. You wouldn't find it fun to interact with, but it would be secure.
Jeremiah: while (1) { exit; }
RSnake: Sure, if you want to get crazy. I was thinking: exit;
Jeremiah: dammit, 5 characters.
RSnake: I rule
Sunday, July 13, 2008
Roxer - still the easiest way to make a web page
Jer Blog Roxer:
It’s been several months since I’ve written about Roxer. Currently Lex does all the coding since I’m investing just about every waking moment at WhiteHat. Primarily I help on Roxer strategy and solve extremely difficult JavaScript problems. Since the beginning we’ve been completely enthralled in the types of pages users build and the features they ask for. Iterative development is a lot of fun as is prioritizing enhancements into buckets that draw a crowd, improving the user experience, and keep people coming back. Astonishingly we’re up over 13,000 users, not bad for near-zero marketing, and that’s if you count my single blog post. :)
Its really cool seeing people from all over the world using something you’ve built. Actually we think over half of our users are outside the U.S. Teachers are posting classroom curriculum. Students are making online book reports. Bands are creating their online presence. Gamers are creating fan pages. And of course there is some other stuff in there we have to remove from time to time that’s’ not PG-13 rated. :) A lot is being published and its become impossible for even us to track.
Our next challenge is trying figure out a business model that makes sense. Fortunately though since everything is so darn cheap to run on the Amazon cloud platform we haven’t really felt pressured to do so, focused more on product and kept the service free. Premium subscription pricing seems to be the way we’ll go, much more attractive than advertising, but we’ll probably try that to. Maybe I’ll post again when we hit 50K users, that’ll be something!
It’s been several months since I’ve written about Roxer. Currently Lex does all the coding since I’m investing just about every waking moment at WhiteHat. Primarily I help on Roxer strategy and solve extremely difficult JavaScript problems. Since the beginning we’ve been completely enthralled in the types of pages users build and the features they ask for. Iterative development is a lot of fun as is prioritizing enhancements into buckets that draw a crowd, improving the user experience, and keep people coming back. Astonishingly we’re up over 13,000 users, not bad for near-zero marketing, and that’s if you count my single blog post. :)
Its really cool seeing people from all over the world using something you’ve built. Actually we think over half of our users are outside the U.S. Teachers are posting classroom curriculum. Students are making online book reports. Bands are creating their online presence. Gamers are creating fan pages. And of course there is some other stuff in there we have to remove from time to time that’s’ not PG-13 rated. :) A lot is being published and its become impossible for even us to track.
Our next challenge is trying figure out a business model that makes sense. Fortunately though since everything is so darn cheap to run on the Amazon cloud platform we haven’t really felt pressured to do so, focused more on product and kept the service free. Premium subscription pricing seems to be the way we’ll go, much more attractive than advertising, but we’ll probably try that to. Maybe I’ll post again when we hit 50K users, that’ll be something!
Monday, July 07, 2008
Some unanswered questions
Some thoughts from over the holiday weekend.
1) Is time (adding or taking away) the only defense against web application timing attacks?
2) What good is using SSL to encrypt usernames/passwords when all other sensitive data is not?
3) Who is getting fined for how much due to lack of PCI-DSS compliance?
4) If automated vulnerability scanning of an application is a test of the tools intelligence, is manual testing a test of the human's intelligence?
5) When oh when will the TCv2 finally be finished!? :)
1) Is time (adding or taking away) the only defense against web application timing attacks?
2) What good is using SSL to encrypt usernames/passwords when all other sensitive data is not?
3) Who is getting fined for how much due to lack of PCI-DSS compliance?
4) If automated vulnerability scanning of an application is a test of the tools intelligence, is manual testing a test of the human's intelligence?
5) When oh when will the TCv2 finally be finished!? :)
Web Security Specialist ~ Tenacious Hunter Needed
We're hiring, especially those want to hack into websites for a living. That's right, paid to hack. If you don't know how, that's OK because we're ready to train. If you or someone you know might be interested in the opportunity, fill out the form on the job listing page. Note: you must reside in the S.F. Bay Area or willing to relocate.
"WhiteHat Security has an amazing opportunity for the creative person itching to take a crack at poking holes in websites while on the prowl for gaping security vulnerabilities. In this role you will have access to thousands – yes, thousands – of well-known websites. Your job will be to actively root through them looking for all the ways a blackhat might use to break into a site. In this role you will master the basics of web application security and secure software engineering and learn what it takes to become a skilled hacker--an incredible launching pad for your career in the web application security industry."
"WhiteHat Security has an amazing opportunity for the creative person itching to take a crack at poking holes in websites while on the prowl for gaping security vulnerabilities. In this role you will have access to thousands – yes, thousands – of well-known websites. Your job will be to actively root through them looking for all the ways a blackhat might use to break into a site. In this role you will master the basics of web application security and secure software engineering and learn what it takes to become a skilled hacker--an incredible launching pad for your career in the web application security industry."
Thursday, July 03, 2008
Whitepaper: Vulnerability Assessment Plus Web Application Firewall (VA+WAF)
For those interested we’ve released a whitepaper on how Vulnerability Assessment Plus and Web Application Firewall (VA+WAF) function independently and collectively. We spend a few pages describing the technical fundamentals of both which many should find educational – especially on the WAF side with industry material in painfully short supply. Very few people really understand the nitty gritty details of how WAF work and deployed in the real-world. I've learned a great deal in the last couple months talking with those who have. There is a little F5 ASM marketing in the paper so beware! :) Enjoy, snippets:
“WAFs at their core are designed to separate safe Web traffic from malicious traffic before it’s received by the website. And, if an attack does find a way to sneak past a WAF, it still has the ability to prevent sensitive information from leaving the trusted network. To get a better understanding of how the technology works, it’s helpful to view a WAF’s functionality as three discrete components - policies, policy generation, and policy enforcement. Depending on the particular WAF in use, they may go about implementing each component in a number of different ways. No one particular way has proven to be the right way, as each has its pros and cons.”
“Every effective vulnerability assessment program requires a cohesive combination of people, process, and technology. Qualified people are necessary to carry out day-to-day tasks, manage the technology, and interpret the results to make them meaningful to the business. Process is required for coordinated efforts between executive management, IT Security, and software development groups to share information, prioritize vulnerability fixes, and enable organizational improvements. The right technology is essential for consistency, efficiency, and comprehensiveness. Whether an organization chooses to perform vulnerability assessments with internal resources, a consultancy, or a Software-as-a-Services vendor, the overall vulnerability program must always account for people, process, and technology. If not, the effort will cost more in time and dollars than it should. Or worse, simply not work.”
“WAFs at their core are designed to separate safe Web traffic from malicious traffic before it’s received by the website. And, if an attack does find a way to sneak past a WAF, it still has the ability to prevent sensitive information from leaving the trusted network. To get a better understanding of how the technology works, it’s helpful to view a WAF’s functionality as three discrete components - policies, policy generation, and policy enforcement. Depending on the particular WAF in use, they may go about implementing each component in a number of different ways. No one particular way has proven to be the right way, as each has its pros and cons.”
“Every effective vulnerability assessment program requires a cohesive combination of people, process, and technology. Qualified people are necessary to carry out day-to-day tasks, manage the technology, and interpret the results to make them meaningful to the business. Process is required for coordinated efforts between executive management, IT Security, and software development groups to share information, prioritize vulnerability fixes, and enable organizational improvements. The right technology is essential for consistency, efficiency, and comprehensiveness. Whether an organization chooses to perform vulnerability assessments with internal resources, a consultancy, or a Software-as-a-Services vendor, the overall vulnerability program must always account for people, process, and technology. If not, the effort will cost more in time and dollars than it should. Or worse, simply not work.”
Wednesday, July 02, 2008
PCI-DSS references the outdated OWASP Top Ten
I’m sure other people have noticed this, at least I hope so, but never mentioned it publicly. If you read PCI-DSS 1.1 section 6.5, the part that covers “Cover prevention of common coding vulnerabilities in software development processes”, you’ll notice the list is identical to that of the OWASP Top Ten 2004 while the latest version is 2007:
6.5.1 Unvalidated input
6.5.2 Broken access control (for example, malicious use of user IDs)
6.5.3 Broken authentication and session management (use of account credentials and session
cookies)
6.5.4 Cross-site scripting (XSS) attacks
6.5.5 Buffer overflows
6.5.6 Injection flaws (for example, structured query language (SQL) injection)
6.5.7 Improper error handling
6.5.8 Insecure storage
6.5.9 Denial of service
6.5.10 Insecure configuration management
I guess technically speaking anything that’s in v2007 and not v2004 you don’t have to worry about. That means you still have to code against Buffer Overflows and Application DoS, but not Malicious File Execution, Insecure Direct Object Reference, and Cross Site Request Forgery (CSRF). Ahh, fun fun. Gotta love compliance. :)
6.5.1 Unvalidated input
6.5.2 Broken access control (for example, malicious use of user IDs)
6.5.3 Broken authentication and session management (use of account credentials and session
cookies)
6.5.4 Cross-site scripting (XSS) attacks
6.5.5 Buffer overflows
6.5.6 Injection flaws (for example, structured query language (SQL) injection)
6.5.7 Improper error handling
6.5.8 Insecure storage
6.5.9 Denial of service
6.5.10 Insecure configuration management
I guess technically speaking anything that’s in v2007 and not v2004 you don’t have to worry about. That means you still have to code against Buffer Overflows and Application DoS, but not Malicious File Execution, Insecure Direct Object Reference, and Cross Site Request Forgery (CSRF). Ahh, fun fun. Gotta love compliance. :)
Web Application Security Today - Are We All Insane?
CSO magazine was kind enough to publish an opinion piece where I present a top-down view of the current state of web application security. I nervously expect a “spirited” flow of blog comments because it questions the value of certain best-practices and deeply held personal philosophies. Fortunately though our general public discourse has advanced a great deal recently and the community at large is a lot more informed of the challenges at hand. I pulled out a snippet to give a feel.
"It is unreasonable to expect publishers, enterprises and other site owners to restart and reprogram every website securely from scratch. Nor can we fix the hundreds of thousands (maybe millions) of custom Web application vulnerabilities one line at time. The very thought sounds insane to me. It would take too long (probably never finish), cost far too much (billions per year), and the bad guys are already ahead of us. Conservative estimates put the total annual IT security spend in the US at $50 billion and e-crime losses at $100 billion. We're losing two dollars for every dollar spent."
Enjoy!
"It is unreasonable to expect publishers, enterprises and other site owners to restart and reprogram every website securely from scratch. Nor can we fix the hundreds of thousands (maybe millions) of custom Web application vulnerabilities one line at time. The very thought sounds insane to me. It would take too long (probably never finish), cost far too much (billions per year), and the bad guys are already ahead of us. Conservative estimates put the total annual IT security spend in the US at $50 billion and e-crime losses at $100 billion. We're losing two dollars for every dollar spent."
Enjoy!
Thursday, June 26, 2008
Can WAFs protect against business logic flaws?
“Web Application Firewalls (WAF) are a total waste of time/money because they can’t protect against business logic flaws!,” a common theme among the few, but vocal, seriously anti-WAF zealots out there. While there is some truth it’s also like saying car door locks are useless because criminals can break in by smashing the windows. Or car alarms are a waste because they don’t protect against carjacking. And steering wheel locks are lousy because the car is at risk to thieves with tow trucks. You see where I’m going with this. Every security measure has a particular purpose, limitation, and overall value to the owner considering what it is they’re protecting.
Sure, WAFs don’t defend against every logic flaw, or even every crazy form of SQLi or XSS. Just as white/black box scanners can’t identify every vulnerability and neither can expert pen-testers or source code auditors. A/V products don’t red flag every piece of malware. Anti-spam misses some junk mail. Yet we still utilize these solutions anyway because their value outweighs their limitations. And of course WAFs don’t replace vulnerability assessment (VA) or secure coding practices just as Nessus doesn’t compete with network firewalls or good segmentation practices. Therefore I recommend we ignore rash criticisms and keep an open mind into what WAFs can/can’t do, the value they may provide today, and consider how they made be improved – including being aided by VA intelligence (VA+WAF).
I’m going to keep my comments vendor agnostic. Perhaps some of the features described below are already included in some of the available WAF products. In fact I know they are and claim no novelty of any of these ideas (probably printed elsewhere), but I’ll leave it to the vendors to comment on their specific products capabilities. I think the readers here might be pleasantly surprised. My intent here is to explore a few of the more common business logic flaw examples we’ve all seen, assume we know where their location (VA), and attempt to hypothesize defense measures.
Business Logic Flaw examples
1) Rotating numbers in URLs, the classic case of Insufficient Authentication, Insufficient Authorization and Insufficient Process Validation where an attacker can gain access to data or functionality their user-level should not have. We’ve seen these issues countless times in order tracking systems, bank account screens, and even in online vote registration. I see at least two possible ways to prevent these types of business logic flaws with a WAF.
URL encryption
The WAF inspects outbound Web page content, dynamically encrypts and replaces every URL directed to the website, and by extension decrypts them on the way back in – completely transparent to the web server or application. For example:
<* a href=”http://website/app.cgi?foo=bar”>action<* /a>
becomes…
<* a href=”http://website/06ad47d8e64bd28de537…”>action<* /a>
or
<* a href=”http://website/app.cgi?foo=bar&t=1fad47d…”>action<* /a>
URL encryption is powerful as it prevents URL parameter tampering and by extension protects against a wide range of attacks (XSS, SQLi, CSRF, etc.). No parameter tampering, no number rotation, no business logic flaw. Implementation is really tricky though because the HTML parser has to be perfect otherwise requests will be blocked when links are missed. Bookmarks and search engine indexing is also potentially disrupted. However, websites where most functionality is behind a login screen, such as banking sites, might not mind. Its also possible these side effects could be reduced by only focusing on the URLs known to be vulnerable (VA) instead of pursuing global enforcement. There is no need to encrypt URLs that aren’t vulnerable.
Session-State tracking
Users can be tracked from one page to the next so it’s technically possible for a WAF to know where they are in a particular flow and where they should be able to get to, or not. If an attacker were to rotate a number in a URL the WAF could be capable of determining if they should have been able to get it (UI-wise) from where they are. If they shouldn’t be able to, deny! Or perhaps a more forgiving threshold is in order so the may try 1, 2, or even 10 illegal URLs, but not more because that would surely be abnormal behavior. Scalability is biggest drawback here as increasingly large state tables are required for tracking. However, if you know a particular URL or parameter name has a problem with number rotation, WAFs can again be configured to focus and enforce controls only there.
2) Session hijacking by way of cookie tampering is another old school hack that has implications for Credential/Session Prediction, Insufficient Session Expiration, and Session Fixation. This issue doesn’t show up as much as it once did because most developers are using the native session handling APIs in their development frameworks as opposed to rolling their own. A very good thing.
Just like the previous example we can utilize some good ol’ on-the-fly cookie encryption/decryption that can be easily performed with a WAF. If an attacker is unable to modify their cookie to a valid value, and the WAF would know cryptographically, then session handling issues go away. You could even add some httpOnly, secure, and non-persistent flags if you want. You’d still probably have issues with Insufficient Session Expiration or Session Fixation, but we’re getting somewhere. The only drawback I can think of is if JavaScript or some other client-side language needed to read/write the original cookies values.
3) WAFs could also potentially be used to stop login brute force attacks or Insufficient Anti-Automation by including CAPTCHAs on-the-fly at various choke points. Again, thresholds would be neat. We could explore other examples, but I think you get the idea and this post is long enough. Well at least I don't want to write anymore. :)
Its important to understand that we’re at the very beginning of WAFs (or website VA for that matter), their deployments, which is also why there is so little field experience posted anywhere. We need an open community dialog so we can see where this technology can go and how it can be improved. - independent of the PCI 6.6 mandate. My point is I don’t think WAFs will be able to solve all of our web application security problems, or even all business logic flaws, and I don’t know of anyone who does. It certainly would be nice though to see what WAFs can do or be made to do. We won’t know unless we keep and open mind and try.
"Any fool can criticize, condemn, and complain, and most fools do."
Benjamin Franklin
Sure, WAFs don’t defend against every logic flaw, or even every crazy form of SQLi or XSS. Just as white/black box scanners can’t identify every vulnerability and neither can expert pen-testers or source code auditors. A/V products don’t red flag every piece of malware. Anti-spam misses some junk mail. Yet we still utilize these solutions anyway because their value outweighs their limitations. And of course WAFs don’t replace vulnerability assessment (VA) or secure coding practices just as Nessus doesn’t compete with network firewalls or good segmentation practices. Therefore I recommend we ignore rash criticisms and keep an open mind into what WAFs can/can’t do, the value they may provide today, and consider how they made be improved – including being aided by VA intelligence (VA+WAF).
I’m going to keep my comments vendor agnostic. Perhaps some of the features described below are already included in some of the available WAF products. In fact I know they are and claim no novelty of any of these ideas (probably printed elsewhere), but I’ll leave it to the vendors to comment on their specific products capabilities. I think the readers here might be pleasantly surprised. My intent here is to explore a few of the more common business logic flaw examples we’ve all seen, assume we know where their location (VA), and attempt to hypothesize defense measures.
Business Logic Flaw examples
1) Rotating numbers in URLs, the classic case of Insufficient Authentication, Insufficient Authorization and Insufficient Process Validation where an attacker can gain access to data or functionality their user-level should not have. We’ve seen these issues countless times in order tracking systems, bank account screens, and even in online vote registration. I see at least two possible ways to prevent these types of business logic flaws with a WAF.
URL encryption
The WAF inspects outbound Web page content, dynamically encrypts and replaces every URL directed to the website, and by extension decrypts them on the way back in – completely transparent to the web server or application. For example:
<* a href=”http://website/app.cgi?foo=bar”>action<* /a>
becomes…
<* a href=”http://website/06ad47d8e64bd28de537…”>action<* /a>
or
<* a href=”http://website/app.cgi?foo=bar&t=1fad47d…”>action<* /a>
URL encryption is powerful as it prevents URL parameter tampering and by extension protects against a wide range of attacks (XSS, SQLi, CSRF, etc.). No parameter tampering, no number rotation, no business logic flaw. Implementation is really tricky though because the HTML parser has to be perfect otherwise requests will be blocked when links are missed. Bookmarks and search engine indexing is also potentially disrupted. However, websites where most functionality is behind a login screen, such as banking sites, might not mind. Its also possible these side effects could be reduced by only focusing on the URLs known to be vulnerable (VA) instead of pursuing global enforcement. There is no need to encrypt URLs that aren’t vulnerable.
Session-State tracking
Users can be tracked from one page to the next so it’s technically possible for a WAF to know where they are in a particular flow and where they should be able to get to, or not. If an attacker were to rotate a number in a URL the WAF could be capable of determining if they should have been able to get it (UI-wise) from where they are. If they shouldn’t be able to, deny! Or perhaps a more forgiving threshold is in order so the may try 1, 2, or even 10 illegal URLs, but not more because that would surely be abnormal behavior. Scalability is biggest drawback here as increasingly large state tables are required for tracking. However, if you know a particular URL or parameter name has a problem with number rotation, WAFs can again be configured to focus and enforce controls only there.
2) Session hijacking by way of cookie tampering is another old school hack that has implications for Credential/Session Prediction, Insufficient Session Expiration, and Session Fixation. This issue doesn’t show up as much as it once did because most developers are using the native session handling APIs in their development frameworks as opposed to rolling their own. A very good thing.
Just like the previous example we can utilize some good ol’ on-the-fly cookie encryption/decryption that can be easily performed with a WAF. If an attacker is unable to modify their cookie to a valid value, and the WAF would know cryptographically, then session handling issues go away. You could even add some httpOnly, secure, and non-persistent flags if you want. You’d still probably have issues with Insufficient Session Expiration or Session Fixation, but we’re getting somewhere. The only drawback I can think of is if JavaScript or some other client-side language needed to read/write the original cookies values.
3) WAFs could also potentially be used to stop login brute force attacks or Insufficient Anti-Automation by including CAPTCHAs on-the-fly at various choke points. Again, thresholds would be neat. We could explore other examples, but I think you get the idea and this post is long enough. Well at least I don't want to write anymore. :)
Its important to understand that we’re at the very beginning of WAFs (or website VA for that matter), their deployments, which is also why there is so little field experience posted anywhere. We need an open community dialog so we can see where this technology can go and how it can be improved. - independent of the PCI 6.6 mandate. My point is I don’t think WAFs will be able to solve all of our web application security problems, or even all business logic flaws, and I don’t know of anyone who does. It certainly would be nice though to see what WAFs can do or be made to do. We won’t know unless we keep and open mind and try.
"Any fool can criticize, condemn, and complain, and most fools do."
Benjamin Franklin
Subscribe to:
Posts (Atom)
