The PCI Security Standards Council's (PCI-SSC) recently published March Assessor Newsletter, which contains rather "interesting" language for certain Approved Scanning Vendors (ASV). It is unclear what the penalty will be for firms who continue their misleading practices. For those curious, WhiteHat Security was once an ASV, but has not been for over a year -- largely because we already understood the following requirements. We actually do focus on 6.6 to the spirit in which its supposed to be applied, while the others pay lip service and take customers for a ride.
ASV: I'm a lawyer so let me be your heart surgeon
Several ASVs have received notices recently surrounding the marketing of services they sell related to being qualified by the Council. While the PCI SSC does qualify each and every ASV to conduct external vulnerability scans to meet the external scan validation requirement for PCI DSS 11.2, it does not give any ASV license to sell their services for other security practices as an agent of the PCI Council.
Here are two examples that are unacceptable and violate the ASVs contract:
1. "As an ASV, our company has been certified by the PCI Council for you to achieve both Requirement 11.2 for vulnerability scanning and Requirement 6.6
There are two issues with the above statement. First, and this is a common mistake, ASVs do not help merchants fully achieve DSS Requirement 11.2. The requirement requires both internal vulnerability scanning and external vulnerability scanning. The Council only qualifies ASVs to perform the second half of that statement. Although an ASV can separately offer internal vulnerability scanning services, internal vulnerability scanning is a) not required to be done by an ASV and b) is not part of the ASV qualification process by the Council. We clarified this with a note in the 1.2 release of the PCI DSS and possibly further clarity to come October 2010. The second and more egregious is related to using a conjunction (YouTube "School House Rock" if you need a refresher on the function of a conjunction) to include another service completely unrelated to anything that has been validated by the PCI Council. In this case, there is no program to validate those who review adherence with Requirement 6.6 and the ASV lab testing is not an exhaustive process to endorse any solution as an exhaustive annual evaluation of the web application security. for application scanning."
Wednesday, March 17, 2010
Friday, March 12, 2010
Best of Application Security (Friday, Mar. 12)
Ten of Application Security industry's coolest, most interesting, important, and entertaining links from the past week -- in no particular order.
- Bypassing CSRF protections with ClickJacking and HTTP Parameter Pollution
- Three Steps to a Rational Security Budget
- Hackvertor and JSReg
- Multiple DOM-Based XSS in Dojo Toolkit SDK
- Weak security ID questions put e-mail at risk
- XSS demo for stealing passwords from the Firefox password manager
- ...because you can't get enough of clickjacking
- A gentle introduction to return-oriented programming
- Facebook Adds Code for Clickjacking Prevention
- Notes Richard Bejtlich OWASP Podcast
Password Managers, is this the best option user’s have?
Before reading the following, ask yourself if you’d recommend to the average user that they store their passwords in a local password manager.
Today there are four primary ways users lose control over their web-based passwords. Phishing Scams (email or SEO), Malware (installing malware or drive-by-downloads), website break-ins (SQLi, RFI, misconfiguration, etc.), and website brute-force attacks. For a user to protect themselves I’ve outlined the client-side technologies they can deploy (reason MFA is left out) and possible changes in their online behavior.
Phishing Scams (user hands over their passwords)
Client-side technology solution(s): Web browser security add-ons and anti-email-spam tools.
Behavior: Tell the difference between real/fake and safe/dangerous websites & emails using available visual indicators.
Outcome: The technology is not consistently effective and users are unable to reliably make accurate real/fake or safe/dangerous decisions.
Malware (passwords stolen off the PC)
Client-side technology solution(s): Update Web browser, Web browser security add-ons, desktop anti-malware, and scheduled patch management.
Behavior: Don’t install “bad” software off the internet. Don’t use a local password managers.
Outcome: The technology is not consistently effective. Users WANT to install software and by extension WILL install “bad” stuff. Users are unable to remember multiple hard-to-guess passwords so they’ll either write them down, have the same password across multiple websites, or use a password manager anyway.
Website Break-ins
Client-side technology solution(s): nothing
Behavior: Use different hard-to-guess passwords across websites.
Outcome: Users are unable to remember multiple hard-to-guess words so they’ll either write them down, use a password manager, or have the same password across multiple websites anyway.
Website Brute-Force Attacks
Client-side technology solution(s): nothing
Behavior: Use different hard-to-guess passwords across websites.
Outcome: Users are unable to remember multiple hard-to-guess words so they’ll either write them down, use a password manager, or use the same password across multiple websites anyway.
Now, consider the options users have for personal password handling:
By enlarge users are unable to remember multiple hard-to-guess words so let's cross #1 off the list. From a security perspective the prevalence of malware has made written passwords easier for a user to keep safe than storing them on a PC. But, from a user perspective, this approach is terribly inconvenient and makes password managers or using the same password across websites more attractive.
If we consider the threat landscape, massive numbers of websites compromises who don’t encrypt their password, a password manager is preferable to having the same password across many websites. If a users account is compromised via website hack, ideally it should not impact the security of the rest of their online accounts.
On the other hand a PC getting infected with malware is a very common problem and could lead to every record in the password manage being lost. However when this happens the user has worse problems than a compromised password manager, i.e. Man-in-the-Browser attacks makes a password-only theft highly unlikely.
When you boil everything down, if a user can mentally remember multiple hard-to-guess passwords across various websites, this is their best option. If they can’t and don’t mind the inconvenience, write the passwords down and keep in a safe place. If they do mind (the inconvenience) and feel their PC is reasonably safe, password managers are the next most secure option. Perhaps the browser vendors should provide a native hard-to-guess password generator in the browser to auto-populate login/registration fields. Better still if they store them in the password manager by default (opt-out rather than opt-in). Then again, unless truly fixed this would encourage using XSS to steal from password managers.
What we do know is left to their own devices, users will continue to the use the same (weak) passwords across multiple websites -- and we know where that leads.
Today there are four primary ways users lose control over their web-based passwords. Phishing Scams (email or SEO), Malware (installing malware or drive-by-downloads), website break-ins (SQLi, RFI, misconfiguration, etc.), and website brute-force attacks. For a user to protect themselves I’ve outlined the client-side technologies they can deploy (reason MFA is left out) and possible changes in their online behavior.
Phishing Scams (user hands over their passwords)
Client-side technology solution(s): Web browser security add-ons and anti-email-spam tools.
Behavior: Tell the difference between real/fake and safe/dangerous websites & emails using available visual indicators.
Outcome: The technology is not consistently effective and users are unable to reliably make accurate real/fake or safe/dangerous decisions.
Malware (passwords stolen off the PC)
Client-side technology solution(s): Update Web browser, Web browser security add-ons, desktop anti-malware, and scheduled patch management.
Behavior: Don’t install “bad” software off the internet. Don’t use a local password managers.
Outcome: The technology is not consistently effective. Users WANT to install software and by extension WILL install “bad” stuff. Users are unable to remember multiple hard-to-guess passwords so they’ll either write them down, have the same password across multiple websites, or use a password manager anyway.
Website Break-ins
Client-side technology solution(s): nothing
Behavior: Use different hard-to-guess passwords across websites.
Outcome: Users are unable to remember multiple hard-to-guess words so they’ll either write them down, use a password manager, or have the same password across multiple websites anyway.
Website Brute-Force Attacks
Client-side technology solution(s): nothing
Behavior: Use different hard-to-guess passwords across websites.
Outcome: Users are unable to remember multiple hard-to-guess words so they’ll either write them down, use a password manager, or use the same password across multiple websites anyway.
Now, consider the options users have for personal password handling:
- Mentally remember different passwords
- Write password down
- Use a password manager
- Use the same password across multiple websites.
By enlarge users are unable to remember multiple hard-to-guess words so let's cross #1 off the list. From a security perspective the prevalence of malware has made written passwords easier for a user to keep safe than storing them on a PC. But, from a user perspective, this approach is terribly inconvenient and makes password managers or using the same password across websites more attractive.
If we consider the threat landscape, massive numbers of websites compromises who don’t encrypt their password, a password manager is preferable to having the same password across many websites. If a users account is compromised via website hack, ideally it should not impact the security of the rest of their online accounts.
On the other hand a PC getting infected with malware is a very common problem and could lead to every record in the password manage being lost. However when this happens the user has worse problems than a compromised password manager, i.e. Man-in-the-Browser attacks makes a password-only theft highly unlikely.
When you boil everything down, if a user can mentally remember multiple hard-to-guess passwords across various websites, this is their best option. If they can’t and don’t mind the inconvenience, write the passwords down and keep in a safe place. If they do mind (the inconvenience) and feel their PC is reasonably safe, password managers are the next most secure option. Perhaps the browser vendors should provide a native hard-to-guess password generator in the browser to auto-populate login/registration fields. Better still if they store them in the password manager by default (opt-out rather than opt-in). Then again, unless truly fixed this would encourage using XSS to steal from password managers.
What we do know is left to their own devices, users will continue to the use the same (weak) passwords across multiple websites -- and we know where that leads.
Sunday, March 07, 2010
Best of Application Security (Friday, Mar. 5)
Ten of Application Security industry's coolest, most interesting, important, and entertaining links from the past week -- in no particular order.
- Verizon Incident Metrics Framework Released
- Wiseguys net $25m in ticket scalping racket
- State of Software Security Report
- Internet Explorer 8 and the Security Development Lifecycle (SDL)
- Top 10 Hacks of 2009 and WAF Mitigations
- FTC alleges that ControlScan offered 'little or no verification' of site security or privacy
- I’m in ur 4sq, snarfin ur password — Part I
- Fifteen Common Activities from BSIMM2
- Even if You Don’t Invent Your Own Crypto….It’s Still Hard
- Facebook founder Mark Zuckerberg 'hacked into emails of rivals and journalists'
Friday, February 26, 2010
Best of Application Security (Friday, Feb. 26)
Ten of Application Security industry's coolest, most interesting, important, and entertaining links from the past week -- in no particular order.
- Hitler and Cloud Computing Security
- Microsoft SDL Core Training Classes & Tools
- A Big Case of ...OOPS...
- Customer-Induced FUD
- NT OBJECTives Response to the Larry Suto Report
- Web Security Dojo v1.0 & Watcher 1.3.0 release
- Online finance flaw: Ameriprise III
- Banks, Businesses, Viruses and the UCC
- Breaking Weak CAPTCHA in 26 Lines of Code
- Finding Input Validations flaws with Taint Checking
Friday, February 19, 2010
Compliance and Habit holding back Application Security
My "Infrastructure vs. Application Security Spending" post must have struck a nerve. I've received a number of comments and emails where it's clear many are grappling with the same organizational budgeting challenges. Sharing these individual experiences help us raise awareness and gain new perspective on things that might work to our advantage. I sought permission to share the content of such insightful email from a Director of Product Security for a large publicly-traded company.
"Good post. It's something I've been preaching at *redacted* since day one. Our business relies on protecting our customers data. Why spend significantly more money on protecting our internal networks then on our product. I've won that battle, but given our security team started from network IT Security guys, that's where the money was spent.
A couple things I thought I'd pass along which you didn't mention, but I'm sure you've though about:
1. Service providers are going to spend money where their customers want them to. If their customer's security teams are all network guys, then the service provider is catering it's "security budget" to those guys. It still befuddles me in this day and age that we get predominantly more nCircle/Qualys/Nessus scans than we do application assessments from our customers. It shows though too in the compliance arena…if the people auditing your company have been baptized by compliance, then the service provider will cater to that. Unfortunately there's way more auditors who look at compliance and network security then application level security.
2. I think the comparison of network/host security vs application security shouldn't equate (right now). Because of the maturity of the market, there are less tools that are practical to rely on. As such, the curve should focus more on people (training, processes, and security staff) then on tools. I'm not saying the tools can't /don't do a good job, I'm just saying that right now they're not sufficient and in general more staffing resources need to be involved. To use an internal example, the fact that all R&D staff at *redacted* go through security training, perform security work every sprint, use secure frameworks, tools, etc, isn't captured by the numbers…and frankly is more valuable than us spending another 100K on a few more licenses of AppScan or WebInspect.
I think it would be really interesting to compare the costs of some of these products vs the benefit they provide. I just find it terribly funny that a Burp license costs ~$200, while running a product like DB Monitoring would costs hundreds of thousands or even millions of dollars in a large data center. That said, customers ask for things like DB Monitoring - because, you know, the five DBAs are more likely to steal their data then the thousands of malicious hackers out there ;-)
I'm not old enough to know…but, I bet the network security guys cracked on how the physical security guys got all the budget way back when. Evolution…"
If you got a story to share, please do!
"Good post. It's something I've been preaching at *redacted* since day one. Our business relies on protecting our customers data. Why spend significantly more money on protecting our internal networks then on our product. I've won that battle, but given our security team started from network IT Security guys, that's where the money was spent.
A couple things I thought I'd pass along which you didn't mention, but I'm sure you've though about:
1. Service providers are going to spend money where their customers want them to. If their customer's security teams are all network guys, then the service provider is catering it's "security budget" to those guys. It still befuddles me in this day and age that we get predominantly more nCircle/Qualys/Nessus scans than we do application assessments from our customers. It shows though too in the compliance arena…if the people auditing your company have been baptized by compliance, then the service provider will cater to that. Unfortunately there's way more auditors who look at compliance and network security then application level security.
2. I think the comparison of network/host security vs application security shouldn't equate (right now). Because of the maturity of the market, there are less tools that are practical to rely on. As such, the curve should focus more on people (training, processes, and security staff) then on tools. I'm not saying the tools can't /don't do a good job, I'm just saying that right now they're not sufficient and in general more staffing resources need to be involved. To use an internal example, the fact that all R&D staff at *redacted* go through security training, perform security work every sprint, use secure frameworks, tools, etc, isn't captured by the numbers…and frankly is more valuable than us spending another 100K on a few more licenses of AppScan or WebInspect.
I think it would be really interesting to compare the costs of some of these products vs the benefit they provide. I just find it terribly funny that a Burp license costs ~$200, while running a product like DB Monitoring would costs hundreds of thousands or even millions of dollars in a large data center. That said, customers ask for things like DB Monitoring - because, you know, the five DBAs are more likely to steal their data then the thousands of malicious hackers out there ;-)
I'm not old enough to know…but, I bet the network security guys cracked on how the physical security guys got all the budget way back when. Evolution…"
If you got a story to share, please do!
Best of Application Security (Friday, Feb. 19)
Ten of Application Security industry's coolest, most interesting, important, and entertaining links from the past week -- in no particular order.
- Microsoft’s Many Eyeballs and the Security Development Lifecycle
- A Comparison of DBIR with UK breach report
- Infrastructure vs. Application Security Spending
- Idea for a Fondue Party
- 2010 CWE/SANS Top 25 Most Dangerous Programming Errors
- Should Software Developers be Liable?
- Directory traversal as a reconnaissance tool
- Abusing WCF to Perform Remote Port Scans
- The State of Web Security Issues
- 3000 Small Dog Electronics customers' credit card details compromised
Thursday, February 18, 2010
Hey Massachusetts, where is your application security requirement?
This relates to my last post where Boaz Gelbord (Security Scoreboard), cited something very interesting about the Massachusetts data security regulation going into effect March 1. Their listed “Computer System Security Requirements” of their "risk-based approach" is pasted below. While I can’t say any one of these security controls is a bad idea, but can someone please tell me how any of this stuff is going to thwart Web-based attacks!? You know the kind of attack organizations and end-users are really dealing with!
No mention at all of (Web) application security, the thing we desperately need, but sure enough more firewalls, SSL, and anti-malware is legally mandated.
(1) Secure user authentication protocols including:
(a) control of user IDs and other identifiers;
(b) a reasonably secure method of assigning and selecting passwords, or use of unique identifier technologies, such as biometrics or token devices;
(c) control of data security passwords to ensure that such passwords are kept in a location and/or format that does not compromise the security of the data they protect;
(d) restricting access to active users and active user accounts only; and
(e) blocking access to user identification after multiple unsuccessful attempts to gain access or the limitation placed on access for the particular system;
(2) Secure access control measures that:
(a) restrict access to records and files containing personal information to those who need such information to perform their job duties; and
(b) assign unique identifications plus passwords, which are not vendor supplied default passwords, to each person with computer access, that are reasonably designed to maintain the integrity of the security of the access controls;
(3) Encryption of all transmitted records and files containing personal information that will travel across public networks, and encryption of all data containing personal information to be transmitted wirelessly.
(4) Reasonable monitoring of systems, for unauthorized use of or access to personal information;
(5) Encryption of all personal information stored on laptops or other portable devices;
(6) For files containing personal information on a system that is connected to the Internet, there must be reasonably up-to-date firewall protection and operating system security patches, reasonably designed to maintain the integrity of the personal information.
(7) Reasonably up-to-date versions of system security agent software which must include malware protection and reasonably up-to-date patches and virus definitions, or a version of such software that can still be supported with up-to-date patches and virus definitions, and is set to receive the most current security updates on a regular basis.
(8) Education and training of employees on the proper use of the computer security system and the importance of personal information security.
No mention at all of (Web) application security, the thing we desperately need, but sure enough more firewalls, SSL, and anti-malware is legally mandated.
(1) Secure user authentication protocols including:
(a) control of user IDs and other identifiers;
(b) a reasonably secure method of assigning and selecting passwords, or use of unique identifier technologies, such as biometrics or token devices;
(c) control of data security passwords to ensure that such passwords are kept in a location and/or format that does not compromise the security of the data they protect;
(d) restricting access to active users and active user accounts only; and
(e) blocking access to user identification after multiple unsuccessful attempts to gain access or the limitation placed on access for the particular system;
(2) Secure access control measures that:
(a) restrict access to records and files containing personal information to those who need such information to perform their job duties; and
(b) assign unique identifications plus passwords, which are not vendor supplied default passwords, to each person with computer access, that are reasonably designed to maintain the integrity of the security of the access controls;
(3) Encryption of all transmitted records and files containing personal information that will travel across public networks, and encryption of all data containing personal information to be transmitted wirelessly.
(4) Reasonable monitoring of systems, for unauthorized use of or access to personal information;
(5) Encryption of all personal information stored on laptops or other portable devices;
(6) For files containing personal information on a system that is connected to the Internet, there must be reasonably up-to-date firewall protection and operating system security patches, reasonably designed to maintain the integrity of the personal information.
(7) Reasonably up-to-date versions of system security agent software which must include malware protection and reasonably up-to-date patches and virus definitions, or a version of such software that can still be supported with up-to-date patches and virus definitions, and is set to receive the most current security updates on a regular basis.
(8) Education and training of employees on the proper use of the computer security system and the importance of personal information security.
Infrastructure vs. Application Security Spending
A recent study published by 7Safe, UK Security Breach Investigations Report, analyzed 62 cybercrime breach investigation and states that in “86% of all attacks, a weakness in a web interface was exploited” (vs 14% infrastructure) and the attackers were predominately external (80%). These results are largely consistent with the US-based Verizon Data Breach Incident Report (2008) which tracks over 500 cases. Combine this knowledge with the targeted Web-related attacks against Google, Adobe, Yahoo, the US House of Representatives, TechCrunch, Twitter, Heartland Payment Systems, bank after bank, university after university, country after country -- the story is the same. It’s a Web security world.
It has been said before and it’s worth repeating, adding more firewalls, SSL, and the same ol’ anti-malware products is not going to help solve this problem!
The reason that Web security problems persist is not a lack of knowledgeable people (though we could use more), perfected security tools (they could be much better), or effective software development processes (still maturing). A fundamental reason is something myself and others have been harping on for a long while now. Organizations spend their IT security dollars protecting themselves from yesterday’s attacks, at the network/infrastructure layer, while overlooking today’s real threats. Furthermore, these dollars are typically spent counter to how businesses invest their resources in technology. To illustrate this point I’m going to borrow inspiration from Gunnar Peterson (Software Security Architect & CTO at Arctec Group).
Let’s look at the approximate 2009 revenue from the largest corporations supplying a significant (most?) portion of IT infrastructure. Cisco $36B, Juniper $3.3B, Microsoft $58.5B, and F5 $653M. Total: $98.5B (USD). To protect this infrastructure from attacks security products are purchased. The approximate 2009 revenue of largest security vendors is Symantec $6B, Kaspersky $100M, McAfee $1.6B, Checkpoint $800M, SourceFire $75M, and IBM/ISS $500M (we think).
We’re spending $9.1B (USD) to protect $98.5B (USD) in infrastructure. Perhaps a ~%10 security tax on infrastructure is acceptable.
Now, let’s take a look at five of the top Web-based companies, which make all their money online, and by extension whose core technology value is rooted in Web code. In 2009 their revenues were: Google $23.6B, Yahoo $6.5B, eBay $8.7B, Amazon $24.5B, Salesforce.com $1.1B. $64.4B in total. Keep in mind that the 2009 eCommerce market is said to be about $130B. To protect these Web-enabled systems let’s use Gary McGraw’s (CTO of Cigital) 2007 software security revenue numbers of $500 million. He takes into account the bulk of white and black box testing tools, professional services consultancies, and web application firewall vendors. Since Gary hasn’t updated his numbers yet, lets adjust up to $750M to reflect market growth between then and 2009.
So in effect ~$750M is being spent to protect $64.4B in eCommerce revenue.
This is further supported by analyst findings. According to Gartner, 90 percent of IT security spending is on perimeter security such as firewalls. Plus to my mind that 1.20% figure is way aggressive. It is likely the percentage is much lower because the $750M is actually being spread out among financial, healthcare, insurance, education, energy, transportation, and government verticals. Perhaps this is also the reason why so many application security professionals wage holy wars over what solution is the best, worst, most important, or should be purchased first.
For the last ten years, I’ve directly experienced application security professionals fighting amongst themselves for scraps off the Big-Security-Vendor’s table. Vulnerability scanners vs WAFs, black vs white box, pen-test vs source code review, certifications vs real world experience, developer training vs secure frameworks, and so on. FAIL! All these solutions are necessary and more! The only way I see to truly improve application security is for organizations to do one (or both) of the following:
Break the IT budget into the following categories:
- Network: all the resources invested in Cisco, network admins, etc.
- Host: all the resources invested in Unix, Windows, sys admins, etc.
- Applications: all the resources invested in developers, CRM, ERP, etc.
- Data: all the resources invested in databases, DBAs, etc.
Tally up each layer. If you are like most business you will probably find that you spend most on Applications, then Data, then Host, then Network.
Then do the same exercise for the Information Security budget:
- Network: all the resources invested in network firewalls, firewall admins, etc.
- Host: all the resources invested in Vulnerability management, patching, etc.
- Applications: all the resources invested in static analysis, black box scanning etc.
- Data: all the resources invested in database encryption, database monitoring, etc.
Again, tally each up layer. If you are like most business you will find that you spend most on Network, then Host, then Applications, then Data. Congratulations, Information Security, you are diametrically opposed to the business!
If security spending can be justified on areas where attacks no longer occur, then perhaps we can justify more time, money, and effort on application security in the areas where the attacks are being waged.
It has been said before and it’s worth repeating, adding more firewalls, SSL, and the same ol’ anti-malware products is not going to help solve this problem!
The reason that Web security problems persist is not a lack of knowledgeable people (though we could use more), perfected security tools (they could be much better), or effective software development processes (still maturing). A fundamental reason is something myself and others have been harping on for a long while now. Organizations spend their IT security dollars protecting themselves from yesterday’s attacks, at the network/infrastructure layer, while overlooking today’s real threats. Furthermore, these dollars are typically spent counter to how businesses invest their resources in technology. To illustrate this point I’m going to borrow inspiration from Gunnar Peterson (Software Security Architect & CTO at Arctec Group).
Let’s look at the approximate 2009 revenue from the largest corporations supplying a significant (most?) portion of IT infrastructure. Cisco $36B, Juniper $3.3B, Microsoft $58.5B, and F5 $653M. Total: $98.5B (USD). To protect this infrastructure from attacks security products are purchased. The approximate 2009 revenue of largest security vendors is Symantec $6B, Kaspersky $100M, McAfee $1.6B, Checkpoint $800M, SourceFire $75M, and IBM/ISS $500M (we think).
We’re spending $9.1B (USD) to protect $98.5B (USD) in infrastructure. Perhaps a ~%10 security tax on infrastructure is acceptable.
Now, let’s take a look at five of the top Web-based companies, which make all their money online, and by extension whose core technology value is rooted in Web code. In 2009 their revenues were: Google $23.6B, Yahoo $6.5B, eBay $8.7B, Amazon $24.5B, Salesforce.com $1.1B. $64.4B in total. Keep in mind that the 2009 eCommerce market is said to be about $130B. To protect these Web-enabled systems let’s use Gary McGraw’s (CTO of Cigital) 2007 software security revenue numbers of $500 million. He takes into account the bulk of white and black box testing tools, professional services consultancies, and web application firewall vendors. Since Gary hasn’t updated his numbers yet, lets adjust up to $750M to reflect market growth between then and 2009.
So in effect ~$750M is being spent to protect $64.4B in eCommerce revenue.
This is further supported by analyst findings. According to Gartner, 90 percent of IT security spending is on perimeter security such as firewalls. Plus to my mind that 1.20% figure is way aggressive. It is likely the percentage is much lower because the $750M is actually being spread out among financial, healthcare, insurance, education, energy, transportation, and government verticals. Perhaps this is also the reason why so many application security professionals wage holy wars over what solution is the best, worst, most important, or should be purchased first.
For the last ten years, I’ve directly experienced application security professionals fighting amongst themselves for scraps off the Big-Security-Vendor’s table. Vulnerability scanners vs WAFs, black vs white box, pen-test vs source code review, certifications vs real world experience, developer training vs secure frameworks, and so on. FAIL! All these solutions are necessary and more! The only way I see to truly improve application security is for organizations to do one (or both) of the following:
- Reallocate a portion of current infrastructure security spend to application security.
- Grow overall IT security spending and increase application security to more than a rounding error.
Break the IT budget into the following categories:
- Network: all the resources invested in Cisco, network admins, etc.
- Host: all the resources invested in Unix, Windows, sys admins, etc.
- Applications: all the resources invested in developers, CRM, ERP, etc.
- Data: all the resources invested in databases, DBAs, etc.
Tally up each layer. If you are like most business you will probably find that you spend most on Applications, then Data, then Host, then Network.
Then do the same exercise for the Information Security budget:
- Network: all the resources invested in network firewalls, firewall admins, etc.
- Host: all the resources invested in Vulnerability management, patching, etc.
- Applications: all the resources invested in static analysis, black box scanning etc.
- Data: all the resources invested in database encryption, database monitoring, etc.
Again, tally each up layer. If you are like most business you will find that you spend most on Network, then Host, then Applications, then Data. Congratulations, Information Security, you are diametrically opposed to the business!
If security spending can be justified on areas where attacks no longer occur, then perhaps we can justify more time, money, and effort on application security in the areas where the attacks are being waged.
Friday, February 12, 2010
Best of Application Security (Friday, Feb. 12)
Ten of Application Security industry's coolest, most interesting, important, and entertaining links from the past week -- in no particular order.
- A Lazy Pen Tester’s Guide to Testing Flash Applications
- Rock Beats Scissors, and People Beat Process
- Hacker threat forces DoH to close appraisal site
- Feds say dev's 'cookie-stuffer' app fleeced eBay
- A Few Billion Lines of Code Later: Using Static Analysis to Find Bugs in the Real World
- Death of Product Reviews
- Are You Rugged?
- Reducing Information Disclosure in ASP.NET Web Services
- OWASP Broken Web Applications Project
- Top 10 Targeted Passwords
Tuesday, February 09, 2010
Where's WhiteHat? Re: Scanner Comparisons
Last week Larry Suto published, “Analyzing the Accuracy and Time Costs of Web Application Security Scanners,” which reviewed desktop black box website vulnerability scanners: Acunetix, IBM AppScan, BurpSuitePro, Cenzic Hailstorm, HP WebInspect, NTOSpider, and Qualys WAS (Software-as-a-Service). This research was meant to build upon Larry’s initial October 2007 study of the market. Several people have asked what I thought of the paper and why WhiteHat Security wasn’t covered. I’m happy to discuss both questions.
First off, the website vulnerability management space is in desperate need of side-by-side comparisons as they are very few and far between. This represents a challenge for organizations building application security programs that want to create a product short-list to evaluate internally. For a variety of reasons, independent and publicly available detailed technical reviews of website vulnerability management products/solutions are unlikely to come from the expected sources, such trade magazines and industry analysts. One of the main inhibitors is that many of these firms do not have a Web application testbed that would allow for an accurate, fair comparison. Thankfully, researchers, such as Larry Suto, help fill the void by investing personal time and sharing their results. Others independents should be encouraged to do the same. I would recommend the “Web Application Security Scanner Evaluation Criteria (WASSEC)” if you wish to do so. Also, Larry confirmed he was not compensated by any vendor for his work.
During the latter stages of Larry’s research, WhiteHat Security was offered the opportunity to be included. In order to take part, we were asked to assess six vendor hosted “test websites” with WhiteHat Sentinel, identify vulnerabilities and report our findings. The testing process was designed to evaluate desktop black box scanner technology using a “Point-and-Shoot” and “Trained” methodology -- something not well-suited for a SaaS offering like Sentinel. What we do and how we do it is very different from the scanning tools, but is still often seen as an alternative. After much consideration, we did not feel that the testing methodology would provide an apples-to-apples evaluation environment for Sentinel. Additionally, and equally important, finding vulnerabilities is only the first piece of the overall value our customers receive, so we politely declined to participate.
*Not to mention, that as a strict rule, we never touch any website without express written authorization.*
The report states, consistent with my expectations, that significant amounts of human/expert time are required for scanner configuration, vulnerability verification, scan monitoring, etc. to enable the aforementioned products to function proficiently. Behind the scenes, Sentinel is no different, except that we perform all of those activities and more for our customers as a standard part of the annual subscription. Doing so means our engineering time has a hard cost to us and staff resources are dedicated to serving customers.
The report confirms that scanner performance varies wildly from site to site, so it’s best to test where they will be deployed. We agree and provide mechanisms for our customers to evaluate Sentinel first-hand for exactly that reason. We want customers to know exactly what they can expect from us on their production systems and not a generic test website. Finally, where Sentinel really excels, is in areas where the report did not (could not) focus. Scalability is one of these. Whether we are tasked with one site, 10, 100, 1,000 or more -- Sentinel is capable of handling the volume.
Over the years I’ve written extensively about black box scanner efficiencies and deficiencies in depth: Automated Scanners vs. Low-Hanging Fruit, Automated Scanner vs. The OWASP Top Ten, shed light on duplication rates, what scanners are good at finding and what they are not -- with a scan-o-meter, discussed business logic flaws, why crawling matters a lot, how much essential human time is required, and even what it takes to make the best scanner. So obviously the scanners overall general poor showing came as no surprise. Most missed nearly half of the vulnerabilities, on test websites no less, where they are designed to be easily found. Imagine how they would perform in the real world! It gets much uglier and dangerous out there I assure you.
I’d highly recommended everyone interested Web application security read Larry’s report for themselves and get familiar with what is the current state-of-the-art in black box scanning products. Much improvement could be made through additional R&D. Remember, keep an open mind, but at the same time take the results with a grain of salt until you test on your systems. Some vendors will say Larry’s work wasn’t perfectly scientific, possessed data errors, was misinterpreted, ran misconfigured, couldn’t reproduce the results, etc. All of that may be true, but so is the fact that it looks like Larry conducted a deeper and fairer analysis than the average would-be user does during typical evaluations.
Here are the three takeaways:
First off, the website vulnerability management space is in desperate need of side-by-side comparisons as they are very few and far between. This represents a challenge for organizations building application security programs that want to create a product short-list to evaluate internally. For a variety of reasons, independent and publicly available detailed technical reviews of website vulnerability management products/solutions are unlikely to come from the expected sources, such trade magazines and industry analysts. One of the main inhibitors is that many of these firms do not have a Web application testbed that would allow for an accurate, fair comparison. Thankfully, researchers, such as Larry Suto, help fill the void by investing personal time and sharing their results. Others independents should be encouraged to do the same. I would recommend the “Web Application Security Scanner Evaluation Criteria (WASSEC)” if you wish to do so. Also, Larry confirmed he was not compensated by any vendor for his work.
During the latter stages of Larry’s research, WhiteHat Security was offered the opportunity to be included. In order to take part, we were asked to assess six vendor hosted “test websites” with WhiteHat Sentinel, identify vulnerabilities and report our findings. The testing process was designed to evaluate desktop black box scanner technology using a “Point-and-Shoot” and “Trained” methodology -- something not well-suited for a SaaS offering like Sentinel. What we do and how we do it is very different from the scanning tools, but is still often seen as an alternative. After much consideration, we did not feel that the testing methodology would provide an apples-to-apples evaluation environment for Sentinel. Additionally, and equally important, finding vulnerabilities is only the first piece of the overall value our customers receive, so we politely declined to participate.
*Not to mention, that as a strict rule, we never touch any website without express written authorization.*
The report states, consistent with my expectations, that significant amounts of human/expert time are required for scanner configuration, vulnerability verification, scan monitoring, etc. to enable the aforementioned products to function proficiently. Behind the scenes, Sentinel is no different, except that we perform all of those activities and more for our customers as a standard part of the annual subscription. Doing so means our engineering time has a hard cost to us and staff resources are dedicated to serving customers.
The report confirms that scanner performance varies wildly from site to site, so it’s best to test where they will be deployed. We agree and provide mechanisms for our customers to evaluate Sentinel first-hand for exactly that reason. We want customers to know exactly what they can expect from us on their production systems and not a generic test website. Finally, where Sentinel really excels, is in areas where the report did not (could not) focus. Scalability is one of these. Whether we are tasked with one site, 10, 100, 1,000 or more -- Sentinel is capable of handling the volume.
Over the years I’ve written extensively about black box scanner efficiencies and deficiencies in depth: Automated Scanners vs. Low-Hanging Fruit, Automated Scanner vs. The OWASP Top Ten, shed light on duplication rates, what scanners are good at finding and what they are not -- with a scan-o-meter, discussed business logic flaws, why crawling matters a lot, how much essential human time is required, and even what it takes to make the best scanner. So obviously the scanners overall general poor showing came as no surprise. Most missed nearly half of the vulnerabilities, on test websites no less, where they are designed to be easily found. Imagine how they would perform in the real world! It gets much uglier and dangerous out there I assure you.
I’d highly recommended everyone interested Web application security read Larry’s report for themselves and get familiar with what is the current state-of-the-art in black box scanning products. Much improvement could be made through additional R&D. Remember, keep an open mind, but at the same time take the results with a grain of salt until you test on your systems. Some vendors will say Larry’s work wasn’t perfectly scientific, possessed data errors, was misinterpreted, ran misconfigured, couldn’t reproduce the results, etc. All of that may be true, but so is the fact that it looks like Larry conducted a deeper and fairer analysis than the average would-be user does during typical evaluations.
Here are the three takeaways:
- Scanner results will vary wildly from website to website. For best results, I highly recommend that you evaluate them on the sites where they are going to be deployed. Better still, if you know of vulnerabilities in those sites ahead of time, use that information for comparison purposes.
- The significant human/expert time required for proper scanner set-up, ongoing configuration, vulnerability verification, etc. must be taken into consideration. Which vulnerabilities you scan for is just as important as how you scan for them. Estimate about 20-40 man-hours per website scanned.
- Scanner vendors should take into consideration that Larry Suto is certainly more sophisticated than the average user. So if he couldn’t figure out how to run your tool “properly,” take that as constructive feedback.
Friday, February 05, 2010
Best of Application Security (Friday, Feb. 5)
Ten of Application Security industry's coolest, most interesting, important, and entertaining links from the past week -- in no particular order.
- Accuracy and Time Costs of Web Application Security Scanner Report
- The Web won’t be safe, let alone secure, unless we break it
- Why don't websites default to SSL/TLS?
- RFI List in Burp Suite
- Web 2.0 Pivot Attacks
- Building Secure Applications with HTML 5: What is Happening and Where?
- Mozilla Accepts Chinese CNNIC Root CA Certificate
- SDL for dummies
- XSS, SQL Injection and Fuzzing Barcode Cheat Sheet
- Microsoft CAT.NET 2.0 - Beta
Thursday, February 04, 2010
Web 2.0 Pivot Attacks
Any penetration tester would agree that pivot attacks, designed to compromise a secondary host to more effectively attack primary targets, are incredibly powerful. Organizations tend to have difficulty protecting all hosts at all times, which is why proper network segmentation is vital should loss of control occur on any one node. Often it’s easier to compromise a host from behind rather than head on. Case in point, a hacker used a pivot attack to break into Heartland Payment Systems and pilfer 130 million CC#s. A SQL injection exploit was used to get a foothold in a non-payment-network-host leading to the eventual data compromise. Recently I had a thought that pivot attacks exist in a Web 2.0 world as well, they are just not typically viewed that way.
Many websites automatically load in content from remote resources (JavaScript, Flash, more HTML, images, etc.), which are hosted by third-party providers. These resources normally embed advertisements (DoubleClick), traffic counters (StatCounter), user trackers (whos.amung.us), games (Pogo), videos (YouTube), and thousands of other forms of dynamic content. These are often generically called “Web page Widgets,” things Web page might want to include in their pages for their visitors. There are thousands, maybe tens of thousands of these types of providers. Let’s look at some top mainstream media websites to see what widget hostname they include:
TechCrunch
ad.doubleclick.net
ads.undertone.com
altfarm.mediaplex.com
b.scorecardresearch.com
bs.serving-sys.com
button.topsy.com
cdn.undertone.com
edge.quantserve.com
googleads.g.doubleclick.net
img.mediaplex.com
mp.apmebf.com
network.realmedia.com
partner.googleadservices.com
pubads.g.doubleclick.net
s0.2mdn.net
services.crunchboard.com
static.ak.connect.facebook.com
widget.startups.com
www.facebook.com
www.google-analytics.com
www.oracle.com
www.sun.com
www.tumri.net
ytaahg.vo.llnwd.net
NY Times
ad.doubleclick.net
admin.brightcove.com
ads.pointroll.com
at.amgdgt.com
brightcove.vo.llnwd.net
c.brightcove.com
googleads.g.doubleclick.net
graphics8.nytimes.com
load.tubemogul.com
markets.on.nytimes.com
receive.inplay.tubemogul.com
static.inplay.tubemogul.com
timespeople.nytimes.com
video2.nytimes.com
64.191.193.124
Wall Street Journal
ac3.msn.com
ad.doubleclick.net
adsyndication.msn.com
om.dowjoneson.com
online.wsj.com
s.wsj.net
www.marketwatch.com
CNN
ads.cnn.com
b.scorecardresearch.com
edition.cnn.com
i.cdn.turner.com
i.cnn.net
metrics.cnn.com
svcs.cnn.com
USA Today
ad.doubleclick.net
ads.adsonar.com
ads.revsci.net
altfarm.mediaplex.com
b.scorecardresearch.com
content.usatoday.com
gannett.gcion.com
i.usatoday.net
img-cdn.mediaplex.com
img.mediaplex.com
js.revsci.net
media.fastclick.net
mp.apmebf.com
optimized-by.rubiconproject.com
pix04.revsci.net
r1.ace.advertising.com
rd.apmebf.com
tap-cdn.rubiconproject.com
usata1.gcion.com
usatoday1.112.2o7.net
Washington Post
ad.bizo.com
ad.doubleclick.net
ads.adsonar.com
ads.bluelithium.com
ads.revsci.net
altfarm.mediaplex.com
bp.specificclick.net
custom.marketwatch.com
fls.doubleclick.net
js.revsci.net
media.washingtonpost.com
mp.apmebf.com
In a Web security context, these websites essentially allow arbitrary executable code, supplied by the third-party, complete access to the browser DOM and the user’s session information. *Exception being IMG SRC loads* That means they can hijack accounts by stealing authentication cookies; change the news or ask for passwords by altering what the user sees on the screen; redirect users to malware laden websites; force browsers to attack other systems, and more. By including Web widgets from an uncontrolled source on your pages, the third-party’s entire infrastructure must be included as part of the implicit trust model. These dangers have been previously discussed by Tom Stripling where the third-party service provider was assumed to be the potential nefarious source. I think the concern lies a bit deeper, where a malicious Web 2.0 pivot attack comes in.
If a bad guy, APT or a less-skilled adversary, wants to surreptitiously compromise a (relatively) hardened Web presence (or its users), they don’t necessarily need go after the target directly, they could instead go after the aforementioned third-party providers. How many of these third-parties take security as seriously as their customers do? Assumed few, but we really don’t know for certain. Please comment below is you have experiences here to share? How many organizations really check up on the third-party’s security posture or even know enough take this risk into consideration? Again, some do, but very few in my personal experience. The organization might dismiss the concern by saying something like:
"If X gets hacked we'll have bigger problems on our hands."
Important to add is that during a Web 2.0 pivot attack no traffic is directly seen by the primary target, which basically makes it impossible for them to detect/thwart the attack before a compromise. Post third-party compromise, it might be nearly as hard to detect a Web widget code update unless you can somehow monitor the content changes in unexpected ways. This of course assumes the primary target knows how, when, or if the third-party changes the code (rare). Not to mention the inclusion of Web page widgets is almost always beyond the visibility of a security team, because this process is largely managed through marketing / product management (not so much application development) and can easily happen at any time with zero notice.
Pen-testers to my knowledge can’t/don’t use this type of pivot attack because the third-party is usually another organization, unwilling to grant security testing authority, and therefore out of the scope of the engagement. Also important is that in a network pivot attack you may still be limited in what you can do on a host due to network secregation, ACLs etc. but in JavaScript space, you are basically God.
Yes, the HTML 5 sandbox would be really nice to have.
Converting unimplementable Cookie-based XSS to a persistent attack
Update: Related work by Mike Bailey, Cross-subdomain Cookie Attacks: [Screenshot 1 & 2]
If you spend enough time looking for Cross-Site Scripting (XSS) vulnerabilities, you are bound to come across a cookie-based version eventually -- where the script injection is located in the Cookie header. The problem is there’s no good way (in a modern browser) to force a victims browser to send an HTTP request with a modified Cookie value (to include HTML/JS). While the website or Web application is still technically vulnerable to XSS this is usually considered unimplementable since no PoC code can be created and the risk/threat is therefore lowered.
I was having this conversation with Rob Tate, a member of WhiteHat’s Engineering team, who enlightened to something I hadn’t previously considered. Cookie-based XSS can be made very useful after all!
Consider an online bank with an XSS through a username Cookie parameter. After successful login the resulting page would read something like, "Hello."
Cookie: username=
Setting the Cookie will most likely require another (non-persistent) XSS vulnerability, which as we know is extremely common. By combining these two vulnerabilities, an unimplementable and non-persistent XSS, you could create a persistent XSS scenario.
What the attacker could do is use the non-persistent XSS to inject a data mining JavaScript function into the browser’s Cookie username parameter via document.cookie. Afterwards every time the victim logs-in the JavaScript will execute in the DOM. Now you have an a persistent XSS attack sticking with the browser over multiple sessions.
If you spend enough time looking for Cross-Site Scripting (XSS) vulnerabilities, you are bound to come across a cookie-based version eventually -- where the script injection is located in the Cookie header. The problem is there’s no good way (in a modern browser) to force a victims browser to send an HTTP request with a modified Cookie value (to include HTML/JS). While the website or Web application is still technically vulnerable to XSS this is usually considered unimplementable since no PoC code can be created and the risk/threat is therefore lowered.
I was having this conversation with Rob Tate, a member of WhiteHat’s Engineering team, who enlightened to something I hadn’t previously considered. Cookie-based XSS can be made very useful after all!
Consider an online bank with an XSS through a username Cookie parameter. After successful login the resulting page would read something like, "Hello
Cookie: username=
Setting the Cookie will most likely require another (non-persistent) XSS vulnerability, which as we know is extremely common. By combining these two vulnerabilities, an unimplementable and non-persistent XSS, you could create a persistent XSS scenario.
What the attacker could do is use the non-persistent XSS to inject a data mining JavaScript function into the browser’s Cookie username parameter via document.cookie. Afterwards every time the victim logs-in the JavaScript will execute in the DOM. Now you have an a persistent XSS attack sticking with the browser over multiple sessions.
Wednesday, February 03, 2010
The Web won’t be safe, let alone secure, unless we break it
There are several security issues affecting all major Web browsers that have remained unaddressed for years (probably because the bad guys haven’t leveraged them aggressively enough, but the potential is there). The problem is that the only known ways to fix these issues (adequately) is to “break the Web” -- i.e. negatively impact the usability of a significant and unacceptable percentage of websites. Doing so is a nonstarter for any browser vendor looking to grow market share. The choice is clear for most vendors: Be less secure and adopted, rather than secure and obscure. This is what the choice comes down to. This is a topic deserving of further exploration.
Web security can be divided into two parts, Website security and Web Browser security. Both are equally important. A website must be able to protect itself from a hostile browser and a browser must be able to protect itself from a hostile website. If either side of these assumptions fails, then there is a problem (the Web is not secure). Attacks targeting browsers, which will be the focus of this post, can be broadly categorized into three distinct vectors:
1) Attacks designed to escape the confines of the browser walls and execute within the desktop operating system below. This is primarily achieved by exploiting memory and file-handling implementation flaws.
2) Behavioral attacks that trick users into doing something, such as downloading and installing malware, thereby harming their machine or encouraging them to reveal sensitive information.
3) Attacks taking advantage of design flaws in the way the Web works. These attacks normally remain within the browser walls and use the victim’s browser as a launch platform for surreptitiously pilfering information from their session or the surrounding network.
After years of massive volumes of CVEs (repository for published vulnerabilities), the browser vendor incumbents (Microsoft, Mozilla, Opera, Google, Apple) have made great strides in addressing vector #1. Some have more work to do than others. This is a good thing, as exploiting unpatched browsers is the primary method for malware propagation such as the so-called drive-by-downloads, legitimate websites hosting malware that infects their visitors. Fortunately “fixing” #1 doesn’t require “breaking the Web,” only updating shoddy code and distributing updates.
Solving #2 is more psychological than technical in nature. The challenge is that people trust computer screens, believe what they see on the Web, and will install anything in order to watch the latest celebrity sex tape or open a personalized e-greeting sent by their “friend.” Attackers prey on this inherent trust, general good nature, and basic human instinct. In response, browsers have provided EV-SSL, Anti-Phishing Toolbars, SSL warning dialogs, password managers, etc. These efforts make important security decisions more visible, harder to get wrong, or remove the decision altogether. Again “fixing” these issues doesn’t require “breaking the Web,” but creating a more intuitive user-interface design.
Many, including myself, have asked the major browser vendors to do something about the CSS History Hacking, a privacy violation where a malicious website can tell if you’ve been to a certain URL, by disabling access to key DOM APIs. They said doing so would break certain websites and upset Web developers. (Update: See Wladimir's comment below for excellent insight into the true difficulty of solving this problem)
To solve Intranet Hacking, the suggestion was made to deny websites with a non-RFC 1918 IP address the ability to passively instruct a browser to connect to RFC 1918 IP addresses. The response was that it would break certain essential features like corporate Web proxy set-ups and add-ons like Google Desktop.
Fixing Clickjacking would require changing IFRAMES implementation so that they would not be transparent or allowed at all. Doing so would undoubtedly cause major Web breakage, such as no banner advertising or Facebook-style application platforms. So instead we get opt-in X-FRAME-OPTIONS, which basically no one uses at the moment.
Maybe browser tab/session separation is in order. When logged-in to a website in one tab, other tabs wouldn’t have session access thereby limiting the damage XSS, CSRF, and Clickjacking could inflict. But, this solution would probably annoy users and Web developers who really want persistent authentication. Oh, and we really need Web tracking cookies too. Gah!
So here we are, waiting for the other shoe to drop, and bad enough things to happen. Then we’ll get the juice required to fix these problems, by default. The bigger problem is when that time eventually comes we might actually be forced to break the Web to secure it. In the meantime, the community has been lobbying hard for opt-in tools that the proactive crowd can use to protect themselves ahead of time. Fortunately, we are starting to see new technologies like XSSFilter, Content Security Policy, Strict Transport Security, and Origin headers come into view. Maybe this is the future and a look into the security proving ground for the changes we’ll need to make later.
Web security can be divided into two parts, Website security and Web Browser security. Both are equally important. A website must be able to protect itself from a hostile browser and a browser must be able to protect itself from a hostile website. If either side of these assumptions fails, then there is a problem (the Web is not secure). Attacks targeting browsers, which will be the focus of this post, can be broadly categorized into three distinct vectors:
1) Attacks designed to escape the confines of the browser walls and execute within the desktop operating system below. This is primarily achieved by exploiting memory and file-handling implementation flaws.
2) Behavioral attacks that trick users into doing something, such as downloading and installing malware, thereby harming their machine or encouraging them to reveal sensitive information.
3) Attacks taking advantage of design flaws in the way the Web works. These attacks normally remain within the browser walls and use the victim’s browser as a launch platform for surreptitiously pilfering information from their session or the surrounding network.
After years of massive volumes of CVEs (repository for published vulnerabilities), the browser vendor incumbents (Microsoft, Mozilla, Opera, Google, Apple) have made great strides in addressing vector #1. Some have more work to do than others. This is a good thing, as exploiting unpatched browsers is the primary method for malware propagation such as the so-called drive-by-downloads, legitimate websites hosting malware that infects their visitors. Fortunately “fixing” #1 doesn’t require “breaking the Web,” only updating shoddy code and distributing updates.
Solving #2 is more psychological than technical in nature. The challenge is that people trust computer screens, believe what they see on the Web, and will install anything in order to watch the latest celebrity sex tape or open a personalized e-greeting sent by their “friend.” Attackers prey on this inherent trust, general good nature, and basic human instinct. In response, browsers have provided EV-SSL, Anti-Phishing Toolbars, SSL warning dialogs, password managers, etc. These efforts make important security decisions more visible, harder to get wrong, or remove the decision altogether. Again “fixing” these issues doesn’t require “breaking the Web,” but creating a more intuitive user-interface design.
Addressing #3, with roots dating back to the earliest days of the Web, is another matter entirely. Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), Clickjacking, CSS History Stealing, Intranet Hacking, etc. are all good examples. While these weren’t pressing issue before, they are trending in a dangerous direction. We’ve seen outbreaks of Twitter worms, XSS Defacements of government websites, Facebook Clickjacking attacks, sites that disclose which porn sites people visit, several Intranet Hacking proof-of-concept tools, and so on.
Many, including myself, have asked the major browser vendors to do something about the CSS History Hacking, a privacy violation where a malicious website can tell if you’ve been to a certain URL, by disabling access to key DOM APIs. They said doing so would break certain websites and upset Web developers. (Update: See Wladimir's comment below for excellent insight into the true difficulty of solving this problem)
To solve Intranet Hacking, the suggestion was made to deny websites with a non-RFC 1918 IP address the ability to passively instruct a browser to connect to RFC 1918 IP addresses. The response was that it would break certain essential features like corporate Web proxy set-ups and add-ons like Google Desktop.
Fixing Clickjacking would require changing IFRAMES implementation so that they would not be transparent or allowed at all. Doing so would undoubtedly cause major Web breakage, such as no banner advertising or Facebook-style application platforms. So instead we get opt-in X-FRAME-OPTIONS, which basically no one uses at the moment.
Maybe browser tab/session separation is in order. When logged-in to a website in one tab, other tabs wouldn’t have session access thereby limiting the damage XSS, CSRF, and Clickjacking could inflict. But, this solution would probably annoy users and Web developers who really want persistent authentication. Oh, and we really need Web tracking cookies too. Gah!
So here we are, waiting for the other shoe to drop, and bad enough things to happen. Then we’ll get the juice required to fix these problems, by default. The bigger problem is when that time eventually comes we might actually be forced to break the Web to secure it. In the meantime, the community has been lobbying hard for opt-in tools that the proactive crowd can use to protect themselves ahead of time. Fortunately, we are starting to see new technologies like XSSFilter, Content Security Policy, Strict Transport Security, and Origin headers come into view. Maybe this is the future and a look into the security proving ground for the changes we’ll need to make later.
Tuesday, February 02, 2010
Be Ready -- With Answers
Where are most reported security vulnerabilities located? In Web applications. How is malware predominately distributed and end-users infected? By visiting legitimate websites that have been hacked and loaded with drive-by-download browser exploits. What were the main attack vectors used in the Aurora attacks affecting Google, Adobe, Yahoo and many others? Targeted reconnoissance using social networks and Web browser exploits. What type of cyber attack recently targeted 49 US House of Representatives members just after President Obama’s State of the Union Address? Website defacement. Popular blog TechCrunch received similar treatment, twice, and just before Apple’s recent iPad announcement. What was the main attack vector used in the largest credit card breach ever, affecting Heartland Payment Systems? SQL Injection of a Web application.
Let’s also not forget that according to Verizon’s Data Breach Incident Report (DBIR), “SQL injection attacks, cross-site scripting, authentication bypass and exploitation of session variables contributed to nearly half of the cases investigated that involved hacking.”
Obviously today’s threat landscape is focused on the Web, not networks as in years past. We are now seeing larger, more high profile, costly, and embarrassing events with increased regularity. But make no mistake, this is just the beginning of what’s to come. The trends are easy to read. Web attacks will get worse, far worse, and far more common. Sure there have been some lawsuits and fines, but no one has gone out of business, suffered a significant stock drop, or lost their lives as a result of a Web security incident. The fact is everyone can still get their webmail, update their Facebook, post to Twitter, check their online bank account balance, and buy a book on Amazon -- all still relatively safely. Enjoy this moment, the age of application security innocence is nearly over.
Web security, application security, software security, or whatever you want to call it will soon come into its own. It will no longer be acceptable, feasible, or even seriously suggestible to run for cover by simply adding more firewalls and SSL. Things like “the cloud” will help make this fail plain as day. For application security professionals working in this field, struggling to get their concerns taken seriously by the business, rest assured very soon they will be coming to you rather than the other way around. They’ll want answers, nay solutions, and will come with a checkbook in hand ready to make the problem go away. When they come to you with this urgency it will be as result of a serious breach, customer revolt, vendor compromise, exposure of the organization’s crown jewels, etc. Issues that directly affect the bottom-line and the ability to transact business.
It would be nice to proactively head off the coming catastrophes, but unfortunately the information security industry doesn’t really work that way. Businesses have a hard time spending ahead of an incident. Really bad things have to happen before the allocation of resources can be justified. At least, that is how has always worked. So today your job is to prepare -- and have the answers ready when asked. This is how:
1) Make yourself visible
Brand yourself, and/or your team, as the go-to internal expert(s) for “application security.” Regularly share interesting links, summarize interesting white papers, and offer to coordinate workshops for management and development teams so they can get up to speed. If you need content, every Friday I publish a “Best of Application Security” feature on my blog. Of course, continue voicing concerns about present risks, even if it means being ignored and overruled when suggesting proactive application security programs. The side effect is that this will help establish your organizational visibility. And you won’t be ignored for long given the coming threats. These recent blog posts can help hone your arguments: “Budgeting for Web Application Security” and “Overcoming Objections to an Application Security Program.”
2) Have your answers ready
Build your internal step-by-step plan for an application security program. Need help getting started? Look no further than Securosis’s “Web Application Security Program” white paper. Take its guidance and adapt it to your organization’s specific needs. So when its asked for you are not caught flatfooted. Few things say more about a person and a security professional than their readiness, especially in the eyes of management.
3) Engage with the community
OWASP, WASC, SANS, MITRE, etc. pick your group and a project to get involved in. Meet people, ask questions, and help out as best you can. No one can be expected to have all the answers to every Web security question, the knowledge base is far too big, so build up your network of contacts so you can ask peers. Remember, this is a two-way street, you get what you give.
Let’s also not forget that according to Verizon’s Data Breach Incident Report (DBIR), “SQL injection attacks, cross-site scripting, authentication bypass and exploitation of session variables contributed to nearly half of the cases investigated that involved hacking.”
Obviously today’s threat landscape is focused on the Web, not networks as in years past. We are now seeing larger, more high profile, costly, and embarrassing events with increased regularity. But make no mistake, this is just the beginning of what’s to come. The trends are easy to read. Web attacks will get worse, far worse, and far more common. Sure there have been some lawsuits and fines, but no one has gone out of business, suffered a significant stock drop, or lost their lives as a result of a Web security incident. The fact is everyone can still get their webmail, update their Facebook, post to Twitter, check their online bank account balance, and buy a book on Amazon -- all still relatively safely. Enjoy this moment, the age of application security innocence is nearly over.
Web security, application security, software security, or whatever you want to call it will soon come into its own. It will no longer be acceptable, feasible, or even seriously suggestible to run for cover by simply adding more firewalls and SSL. Things like “the cloud” will help make this fail plain as day. For application security professionals working in this field, struggling to get their concerns taken seriously by the business, rest assured very soon they will be coming to you rather than the other way around. They’ll want answers, nay solutions, and will come with a checkbook in hand ready to make the problem go away. When they come to you with this urgency it will be as result of a serious breach, customer revolt, vendor compromise, exposure of the organization’s crown jewels, etc. Issues that directly affect the bottom-line and the ability to transact business.
It would be nice to proactively head off the coming catastrophes, but unfortunately the information security industry doesn’t really work that way. Businesses have a hard time spending ahead of an incident. Really bad things have to happen before the allocation of resources can be justified. At least, that is how has always worked. So today your job is to prepare -- and have the answers ready when asked. This is how:
1) Make yourself visible
Brand yourself, and/or your team, as the go-to internal expert(s) for “application security.” Regularly share interesting links, summarize interesting white papers, and offer to coordinate workshops for management and development teams so they can get up to speed. If you need content, every Friday I publish a “Best of Application Security” feature on my blog. Of course, continue voicing concerns about present risks, even if it means being ignored and overruled when suggesting proactive application security programs. The side effect is that this will help establish your organizational visibility. And you won’t be ignored for long given the coming threats. These recent blog posts can help hone your arguments: “Budgeting for Web Application Security” and “Overcoming Objections to an Application Security Program.”
2) Have your answers ready
Build your internal step-by-step plan for an application security program. Need help getting started? Look no further than Securosis’s “Web Application Security Program” white paper. Take its guidance and adapt it to your organization’s specific needs. So when its asked for you are not caught flatfooted. Few things say more about a person and a security professional than their readiness, especially in the eyes of management.
3) Engage with the community
OWASP, WASC, SANS, MITRE, etc. pick your group and a project to get involved in. Meet people, ask questions, and help out as best you can. No one can be expected to have all the answers to every Web security question, the knowledge base is far too big, so build up your network of contacts so you can ask peers. Remember, this is a two-way street, you get what you give.
Friday, January 29, 2010
Best of Application Security (Friday, Jan. 29)
Ten of Application Security industry's coolest, most interesting, important, and entertaining links from the past week -- in no particular order.
- Gunnar Peterson on APTs: What Infosec Should Learn & Are Coming from Inside the House!
- Umm…TechCrunch? Defacement Two in 24 Hours
- Congressional Web Site Defacements Follow the State of the Union
- Google to Pay For Bugs Found in Chromium
- Chromium Security in Depth
- WASC RSA 2010 Meet-up
- Facebook sandbox escape
- Dasient Q4'09 web-based malware data and trends
- CSS History Hack In Firefox Without JavaScript for Intranet Portscanning
- Segmented Web Browsing Will Be the DMZ of the 2010’s
Thursday, January 28, 2010
WASC RSA Meet-Up 2010!
For those attending RSA Conference 2010 (San Francisco / March 1 – 5) and want to mingle with fellow Web application security people, the Web Application Security Consortium (WASC) luncheon is the place to be. Free drinks and appetizers will be served (sponsored by WhiteHat Security). WASC meet-ups are rare opportunities to shake hands with like minded people we only otherwise communicate with virtually. We'll shoot some pool, chit chat, and generally have a good time with people of similar security interests. Everyone is welcome, but remember the space at Jillan's is extremely limited ( RSVP quickly if you want to get in.
To attend please go directly to Jillian's to check-in with WhiteHat staff and then you will be granted access to the party.
WASC RSA 2010 Meet-up
Wednesday, March 3, 2010
Lunch served: 12:00 PM to 2:00 PM
Jillian's@Metreon
101 Fourth Street | 415.369.6101
RSVP by February 26, 2010*
Friday, January 22, 2010
Best of Application Security (Friday, Jan. 22)
Ten of Application Security industry's coolest, most interesting, important, and entertaining links from the past week -- in no particular order.
- Is APT After You?
- Microsoft: Introducing Quick Security References (QSRs)
- Missed pages and the usefulness of "site maps" for web app vuln scanning
- Private browsing in Flash Player 10.1
- Presentation about WAFs in the cloud
- How Often Should I Reassess My Web Applications?
- A Fantasy Explanation of Standard vs. Blind SQL Injection
- Researcher demos clickjacking attack on Facebook
- Analysis of 32 million breached passwords
- The Fallacy of Secure Software
Friday, January 15, 2010
Best of Application Security (Friday, Jan. 15)
Ten of Application Security industry's coolest, most interesting, important, and entertaining links from the past week -- in no particular order.
- Top Ten Web Hacking Techniques of 2009 (Official)
- Default https access for Gmail
- new static analyzer from Google
- Purported Interview With Facebook Employee Details Use Of ‘Master Password’
- Software testing firm says no to responsible disclosure
- Web-based systems vs. Advanced Persistent Threat
- The Three Domains of Application Security
- How to Use the Adobe JavaScript Blacklist Framework
- CSS History Knocker (sites you've visited)
- Threat Classification 'Cross Reference View' (TCv2.1 Inclusion Proposal
Wednesday, January 13, 2010
Web-based systems vs. Advanced Persistent Threat
Everyone is giving their $0.02 on the Google v. China situation, and while I normally shy away from blogging about late breaking news, a term Richard Bejtlich used really resonated with me. "Advanced Persistent Threat" (APT). Doesn’t that just capture the essence of the type of attacker we’re up against perfectly? An attacker utilizing 0-day vulnerabilites, spear phishing tactics, one-off malware, and with little time, money, or legal constraints. Now, not all people or organizations using web-based systems are going to be the targets of APTs, but clearly some will be.
Lets broaden out our thinking beyond Google, as the problem is larger than they are, to include other “free” web-based services such as Facebook, Yahoo, Twitter, Microsoft, etc. I believe there is no way the average user can be considered reasonably safe from an APT on these systems. To be fair, these providers make no such claim as they are only built to withstand the lowest-common-denominator of attacker -- not APTs. Since all potential victims are equidistant, practically speaking all it really takes is a username/password or a bit of malware for any online account to be compromised. A very low bar and clearly no amount of SSL, firewalls, Anti-Virus, or CAPTCHA technology is going to raise it.
Secondly, an APTs target is unlikely to have any idea when/if their online accounts are being attacked. The infrastructure is not theirs to monitor. Web-based systems have no real notion of intrusion detection (or even a delete key) unless you include those emails when your account is locked out or password is changed without your knowledge. Even more troubling, victims will not have any idea when/if the threat succeeded in their mission. Next, as if there was any question, these web-based system not legally or fiscally accountable for breaches -- whether it was their fault of not. And finally, APTs will not stop no matter who lays down the ultimatum.
When everything is taken into consideration, any user who believes they are going to be a target of an APT should not be using these systems for anything they can’t afford to lose control over. The fact that the U.S. government is moving their system in this direction really concerns me. Perhaps there is a silver lining. These events could be the stimulus required for a new breed of web-based services to rise up and differentiate based upon security and maybe willing to take on some liability.
Lets broaden out our thinking beyond Google, as the problem is larger than they are, to include other “free” web-based services such as Facebook, Yahoo, Twitter, Microsoft, etc. I believe there is no way the average user can be considered reasonably safe from an APT on these systems. To be fair, these providers make no such claim as they are only built to withstand the lowest-common-denominator of attacker -- not APTs. Since all potential victims are equidistant, practically speaking all it really takes is a username/password or a bit of malware for any online account to be compromised. A very low bar and clearly no amount of SSL, firewalls, Anti-Virus, or CAPTCHA technology is going to raise it.
Secondly, an APTs target is unlikely to have any idea when/if their online accounts are being attacked. The infrastructure is not theirs to monitor. Web-based systems have no real notion of intrusion detection (or even a delete key) unless you include those emails when your account is locked out or password is changed without your knowledge. Even more troubling, victims will not have any idea when/if the threat succeeded in their mission. Next, as if there was any question, these web-based system not legally or fiscally accountable for breaches -- whether it was their fault of not. And finally, APTs will not stop no matter who lays down the ultimatum.
When everything is taken into consideration, any user who believes they are going to be a target of an APT should not be using these systems for anything they can’t afford to lose control over. The fact that the U.S. government is moving their system in this direction really concerns me. Perhaps there is a silver lining. These events could be the stimulus required for a new breed of web-based services to rise up and differentiate based upon security and maybe willing to take on some liability.
Tuesday, January 12, 2010
Top Ten Web Hacking Techniques of 2009 (Official)
Every year the Web security community produces dozens of new hacking techniques documented in white papers, blog posts, magazine articles, mailing list emails, etc. Not to be confused with individual vulnerability instances brandishing CVE numbers, nor intrusions / incidents, but actual new methods of Web attack. Some techniques target websites, others Web browsers, and the rest somewhere in between. Historically much of this research would unfortunately end up in obscure corners of the Web and become long forgotten. Now it its fourth year the Top Ten Web Hacking Techniques list provides a centralized repository for this knowledge and recognize researchers contributing to the advancement of our industry. 2009 produced ~80 new attack techniques (see below).
The diversity, volume, and innovation of the research was impressive. Competition was as fierce as ever and the judges had their work cut out. Rich Mogull, Dinis Cruz, Chris Hoff, HD Moore, Billy Rios, Dan Kaminsky, Romain Gaucher, Steven Christey, Jeff Forristal, and Michal Zalewski were tasked with ranking the field based upon novelty, impact, and overall pervasiveness. For any researcher simply the act of creating something unique enough to appear on the list is itself an achievement. Today the polls are close, votes are in, and the top ten list has been finalized. Researchers making the cut can expect to receive praise amongst their peers and take their place amongst those from previous years (2006, 2007, 2008).
Top honors go to Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de Weger for their work on “Creating a rogue CA certificate.” The judges were convinced by no small margin that this entry stood head and shoulders above the rest. The team will be awarded a free pass to attend the BlackHat USA Briefings 2010! (generously sponsored by Black Hat)
Top Ten Web Hacking Techniques of 2009!
1. Creating a rogue CA certificate
Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de Weger
2. HTTP Parameter Pollution (HPP)
Luca Carettoni, Stefano diPaola
3. Flickr's API Signature Forgery Vulnerability (MD5 extension attack)
Thai Duong and Juliano Rizzo
4. Cross-domain search timing
Chris Evans
5. Slowloris HTTP DoS
Robert Hansen, (additional credit for earlier discovery to Adrian Ilarion Ciobanu & Ivan Ristic - “Programming Model Attacks” section of Apache Security for describing the attack, but did not produce a tool)
6. Microsoft IIS 0-Day Vulnerability Parsing Files (semi‐colon bug)
Soroush Dalili
7. Exploiting unexploitable XSS
Stephen Sclafani
8. Our Favorite XSS Filters and how to Attack them
Eduardo Vela (sirdarckcat), David Lindsay (thornmaker)
9. RFC1918 Caching Security Issues
Robert Hansen
10. DNS Rebinding (3-part series Persistent Cookies, Scraping & Spamming, and Session Fixation)
Robert Hansen
Congratulations to all!
Coming up at IT-Defense (Feb. 3 - 5) and RSA USA 2010 (Mar. 1 - 5) it will be my great honor to introduce each of the top ten during my “2010: A Web Hacking Odyssey” presentations. Each technique will be described in technical detail for how they work, what they can do, who they affect, and how best to defend against them. The opportunity provides a chance to get a closer look at the new attacks that could be used against us in the future.
The Complete List
The diversity, volume, and innovation of the research was impressive. Competition was as fierce as ever and the judges had their work cut out. Rich Mogull, Dinis Cruz, Chris Hoff, HD Moore, Billy Rios, Dan Kaminsky, Romain Gaucher, Steven Christey, Jeff Forristal, and Michal Zalewski were tasked with ranking the field based upon novelty, impact, and overall pervasiveness. For any researcher simply the act of creating something unique enough to appear on the list is itself an achievement. Today the polls are close, votes are in, and the top ten list has been finalized. Researchers making the cut can expect to receive praise amongst their peers and take their place amongst those from previous years (2006, 2007, 2008).
Top honors go to Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de Weger for their work on “Creating a rogue CA certificate.” The judges were convinced by no small margin that this entry stood head and shoulders above the rest. The team will be awarded a free pass to attend the BlackHat USA Briefings 2010! (generously sponsored by Black Hat)
Top Ten Web Hacking Techniques of 2009!
1. Creating a rogue CA certificate
Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de Weger
2. HTTP Parameter Pollution (HPP)
Luca Carettoni, Stefano diPaola
3. Flickr's API Signature Forgery Vulnerability (MD5 extension attack)
Thai Duong and Juliano Rizzo
4. Cross-domain search timing
Chris Evans
5. Slowloris HTTP DoS
Robert Hansen, (additional credit for earlier discovery to Adrian Ilarion Ciobanu & Ivan Ristic - “Programming Model Attacks” section of Apache Security for describing the attack, but did not produce a tool)
6. Microsoft IIS 0-Day Vulnerability Parsing Files (semi‐colon bug)
Soroush Dalili
7. Exploiting unexploitable XSS
Stephen Sclafani
8. Our Favorite XSS Filters and how to Attack them
Eduardo Vela (sirdarckcat), David Lindsay (thornmaker)
9. RFC1918 Caching Security Issues
Robert Hansen
10. DNS Rebinding (3-part series Persistent Cookies, Scraping & Spamming, and Session Fixation)
Robert Hansen
Congratulations to all!
Coming up at IT-Defense (Feb. 3 - 5) and RSA USA 2010 (Mar. 1 - 5) it will be my great honor to introduce each of the top ten during my “2010: A Web Hacking Odyssey” presentations. Each technique will be described in technical detail for how they work, what they can do, who they affect, and how best to defend against them. The opportunity provides a chance to get a closer look at the new attacks that could be used against us in the future.
The Complete List
- Persistent Cookies and DNS Rebinding Redux
- iPhone SSL Warning and Safari Phishing
- RFC 1918 Blues
- Slowloris HTTP DoS
- CSRF And Ignoring Basic/Digest Auth
- Hash Information Disclosure Via Collisions - The Hard Way
- Socket Capable Browser Plugins Result In Transparent Proxy Abuse
- XMLHTTPReqest “Ping” Sweeping in Firefox 3.5+
- Session Fixation Via DNS Rebinding
- Quicky Firefox DoS
- DNS Rebinding for Credential Brute Force
- SMBEnum
- DNS Rebinding for Scraping and Spamming
- SMB Decloaking
- De-cloaking in IE7.0 Via Windows Variables
- itms Decloaking
- Flash Origin Policy Issues
- Cross-subdomain Cookie Attacks
- HTTP Parameter Pollution (HPP)
- How to use Google Analytics to DoS a client from some website.
- Our Favorite XSS Filters and how to Attack them
- Location based XSS attacks
- PHPIDS bypass
- I know what your friends did last summer
- Detecting IE in 12 bytes
- Detecting browsers javascript hacks
- Inline UTF-7 E4X javascript hijacking
- HTML5 XSS
- Opera XSS vectors
- New PHPIDS vector
- Bypassing CSP for fun, no profit
- Twitter misidentifying context
- Ping pong obfuscation
- HTML5 new XSS vectors
- About CSS Attacks
- Web pages Detecting Virtualized Browsers and other tricks
- Results, Unicode Left/Right Pointing Double Angel Quotation Mark
- Detecting Private Browsing Mode
- Cross-domain search timing
- Bonus Safari XXE (only affecting Safari 4 Beta)
- Apple's Safari 4 also fixes cross-domain XML theft
- Apple's Safari 4 fixes local file theft attack
- A more plausible E4X attack
- A brief description of how to become a CA
- Creating a rogue CA certificate
- Browser scheme/slash quirks
- Cross-protocol XSS with non-standard service ports
- Forget sidejacking, clickjacking, and carjacking: enter “Formjacking”
- MD5 extension attack
- Attack - PDF Silent HTTP Form Repurposing Attacks
- XSS Relocation Attacks through Word Hyperlinking
- Hacking CSRF Tokens using CSS History Hack
- Hijacking Opera’s Native Page using malicious RSS payloads
- Millions of PDF invisibly embedded with your internal disk paths
- Exploiting IE8 UTF-7 XSS Vulnerability using Local Redirection
- Pwning Opera Unite with Inferno’s Eleven
- Using Blended Browser Threats involving Chrome to steal files on your computer
- Bypassing OWASP ESAPI XSS Protection inside Javascript
- Hijacking Safari 4 Top Sites with Phish Bombs
- Yahoo Babelfish - Possible Frame Injection Attack - Design Stringency
- Gmail - Google Docs Cookie Hijacking through PDF Repurposing & PDF
- IE8 Link Spoofing - Broken Status Bar Integrity
- Blind SQL Injection: Inference thourgh Underflow exception
- Exploiting Unexploitable XSS
- Clickjacking & OAuth
- Google Translate - Google User Content - File Uploading Cross - XSS and Design Stringency - A Talk
- Active Man in the Middle Attacks
- Cross-Site Identification (XSid)
- Microsoft IIS with Metasploit evil.asp;.jpg
- MSWord Scripting Object XSS Payload Execution Bug and Random CLSID Stringency
- Generic cross-browser cross-domain theft
- Popup & Focus URL Hijacking
- Advanced SQL injection to operating system full control (whitepaper)
- Expanding the control over the operating system from the database
- HTML+TIME XSS attacks
- Enumerating logins via Abuse of Functionality vulnerabilities
- Hellfire for redirectors
- DoS attacks via Abuse of Functionality vulnerabilities
- URL Spoofing vulnerability in bots of search engines (#2)
- URL Hiding - new method of URL Spoofing attacks
- Exploiting Facebook Application XSS Holes to Make API Requests
- Unauthorized TinyURL URL Enumeration Vulnerability
Friday, January 08, 2010
Best of Application Security (Friday, Jan. 8)
Ten of Application Security industry's coolest, most interesting, important, and entertaining links from the past week -- in no particular order.
- WASC Threat Classification v2.0 & OWASP Top Ten Mapping
- Thoughts on an AppSec Program (p1, p2, p3, p4, p5)
- Mr Bean replaces Spanish PM on EU presidency site
- Hacker pilfers browser GPS location via router attack & XSS PoC
- Looking at what makes good Application Security knowledge
- Research page on Web Security Ratings and Disclosure Policies
- NAT Pinning & NoScript's ABE
- Secure Storage using the OWASP ESAPI
- Java EE 6: Web Application Security made simple!
- Ruby on Rails: Secure Mass Assignment
Wednesday, January 06, 2010
In absense of a security strategy
From experience working with all manner of organizations there are a number of unique security strategies present in the industry. Since every business operates differently, perhaps there is no right or wrong approach. That is, as long as the approach is properly aligned with the goals of the business. If not, the end result will lead to failure and in my opinion represents one of the largest, if not the largest, challenges presently facing the industry. That along with “justification,” which is probably the same thing.
Here are the strategies I’ve managed to identify:
Incident Response (aka: public relations)
Ensure that the exact types of previous break-ins, that have also been publicly attributed to the organization, will (hopefully) never happen again. Organize a set of public relations talking points for media inquiry in case it does.
Compliance (aka: satisfy the checkbox)
Satisfy audit requirements for any/all applicable regulations where failure will result in significant business loss. Ignore the rest until they do. Decisions on whether a particular security safeguard is required should be left to the discretion of the on-site auditor, but only after appropriate organizational push back.
Risk Management (aka: control-based)
Implement minimum industry accepted best-practices controls that establish a defensible due diligence posture in the event of incident or public inquiry. Engage with a well-known security consultancy that may positively attest to your organizations adherence via a thorough risk assessment.
Business Continuity (aka: keep the boss happy)
Address any security issues that have previously inhibited managements ability to use email or view online adult entertainment. Other outstanding risks are considered secondary and should be revisited periodically by the security steering committee.
Threat-based
Identify and categorize the various threat agent that must be successfully defended against. Actively monitor threat agent activity, implement security control that limit their capabilities, and generate business-level activity reports.
Competitive Advantage (aka: customer-based)
Obtain a list of essential security controls from key customers/prospects, competitor technical literature, and provide assurance to customers that these highest standards of due care have been implemented.
Obviously many of these descriptions are meant to be humors while still reflecting some resemblance of today's organizational reality. Most organization adopt more than a single strategy to form their own unique hybrid approach to information security.
Here are the strategies I’ve managed to identify:
Incident Response (aka: public relations)
Ensure that the exact types of previous break-ins, that have also been publicly attributed to the organization, will (hopefully) never happen again. Organize a set of public relations talking points for media inquiry in case it does.
Compliance (aka: satisfy the checkbox)
Satisfy audit requirements for any/all applicable regulations where failure will result in significant business loss. Ignore the rest until they do. Decisions on whether a particular security safeguard is required should be left to the discretion of the on-site auditor, but only after appropriate organizational push back.
Risk Management (aka: control-based)
Implement minimum industry accepted best-practices controls that establish a defensible due diligence posture in the event of incident or public inquiry. Engage with a well-known security consultancy that may positively attest to your organizations adherence via a thorough risk assessment.
Business Continuity (aka: keep the boss happy)
Address any security issues that have previously inhibited managements ability to use email or view online adult entertainment. Other outstanding risks are considered secondary and should be revisited periodically by the security steering committee.
Threat-based
Identify and categorize the various threat agent that must be successfully defended against. Actively monitor threat agent activity, implement security control that limit their capabilities, and generate business-level activity reports.
Competitive Advantage (aka: customer-based)
Obtain a list of essential security controls from key customers/prospects, competitor technical literature, and provide assurance to customers that these highest standards of due care have been implemented.
Obviously many of these descriptions are meant to be humors while still reflecting some resemblance of today's organizational reality. Most organization adopt more than a single strategy to form their own unique hybrid approach to information security.
To disable IE8's XSS Filter or not?
Since this article was published, Major IE8 flaw makes 'safe' sites unsafe, I’ve fielded a number of inquiries asking for guidance. Should they follow Google’s lead and proactively disable IE8’s XSS Filter (X-XSS-Protection: 0) until a patch is made available or leave it enabled? Without getting into any technical detail, here are my thoughts on the matter:
If your organization is REALLY concerned about XSS attacks, is VERY confident the website in question is one of the very few completely free from XSS issues (as apparently Google is), and is prepared to fix any XSS issues that surface within DAYS -- then you may consider disabling the XSS Filter to reduce any remaining attack surface until a patch arrives.
On the other hand if you are like most who have XSS, or don't know if they do or not, then leave the XSS Filter alone to do its job -- give your IE8 users a fighting chance.
If your organization is REALLY concerned about XSS attacks, is VERY confident the website in question is one of the very few completely free from XSS issues (as apparently Google is), and is prepared to fix any XSS issues that surface within DAYS -- then you may consider disabling the XSS Filter to reduce any remaining attack surface until a patch arrives.
On the other hand if you are like most who have XSS, or don't know if they do or not, then leave the XSS Filter alone to do its job -- give your IE8 users a fighting chance.
Monday, January 04, 2010
WASC Threat Classification to OWASP Top Ten RC1 Mapping
Update 01.05.2009: From feedback received, added some TCv2 classes that also map.
With most of the work done by Bil Corry (@bilcorry), here is a solid first pass at creating a mapping between the newly released WASC's Threat Classification v2 and OWASP's Top Ten 2010 RC1. This should help those actively using one or both of use documents.
With most of the work done by Bil Corry (@bilcorry), here is a solid first pass at creating a mapping between the newly released WASC's Threat Classification v2 and OWASP's Top Ten 2010 RC1. This should help those actively using one or both of use documents.
Friday, January 01, 2010
Best of Application Security (Friday, Jan. 1)
Ten of Application Security industry's coolest, most interesting, important, and entertaining links from the past week -- in no particular order.
- My Personal Security Guiding Principles
- Popup & Focus URL Hijacking
- Exploiting Microsoft IIS with Metasploit
- Results of Investigation into Holiday IIS Claim
- Cryptographic Storage Cheat Sheet
- WAF vs IPS (or Four Things Your IPS Can’t Do)
- Generic cross-browser cross-domain theft
- Twitter bans obvious passwords
- Web Attacks and Defenses that Could Affect Users in 2010
- SQL Injection Resources
Subscribe to:
Posts (Atom)