Friday, December 10, 2010

WikiLeaks DDoS and You

So I read a recent article yesterday about the WikiLeak supporters doing DDoS attacks on sites and it got me thinking.

Really thinking.

Consider this -- a group of hackers (and support them or not that is what they are), are bringing sites down at will on a moment's notice. No weeks of preparation, or coordinated touch and then attack. This is "hmmm...them" and boom that site is down. MasterCard, Visa, PayPal, etc etc. Boom. ______ Insert your company name here ______ BOOM.

Botnets are out there just twiddling thumbs. Some C&C (command & control, those "mothership" servers that command and control the bots at your parents' house and my uncles' house and those of the annoying admin assistants at work that forward you all those emails with smiling cats and angels and hearts and "you mean the world to me") servers are just sitting idle, a hair off the network. Infected machines are everywhere. Maybe mine right now. Maybe yours. Waiting. Some C&C comes online and says "Hit Greg's site" and voila it is down.

So why is WikiLeaks freaking me out a bit? I think WikiLeaks is a great thing. I really do. I may be wrong in thinking that, and to be honest I haven't researched the laws, but if you are dumb enough to leak out confidential stuff then it isn't their fault for publishing it. After the first few leaks, you'd think integrity and ethics would keep people from leaking info...ah but that isn't human nature, which dictates self-aggrandizing and soap boxes! Anyway, without more editorial, what is happening with WikiLeaks freaks me out because it shows that an organized group can take down big sites at will. If big sites are having problems, your mom and pop shop will too.

I have been soapboxing about devs learning about security and plugging holes. And the DDoS attacks show that even that won't stop them. You have to mess with DNS. And we all know how many people are good at messing with DNS and getting it all back in order a month later. It ain't the devs who can't close XSS holes that have been open since 1999! That's for sure.

So here are the pieces and you tell me how it affects you:
  • Crippling attack

  • lack of understanding of attack

  • lack of resources to stop attack (expertise and time in-house or $$ for out-house)

  • lack of understanding and resources to bring things back up

  • lack of disaster recovery plan in most cases

  • this attack brings your site's server down...oops is your email on there too?

  • this attack is not stopped by anti-virus or strong development best practices

  • this attack can happen to anyone at will and on a moment's notice

How do you rate in those? How about your company? Your friends? Your family? Your nation?

If a big huge attack has not been done yet, it is simply not yet time. The pieces are there. The code is there. The bots are there. It is just a matter of time before a set of things are brought down at once. Or that you or I say something that makes someone mad and boom...we are down.

I read how one guy did DNS changes that basically redirected the DDoS attacks back on the C&C server and it brought down the attack! ha! Classic and well done! But that is rare. You and I don't have that working for us. What can we do? I look forward to some comments and input on this one.

I am available for consultation or idea swapping on this sort of thing. In addition I train and speak to .NET developers about securing their web apps. Even though this sort of DDoS attack is not stopped through standard ASP.NET programming, there are lots of places where other attacks come through your apps. XSS and SQL Injection continue to run rampant. I can help you cut your risk of damaging attack significantly by doing a code review, training your developers or just helping you with next steps. Contact me at for more information.

Thursday, December 9, 2010

Security in Apps Becoming Mainstream

Interesting article in DarkReading the other day about app security becoming part of the enterprise for software development.

It appears that folks are getting the first part of the solution, which is a nice start. Well, ok, we'll say the second part. The first part is really listening. Many of us aren't even there yet. The next step is to realize it needs to be part of your development process.

So here is what happens: you are in the dark, you hear about the issues for the first time and think "oh crap", you then panic and make all your developers get trained and stop 100 different things, they burn out and argue with you and it falls apart a bit. Take a quote from the article:

Sima also argues that too many firms ramp up their secure development programs too quickly. While training developers to write more secure code is a good thing, project managers should not go overboard, he says. Rather than try to tackle the top 10 or top 25 software issues, companies should instead take a small bite.

This is GREAT advice. As I have mentioned in previous posts, just learn about XSS and SQL Injection. Learn about them -- what they are, how they work, how to stop them. And then act on what you know. Taking care of those two alone will stop about 70% of all web attacks on your site.

Don't even tackle the top 10. Read up on them. Then tackle XSS and SQL Injection. Get your feet wet while you stop 70% of the attacks. Then move from there to CSRF, Authentication issues, Session issues and lots and lots of other things.

Just so you know, I can help you too. I am happy to work with you to train your .NET developers, or do code reviews or just consult with you on next steps. Drop me a note at and I will be happy to show you how easy it can all be.

Wednesday, November 3, 2010

Lots Going On

I'm back after a month hiatus or so. Figures I'd get too busy to blog right as so many juicy "write about me" sort of things happen. To be honest, I hope you've wondered what my take is. Not that I'm some security guru, or the man in the know, but because it means you are interested in this stuff and realize I am too, wanting to hear more about what I am seeing from the trenches.

Either way, here is my take on the last month, plus a peek at what is coming down the pike/pipe.

ASP.NET Oracle Thingy

So this was a biggie for .NET developers, ASP.NET developers in particular. As you likely know by now, it had nothing to do with Oracle Corporation or any of their technology. I won't explain what it was, since others have done better than I ever could. The vulnerability hit the internet blog posts mid-September and a fix was in place soon after. Microsoft ranked it as a big deal, though my first glance at it was no big deal. I still think they made it a bigger deal than it needed to be, but honestly it was refreshing to see such movement and activity on it. So why didn't I think it was a big deal? It was something that would take some time to exploit. Sure, the payloads of web.config files and all that would be worth it, but it takes quite a bit of exploit attempts to get the thing to work.

Now, to play the other side of things, which I enjoy doing as well, I REALLY hope you have applied the patch Microsoft gave you for your servers! My lack of whizbang about the issue doesn't mean I find it something to ignore. In fact in this case it is the opposite. The noise and commotion over this vulnerability makes hackers go "ooooh, pretty lights..." and head TOWARDS the issue. If they weren't trying it before, they sure are now. I have no formal study-borne proof of my assertion, but I know human nature. Didn't it cross your mind just a little as to whether YOU could execute it? I did mine. I thought it would be cool to write a routine that ran through some stuff and tried it over and over, even if only on my localhost. The truly bad guys/gals are too. And for some reason this exploit seems accessible to isn't all complicated I guess.

Anyway, PATCH YOUR SERVERS if you haven't already.

Lots Of Us In The News

Ok. So not me and likely not you. But we have to understand that though it was "them", "thems is us". How close are you or me from being a negative headline? In the last month news broke about healthcare data compromised, bank accounts broken into, Twitter hacked using onMouseOver javascript to send you to your favorite porn site faster, Twitter had a password-stealing phishing scam hit many people including CNN anchor Rick Sanchez (though it was a rather amusing hack), Facebook had at least one notable issue, and the SCADA attack showed us how subtle, intense and intelligent pockets of the hacker community are. The SCADA one in particular causes me anxiety. Facebook, Twitter, etc...close your holes already and adjust with the zillions of people who are on your systems. Not that these were avoidable in every case, but keep being diligent on closing holes. If you are popular then you are a huge target.

The SCADA one, however is different. Getting people to download a piece of software silently by just visiting a website, having your machine attack a single system in a concentrated effort, knocking that system down and still not being sure who attacked it...that to me is scary. Now, granted, where did it all start? Getting people to download software. They can either be silly enough to just surf to random sites where the software sits, or it is a good site that they go to that is silly enough to not close its holes. Again, Cross-Site Scripting and SQL Injection can really put the hurt on and allow lots of other attacks get the foothold they need to go forward.

Looking Forward

I don't like to look too far forward in this field. It is a lot harder to predict than general technology or programming. But this is so clear and getting clearer every day. What is happening is that hackers are looking more at the application layer and developers are lagging more than ever. As we educate the good guys, we point out our flaws to the bad guys. And frankly, they have more to gain in attacking than we do in defending. Defense costs money and if you do it right you have nothing to show for it. "Hey boss! I need a raise! Nothing has hit us for a year!" Uh, yeah. Unfortunately, if nothing has hit you, it could be you are really good at defending or that hackers just haven't given you the time of day yet.
I am predicting a higher use of CSRF and that is coming to pass. I am also predicting that we are just seeing the tip of the iceberg on successful, intelligent attacks. SCADA, though somewhat complicated and highly organized, wasn't all that difficult. We still have the easy holes to plug. Once we plug those, and I don't know that we ever will completely, they will be a few steps ahead of us, ready and waiting with more complex attacks. I'm a glass half full guy, really I am, but the state of software security has me wondering WHEN not IF a large full-scale attack will wipe out the internet for an extended period. The bad guys are already taking our money from our accounts, stealing data from our companies, attacking our systems and they already are doing it rather silently. They are growing in understanding and savvy. We aren't. We aren't. We aren't.
Our bosses still expect us to make our sites 100% secure (impossible), and they are not training the rank and file developer on security. "You are the security folks. I count on YOU." But we can't follow every developer and do code isn't feasible. We are still building crappy software and sites full of holes. And if you aren't even sure what the holes are in your code, shame on you but you aren't alone. Let me know if I can help. I am willing to educate you, point you to awesome training materials and sites, look at your code, build something for you. It really is time to get off the sidelines.

Saturday, September 18, 2010

CSRF On The Rise

If you have heard any of my talks in 2010 you know how scary CSRF (Cross-Site Request Forgery) is and how I think it will be taking off and going from #5 in the OWASP Top 10 to #3 (hard to top SQL Injection and XSS at #1 and #2). It hasn't gotten a lot of press, and there hasn't been a ton of action on that front by the bad guys...yet.

But this week an article in DarkReading about CSRF came out that shows it is starting to increase. My comment at the bottom of the article should sound familiar to those of you watching this blog (I think there are 4 or 5 of you out there, right? ) -- the press and the noise is still about patching and server-side, network-facing solutions. They are band-aids and stitches fixing holes that will continue and continue until developers learn to code more securely.

"Blah blah blah" some of you may be saying. "Same old same old. Show us something more, Greg." Well, if you thought that, or said it out loud, I have to ask "Are you actively coding against SQL Injection and Cross-site Scripting?" If you are, and my spiel sounds old, then it is time to move on away from here. And CONGRATULATIONS, Grasshopper! You have become a better developer and that is a success for us both in my book!

For the rest of you, please dig in. Read my previous posts and go to sites like OWASP and and see how to code against SQL Injection and Cross-site scripting. These two things alone will help us all.

So what about CSRF? What can I do about it? The short answer is that the hole is plugged at the destination of the attack, and that is by validating all actionable requests thoroughly. Huh? I will do more posts about CSRF, what it is, how it works, but in general it is that you have to make sure requests come from someone you know already, that has logged in and has a specific signature or footprint so you know every request that comes from that person. Analogy time -- if someone came to your door, 6 ft and blonde, and hands you their username and password, then you can generate a ticket and session for them. If someone 5' and brunette comes to the door with the first person's ticket, is it the first person? Obviously not, but our web servers only look at the ticket! If you have the ticket you MUST be the right person. Ouch! This is what makes CSRF work, executing an action on someone else's behalf. So the solution is to look for the 6ft blonde on each request using that ticket. For you .NET folks that solution is via the ViewStateUserKey. ViewStateUserKey can be set to the session id of the current user and that will be enough to show the server it really is the right person. The hacker won't have viewstate in a link, and if they try to create a whole form to do the work it won't have the current session in it. Ahhh...much better! (Side note about it not being perfect found in this article.)

