Category Archives: Practice Sites

OWASP’s Juice Shop Practice Site: A Refreshing Reminder

[Juice Shop:  Download it | Hack it | Tweet it | Alternative to it]

At a time when continuous integration is king and anyone with a web scanner is calling themselves a pen tester, OWASP’s Juice Shop project  is a refreshing reminder of the need for creative, out of the box security testers in our software security assurance programs.

With the popularity of agile methodologies and devOps, lengthy software security assurance activities can slow things down. To counter this, lengthy DAST scanning and code reviews have given way to automated security testing. For identifying simple vulnerabilities such as cross-site scripting and SQL injection, this is a good solution and allows organizations to scale their efforts beyond the range of manual testing. However, automated assessment without strong security involvement in the design phase can leave such security flaws as logic errors and weaknesses in complex workflows dangerously undiscovered. In an industry that has tasted the cost-savings of security test automation, adding expensive manual assessments back in to the release process can be a hard sell. And then came OWASP’s Juice Shop.

I was approached by the author of Juice Shop, Björn Kimminich, to do a write-up on the OWASP project. To confess up front, I didn’t know much about his project and readied my scanners for what I thought would be a fun point and shoot session. However, during my initial inspection I XSS’d the search field and a banner popped up telling me that I had completed a challenge.

Challenge accepted!

With a little more digging I found that the site contained an actual score board tracking what I and had not completed. My MLK weekend plans were now aborted and the obsessive security geek in my had taken over.

Fast-forward a lost weekend and a lot of Googling and I’m about ¾ths done with the challenges- which isn’t half bad for a middle-aged security exec. What is remarkable however, is that in spite of the fact there are 39 unique hacking challenges the majority of the exploitable flaws do not show up on a dynamic, authenticated scan! This is fairly serious considering some of these challenges include defrauding the Juice Shop out of money, taking over the admin account, and impersonating the Juice Shop’s CISO. None of these however were found by the several dynamic scanners I ran against the site.

So, what is my take-away from all this? Try running Juice Shop through your current assessment program and see how many of the findings your processes uncover. I suspect you’ll either be beefing up your security design reviews or adding manual pen testing back in to your process. Maybe even both…

Note: If you don’t have the time or technical patience to bring up your own instance, there’s an online practice site by Heroku that will save you the time.

Also see the Hackazon and Google Firing Range reviews.

Google’s Firing Range Test Site

[ Giigle Firing Range: Download it | Hack it | Alternatives to it]

Google's Firing Range

Yesterday, Google Security Engineer Claudio Criscione released version 0.42 of the web scanner test application called Firing Range. The author of the test app describes Firing Range as “a Java application built on Google App Engine and contains a wide range of XSS…” They make the source available on github or there is a public website available for target practice.

At first glance, Firing Range looks sparse. However, those who don’t look past the landing page and launch a tool or two are not going to be able to appreciate the elegance of the test site. Firing Range is a unique and valuable addition to the web’s portfolio of test sites.

While the Hackazon test site provides what I have described as a “torture test” for scanners Firing Range is more of a “Rubik’s cube.” Most scanners will complete a test of Firing Range in well under an hour and nothing about the site is resource intensive or attempts to hide vulnerabilities from the test tool. Instead, Firing Range takes the opposite approach and focuses on completeness of the assessment. That is, every test page is directly available within the first two levels of the landing page and all the test pages are labeled for the target test. For example, all of the pages that test for reflective cross site scripting are available from the reflected cross site scripting page. This page is then broken in to clearly defined sections:

Firing Range Screen Capture

Firing Range on its own should not be considered a single source for testing a scanner (and I do not believe the author ever meant for it to be). However I believe that it will soon become a gold standard when assessing a scanner’s ability to detect and report on cross-site scripting.

Google's Firing Range


  1. For evaluating a scanner’s strengths and weaknesses in detecting and reporting on cross-site scripting, you won’t find a better tool than Firing Range.
  2. The author has carefully and thoroughly labeled each test and offered explanations where needed.
  3. Firing Range allows an assessor to map the true positive findings and false negative findings.



  1. Firing Range makes no attempt to test a scanner’s ability to test in real life situations such as complex workflows like you would find in an eCommerce site.
  2. Firing Range tests very little beyond cross site scripting. It would be great to see this model extended to other vulnerability families.