Why You Should Re-Consider Custom Error Pages

Custom error pages are one of the things that I have always seen in the nice to have requirements document when I was a software developer. You know, when we are done with the “real work”, you will start putting those in web.xml or web.config and start testing them out.

It almost never happened.

There were so many excuses, no time for starters. Sometimes, it was hard to get the log files from the production server so error pages, as bad as they were, were being looked at as a faster way to see the bug and get it fixed quickly to get that manager off our backs.

Plus, why implement something that will never be used, don’t we create perfect code anyways? all the time?

My experience in software security and my deep interest in graphic design taught me differently.

Neglecting custom error pages can add a HUGE security hole in your application. 75% of the attacks that happen on the internet today are targeted towards the application level. This includes your application but more importantly the underlying systems that support your application, like IIS, SQL Server, mySQL….etc. There are a lot of vulnerabilities with every single underlying system you might imagine. Windows, SQL Server, .NET, Oracle….etc. The attacker just wants to know which system you are using and then it is just a matter of time until they are able to penetrate it specially for non-patched systems.

Custom error pages keeps you in control: Although, we know that it is pretty much a bug and something went wrong with the application but a nicely designed error page allows you to fail with grace. Users wouldn’t think of this as a screwed up application, they will feel like being informed of what’s going and that’s it. It gives you a chance to say: I screwed … I am sorry

Your customers will appreciate it.

Custom error pages are user friendly. You know the ugly stack traces FREAK people out? Don’t you? The first thing I (and I am a software developer) think is: What did I do wrong?. You don’t want your customer to feel guilty or bad using your application. Custom error pages communicates the message to your users that it is the application’s fault, we are sorry and please come back again.

Users will understand. I do every single time LinkedIn gives me the screen above.

Custom error pages can add traffic to your web application: Just a last thought, if you changed your website and a customer bookmarked one of the old pages, he will get a 404 with the new website and he might not come back again, specially with traffic shapingsteeling ISPs. With the custom error pages, it is a way to redirect this user back to the new website by providing  a nicely designed 404 page with a link to the home page. This can add a lot of lost traffic back to you mainstream.

How did custom error pages help you?

What’s Common Between Software Security and Recycling

Every time I think about software security and its  adoption inside software companies, I remember my habits regarding recycling. Let me give you a bit of recap, the City of Ottawa decided to introduce something called the green bin which is your regular garbage bin only green in color and should only contain the organic waste. This is of course different than the black box which should have all the paper waste, blue box for the glass and plastic waste and finally the regular bin for everything else.

I like recycling because I feel I am doing something good to my environment. However, I hate the fact that I have to have 4 bins in my kitchen (or even in my small garage) just for garbage, I mean this way I won’t even have a space for my car for God’s sake.

Software companies must think of security the same way, too many bins out there ! Security code review, dynamic scans assessments, web app firewalls, intrusion detection, forensics…..etc

I just want to feel good and have one bin only to deal with!

I drive my wife crazy trying to optimize everything. She might be right though. We live together, no kids for now in a 3 bedroom house and I work from home. I am the kind of dude who sets the thermostat at 10:00 PM – 7:00 AM to 15 Celsius (60 F) because we are usually asleep during this time and don’t need the whole house heated. I have an oil heater in the bedroom that’s set automatically to start at 9:30 PM at 21 Celsius (70 F) to heat up our room and another oil heater that starts automatically at my office 8:00 AM till 5:30 PM because this is where I usually spend the whole day. The house thermostat is set to 21 Celsius from 7-8 AM in the morning as this is time we wake up and use most of the house and from 5-10 PM every day as this is again dinner and wind time and we usually use most of the house. I might be paying more for the electricity and gas combined but I feel that I am optimizing my resources and heating only the room I need.

Software security is the same thing, it is about optimizing your resources. Recent statistics reveal that as many as 70% of websites have vulnerabilities and according to Gartner and the U.S. Computer Emergency Response Team (U.S. CERT), 75% of new attacks specifically target the application layer. This means that there is a 75% chance your application will get hacked. How much time and money will be spent fixing the problem? And from my experience these problems never come at a good time. If you are still not convinced, check out the recent attacks against Google, Adobe and 30 other companies.