So now maybe I will have to harp on proper CSRF coding as well as SQLi and XSS...

Wednesday, August 25, 2010

Great Training

I just took this course, in order to prepare for the GSSP-.NET certification and they've updated it to be language agnostic and cover what is really necessary and important for web developers to know. It focuses on the OWASP Top 10 you hear me talk about, etc. (This is a nice change from what was really a B or C+ course) You need to take this course if you build web apps -- .NET, Java, PHP, whatever. Take this course.

Saturday, August 21, 2010

More SQL Injection Woes

These happen all the time, but hey it is in the headlines now so let's throw this one out to you as well. From newsletter I get:

--Japanese Online Supermarket Database Hacked (August 15, 2010) Attackers reportedly used SQL injection attacks to steal customer information from the databases of eight Japanese online supermarkets.
The attacks took place in late July 2010. Some credit card companies have reported fraudulent activity on accounts compromised in the attacks.

CLOSE THE SQL INJECTION HOLES PEOPLE! It is easy to do...parameterized queries! Email me if you aren't sure how to do them in ASP.NET.

Monday, August 9, 2010

Quiz #1 Answers - SQLi

OK, here are the answers...let me know how you did!

Q1. Parameterized queries are 100% effective against SQL Injection. True or False.

TRUE! SQLi is a PARSING issue, and using a parameterized query does not allow you to parse additional commands among your intended one.


Q2. If you can't do parameterized queries, then you can do stored procedures in the database. They offer you the same level of protection. True or False.

FALSE! Though I recommend stored procedures to avoid mistakes on the business and data layer of .NET code, among other reasons, it is no guarantee the DBA coded the stored proc to use query parameters. He/she could still be concatenating the parameters as strings into a SQL command...ouch.


Q3. Neither is perfect, but which is better for validation: black-listing or white-listing?

White-listing is better because you know what you want and can check for that, discarding anything else no matter how tricky the hackers try to get. If you black-list, you run a huge risk of missing tomorrow's new attacks, or of canonicalization errors where the hacker encodes the attack one layer deeper than where you look. Don't chase hackers, trying to learn their latest tricks...know your holes and plug them.


Q4. If you thoroughly validate your input then you should be fine. True or False.

FALSE! Most validation is done client-side. And with javascript. Turn that off and see how your web page reacts. Even with good server-side validation, you have to accept strings sometimes...and those can be used to nail you with SQLi. That being said, you do make huge strides when you validate thoroughly...always do it! Makes your job of stopping them so much easier. It just isn't enough on its own to stop them, so don't rely on your best efforts as a "be all end all" sort of thing.


Q5. Removing single-quotes from input data is an effective means of preventing SQLi. True or False.

FALSE! Well, true, but false. Getting rid of single quotes is one part of defense in depth. It will stop them from ending a string and putting a new command after it. Sure. But the hacker can encode it to hide it...are you checking for that? It can be part of a last name like O' you let that through? Like other validation methods, it isn't enough to scrub out single quotes and sleep well at night.


Q6. SQLi defense is like chasing a wind: by the time you figure out what to do it shifts and you have to do something else to protect your apps. True or False.

BIG FALSE! Go back to Q1. Make your queries parameterized. Done. It isn't hard. Like I said earlier, don't chase the wind...don't keep up on every hacker trick so you can be prepared for them. Instead know your holes and plug 'em. Analogy -- don't stay on top of what tools people are using to break into houses through windows. Instead, put bars on your windows, lock them, etc. Know what the holes are and plug them, rather than finding out what tools are being used and trying to thwart each of them.

SQL Injection is TOTALLY preventable. And it is YOUR responsibility to code for that. If you didn't get all the above correct, you are not alone. Just dig in more at sites like and read up on SQL how to do parameterized queries on MSDN...etc. You can do this!

Thursday, August 5, 2010

Quiz #1 - SQLi has been awhile since I've posted...been busy! One good thing out of this time away is my passing the GSSP-.NET certification earlier this week. Yay me! Honestly, though, if you are a .NET developer for Windows or Web you need to take this exam. 100 questions that cover everything from SQLi (SQL Injection) and other web attacks to how to put appropriate Code Access Security (CAS) on your DLLs and EXEs to how .NET security policies are set up for proper permissions to be granted on your apps.

Since I am in test-taker mode, I decided the best things to post right now are some questions based on what you should know. If you get the questions wrong, don't worry but instead dig in a little and learn why. Find out what the hackers already know!

So, quiz #1 will be on SQLi. Feel free to post your answers and I will let you know what the answers are in a few days or so. I will not post your answers until I have enough there to post them. No fair having some smarty pants get the right answer before you've even read the question, and then you see her/his answer in the comments, right?

Q1. Parameterized queries are 100% effective against SQL Injection. True or False. (Nothing like starting off with a holy war sort of question, huh?)

Q2. If you can't do parameterized queries, then you can do stored procedures in the database. They offer you the same level of protection. True or False. (hee, another holy war sort of question)

Q3. Neither is perfect, but which is better for validation: black-listing or white-listing? (Black-listing is looking for malicious characters/strings and removing them. White-listing is telling the app what you expect and denying everything else.)

Q4. If you thoroughly validate your input then you should be fine. True or False.

