Just to help keep you learning about this stuff, here is what sounds to be a really great SANS webcast on XSS and CSRF "taking over the world". Seriously, you have to hear stuff like this one. If it is anything like what it sounds like it will be, it will be worth it to have the pants scared off you. Yeah, sure, watch it nowhere near coworkers then...it is rough to pick up your pants around them and have to explain your being scared.
But seriously, the whole battle is to keep yourself educated and acting on what you learn. I am telling people "CSRF is scary and should be taken seriously". It is #5 on the OWASP Top 10 Risks for 2010, but for me it is #3, behind XSS then SQLi. And I know, I switched XSS to #1. Injection is a huge risk, but XSS is the foundation behind all these crazy attacks. Stop XSS and a boatload of attacks are stopped.
In a New England GiveCamp talk I gave to developers and non-profits over the weekend, one attendee asked about how to stop the attack where they drop off mini VNC on your machine. I have to reiterate here -- I don't care what they drop off and I don't stay on top of what the flavors of attack are. It is irrelevant, frankly. The question was a good one, and I'm not in any way knocking his train of thought. But step back for a sec and see that these dangerous things are being left on our sites through an open door. Stop XSS and they can't do that anymore. We have to stop looking at who is knocking on the door and trying to figure out if they are a good guy or bad guy. Stop XSS and deny whatever isn't whitelisted on your site. Be a good maitre d' and only allow in those folks on the list, whether during input validation or some other function of input.
Speaking of GiveCamp (#negc2010 on Twitter), it was a very rewarding and satisfying experience as a web developer. But I have to admit I was disappointed in the turnout to my talk. Granted, people were cranking on Saturday morning at 9 am...but take 30-40 min to hear about web security, right? Out of the 150 or so people there, I had I think 10. I didn't count but it was around that. Security just isn't given the nod it needs to have, and we will continue to code crappy software. That being said, I know the folks on one team and they are security-conscious and really didn't need to go. But how many others built sites that fall short?
All I know is I better not hear excuses...
Wednesday, June 16, 2010
Saturday, June 5, 2010
Devs Should Be Primary Security Contact
Great article on DarkReading.com -- http://bit.ly/90vL9Y
The core of it is to have devs be in charge of security for a web app. Horrors!! Well, given today's developers, that is one scary and risky thing. But I am all for it. Find the right person, full of energy and willingness to stay on top of web app security trends and you have probably the BEST ally for your security conscious needs.
Here's why -- a) no one knows application development like a dev. Your security analyst can't read all your code and know where a hole might be. b) A good dev can talk to security guys and find a way to meet their needs from a development perspective. c) A dev will always get an ear of the other devs. It might take pulling teeth to get the other devs to code securely but it is sure a better chance than some security analyst or CISO coming in and dictating how they should code! (It's bad enough our project mgt, marketing and PR folks already think they can dictate site design and code to us, as well as the deadlines to meet their needs)
Companies serious about web application security need to train their developers, pick the best of the bunch and make them security analysts for web projects. It is one of the best ways to ensure secure apps.
The core of it is to have devs be in charge of security for a web app. Horrors!! Well, given today's developers, that is one scary and risky thing. But I am all for it. Find the right person, full of energy and willingness to stay on top of web app security trends and you have probably the BEST ally for your security conscious needs.
Here's why -- a) no one knows application development like a dev. Your security analyst can't read all your code and know where a hole might be. b) A good dev can talk to security guys and find a way to meet their needs from a development perspective. c) A dev will always get an ear of the other devs. It might take pulling teeth to get the other devs to code securely but it is sure a better chance than some security analyst or CISO coming in and dictating how they should code! (It's bad enough our project mgt, marketing and PR folks already think they can dictate site design and code to us, as well as the deadlines to meet their needs)
Companies serious about web application security need to train their developers, pick the best of the bunch and make them security analysts for web projects. It is one of the best ways to ensure secure apps.
Wednesday, June 2, 2010
Lightning in Your Cloud Tag Widget
There is a crafty little XSS hole in the cloud widgets of several big name content management systems. It takes advantage of Flash files that allow arbitrary HTML tags to be injected...sigh.
WordPress, Joomulus, JVClouds3D, Joomla and Blogumus as well as BlogEngine.NET and Kasseler CMS.
Read the article on it
So be careful what you put out there...encode it before you just slap it into your handy-dandy cool cloud tag thingy.
WordPress, Joomulus, JVClouds3D, Joomla and Blogumus as well as BlogEngine.NET and Kasseler CMS.
Read the article on it
So be careful what you put out there...encode it before you just slap it into your handy-dandy cool cloud tag thingy.
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!
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!
Labels:
persistent XSS,
reflective XSS,
XSS
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!!
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!!
Labels:
CSRF,
malware,
OWASP,
SQL Injection,
XSS
Subscribe to:
Posts (Atom)