Join Kevin Skoglund for an in-depth discussion in this video Keeping error messages vague, part of Foundations of Programming: Web Security.
In this movie, we're going to talk about the importance of keeping your error message vague. You'll remember back in the last chapter when we talked about the principal of security through obscurity. We talked about how you never want to give away more information than you have to. You want to be stingy about that information. And that's especially true with errors. Because a lot of times a hacker will try something and get an error as a result. And, they'll use that feedback from the error to determine what to try next. So, the errors play a critical role in how a hacker interacts with your site.
If they get meaningful feedback, then they can adapt their attacks. But if they don't get meaningful feedback, then they're left in the dark, and that's where we want them to be. So, as you're developing, you probably are going to want to have Errors turned on. So that you can see the bugs that are happening while you're working on your application. But when you actually launch it to production, you want to make sure that you turn off that detailed error reporting. Instead, you just want to return generic 404 and 500 pages. Those are just pages that say either something wasn't found, which is 404, or 500, something went wrong.
We don't specify what went wrong. We just say something wasn't right. And that's it. We don't need to elaborate. The most end users, they don't care what went wrong. Hackers are the only ones who wish they knew, what had actually gone wrong so they could diagnose it and try different attack. To the end-user, the fact that it didn't work is enough. Now, if errors do happen in production, you can still handle those. For example, your site could send an email to developers with details about the error and what happened and it could log all that information in an email. Or it could log it in a log file so that the developer could go on the server and take a look in the server logs and see the error was.
They don't need to see that 500 page. Chances are, they are not the one who triggered it anyway, right? It was an end-user. So, it's much more useful to have developers depending on server logs and email notices than it is to put meaningful data inside those error pages. Now, your application will be returning these generic error pages. But it's also a good idea to configure your web server to use those same error pages, the web server doesn't necessarily use them by default. If something happens at the web server level before it ever gets to your application, the web server needs to know how to handle it.
And if it returns a 500 error you want it to look the same as the 500 errors that your web application returns. And not only does it give your site a more tailored in custom look but it also again presents this single error page. It doesn't give us any indication of where things went wrong in the process. It doesn't even let us know if the error happened at the server level or at the application level.
This course is great for developers who want to secure their client's websites, and for anyone else who wants to learn more about web security.
- Why security matters
- What is a hacker?
- How to write a security policy
- Cross-site scripting (XSS)
- Cross-site request forgery (CSRF)
- SQL injection
- Session hijacking and fixation
- Passwords and encryption
- Secure credit card payments