Q5. Removing single-quotes from input data is an effective means of preventing SQLi. True or False.

and last one:

Q6. SQLi defense is like chasing a wind: by the time you figure out what to do it shifts and you have to do something else to protect your apps. True or False.

Good luck! I am very interested in your answers! Those that answer all six correctly will win a free round of applause from me.

Friday, July 16, 2010

"Why Can't Johnny Develop Secure Software?"

"Why Can't Johnny Develop Secure Software?"

What a great article from It points out what I've been saying all along and has some nice insight too. Not that I need or want validation -- I know the truth about developers and the lack of secure programming -- it is just nice to see bigger names and bigger press about the issue. The more we see about this, the more likely things are to change.

Best quote of the article:
But nearly all experts agree that no matter how strong the training effort, the average developer will never be very security-savvy. "They're always going to be more focused on code quality and trying to meet their deadlines," Sima says. "If I'm a developer, as soon as I've been assigned a project, I'm already behind. If there's a faster way to do something, they're going to take it, because for them speed is more important than security."

Wednesday, June 16, 2010

XSS/CSRF Webcast

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 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...

Saturday, June 5, 2010

Devs Should Be Primary Security Contact

Great article on --

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.

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'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 ( and I will help you get to where you need to be.

Need more web security problems in the headlines? 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 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 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!

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.

Tuesday, April 20, 2010

OWASP Top10 Final Copy Released

