OK, I hope I'm being clear enough. Apologies if I'm not. First off, I'm building from the master branch. Building from command line, so no IDE involved, FWIW.

While preparing for an upcoming coding lab session, I worked through all the XSS and SQLi labs. In doing that, I found several of the java class files seemed to have copies in two places:

WebGoat-Lessons/goat-hills-financial
and
WebGoat-Lessons/cross-site-scripting (and similar for sql-injection)

In particular, for the XSS lab Stage 1, there is an UpdateProfile.java in both locations.

Checking the WebGoat-Lessons/cross-site-scripting/.../CrossSiteScripting.java file, I see the one that is actually being imported is the one in goat-hills-financial.

HOWEVER, that version of UpdateProfile.java uses the parser class to read in the employee's profile, so it contains no XSS problem.

If I import the version of UpdateProfile.java in cross-site-scripting, then the vulnerability is indeed there. BUT this is not how the lab is distributed.

FWIW, looking at the instructor code in the WebGoat-Legacy tree, it's clear that the instructor version was built upon the version of UpdateProfile.java located in the cross-site-scripting directory, NOT the one that is in goat-hills-financial.

Seems there's an easy fix for this one, and that is to copy the UpdateProfile.java from cross-site-scripting to goat-hills-financial, but I wouldn't want to undo something that is being worked on in the goat-hills-financial version.

I have not yet exhaustively checked all the files in goat-hills-financial as well as cross-site-scripting, sql-injection, and role-based-access-control, but that's the next step. My gut feel is that what I'm seeing is a bunch of remnants from older version, but I don't know which is which.

Can anyone please shed some light on this for me?

Thanks.

Ken van Wyk