Experimenting with application intrusion #detection and #response changed how I look at certain practices such as penetration tests and reports coming from the testing team. This is many years ago where my team received a pentest report of a web application we have been working on, however, before we received the report, I started looking for signs and indicators of what the pentesters tried out - XSS, SQLi and other common attacks and payloads - in the UI. I noticed that they also tried a CSV injection attack in one part of the web application which had a CSV file export. This did not end up in the report that we received as they did not manage to find a CSV injection vulnerability - the input they tried to inject into was never part of the exported CSV file. However, a while after we got the report, we started introducing a change in the code of the CSV file export and guess what this change was: it now included the input that the pentesting team tried to inject into. We were luckily changing the code without introducing a vulnerability, however, I keep thinking about this a lot since we more or less dodged this bullet because of a manual method of searching for what the pentesting team has been up to.
Instead of manually searching through logs or other resources for indicators of an attack, why not create detection points for the web application that focus only on blatant attack(er) activity and create dedicated logging for intrusion detection?
Here are some example categories of detection points:
* Monitoring and logging of suspicious activity that could never come from a benign user:
- Why would a benign user change a cookie (#honeytoken) value that was never meant to be touched ;)
- Why should your server-side input validators fail when the input should have been rejected by the same validators on the client-side?
* Monitoring and logging of attacker-induced errors and exceptions:
- Syntax errors may be caused by code injection probes (e.g., SQLi)
* Monitoring and logging the performance of security controls:
- Did the CSV escaping mechanism really prevent the CSV injection attack?
Especially the second category of detection points is noteworthy as it touches on the idea that an attacker will be eventually successful - errors and exceptions in this case might be the first sign and should therefore not be neglected. But that does not mean that we can't do anything about it ;)
To learn how to implement such detection points for your web applications, have a look at the very good OWASP resources that guide you how to make web applications attack(er)-aware and self-defending:
* OWASP AppSensor - Comprehensive Guide and Detection Points:
https://owasp.org/www-project-appsensor/
* OWASP Top Ten Proactive Controls - Implement Security Logging and Monitoring:
https://owasp.org/www-project-proactive-controls/v3/en/c9-security-logging
* OWASP Testing Guide - Test Defenses Against Application Misuse:
https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/10-Business_Logic_Testing/07-Test_Defenses_Against_Application_Misuse
* OWASP Code Review Guide - Reviewing Security Alerts, Review for Active Defense:
https://owasp.org/www-project-code-review-guide/
* OWASP Application Logging Vocabulary Cheat Sheet:
https://cheatsheetseries.owasp.org/cheatsheets/Logging_Vocabulary_Cheat_Sheet.html
This is one of my first posts where I will speak more about the topic of attack-aware web application development and #defendabledesign - the hashtag which I will use from now on for this topic ;)
Hope you all have a nice evening and weekend, see you around!
#infosec #dfir #blueteam #appsec #webdevelopment #websecurity
Tolga
