The imports used by CrossSiteScripting.java are using the versions from the base class GoatHillsFinancial for the view, edit, update and find actions. When removing these imports so the lesson-specific versions are used the injection works and I can XSS myself on the field as expected.

This revealed a new issue. When logging out of GHF and logging in as Jerry it seems the injected code is no longer saved. When viewing Tom's profile the real address for Tom is shown. The issue is the same even if not logging out and simply going to "List staff" and then "View profile" again.

I added some logging to the CreateDB.createEmployeeTable method and I can see the injected code in the db update and then the table is dropped.

try {
    String dropTable = "DROP TABLE employee";
    statement.executeUpdate(dropTable);
    System.out.println("Dropped employee table");
} catch (SQLException e) {
    System.out.println("Info - Could not drop employee table");
}

As you can see at the end the employee table is dropped and recrated. Not sure why this is happening yet.

INFO: WebGoat: Mon Feb 01 22:11:58 CET 2016
...
address1=<script>alert(1)</script>,address2=New York
...
2016-02-01 22:11:58,160 DEBUG - Mon Feb 01 22:11:58 CET 2016
...
address1=<script>alert(1)</script>,address2=New York
...
2016-02-01 22:11:58,160 DEBUG - Screen: LAB: Cross Site Scripting
2016-02-01 22:11:58,162 DEBUG - Leaving doPost: 
...
2016-02-01 22:11:59,427 INFO  - Role: user
2016-02-01 22:12:01,996 DEBUG - Entering doPost
2016-02-01 22:12:01,996 DEBUG - request: SecurityContextHolderAwareRequestWrapper[ org.springframework.security.web.context.HttpSessionSecurityContextRepository$Servlet3SaveToSessionRequestWrapper@b92419a]
2016-02-01 22:12:01,996 DEBUG - principle: org.springframework.security.authentication.UsernamePasswordAuthenticationToken@979218f8: Principal: org.springframework.security.core.userdetails.User@5e22dd8: Username: guest; Password: [PROTECTED]; Enabled: true; AccountNonExpired: true; credentialsNonExpired: true; AccountNonLocked: true; Granted Authorities: ROLE_WEBGOAT_USER; Credentials: [PROTECTED]; Authenticated: true; Details: org.springframework.security.web.authentication.WebAuthenticationDetails@0: RemoteIpAddress: 0:0:0:0:0:0:0:1; SessionId: 27D093EED34F4FC1614D914A1F0CDB18; Granted Authorities: ROLE_WEBGOAT_USER
2016-02-01 22:12:01,996 DEBUG - HH Entering Session_id: E281573DD26B8F828DDBEF5B108BD43D
Successful connection to database
Dropped employee table
Success: creating tables.
Successfully refreshed the database.

After some more debugging I have found the following:

• CrossSiteScripting class extends RandomLessonAdapter
• RandomLessonAdapter has a method setStage that recreates the database
• WebSession.update checks if the stage argument is precent on each request
• When the stage argument is passed in, WebSession.update calls setStage on the RLA.
• The stageargument is passed with every request in the GHF-form
• It seems LessonContentView.js adds the arguments to all forms in makeFormsAjax by setting the url option for the form to url: this.model.urlRoot
• Since the link to the xss-lesson stage 1 goes to #attack/279/900/1 the stage argument will be passed on for each request

Now; a few questions:

1. Is the stage argument supposed to be passed along for each request so the WebSession.update?
2. Can we remove the stage argument from the GHS requests?
3. Should another argument be added to indicate that a lesson is "ongoing" and then update WebSession.update?
4. Other?

Awesome sleuthing.

Merged so closing.