Testing Tour Stop #25: Pair Penetration Testing with Peter

Just a few days before my testing tour is coming to an official end, I had my final stop with Peter Kofler.

Just had the final stop on my #TestingTour together with @codecopkofler. We had our third session on penetration and security testing and it was a great ending to a fantastic tour! 🎉

— Elisabeth Hocke (@lisihocke) October 29, 2018

We had two sessions on my tour already together which makes Peter the only one I had the pleasure of pairing with three times. In all three sessions we tackled different security testing challenges, each time using Dan Billing’s Ticket Magpie as our target. The first time we focused on exploring the application using SQL injection. The second time we tried automating SQL injections. This time we planned to have a closer look at cross-site scripting (XSS) and see what fake content we could place.

Starting Out

In the beginning of our session, we looked for potential input fields where we could give cross-site scripting a try. We registered as new user and found a comment field on each offered concert. We added a comment containing an HTML tag to see whether this was allowed, and it was. We went ahead and added a simple script that should show up an alert. Interestingly, the Chrome browser considered this a potential cross-site scripting attempt and blocked it showing the error code "ERR_BLOCKED_BY_XSS_AUDITOR". Navigating again to the concerned page, however, indeed showed us the desired alert.

As we had already proven that the application was vulnerable to cross-site scripting, we considered to try out actual scenarios. What if we changed the link of the button to book a concert to lure the user to a different site? We used our JavaScript knowledge and tried out how to target the desired elements in Chrome's Dev Tools console until we had the right command. We added the script in our comment and this worked just fine!

What about posting comments in the name of another user? This was even easier than considered, we found the user name to be a hidden field of the form so we could simply change it using DevTools before submitting the comment. Tampering with web parameters was not our goal, so we decided to inject a script to change already existing user names. We found out how to select the desired elements to change, submitted our comment including the script, and all targeted user names got replaced. However, we found it did not work when adding a new comment in the name of the targeted user. Right, the script had already been executed at that point in time. So we changed the implementation to be executed only when the DOM content had been fully loaded. It still didn't work, but why? The console showed us that an error was thrown. What was wrong with our script? After spending some time on debugging we realized it might just be a copy and paste error, we might have copied some non-ASCII text from a website sample. We sanitized our code - and now it worked!

All this was surprisingly easy, so we still had some time left which we spent on brainstorming what else we might try on our current target practice application or what we in general would want to learn more about.

• Cross-site scripting attack tools like XSS-Proxy
• Denial of service (DOS)
• Remote code execution
• XML External Entity (XXE) Processing (for which would need an interface)
• Session hijacking
• Cross-site request forgery (CSRF)

One of the best resources to get an overview on the most critical web application security risks alongside further resources are still the OWASP Top 10.

Looking Back

We were really successful with our attempts. Frustration was kept at a minimum, not everything worked at once but we made it work together. This was great for learning. However, it felt quite easy as well. This might have been due to the fact that both Peter and me complemented each other very well regarding our knowledge. Peter contributed most of the JavaScript knowledge where I lacked a lot of practice, and I was fluent with the Chrome DevTools that he never used as pure backend developer.

Time flew by and collaboration was smooth. The only thing we noticed: it was not easy for me to not see Peter's screen. I could not see when he shifted his focus away from the shared screen to his screen in order to research useful resources. Though this style had worked in previous sessions for us, we considered we would try researching together and sharing screen control in a future session. Would we have a future session? Well, the whole area of security testing is still really interesting for both of us so we might go deeper together on this topic outside of my testing tour.

This was the last stop on my testing tour in 2018. I aimed for ten pair testing sessions in ten months and ended up with 25. I am still amazed by this awesome learning journey together with so many amazing people. My final task to conclude the tour is to take time and reflect on it as whole, so stay tuned!