I got a mail forwarded from my current manager. A security scan in relation to our PCI certification had flagged a functionality as insecure, on a medium level.
The scanning tool was able to post URI encoded strings, which could be evaluated as working Javascript. This would enable a malicious user to manipulate with the functionality on the page. The functionality in question has nothing to do with the PCI related parts directly, but if your site has a vulnerability, you can loose your PCI certification all together and the people receiving the scans are not so interested in the technical details, they just react to a red flag.
The fix seemed quite obvious after having understood the problem. I would decode all URI encoding to UTF-8 and then I could encode everything as HTML entities prior to propagating it.
The actual implementation did however give me some headaches. To begin with the data was XML. The data was passed untouched through and processed using XSL to render the HTML result for the client.
So in order to perform the decoding and encodings I had planned, I started by transforming the original XML to a native Perl data structure using XML::Simple for easier access.
I implemented the operations and started working on the translation of my cleaned data structure to XML again.
This was not quite as easy as expected and it took several attempts to get the XML in a condition where it resembled the original, this was a goal in itself, since I wanted to avoid making changes to the XSL. The XML did not completely resemble the original, but it was close enough for the XSL to work.
I then set out to test the complete setup on one of the designated hosts, then things really started to go the wrong way. The build tool I am using is based on Module::Build. The Module::Build version required was not compatible with the perl interpreter installed. After a brief moment of disappointment, I just decided to work around the scripted installation process and target the task at hand.
Next disappointment came swiftly, the new version of the software simply did not work. My use of XML::Simple was based on newer features, not supported by the currently installed version. So I attempted an upgrade. The same problem, the contemporary version of XML::Simple was not compatible with the installed perl version.
After some cursing (which I will leave out here), I discussed the problem with the colleague sitting opposite me. Explaining him the problem gave the solution. I would create a simpler fix, avoiding all the data structure transformations and simply using a regular expression.
I revisited my test suite and mocked important components and finally I was able to see the fix working.
This is the second time I experience and XSS vulnerability. The first time, it was introduced by a freelancer I employed and we got a lot of heat from the developer receiving the PCI scan.
As things often go, nemesis sets in and the new vulnerability I am describing here was actually introduced by the same developer who complained over our previous guest appearance in the security scan report.
The most important lessons learned, must be that we will keep introducing new holes. Things that can help us too keep this to a bare minimum must be a combination of the following:
- Peer review of the source code
- Education in understanding holes
- Security Testing
- Introduction of general components to close holes and education in their use
We are not particularly good at the above, since it is not practices required by our organization, so everything is left up to the developers and hence their knowledge, time, workload and interpretation of priorities. This leads us to a new problem, which is that we are bound to developers, meaning that when they leave/disappear the knowledge goes.
I will get back to knowledge in organizations in a later blog entry.
Suggestions for additional practices are more than welcome, since this is just one war story and not a particularly interesting one, but I am sure I am not the only one who has a story or two on XSS vulnerabilities or similar and the following reflections we make as developers dealing with these.
I also expect to write up a blog entry more on the actual functionality in use, to share my experiences.
0 Comments.