Your error handler is one of your most important security defenses
Published in · 25 min read · Feb 9, 2022
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⚙️ Check out my series on Automating Cybersecurity Metrics | Code.
🔒 Related Stories: Secure Code | Application Security | Cybersecurity
💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Do you write error handlers that capture errors when your application executes? All the errors? Do your applications crash miserably with the wrong inputs or fail gracefully? Can your application continue when it needs, even when an error occurs? When a crash occurs do you capture the output and deal with it appropriately or let it spill onto the screen for anyone to read? Does your error handling or logging code have a security vulnerability?
Error handling that gives up secrets
While performing a particular AWS penetration test for a customer I was tasked with testing their APIs. All I had was a Swagger file (a file that defines all the ways you can call the API and the related parameters.) I wrote a custom fuzzer that parsed the Swagger file and inserted attack values into the API calls. Fuzzing is a mechanism for testing code with a lot of attack strings quickly and I wrote more about this fuzzer for IANS Research. I don’t recommend only testing an API because that can provide limited results, but in this case, that’s all I had.
While testing the API I noticed that one of the error messages reflected the data I entered back to the screen. Sure enough, I had a cross-site scripting (XSS) attack. Even worse, I could use that cross-site scripting attack to send me the JSON web token of the user that made the crafted API call. If I could trick a user into going to a page that produced that error I could use obtain their credentials and make additional API calls using them.
If you want to see this in action, I did a demo in my talk at RSA in 2020:
