Showing posts with label SQL Injection. Show all posts
Showing posts with label SQL Injection. Show all posts

Thursday, February 17, 2011

BBC Sites Injected with Nasty IFRAME

An article in Dark Reading today tells about a nasty attack on two BBC sites that has an IFRAME injected onto the site that downloads nastiness to your computer, and only 20% of the anti-virus software packages catch it. OW!

Read the article

Key thing is injected. It almost makes it sound like BBC is a victim, doesn't it? "Hey did you read how the bad guys injected this nasty code into two BBC sites?" Folks, in a sense they ARE a victim, with an unwanted set of code put there by some 3rd party. But um, hello??!! YOU LEFT THE DOOR OPEN!!

When you read the word "injected", think "unwitting developer leaving a wide open door for hacker to put stuff on their site". BBC...surely lots of developers, a few development managers, must have some infosec and compliance people. And a hole like that is left open?

Maybe it was a tricky hole or something really brilliant that got around the standard defenses. But I have a hard time thinking that is the case.

In any case, the developers left a hole open.

So my question to you is:

How many headlines will it take before you change your code?

Don't wait until you ARE the headline...

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 greg@bangordevelopers.com 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 novices...it 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 reviews...it 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 ha.ckers.org 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.

http://www.sans.org/vlive/details.php?nid=21094

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 SANS.org 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.
http://www.japantoday.com/category/crime/view/hackers-steal-customer-data-by-accessing-supermarket-database

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'Brien...do 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 owasp.org and read up on SQL Injection...read how to do parameterized queries on MSDN...etc. You can do this!

Thursday, August 5, 2010

Quiz #1 - SQLi

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

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, April 20, 2010

OWASP Top10 Final Copy Released

OWASP (www.owasp.org) 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.

http://www.owasp.org/index.php/Top_10

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: http://www.esecurityplanet.com/headlines/article.php/3866011/eBay-Vulnerabilities-Found.htm

Here is a good paper on what the top holes are and how to fix 'em: http://www.owasp.org/images/0/0f/OWASP_T10_-_2010_rc1.pdf. And in the coming weeks I'll give a full explanation of SQL Injection and CSRF to help you if you need it.

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

http://www.sans.org/top25-programming-errors/

http://www.computerworld.com/s/article/9157218/Hold_vendors_liable_for_buggy_software_group_says