Code review can only do so much...
I am involved in the development of the Application for Incident Response Teams (AIRT). AIRT is GNU GPL-licensed Free and Open Source Software that is designed to do one very specific task very well: to support computer security incident response teams (CSIRTs) in the bureaucratic aspects of incident response.
AIRT allows CSIRTs to receive incident reports, extract the relevant information from them, create incident tickets, follow the process flow of handling the tickets, and communicate with the teams that are handling the incidents, or track incident handlers. A lot of AIRT's development is directly influenced by SURFcert, the Dutch National Research and Education Network's CSIRT.
While the documentation that is available online is currently still lacking, the software is used intensively by several large teams world-wide. Each of these times has indicated that by using AIRT, the average time spent on bureaucracy has reduced dramatically; sometimes as much as from twenty-five minutes per incident to less than one minute per incident. Again; AIRT is a tool for professionals, and its installation, setup, and use is sometimes a bit arcane.
Professional support and development services are available.
The point of this post is not to turn it into a sales-pitch, but hey; if it generates some revenue, that's a nice bonus :-) What i wanted to touch on is the fragility of code development.
AIRT is developed in PHP and relies on a Postgresql back-end. All the code is developed by a small group of developers who are serious about their work.
We believe (unlike many others), that developing in PHP does not have to lead to bad or insecure code any more than in any other language, and we have always been very careful about attempting to maintain a high level of quality. We believed that we made good code, with few security bugs, or any other surprises in it.
We were overconfident.
While we did a lot of code-review by peers, we recently got a bug report that we had some SQL injection vulnerabilities in our code. The extent of the message was "mwahaha; your c0d3 suxx0rs. i canz inject seekwul 33z1" (direct quote) without many more details. While bugreports like these are "less than optimal", we do take them seriously and we did a full eyeball code review again. And indeed, we did find one more error.
About the same time, I had also been looking at the excellent work done by the people over at OWASP. Anyone doing any web development should become very familiar with that project!
Anyhow; while I had looked at the WebScarab tool, I had not spent much time with it, and I was unable to use it effectively. This was also true for the Paros Proxy. There was never a direct need, which unfortunately directly translates to a lower priority.
This time, however, there was a more pressing reason: we had found an actual vulnerability, and we were led to believe there were more. Rather than concentrating on these two tools, I opted to take a look at the Acunetix web vulnerability scanner.
And I was glad that I did. After downloading the free version (which only checks for cross-site scripting errors, getting started was a little tricky. After some initial experimentation, we were rocking.
Remember: we thought that we had good code. The Acunetix scanner proved us wrong. It found several more vulnerabilities in our code. The lesson learned: code review can only do so much.
Many of the AIRT web pages are complex, and sometimes contain up to twenty different input parameters. Manually fuzzing becomes excessively complicated because many of these page elements have a direct effect on each other. Using a tool, such as the Acunetix web application vulnerability scanner, provides a very valuable addition to the testing process, and I recommend it wholeheartedly.
Unfortunately, the price tag of the scanner is pretty high-- a simple GPL project can most likely not afford to purchase the tool to benefit from its entire arsenal of vulnerability scans. I know we cannot.
By the way-- if anyone reading this is willing to sponsor us with a copy of the software, please let me know :-)
Having said this, not all vulnerabilities translate to risk. In this case, all the vulnerable code was only accessible by a highly trusted group of security professionals. Within AIRT, all users who can log in interactively are considered equal, so local privilege escalation would have been hard. Of course, improper scrubbing of inputs and outputs can be abused in many different ways, but the combination between access controls and excessively paranoid and security-aware users makes me believe that our exposure was limited.
AIRT allows CSIRTs to receive incident reports, extract the relevant information from them, create incident tickets, follow the process flow of handling the tickets, and communicate with the teams that are handling the incidents, or track incident handlers. A lot of AIRT's development is directly influenced by SURFcert, the Dutch National Research and Education Network's CSIRT.
While the documentation that is available online is currently still lacking, the software is used intensively by several large teams world-wide. Each of these times has indicated that by using AIRT, the average time spent on bureaucracy has reduced dramatically; sometimes as much as from twenty-five minutes per incident to less than one minute per incident. Again; AIRT is a tool for professionals, and its installation, setup, and use is sometimes a bit arcane.
Professional support and development services are available.
The point of this post is not to turn it into a sales-pitch, but hey; if it generates some revenue, that's a nice bonus :-) What i wanted to touch on is the fragility of code development.
AIRT is developed in PHP and relies on a Postgresql back-end. All the code is developed by a small group of developers who are serious about their work.
We believe (unlike many others), that developing in PHP does not have to lead to bad or insecure code any more than in any other language, and we have always been very careful about attempting to maintain a high level of quality. We believed that we made good code, with few security bugs, or any other surprises in it.
We were overconfident.
While we did a lot of code-review by peers, we recently got a bug report that we had some SQL injection vulnerabilities in our code. The extent of the message was "mwahaha; your c0d3 suxx0rs. i canz inject seekwul 33z1" (direct quote) without many more details. While bugreports like these are "less than optimal", we do take them seriously and we did a full eyeball code review again. And indeed, we did find one more error.
About the same time, I had also been looking at the excellent work done by the people over at OWASP. Anyone doing any web development should become very familiar with that project!
Anyhow; while I had looked at the WebScarab tool, I had not spent much time with it, and I was unable to use it effectively. This was also true for the Paros Proxy. There was never a direct need, which unfortunately directly translates to a lower priority.
This time, however, there was a more pressing reason: we had found an actual vulnerability, and we were led to believe there were more. Rather than concentrating on these two tools, I opted to take a look at the Acunetix web vulnerability scanner.
And I was glad that I did. After downloading the free version (which only checks for cross-site scripting errors, getting started was a little tricky. After some initial experimentation, we were rocking.
Remember: we thought that we had good code. The Acunetix scanner proved us wrong. It found several more vulnerabilities in our code. The lesson learned: code review can only do so much.
Many of the AIRT web pages are complex, and sometimes contain up to twenty different input parameters. Manually fuzzing becomes excessively complicated because many of these page elements have a direct effect on each other. Using a tool, such as the Acunetix web application vulnerability scanner, provides a very valuable addition to the testing process, and I recommend it wholeheartedly.
Unfortunately, the price tag of the scanner is pretty high-- a simple GPL project can most likely not afford to purchase the tool to benefit from its entire arsenal of vulnerability scans. I know we cannot.
By the way-- if anyone reading this is willing to sponsor us with a copy of the software, please let me know :-)
Having said this, not all vulnerabilities translate to risk. In this case, all the vulnerable code was only accessible by a highly trusted group of security professionals. Within AIRT, all users who can log in interactively are considered equal, so local privilege escalation would have been hard. Of course, improper scrubbing of inputs and outputs can be abused in many different ways, but the combination between access controls and excessively paranoid and security-aware users makes me believe that our exposure was limited.