Friday, May 28, 2010

Tabnapping! Nasty, AVOIDABLE stuff!

Have you read the news about the newest type of phishing attack? "Tabnapping". Nasty, nasty stuff. Sneaky, and believable, and many standard "no script" sort of protections don't stop it.

I've now read several articles on it and I am once again floored at the "what's the band-aid" mentality, and the "how to browse safely" focus of everyone!

Analogy: there is a machine making gaping holes in your street's sidewalk. You inform people about the latest hole. You analyze the hole and how to walk around it. You explain how to avoid it in the dark or see new holes as they are created. But no one thinks about stopping the machine that is making the darn holes!! If the machine can't be turned off then at least blockade your street from the machine. If everyone did that then holes would be much less frequent and dangerous!

Read the article mentioned above. Any of you pick up the key clue on stopping it?? I've been harping on it. Come on, you should know this one by now! Yup, XSS! Tabnapping works by a script on a friendly site's page! How'd it get there? Hmmmmm...SOME DEVELOPER LEFT THE DOOR OPEN ON THE FRIENDLY SITE!

This attack (and many others) can be greatly slowed by developers closing their XSS holes.

Is your site going to be the next headline of poor programming? No more excuses! Close the XSS holes!

Wednesday, May 26, 2010

Facebook (in)security, Heartland settlement with MC, more SQLi woes

Ok ok...facebook and privacy are not related words these days, except in headlines. I feel bad for facebook as they have a good service that truly is connecting people together. But come on. You are this hot service, you gotta have an idea that the target on your back is pretty freaking huge. Every big name gets a big target...it's a law somewhere I think. Yeah, you snicker, but when you get big I hope your doors are locked too ;-).

So a CSRF flaw in facebook is allowing hackers to delete your friends. (Cool if they could silently delete those we hid for being annoying, overwhelming or just plain whacked.) They knew this flaw existed. It took them a while to fix I guess. The same flaw exposes user's birthdays and other private data...even if marked as private. Oh joy! As if their own exposing of your info to third parties by default wasn't bad enough. I'm going to add a poll to see if anyone of you is going to leave facebook for privacy reasons. Note, though, that they came out this week with news about a slew of new privacy options to make it easier to do big ticket privacy items. Now if they close the security holes to make sure what they intend is actually what happens...

Heartland, having already been whacked with over $60 million in settlement fees (that is just the fees to Visa and Amex...never mind lawyers fees from lawsuits, PR fees, etc etc etc) was just hit with the Mastercard settlement...another $41.4 mill. So over $100 million in settlement fees. Anyone want to figure out if you have that in your bank accounts just waiting to be thrown away? Gone. $100 MILLION. Due to mistakes in coding. Due to devs LIKE YOU AND ME not closing XSS and SQL Injection holes. Do you really want to be part of the team causing a headline like that? Close the holes! Need help? Send me an email (greg@bangordevelopers.com) and I will help you get to where you need to be.

Need more web security problems in the headlines? profiles.fring.com has some CSRF holes. Some SQL injection: "A Dutch transit website has been shut down after authorities were presented with evidence of a demonstration that allowed an attacker access to the personal information of 168,000 passengers." read the article

Shoddy passwords, data stolen, sites wiped out, hacking is becoming child's play. This is no one's fault but us as developers. There is no excuse for leaving a site open to XSS, SQL Injection or CSRF.

Not sure how to plug those holes in ASP.NET? See previous posts about it or read up on it at http://www.owasp.org or call me and I'll be happy to come in to do a training or have informal brown bag discussions with your developers to get them on the right track. We have to be in this together! Close those holes and make no more excuses!!

Saturday, May 8, 2010

Vulnerable Sites Database; plus which web language is most vulnerable

Vulnerable Sites Database

Yikes! Just what we need out there. An online database of sites that are vulnerable to web attacks. I hope my sites are never listed in there. Now that the database is in place, and people can sign up and add sites to the list, the ever-growing target on our businesses gets bigger. It is just a matter of time before some of our sites are there. Sigh.

Now, more than ever, we need to educate ourselves, our bosses, and other developers to the dangers we build into our sites every single day. We need to be diligent and persistent. The dark side of the web is making it easier and easier to exploit sites...the info is right there for the taking by anyone with a malicious idea.

Interesting note on that database site. On the right side of the screen is a tag cloud and what are the two biggest phrases in it? If you have to even look at this answer you need to educate yourself quite a bit and need to do it now -- XSS and SQL Injection. In the words of the band Miracle Legion, "Well, surprise surprise surprise".

Are your sites safe? Are you actively coding against these two attacks?

Web programming language security comparison

On another note, there was a recent WhiteHat Security study about which web programming languages have the most vulnerabilities and are the safest, etc. I don't promote one over the other, as it would be like promoting one hammer over another when building a house, but since this blog is all about securing ASP.NET sites, I will focus on those results.

The article at DarkReading.com is pretty eye-opening. I mean, we know ASP.NET has some helpful protection right out of the box, but I had no idea how vulnerable the sites are that are being built in the other languages. Here is a quick summary of points that stuck out to me:
  • "WhiteHat found that Perl, Cold Fusion, JSP, and PHP were most likely to contain at least one serious vulnerability -- 80 percent of the time, according to the report. Strut has the lowest number of existing vulnerabilities in a website, at 5.5 percent, followed by Microsoft's .NET at 6.2 percent." (80%??? 8 out of 10 PHP sites? Ow!)

  • "... more than eight in 10 Perl-based websites harbor cross-site scripting (XSS) bugs versus half for .NET, which was the lowest rate." (I still think HALF being the lowest rate is pretty scary...come on ASP.NET devs, button those up -- it is easy!)

  • "Cold Fusion had the most SQL injection flaws -- nearly 40 percent of the websites had them -- and Struts and JSP had the lowest, with 14 percent and 15 percent, respectively..." (Again I think 14% being the lowest for having SQL Injection flaws is too high. That is 1 in 7 sites built with Struts or JSP. Everyone else is higher! More than 1 in 3 for Cold Fusion sites...ow.)
These were eye opening for sure. It is good that .NET fares so "well" in this, but look at those numbers. Honestly, this blog is about waking up ALL web developers, taking the practical part to the .NET folks.

Talk to your .NET hater friends out there!! Perl, Cold Fusion, JSP, etc...they all have vulnerabilities in their sites, up to 80% of the sites as noted in the first bullet. So talk to them to educate them, and close your .NET holes while you're at it so they can't point the finger back at your sites too. ;-)

See the entire report for details.

Tuesday, May 4, 2010

IE8 XSS Filter

Did you know IE8 has an XSS filter in it? It is on by default in the Internet zone but you have to turn it on in the Local and Intranet zones. You do this in your internet options, about 3/4 of the way down:


More information on it here

But WAIT! What's this?? Maybe we shouldn't set it just yet!

http://blogs.zdnet.com/security/?p=6221

Sigh. For me, I say leave well enough alone for now. Keep the filter, let them update it in June (per the zdnet post link) as it is better than nothing on my Dad's computer.

Stay on top of these things but realize security should never be browser-specific. You will have users to your sites with all sorts of browsers...close your holes and be safe on the web. It is a wild world out there.