I didn’t even want to write about this, because hopefully it is not a wide spread problem but it is such a catastrophic programming mistake which I saw in a production system that I felt the need to talk about it. So to summarize this blog post in one sentence: total client-side exploit using user defined XSLT.
I recently obtained the Advanced Penetration Testing for Highly-Secured Environments: The Ultimate Security Guide book, so I figured I write a little summary about it as I did with the other security books that I read.
I was lucky enough to do a penetration test on applications using Direct Web Remoting (DWR), and I would like to share my experiences. It is another interesting technology in the wild jungle of the web frameworks and libraries. It defines itself as follows:
“DWR is a Java library that enables Java on the server and JavaScript in a browser to interact and call each other as simply as possible.”
Continue reading
My colleague brought my attention to a really interesting ‘feature’ of browsers. Namely that XHTML namespaces in an XML document will be rendered as XHTML instead of XML. That means that if you can some way control an XML that will be rendered by the target’s browser, then you can insert HTML and of course JavaScript code. So this feature widens an XML injection to an endless attack vector.
Continue reading
In the ocean of web application development frameworks there are a quite a few which tries to create rich web application in the same way as traditional desktop-based applications. One of them is the open-source Echo Web Framework from NextApp. It is a Java based system which is kind of practical because everybody has at least one Java developer friend. The Echo applications can be deployed in most of the Java web containers. But the most important difference is that instead of creating for instance a .jsp file to create a view the developer write only things like window.add(button);. That means that for the developer should not care about the fact that his application will be accessed with a web browser. In some way it is really cool that you can just say the words and everything happens automagically but for me it is always a bit weird when I don’t have control over something, but that’s just my taste. And the magic in this case is done by JavaScript. Before going into details I must say that I don’t have full understanding of the Echo Framework and how one should use it properly, I understood it only to be able to do a pentest and to attack it properly. In this post I write about the Echo2 framework and my experiences from the penetration tester’s point of view.
Continue reading
First of all I must say that there are web applications which get output escaping right. I had a confrontation recently with one. I could store malicious attack strings in the database that were shown on the UI, still I couldn’t evade the output escaping even though I tried really hard. At the end I had to accept that the JavaScript generated UI was too good.
Continue reading
During my first pentest reports it happened a few times that I suddenly realised that I hadn’t saved some data which would have been good to include in the report. Usually this costs you only time to reproduce the problem and gather that data again, but sometimes it’s not possible. Either you are not allowed to access the target system anymore or in case of a test environment it might not be even running anymore. In this case you need to accept that your report will be worse as it could have been. To avoid these situations I tried to summarize for myself what is needed to a report and how all relevant data should be stored for a finding. Bear in mind that usually every penetration tester has their own way to keep their data so this here is just my way(or the highway..).
© 2024 Æther Security Lab
Theme by Anders Noren — Up ↑