Over HALF A BILLION records of personal information have been exposed/mishandled in the past eight years

From the Holy $#@! department, this just in from a ComputerWorld article authored by Jay Kline.

From the article:

By my count, over half a billion records of personal information have been exposed or mishandled in the past eight years. And these are only from breaches where a record count has been publicly revealed.

That's more than the population of the European Union, and more than the number of people living in the U.S., Canada, Mexico and all of Central America and the Caribbean combined.

need I say more, ...

WASC Web Application Security Statistics 2007

For those hungry for more web application security vulnerability data, WASC has released its Web Application Security Statistics report for 2007

Direct link to report is here.

Thanks,
Joe

<<<>>>

Web Fraud 2.0

A couple weeks back Brian Krebs at the Washington Post ran a series on Web 2.0 fraud (here). My apologies if you have seen this already but if not, I recommend that you take a few minutes to check out some of these posts.

Think of this as SasS for the bad guys and if you have not yet been exposed to the existence of these services then I am pretty sure you will find this series *very* illuminating.

Web Fraud 2.0: Cloaking Connections
These days, nearly every aspect of the underground online economy that supports commercial crime operations has been automated. Online forums and criminal social networking sites have long offered aspiring newbies tips on getting started. But a slew of extremely popular...

Web Fraud 2.0: Validating Your Stolen Goods
If there is any truth to the old saying that there is no honor among thieves then it is doubly true for thieves who transact with one another yet never actually meet face-to-face. Perhaps that explains the popularity of certain...

Web Fraud 2.0: Digital Forgeries
For businesses, positively identifying someone online - by name, or physical location - is extremely difficult. Many Internet firms seek to verify the identity of customers by requesting scanned copies of their driver's licenses, passports, or utility bills. But what...

Web Fraud 2.0: Distributing Your Malware
The allure of cyber crime lies in its promise of quick riches, much like that of the illegal drug trade. But building a network of hacked personal computers that can distribute your data-stealing malicious software is a time-consuming process that...

Web Fraud 2.0: Thwarting Anti-Spam Defenses
Spammers have made great strides this past year in defeating CAPTCHAs, the distorted text used as a security test to ensure a person and not a machine is behind a computer screen. But automated programs that spammers use to thwart...

Thanks,
Joe

<<<>>>

In a perfect world, ... what is your webappsec “wish list"?

I was recently asked what web application security model/framework I would like to see within the development process that (assuming all requirements were being addressed) would allow me to enjoy a relaxing, albeit hypothetical =), vacation away from broadband access and the constant worries of web application security. =)

I know, I know, this seems like a silly exercise on the surface but bear with me on this one. As I dove into it further, I realized that it was actually quite helpful for fleshing out my concerns and then mapping these concerns back to possible solutions.

I realized that I spend most of my time trying to manage the expectations of others and I had not yet effectively presented my own expectations.

I am also sensing an opportunity to measure progress within the overall web application security effort and possibly map this back to quantifiable and repeatable metrics as well.


Here is an initial cut at my "wish list" (in no particular order and subject to change):