I rest my case.

They both will need some change. So I want to recycle, feel good and do the right thing but to think every time I am throwing something out?!! Ok, should this go to the blue, green or yellow bins? Oh, there is no yellow !! Let me get back to the chart to find out where does yogurt containers go!! What just happened here?? Something that I used to do without thinking twice about and was handled previously using the left side of brain, now it has to move to the right side of the brain, I have to think before doing it and we humans don’t like to think. At least not garbage related decisions.

Involving software security in the software development life cycle needs some changes, it needs changing the mindset of senior management, needs changing the mindset and habits of the developers, changing the way developers write code and introducing some controls. And again, we humans do not like change.

They both have no immediate monetary reward: While I am throwing the plastic-inside of the cereal box and trying to remember which bin it should go to, I think to myself, what’s in it for me? Yes, I will feel good, I have done something good to my environment and I can now stand proudly next to my green bin as being the “green” neighbor on the block. But what’s really in it for me? I mean I am paying for this every year to have my green bin picked up, can’t I just pay and not do the work involved?

Software companies think of it the same way. I was once talking to a CEO about the importance of security in the life cycle of their software service and he told me: I can’t introduce any security controls because this would mean extra cost to our business model and our customers won’t pay for it because they should have their software already secured 100%. I asked: Why do you add extra cost for quality assurance then?

Software companies don’t think that there is any return of investments for software security. I always ask this: Why do you do quality assurance then? why do you always put cost, estimate, time and engineers into quality assurance and not security testing?

The Missing Truth Behind An SQL Injection Attack

SQL Injection is an attack that exploits a vulnerability in software code where the query is constructed dynamically via String concatenation. SQL Injection is one of the oldest Injection attacks out there dated back to 1998 when it was discovered by Rain Forest Puppy.

I imagine back in 1998, SQL Injection was one of the easiest attacks with the most bang out of the hacker’s buck. They would go and use the famous 1′ or ‘1’ =1 or someting and boom….lots of goodies.

Although there is a lot more awareness now for SQL Injection compared back to 1998. Amazingly SQL Injection still tops OWASP’s Top 10 as #2 in the list among other injection attacks like command injection, header injection…etc

Wait, but you just said that there is more awareness now regarding SQL Injection attack compared to 1998 for example?

Exactly, I will explain that later. Preventing against SQL Injection attacks is simple:

  • If you are using queries, Use parameterized queries.
  • If you are using stored procedures, use parameterized stored procedures.

This is absolutely no exhaustive list of SQL Injection prevention list. This simple changes seems to be almost eliminating SQL Injection vulnerabilties in the code implementing them. Seems obvious and easy enough, right? Why the heck is it then that SQL Injection is still #2 on OWASP’s top 10 list and SANS top 20 list?

  • Because developers think that threat comes only from users’ input, they don’t think that threat can come from things like their own database, internal configuration files or from other data read from XML streams. Developers associate risk with human beings only, they don’t associate risks with machines or other systems their code interact with.
  • What are you saying here? I am saying that my guess is that the reason SQL Injection is still that high of a risk because developers should parameterize everything in their queries and not only fields coming from the request or from a form.
  • Don’t think that just because the data is loaded from internal configuration file or from your own database that it is safe. Unless developers has 100% control over the machine on which the code will be deployed and he is an expert in network security and guards this machine 24/7, don’t trust ANY input that you are using in your SQL query.
  • OK, I have done that, now what? ….Validate your input. Why, it is irrelevant now, right? What if you made a mistake and didn’t follow through, unintentionally ofcorse, all the best practices, wouldn’t you like an extra net to fall into, it is like the car warranty for a new car, you know you almost wouldn’t use it but it is just good to be there. What if attackers were smarter than you are and exploited a vulnerabilitiy in the database driver you are using. Now you know what I mean? 🙂

Here are some of the best articles that covers the basics of SQL Injection, an article by SecuriTeam, MSDN and lots of SQL Injection tricks here. Jermiah Grossman’s article about SQL Injection is really cool too, check it out.