OWASP ( just released the final version of their Top Ten Risks for 2010 document. For those of you that have seen my talks on web app security, I was working off the Release Candidate so you will want to read up on this final version.

Friday, April 16, 2010

CSRF Big Deal or Not?

Great blog post about CSRF and whether it is a big deal or not.

You have to read this and then read all the comments. Great feedback plus back and forth by folks in the field. The important thing is to keep this topic and others in our minds, and share the knowledge with other developers. Only you can prevent forest fires...wait, I mean, web attacks.

Wednesday, April 7, 2010

New category of XSS attack -- so what?

In DarkReading ( there is a current article about a new type of XSS attack that exploits services that provide networking data, where malicious data is stored in TXT records or other back-end things and are then returned by a service where it is executed on network admin screens.

Uh...this is no different than any other XSS attack. Sure, new category. Sure, really tough to find. But hellooooo? You have input from an untrusted source (data file) that you are taking and displaying to a screen. Service developer, scrub your output! Network app screen developer, encode your output! Duh!!! Come on people. This just shows that we need to be aware that hackers are going to a deeper and deeper level in our systems. As we patch our brochureware sites, they are going to the network folks that don't care to be security developers. But we have the responsibility to do it right.

And it is easy. Please encode and stop XSS!

Sunday, March 28, 2010

Interesting (No) Show of Hands

Yesterday I spoke at CodeCamp 13 in Waltham, MA about web app security. Two talks, one for XSS and SQL Injection, the other for CSRF and discussion about the rest of the OWASP Top 10 list. During the first session I asked a set of questions to see first-hand whether what I had suspected was true. People were to raise their hand if the first question was a "yes" answer and leave it up until they answered "no" to a question.

Here is the set of questions, in order. Note the spot where you can't answer a question with a "Yes".
  1. Do you build web sites/apps, web services, or windows apps that use a browser control?

  2. Do you know what SQL Injection is?
  3. Do you know how it works?
  4. Do you actively code against SQL Injection attacks?

  5. Do you know what XSS is?
  6. Do you know how it works?
  7. Do you actively code against XSS attacks?
Did you answer "yes" to all seven questions? I had 26 people in the talk and almost all raised their hand for the first question, which makes sense. After all seven questions, not a single hand was left up. There were 3 or 4 people who made it through six of the seven questions, but no one actively codes against those attacks.


Think about this for a second. This was at a CodeCamp, where real developers go. There were hundreds of developers that didn't attend the event. There were 26 people in the room with me, so those are those most interested in security. There were dozens and dozens attending other sessions at the event at the same time, missing my talks by choice. So the most likely people to be good at protecting their sites are not actively protecting their sites against the top two attacks. Granted some gurus there likely didn't attend my talks since they already do all the work and didn't need them, but this is a clear statement to me about what is not happening in the development community.

Do I blame those folks that attended my session(s)? No way. They had great questions, were honestly concerned, and I know they left with a desire to turn things around. They were a great bunch for sure. But I hope it showed them, as it did me, that this is the norm. There is a lot of work left to be done to educate people on secure web app development. Hopefully the army is a little bigger after yesterday.

Reflected vs Persistent XSS

Most of us by now know what XSS is, how it works and how to stop it. But you may be hearing a bit more now about "reflected XSS" or "persistent XSS". What are they and how are they different, and most of all does it matter?

Reflected XSS

Reflected XSS is when the attacker sends along a link to a vulnerable page with a script in it and victims run the page as the attacker wants it set up. For example, think of search engine pages. If the attacker puts something in the search text so that search results are compromised, he/she can send you a link to that exact page. When you click on the link to that page YOU get the compromised search results and the attacker has you right where they want you...script running on your browser automatically.

Many times reflected XSS is used to grab your cookies so they can impersonate you, but obviously it can be for other things too.

Persistent XSS

This is where a site has malicious code on it, either on purpose or via user input. The victim may be going to a legitimate page with a malicious post (think discussion forum on legit site), or a malicious page whose intent is to attack you or others using your browser.

On thing malicious XSS sites are doing these days with persistent XSS is to infect your machine with malware. They accomplish this by telling you that you need to download a codec to view a file on their site. You accept the download and get the malware.


Something we can agree on is that we can all avoid going to malicious sites for the most part. We just stick to nice neighborhoods and avoid the skeevy ones. But malicious posts on trusted sites are hard to avoid. Consider You go there to solve a tech problem and you hit a post with 15 replies. You get all 15 replies, like it or not. Those posts may have images that are pulled, etc. Before you go to the page, do you know if the page has a malicious script on it? You open the page and BOOM, everything runs...ain't a thing you can do about it either. (Don't worry, StackOverflow does not have this vulnerability, but do you know if other sites you hit are not vulnerable?)

Using something like the NoScript FireFox plugin is a smart thing. It blocks scripts until you allow them for a page or site. So the one bad post out of 15 will have its malicious script blocked unless you say it is ok to go to and pull their script (in that case shame on you).

Final Thought

So now you know reflected and persistent XSS attacks. Do their differences matter? Maybe, but only from you being a USER so you know what to look for or watch out for. IM's, email links, links on pages, etc. Being a web dev, it doesn't matter at all. Stop allowing XSS on your sites, period. You block them the same way. Stop making excuses and get your site plugged, which stops all XSS attacks cold.

Wednesday, March 17, 2010

About eBay Vulnerabilities

So mid-February it was announced that eBay had some exploitable parts. Not cool! Guess what they involved? One had cross-site scripting (XSS) and another had SQL Injection. A third, that may still be unpatched, is a cross-site request forgery (CSRF) hole. Huh. Surprise surprise! These are the top holes, and have been railed about for years, literally. And here is another example of a big company with lots of developers with those old holes in place. Granted CSRF is tricky and sorta new, at least newly being exploited. But XSS and SQL Injection? Wow. The holes were in rather non-standard pages, but doesn't the mini basement window at the back of your house still get you in, where you can unlock the front door from the inside?

No more excuses! Patch those holes BEFORE you become a news headline! Oh, speaking of which:

Here is a good paper on what the top holes are and how to fix 'em: And in the coming weeks I'll give a full explanation of SQL Injection and CSRF to help you if you need it.

Sunday, February 28, 2010

Why a Crippling Attack Against US Companies is Very Possible

Sure, some people are doomsayers and we look at them as fringe folks with a grain of truth expanded out to being an entire movement. I'm not being a doomsayer, but a realist, when I say that a concerted web attack on US companies is very possible.

First, in America we believe we are invincible and the smartest, most savvy people on the earth. We are prideful and boastful and believe we deserve every good thing, whether we work for it or not. I know that is a generalization but look around at the people in your neighborhood...I may not be describing YOU but look around you. In the "You serve me" mentality, people think security is someone else's thing, and that others will protect them. In companies, I've seen it where dollars outweigh quality and bad software gets shipped. If they are cutting corners on functionality, do you think they are even doing security on the pieces they create?

Second, we all know security is not "baked in" yet. It is something people add on top of the functionality that makes them money, if they get time. And right now times are tough you think companies are going to invest in baking security into the software lifecycle? While cutting jobs or shipping them overseas? While cutting corners and costs?

But the bad guys aren't taking time off to let us retool. What happened to Google and Intel and other companies lately is going to continue. Our image of everyone else in the world being less intelligent than us leads us to both our lack of diligence and to their anger against us. Do IT folks (and comical TV ads) bash Microsoft for just the same reasons of them being the arrogant big guy? Like it or not, people are putting our machines under their silent control and putting things in our hands to use against our own companies, government agencies, etc. Some of these botnets are for spam but it is clear now that no one is immune to flat out attack. A little social engineering and mom & pop machine takeover and you have a virtual army set to strike.

Recent stats say that 3-10% of all corporate PCs are compromised right now with malware that most likely puts them into a botnet. These are the places with good protections in place.

This blog started because I was floored at how many developers in big named companies were building sites with big security flaws. I assumed the little guys weren't doing security the best but to see some big companies not doing it floors me. As "invincible" Americans we learn many lessons the hard way and it is not going to do us, and the country we love, any good to learn this lesson that way.

If you are not learning about web security today, and making sure your sites don't allow for attack on/by them, then you are giving some really bad, money-driven people a foothold, a soldier. Enough footholds and you have an army.

My thinking is that many of the devs won't read this post at all even if presented with it, and if they do read it they will poo-poo it as someone else's concern or some doomsayer's rant. It is the way we are as humans and Americans, and we run a strong risk of falling hard simply by not doing the grunt work today.

Saturday, February 27, 2010

Chilean Earthquake search results and your code

So after this morning's earthquake in Chile, it appears that the lovely new (and effective) fake anti-virus software is being propagated out through bad web sites that have cloaked themselves as being about the earthquake and had gotten themselves to the top of the search results on engines like Google. Unwary clickers would go to their site and voila, you've got a virus and they'd LOOOVE to fix it for you. Sigh. Sure, the bad sites will start going further down the list as the day wears on and real sites start getting back to the top based on volume and people linking to those articles.

"Whew!" you say, "Better that this isn't something that is on MY site! Man I could get in trouble for that!" Well, other than just plain old bad sites willingly hosting the fake anti-virus software, you have to be aware that there are other valid sites that the software is coming from (until it is noticed and removed). Is it one of yours?

If you have XSS allowed on your site, especially if you are hosting a forum or discussion group at all, you may have links right to that software ON YOUR SITE. You have to make sure you have XSS covered in all places. If I am a hacker, I'd set up the bad site for search results to have an IFRAME that points to your site which has another hidden IFRAME that grabs the software from a third server. You may be an unwitting contributor to today's malware distribution.

Lock it up and keep your sites out of the mix!

Friday, February 19, 2010

Top Groups Say Devs Should Be Liable

I love this! I'm not the only one saying this stuff. SANS and Mitre are now saying it out loud too -- developers should be held responsible for their product's security.

"Vendors Should Be Liable for Code Security (February 16 & 17, 2010) The 2010 CWE (Common Weakness Enumeration)/SANS Top 25 Most Dangerous Programming Errors list points to cross-site scripting (XSS), SQL injection, and buffer overflow vulnerabilities as the causes of nearly all major cyber attacks in recent years. The consortium behind the list, headed by the SANS Institute and Mitre Corp., is also publishing draft language to use in procurement documents that would hold software development organizations liable for product security."

Monday, February 1, 2010

XSS Part 3 - How to stop the attacks

In this third of four posts on XSS you will learn how you can stop XSS attacks cold in your ASP.NET apps. "What? Me? Stop them? But those are vicious, deadly attacks by professionals and I am just a newb!" Oh cut it out. Quit your whining and understand that if you don't stop them, they will get your data or attack your company. Find out how to stop the attacks and make it so.

So, in previous posts, we saw what XSS is and how the attacks are executed. Keep in mind the nasty things like img tags that simply execute what is in their "src" attribute without any thought to whether or not there is a real image being returned. If a hacker puts inline script or a URI to an offsite script into the src attribrute, then the script will be returned and executed in your browser.

Ow! So what can be done? Is all lost?? No of course not...settle down. First of all, the bad img tag needs to be on your site somehow. YOU won't put one there, so how else can it get there? Well, if you allow comments on your press releases or on photos on your site, or you allow users to supply input that gets stored or processed for redisplay on your site (comments, posts, discussion groups, user content, profile, etc) then you have to block XSS from happening.

Whitelist Data Entry

Go to those points of data entry into your system, and don't forget things like URLs that you process. Consider whitelisting all input. What is whitelisting? Well, you know that a blacklist is something you don't want to be on because it keeps you out of fun places. Anyone not on the list is allowed in -- but in our case, what if you forget to add the next new method of attack that comes out? And did you catch every way that the attack could be encoded to hide it and beat your filters? A whitelist is the list of acceptable input for a point of entry. Everything else is disallowed -- this protects you now AND in the future. And the maitre d' doesn't accept bribes.

Think about your site's contact form that asks for name and address info. Why accept 4000 characters in the city field? Why accept special characters in a zip/postal code field? Whitelist acceptable input for those fields.
  • Limit your input

  • Strongly type input where possible

  • Do NOT rely on input constraints to save you

Do NOT Rely on Input Validation/Whitelisting Only

That last point is important. Very important. In many cases you use javascript to constrain and validate input on the client side. Whoops...I just turned off scripting in my browser and now I am entering a script tag into the address field! So why bother constraining input at all? Good question. The thing to keep in mind is that input validation should be viewed as a help to your users. Constraining your input is good to stop casual hackers from trying some things, but anyone really trying to get in will not find your input validation a hindrance. So you should set up validators to help someone realize that your address field is only 30 characters when they entered 35, or that a valid phone number does/doesn't accept dashes. That sort of thing.

What To Do If The Whitelist Idea Isn't Possible

Another reason to not rely on input validation is that in some cases your whitelist is going to be too broad to stop some things from happening and/or you can't whitelist easily. Let's say you have a piece of code that looks at the querystring and spits some things out to the screen based on it: for example.

This page is going to get data based on the region querystring variable, and then use that variable as the title to the graph of data. Sure, not a best practice website right there, but you sometimes have to work with other peoples' code, dontcha? So the code grabs the region variable and pulls data, showing a message "No data found" if there is an error or if there is no data found. The logic then takes the region variable and puts it in a label control on the screen. Easy enough! Weeeelllll, let's put some script in the querystring and see what we get!<script>alert('hi')</script>

Clearly, this "region" will not return any data and will probably return an error of some sort. But what about when we take the variable and put it into a label control? Can you be sure it won't be put to the browser "as is" and executed as script?

What if the web page takes in a comment about the website and upon postback says "Thank you for your feedback. The following has been sent to our staff: your comment here."? And you want to let people put html in the field so they can bold their nasty words and up the font size when they are yelling at you. What if someone puts the above script tag in that field? You get the idea. People can and will misuse your forms to put script in there. Will the script attack you? Maybe. Could be setting up shop to use your server as a member of a botnet...or opening a gate to distributing malware to attack Land's End. Who knows? Anyway, whitelisting won't help you in some cases.

Encode Your Output To The Screen

One of the best (and only) ways to protect your web pages is to encode all output to your browser. Assume it has been tampered with or is user-generated (we never trust users) and put the proper encoding on all of it. Hey, let the input come in decoded and nasty, and then process it normally, but then encode it before you put it back to the screen. Like with the region example above, who cares if you try to query the database for a region with a script name? (It DOES matter, but we will cover this when we talk about SQL Injection.) So the database returns no records. Great! But if your page takes the input and does a Response.Write() or some other method of putting the raw input to the screen, you need to encode it.

To encode it, you may think to use HttpUtility.HtmlEncode() as mentioned in Microsoft's Patterns and Practices on preventing XSS attacks. This works great for data going to HTML. But what if the data is going to an img tag, an attribute of another tag, the URL, or is being inserted into javascript? HTML encoding may not be what you want. I highly recommend you use Microsoft's new Anti-XSS Library which gives you more granular control with different methods that go to javascript, URL, HTML, etc. You just put the dll in your bin and use the methods in your code.

Whatever you use, encoded script won't run. Period. Doesn't matter what the pesky script would have done, it becomes plain old text that is output as is to the browser rather than executed.

ASP.NET's Default Protection Against XSS

The nice thing for all of us is that ASP.NET 1.1+ has built-in protection against XSS by looking for script tags or other dangerous things. If someone tries to put script in there, including ways where they try to obfuscate what they are doing, the ASP.NET engine sees it and gives you an error message like the following:

A potentially dangerous Request.QueryString value was detected from the client (txt="<SCRIPT SRC=http://h...").

This is turned on by default. Great, right? Well, us lovely developers hit a message like that and wonder "How can I turn that off so I can allow b tags in my content?" We see, "Oh! It is just a page-level attribute!" and turn it off. Sigh. The attribute is ValidateRequest and it is set to True by default. Sure, set it to False and then tags are allowed through...but hey wake up! Tags are allowed through! You've just given hackers an open door. Find other ways to allow b tags. Which is better, a user complaining they can't bold something or a user complaining their social security number was stolen off your site? Your call.

Remember that the default protection is only on the request so you still need to encode the response.


Another reason for going only after the output to the browser is that the browser is where these scripts run. You do have to consider how your data is being used by other people/systems, however. Web input can go to an internal reporting system and that can be as big a problem.

One thing you might not have considered is error logging. Be careful! Don't throw the raw data put into your fields to your event log without encoding it! Think about it -- you drop the script into the event log and there is some internal PHP page your system admins have put in place to view errors called from your site. BAM...script runs in THEIR browser and it might be silent and behind the scenes. Your site is fully protected, your input is validated, your output is encoded, you don't allow scripts to affect your processing, etc. But you dropped the script into a data store (event log) that can be used by other groups who don't have all that security in place. In my opinion, your system admins need to be better about security...they don't have an excuse either. Just like you. But don't give someone a lit bomb either. You are the one in control of the data so you are responsible for it...and you are the one that should be held responsible for the script running on their machines. You handed them a lit bomb. Don't blame them for not disarming it.


That is really all there is to it. Blur your eyes on all my explanation and it boils down to three things:
  1. Validate and whitelist all input but don't rely on these alone

  2. Encode all output to the screen, plus to any data store that might have consumers of the data that don't/can't encode their output.

  3. Don't turn off default ASP.NET protection of ValidateRequest unless you plan on writing the code you need to whitelist and protect your input sources.

And doing all of these is easy. Use good validators from ASP.NET's toolbox, and use the Microsoft Anti-XSS Library to encode your output.

The next and last post on XSS will give you links and ideas on where to learn the details of how you perform the actual protection in your code.

XSS Part 2 - How the attack works

In this second of four parts about XSS, you will learn how the attack works against your ASP.NET applications. If you are unsure what XSS is, go back and read the first post on it.

So now you know what it is, but you wonder how it works against you. The attack works against any opening where you could get data from a user or from a database and that data ends up being script that executes in your user's browser.

In its simplest form, it is a script tag that executes some inline script directly. Imagine someone typing this sort of script into a blog post comment (on a site that does not stop XSS):

Great post! <script type="text/javascript">alert('Your virus defs are out of date. Please go to for an update');</script>

The post "Great post!" would show as you expect, but then there is a script that will run too, showing an alert box and telling you to go to a bad site. What if the javascript just took you there in a new window without an alert box? What if they did it in a hidden iframe right in that post? It would just run and take you there automatically!

Anything people can do using javascript can be used against you -- take your cookies and send them to a site in Russia (man, I hope you aren't doing online banking at that moment!)...go to a site to download malware onto your machine...give you a popup saying virus defs are out of date so they can install malware on you...

Besides script tags, can you think of other tags they could use? Yes, I mentioned iframes. What else? What about img tags? Huh? Did you know you can put a link to a 3rd party script in the src attribute and it will execute?

<img src= />

What I want you to know is that XSS is often not about hitting you right now, or defacing your site right now. Sure, that is possible and does happen. But the big thing is that XSS is used to set you up for either further (and bigger) attacks, or to use you to be part of a bigger more damaging attack on either your company or another company. Imagine XSS used to drop attack malware on 1000 computers...the XSS doesn't hurt you per se...but it drops off part of a bomb to be used against some big name site in a concerted attack. Your machine simply becomes one of the drones. XSS can also open the door to CSRF attacks, and other unfun stuff by letting the attacker drop links used in CSRF attacks onto your forum. We'll talk about CSRF in future posts.

Think you are safe because you sanitize all your webform input? Not so fast, pretty boy. What if your database admin put (or updated) a post in the database by hand, putting script in there? You can't possibly cover every way data gets touched, but you can handle all the output since it is funneled through the single point at the browser. Winform, webform, manual input, generated/calculated data...they all gotta go to the browser. Don't think any of it is safe and scrubbed.

jQuery is some cool stuff, is it not!? It can manipulate the DOM on the fly, swapping images, colors, text, etc. It's just javascript. What if that complimenting post tucked some jQuery in there and changed your banner ads to point to sites that dropped malware off on you? You wouldn't know, your customers wouldn't know...well until someone gets burned and complains to you and you say "What? We don't have banner ads that go to!" and you have to shut down your site for a day to clean up the mess.

Your fault.

Stopping XSS is so easy in ASP.NET. You have to be detail oriented, but it isn't hard. I'll show you in the next post. In the meantime, check out and get familiar with some of the other ways XSS can be done on your site. Try a few out on your webforms! Oh, but alert your Info Sec folks before you do that to make sure you don't get in trouble. We need you on the front lines!!

XSS Part 1 - What it is

In this first of four post about XSS, we'll define what it is. The following posts will talk about how the attack is executed, how you can stop it and what resources are available for you. By the end, you will not have any excuses that make any sense as to why security isn't part of what you do.

First, let's define XSS. XSS stands for "Cross-Site Scripting" which means a script on one site is executing at another site, in your browser. OWASP (Open Web Application Security Project)1 has listed XSS as the #2 web attack risk for 20102.

From their document outlining the top risks for 2010, they define XSS as:
"XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation and escaping. XSS allows attackers to execute script in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites."

Ouch! Sounds nasty, and it is.

So what does this mean to you as a developer? You have a big problem if you take untrusted data and send it to a browser without validation/escaping. So let's define this a little closer.

"Untrusted Data"

-- how do you know what data to trust? Are you trusting your database since it is behind the firewall and is only accessible by system admins? You are? Really?? How does your data get into the database? What if your admins are corrupt and decide to modify the data by hand? Don't ever trust database input. You don't know how it got there. Don't trust user supplied input from form fields. Don't trust URL querystrings. Don't trust anything outside of your app.

Paranoid mentality? Perhaps...but will your CEO care if you say "We felt we were being too paranoid so we trusted that data and didn't realize it would bite us." You can't be too paranoid. Get over the stigma and protect your data.


-- this simply means you have tested that the data is what you expect to receive, and that you are outputing what you expect to output to the screen by revalidating it and making sure special characters are escaped to render them harmless. Escaping means taking a ">" symbol and making it into "&gt;" for example. If you expect a date for input, make sure it is a date and not some script that will run in the browser. Think people won't use your app like that? Wrong. We're talking about cash here. People will do all sorts of things for some green. If they find your app easy prey, they will use it and tell their friends what the hole is.

Why is this an issue?

-- well, let's assume you leave a field on your web form that accepts 100 characters and you don't validate it. If the user puts a script tag in there instead and it calls a script from a bad site, that runs on your machine and takes your cookies and sends them to Russia, let's won't be happy if the cookie is to your online banking site and someone just used it to transfer money to themselves in your name.

"So if I don't trust any user input and I validate all input/output plus escape output, am I safe from XSS?" Great question. See Part 3 of this series to know for sure. But first, to help you answer the question yourself, let's take a look at how an XSS exploit happens. That is coming up in the next post.


Saturday, January 30, 2010

How Attacks Are Being Done Today

I was going to write my next post about XSS as it is such a prevalent attack that opens the door to other attacks, but I had to post about what I just read instead. I'll hit XSS soon.

An article in darkreading.com1 was saying that Mandiant researched attacks over the last seven years and found that APT attacks (Advanced Persistent Threat), besides seeming to have Chinese ties (I won't go there as I don't think it matters where they come from, just that we stop them from any location, including our own companies), are so nasty that security software was able to detect only 24% of the malware used in the attacks!

So these attacks are going on right now undetected...

In addition, there are seven stages of APT attacks:
  1. Reconnaissance - checkin' you out and getting a lay of the land
  2. Intrusion into the network - finding the hole and getting in
  3. Establishing a backdoor -- a piece of wood to hold the door open
  4. Obtaining user credentials -- social networking and electronic means
  5. Installing multiple utilities -- remember the door you left open in #2 and #3?
  6. Privilege escalation, lateral movement, and data exfiltration -- taking over via open door
  7. Maintaining persistence -- making sure you can't delete it

Two things I note here -- 1) you have seven opportunities to catch them and stop them and this isn't happening, 2) YOU as a developer can stop them at #2, thus stopping the whole thing. Don't you see it now? If developers did their job to their best ability, the holes would not exist as much as they do. Would holes be found? Sure. Can we plug everything? I don't think so. But these are prevalent attacks, over seven years! Devs, get over it and learn how to code securely!!

I can't tell you how many devs think they don't need to learn security coding because they simply do intranet programming. See #6 above...they are in and using those loose security intranet apps to take over your organization. How cozy do you feel behind your firewall now? Come on gang! Learn the easy stuff and stop them!

Yes, stopping these attacks is easy...I'll show you how to stop XSS next and you will be that much more protected. Stop making excuses and do what you have to do to protect your organization and your customers!


Wednesday, January 20, 2010

No More Excuses!

Hey, you're a web application developer. I know you have deadlines looming, looming angst about your web site's security, and heirloom code you have to maintain. Get over it. This blog is all about helping you, and me, stay on top of security. Headlines scream about simple development mistakes costing 170 million credit card numbers. Some of those people lost money. You ever have someone wipe your card out? Painful and time/energy-consuming to correct. Someone's simple mistake(s) caused that to happen. People can blame the company, or the semi-clueless (at the time) CEO, or the guile of hackers. But guess what...someone programmed that code and either was not understanding what they were coding, or were flat out negligent.

To me, it is their fault.

Part of the blame has to go to the company execs and programming managers of a company that stakes its reputation on protecting and delivering peoples' credit card data. But the programmers also work for them and have to understand what their work affects every day they come in and sit down with a cup of coffee and a freshly booted PC.

I know, I know. Deadlines, budgets, tight time schedules, someone else promising you will deliver on an impossible schedule...all causing security to get baked in later if at all.

You know what? Get Over It.

This blog will hopefully educate, entertain and help us all out. This will be a no holds barred look at web app security, from an ASP.NET standpoint mostly. PHP guys/gals...get over it. (See a theme here? ) The stuff on this site will hopefully apply to you too, and you can go figure out how to code those things I put in as ASP.NET logic. I will try to keep things as language agnostic as possible, since I would prefer all web devs have the knowledge, but there will be days when I post ASP.NET or IIS specific things, whether exploits or fixes.

So no more excuses! You can learn this stuff pretty quickly and stop many many attacks dead. You can be the hero.

I will start my next post talking about XSS. Never heard of it? Please tell me you don't build websites...