1. No code defects. Period.
a. Effective Static Code Analysis (SCA) tool will help here.
b. Security issues are exponentially less expensive the earlier in the SDLC they are found
c. Processes designed to catch code defects early are consistent with proactive security
d. "Underneath all our security issues lies our inability to write defect-free code. Solve that and we've solved the security issues. Focus on the security alone and we won't solve anything". (Credit to Ivan: http://blog.ivanristic.com/2008/07/ive-come-to-rea.html)

2. All developers are adequately trained and understand how to write secure code
a. Developer incentives for writing secure code
b. Developer incentives for undergoing/completing security training

3. Ongoing incentives for developers to proactively find defects in application code that they are not directly responsible for

4. No XSS in the application
a. Potentially redundant since "no code defects" above implies no XSS

5. No XSRF in the application
a. Again, potentially redundant since "no code defects" above implies no XSRF

6. Web AppSec team involved as early in the feature conception and business case/justification phase as possible

7. Web AppSec team involved within "requirements" phase as well.

8. Web AppSec team involved within user design and feedback phase

9. Web AppSec team involved during clarification of the PRD (including tech specs and tech review)

10. Web AppSec team involved during implementation plan

11. Web AppSec visibility offered within QA process
a. QA process has complete coverage of entire web application
b. QA regression tests are comprehensive and effective

12. The number of ingress/egress points within the web application will be kept to a minimum.
a. Main authentication page cannot be bypassed for direct access to other pages on the site
b. Only one ingress point into the application (login page)

13. No mixed content allowed
a. HTTPS is required for ALL content on the site
b. This includes requirement for "secure" flag on cookies

14. Entry pages to the app will be kept simple.
a. Authentication/gateway access points to the application are control points and these pages should remain simple in order minimize risk for bypassing security.

15. Access to ALL pages in the app will require authentication

16. Support for Current authentication Security Standards.
a. Authentication scalable to accommodate web services

17. Session identifier timeout value is easily and readily adjustable within the range of 0-30 minutes.
a. Preference is for unique session identifier (single use) per user transaction
b. However performance implications of this dynamic session identifier allows the option to readily and easily scale (on demand) session identifier timeout value to as high as 30 minutes when necessary.

18. All user data is required to be encrypted in transit

19. All user data is encrypted "at rest", specifically Personally Identifiable Information (PII)
a. Column level encryption offered for all customers/users

20. No unknown use cases within the web application
a. All possible use cases have been planned for and identified

21. Application offers complete and granular reporting into user actions to assist with forensic analysis

22. All possible user "incidents" have been planned for in terms of security "events" and a pre-determined course of action is available for all events

23. All data is escaped appropriately when rendered back to the user's browser

24. Threat Modeling and Data Flow Diagrams
a. Ongoing Threat Modeling for the entire web application
b. Current Data Flow Diagrams are maintained for the entire web application

25. Defenses against Distributed Denial of Service (DDoS) attacks

26. Defenses against Phishing/Pharming attacks


My apologies for the long post, ... =)

As always, your thoughts/comments are both welcome and encouraged.

thanks,

joe

<<<>>>

Web Application Security Roadmap presentation at OWASP NYC AppSec 2008

I will be presenting my Web Application Security Roadmap at upcoming OWASP NYC AppSec 2008 conference later this year.

Draft of current presentation is available here.

Judge Orders YouTube to Give All User Histories to Viacom

I posted this to the WASC listserv

From the post:

A link to the court ruling is included in the article referenced above and I encourage you to take a moment to read it if you have the time.

The way I see it, at the end of the day, web application security professionals ultimately work to build confidence and a sense of both trust and integrity for the end user experience. Without confidence, trust and integrity then the Internet as we know it falls away and we are likely left without an outlet for our passion.

Many pieces of this court ruling troubled me and I wanted to share it with the list in case others on the list had missed it.

If end users ever get to the point that they fear visiting public and otherwise respected sites then that seems to do us all a disservice. Does this not encourage the further development of a DarkNet that shields end users from unforeseen liability and if so, does this not also complicate efforts to secure and protect web applications by security professionals?

Sure, maybe I am overreacting but in a world based upon precedents, this one troubles me more than others.

Your thoughts?

Using .htaccess as a Web App Firewall (WAF)

Wow! This just in from the 'Totally Cool and Amazing Department", ...

Rewrite your .htaccess file to work as a WAF

From the post:

Alright, so I rewrote my .htaccess today. Made it smaller and far better than it previously was. It basically is a miniature webapplication firewall that can help secure your server and applications too. Don't be fooled by it's size, it maybe fit into 1KB, it still protects you from nearly every webapplication attack there is. Even if you have holes, they can't be exploited anymore, and thus prevents future bugs and attacks. A solution doesn't have to be difficult, often the simple ones are the most elegant ones. Well, if you don't believe me, go try it out! Simple!

The entire post is here