Veracode Fix — Single Advisor Holder PR v1 by github-actions[bot] · Pull Request #5 · harlockus/verademo-java-web

github-actions · 2026-01-08T20:15:46Z

This PR exists to trigger Veracode Fix (single) suggestions as PR comments/annotations.

github-actions · 2026-01-08T20:19:10Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/java/com/veracode/verademo/controller/UserController.java

Lines 161 to 171 in 9ac1141

    
           logger.info("Creating the Statement"); 
        
           String sqlQuery = "select username, password, password_hint, created_at, last_login, real_name, blab_name from users where username='" 
        
           		+ username + "' and password='" + md5(password) + "';"; 
        
           sqlStatement = connect.createStatement(); 
        
           logger.info("Execute the Statement"); 
        
           ResultSet result = sqlStatement.executeQuery(sqlQuery); 
        
           /* END BAD CODE */ 
        
           // Did we find exactly 1 user that matched? 
        
           if (result.first()) { 
        
           	logger.info("User Found.");

Caution

CWE: 89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Severity: 4
This database query contains a SQL injection flaw. The call to java.sql.Statement.executeQuery() constructs a dynamic SQL query using a variable derived from untrusted input. An attacker could exploit this flaw to execute arbitrary SQL queries against the database. The first argument to executeQuery() contains tainted data from the variable sqlQuery. The tainted data originated from an earlier call to AnnotationVirtualController.vc_annotation_entry. Avoid dynamically constructing SQL queries. Instead, use parameterized prepared statements to prevent the database from interpreting the contents of bind variables as part of the query. Always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP

--- src/main/java/com/veracode/verademo/controller/UserController.java
+++ src/main/java/com/veracode/verademo/controller/UserController.java
@@ -148,22 +148,21 @@
 		}
 
 		Connection connect = null;
-		Statement sqlStatement = null;
-
-		try {
-			// Get the Database Connection
-			logger.info("Creating the Database connection");
-			Class.forName("com.mysql.jdbc.Driver");
-			connect = DriverManager.getConnection(Constants.create().getJdbcConnectionString());
-
-			/* START BAD CODE */
-			// Execute the query
-			logger.info("Creating the Statement");
-			String sqlQuery = "select username, password, password_hint, created_at, last_login, real_name, blab_name from users where username='"
-					+ username + "' and password='" + md5(password) + "';";
-			sqlStatement = connect.createStatement();
-			logger.info("Execute the Statement");
-			ResultSet result = sqlStatement.executeQuery(sqlQuery);
+PreparedStatement sqlStatement = null;
+try {
+    // Get the Database Connection
+    logger.info("Creating the Database connection");
+    Class.forName("com.mysql.jdbc.Driver");
+    connect = DriverManager.getConnection(Constants.create().getJdbcConnectionString());
+    /* START BAD CODE */
+    // Execute the query
+    logger.info("Creating the Statement");
+    String sqlQuery = "select username, password, password_hint, created_at, last_login, real_name, blab_name from users where username=? and password=?";
+    sqlStatement = connect.prepareStatement(sqlQuery);
+    sqlStatement.setString(1, username);
+    sqlStatement.setString(2, md5(password));
+    logger.info("Execute the Statement");
+    ResultSet result = sqlStatement.executeQuery();
 			/* END BAD CODE */
 
 			// Did we find exactly 1 user that matched?

github-actions · 2026-01-08T20:19:21Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/java/com/veracode/verademo/controller/UserController.java

Lines 311 to 321 in 9ac1141

    
           Class.forName("com.mysql.jdbc.Driver"); 
        
           Connection connect = DriverManager.getConnection(Constants.create().getJdbcConnectionString()); 
        
           String sql = "SELECT username FROM users WHERE username = '" + username + "'"; 
        
           Statement statement = connect.createStatement(); 
        
           ResultSet result = statement.executeQuery(sql); 
        
           if (result.first()) { 
        
           	model.addAttribute("error", "Username '" + username + "' already exists!"); 
        
           	return "register"; 
        
           } 
        
           else {

Caution

CWE: 89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Severity: 4
This database query contains a SQL injection flaw. The call to java.sql.Statement.executeQuery() constructs a dynamic SQL query using a variable derived from untrusted input. An attacker could exploit this flaw to execute arbitrary SQL queries against the database. The first argument to executeQuery() contains tainted data from the variable sql. The tainted data originated from an earlier call to AnnotationVirtualController.vc_annotation_entry. Avoid dynamically constructing SQL queries. Instead, use parameterized prepared statements to prevent the database from interpreting the contents of bind variables as part of the query. Always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP

--- src/main/java/com/veracode/verademo/controller/UserController.java
+++ src/main/java/com/veracode/verademo/controller/UserController.java
@@ -312,8 +312,9 @@
 			Connection connect = DriverManager.getConnection(Constants.create().getJdbcConnectionString());
 
 			String sql = "SELECT username FROM users WHERE username = '" + username + "'";
-			Statement statement = connect.createStatement();
-			ResultSet result = statement.executeQuery(sql);
+PreparedStatement statement = connect.prepareStatement("SELECT username FROM users WHERE username = ?");
+statement.setString(1, username);
+ResultSet result = statement.executeQuery();
 			if (result.first()) {
 				model.addAttribute("error", "Username '" + username + "' already exists!");
 				return "register";

github-actions · 2026-01-08T20:19:33Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/java/com/veracode/verademo/controller/UserController.java

Lines 490 to 500 in 9ac1141

    
           /* START BAD CODE */ 
        
           String sqlMyEvents = "select event from users_history where blabber=\"" + username 
        
           		+ "\" ORDER BY eventid DESC; "; 
        
           logger.info(sqlMyEvents); 
        
           Statement sqlStatement = connect.createStatement(); 
        
           ResultSet userHistoryResult = sqlStatement.executeQuery(sqlMyEvents); 
        
           /* END BAD CODE */ 
        
           while (userHistoryResult.next()) { 
        
           	events.add(userHistoryResult.getString(1)); 
        
           }

Caution

CWE: 89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Severity: 4
This database query contains a SQL injection flaw. The call to java.sql.Statement.executeQuery() constructs a dynamic SQL query using a variable derived from untrusted input. An attacker could exploit this flaw to execute arbitrary SQL queries against the database. The first argument to executeQuery() contains tainted data from the variable sqlMyEvents. The tainted data originated from earlier calls to AnnotationVirtualController.vc_annotation_entry, and java.sql.Statement.executeQuery. Avoid dynamically constructing SQL queries. Instead, use parameterized prepared statements to prevent the database from interpreting the contents of bind variables as part of the query. Always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP

--- src/main/java/com/veracode/verademo/controller/UserController.java
+++ src/main/java/com/veracode/verademo/controller/UserController.java
@@ -491,8 +491,9 @@
 			String sqlMyEvents = "select event from users_history where blabber=\"" + username
 					+ "\" ORDER BY eventid DESC; ";
 			logger.info(sqlMyEvents);
-			Statement sqlStatement = connect.createStatement();
-			ResultSet userHistoryResult = sqlStatement.executeQuery(sqlMyEvents);
+PreparedStatement sqlStatement = connect.prepareStatement("select event from users_history where blabber=? ORDER BY eventid DESC");
+sqlStatement.setString(1, username);
+ResultSet userHistoryResult = sqlStatement.executeQuery();
 			/* END BAD CODE */
 
 			while (userHistoryResult.next()) {

github-actions · 2026-01-08T20:19:55Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/java/com/veracode/verademo/controller/BlabController.java

Lines 485 to 495 in 9ac1141

    
           // Find the Blabbers 
        
           logger.info(blabbersSql); 
        
           blabberQuery = connect.prepareStatement(blabbersSql); 
        
           blabberQuery.setString(1, username); 
        
           blabberQuery.setString(2, username); 
        
           ResultSet blabbersResults = blabberQuery.executeQuery(); 
        
           /* END BAD CODE */ 
        
           List<Blabber> blabbers = new ArrayList<Blabber>(); 
        
           while (blabbersResults.next()) { 
        
           	Blabber blabber = new Blabber();

Caution

CWE: 89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Severity: 4
This database query contains a SQL injection flaw. The call to java.sql.PreparedStatement.executeQuery() constructs a dynamic SQL query using a variable derived from untrusted input. An attacker could exploit this flaw to execute arbitrary SQL queries against the database. executeQuery() was called on the blabberQuery object, which contains tainted data. The tainted data originated from an earlier call to AnnotationVirtualController.vc_annotation_entry. Avoid dynamically constructing SQL queries. Instead, use parameterized prepared statements to prevent the database from interpreting the contents of bind variables as part of the query. Always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP

--- src/main/java/com/veracode/verademo/controller/BlabController.java
+++ src/main/java/com/veracode/verademo/controller/BlabController.java
@@ -467,27 +467,24 @@
 		logger.info("User is Logged In - continuing...");
 
 		Connection connect = null;
-		PreparedStatement blabberQuery = null;
-
-		/* START BAD CODE */
-		String blabbersSql = "SELECT users.username," + " users.blab_name," + " users.created_at,"
-				+ " SUM(if(listeners.listener=?, 1, 0)) as listeners,"
-				+ " SUM(if(listeners.status='Active',1,0)) as listening"
-				+ " FROM users LEFT JOIN listeners ON users.username = listeners.blabber"
-				+ " WHERE users.username NOT IN (\"admin\",?)" + " GROUP BY users.username" + " ORDER BY " + sort + ";";
-
-		try {
-			logger.info("Getting Database connection");
-			// Get the Database Connection
-			Class.forName("com.mysql.jdbc.Driver");
-			connect = DriverManager.getConnection(Constants.create().getJdbcConnectionString());
-
-			// Find the Blabbers
-			logger.info(blabbersSql);
-			blabberQuery = connect.prepareStatement(blabbersSql);
-			blabberQuery.setString(1, username);
-			blabberQuery.setString(2, username);
-			ResultSet blabbersResults = blabberQuery.executeQuery();
+PreparedStatement blabberQuery = null;
+String blabbersSql = "SELECT users.username, " + " users.blab_name, " + " users.created_at, "
++ " SUM(if(listeners.listener=?, 1, 0)) as listeners, "
++ " SUM(if(listeners.status='Active', 1, 0)) as listening"
++ " FROM users LEFT JOIN listeners ON users.username = listeners.blabber"
++ " WHERE users.username NOT IN (\"admin\", ?)" + " GROUP BY users.username" + " ORDER BY ?;";
+try {
+    logger.info("Getting Database connection");
+    // Get the Database Connection
+    Class.forName("com.mysql.jdbc.Driver");
+    connect = DriverManager.getConnection(Constants.create().getJdbcConnectionString());
+    // Find the Blabbers
+    logger.info(blabbersSql);
+    blabberQuery = connect.prepareStatement(blabbersSql);
+    blabberQuery.setString(1, username);
+    blabberQuery.setString(2, username);
+    blabberQuery.setString(3, sort);
+    ResultSet blabbersResults = blabberQuery.executeQuery();
 			/* END BAD CODE */
 
 			List<Blabber> blabbers = new ArrayList<Blabber>();

github-actions · 2026-01-08T20:20:07Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/java/com/veracode/verademo/commands/RemoveAccountCommand.java

Lines 42 to 52 in 9ac1141

    
           /* START BAD CODE ------*/ 
        
           String event = "Removed account for blabber " + result.getString(1); 
        
           sqlQuery = "INSERT INTO users_history (blabber, event) VALUES ('" + blabberUsername + "', '" + event + "')"; 
        
           logger.info(sqlQuery); 
        
           sqlStatement.execute(sqlQuery); 
        
           sqlQuery = "DELETE FROM users WHERE username = '" + blabberUsername + "'"; 
        
           logger.info(sqlQuery); 
        
           sqlStatement.execute(sqlQuery); 
        
           /* END BAD CODE */

Caution

CWE: 89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Severity: 4
This database query contains a SQL injection flaw. The call to java.sql.Statement.execute() constructs a dynamic SQL query using a variable derived from untrusted input. An attacker could exploit this flaw to execute arbitrary SQL queries against the database. The first argument to execute() contains tainted data from the variable sqlQuery. The tainted data originated from earlier calls to AnnotationVirtualController.vc_annotation_entry, and java.sql.Statement.executeQuery. Avoid dynamically constructing SQL queries. Instead, use parameterized prepared statements to prevent the database from interpreting the contents of bind variables as part of the query. Always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP

--- src/main/java/com/veracode/verademo/commands/RemoveAccountCommand.java
+++ src/main/java/com/veracode/verademo/commands/RemoveAccountCommand.java
@@ -41,10 +41,13 @@
 			result.next();
 			
 			/* START BAD CODE ------*/
-			String event = "Removed account for blabber " + result.getString(1);
-			sqlQuery = "INSERT INTO users_history (blabber, event) VALUES ('" + blabberUsername + "', '" + event + "')";
-			logger.info(sqlQuery);
-			sqlStatement.execute(sqlQuery);
+String event = "Removed account for blabber " + result.getString(1);
+    sqlQuery = "INSERT INTO users_history (blabber, event) VALUES (?, ?)";
+    PreparedStatement sqlStatement2 = connect.prepareStatement(sqlQuery);
+    sqlStatement2.setString(1, blabberUsername);
+    sqlStatement2.setString(2, event);
+    logger.info(sqlQuery);
+    sqlStatement2.execute();
 			
 			sqlQuery = "DELETE FROM users WHERE username = '" + blabberUsername + "'";
 			logger.info(sqlQuery);

github-actions · 2026-01-08T20:20:19Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/java/com/veracode/verademo/commands/ListenCommand.java

Lines 35 to 45 in 9ac1141

    
           action.execute(); 
        
           sqlQuery = "SELECT blab_name FROM users WHERE username = '" + blabberUsername + "'"; 
        
           Statement sqlStatement = connect.createStatement(); 
        
           logger.info(sqlQuery); 
        
           ResultSet result = sqlStatement.executeQuery(sqlQuery); 
        
           result.next(); 
        
           /* START BAD CODE -----*/ 
        
           String event = username + " started listening to " + blabberUsername + "(" + result.getString(1) + ")"; 
        
           sqlQuery = "INSERT INTO users_history (blabber, event) VALUES (\"" + username + "\", \"" + event + "\")";

Caution

CWE: 89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Severity: 4
This database query contains a SQL injection flaw. The call to java.sql.Statement.executeQuery() constructs a dynamic SQL query using a variable derived from untrusted input. An attacker could exploit this flaw to execute arbitrary SQL queries against the database. The first argument to executeQuery() contains tainted data from the variable sqlQuery. The tainted data originated from an earlier call to AnnotationVirtualController.vc_annotation_entry. Avoid dynamically constructing SQL queries. Instead, use parameterized prepared statements to prevent the database from interpreting the contents of bind variables as part of the query. Always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP

--- src/main/java/com/veracode/verademo/commands/ListenCommand.java
+++ src/main/java/com/veracode/verademo/commands/ListenCommand.java
@@ -35,9 +35,11 @@
 			action.execute();
 
 			sqlQuery = "SELECT blab_name FROM users WHERE username = '" + blabberUsername + "'";
-			Statement sqlStatement = connect.createStatement();
-			logger.info(sqlQuery);
-			ResultSet result = sqlStatement.executeQuery(sqlQuery);
+sqlQuery = "SELECT blab_name FROM users WHERE username = ?";
+PreparedStatement sqlStatement = connect.prepareStatement(sqlQuery);
+sqlStatement.setString(1, blabberUsername);
+logger.info(sqlQuery);
+ResultSet result = sqlStatement.executeQuery();
 			result.next();
 			
 			/* START BAD CODE -----*/

github-actions · 2026-01-08T20:20:31Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/java/com/veracode/verademo/commands/IgnoreCommand.java

Lines 35 to 45 in 9ac1141

    
           action.execute(); 
        
           sqlQuery = "SELECT blab_name FROM users WHERE username = '" + blabberUsername + "'"; 
        
           Statement sqlStatement = connect.createStatement(); 
        
           logger.info(sqlQuery); 
        
           ResultSet result = sqlStatement.executeQuery(sqlQuery); 
        
           result.next(); 
        
           /* START BAD CODE */ 
        
           String event = username + " is now ignoring " + blabberUsername + "(" + result.getString(1) + ")"; 
        
           sqlQuery = "INSERT INTO users_history (blabber, event) VALUES (\"" + username + "\", \"" + event + "\")";

Caution

CWE: 89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Severity: 4
This database query contains a SQL injection flaw. The call to java.sql.Statement.executeQuery() constructs a dynamic SQL query using a variable derived from untrusted input. An attacker could exploit this flaw to execute arbitrary SQL queries against the database. The first argument to executeQuery() contains tainted data from the variable sqlQuery. The tainted data originated from an earlier call to AnnotationVirtualController.vc_annotation_entry. Avoid dynamically constructing SQL queries. Instead, use parameterized prepared statements to prevent the database from interpreting the contents of bind variables as part of the query. Always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP

--- src/main/java/com/veracode/verademo/commands/IgnoreCommand.java
+++ src/main/java/com/veracode/verademo/commands/IgnoreCommand.java
@@ -35,9 +35,11 @@
 			action.execute();
 						
 			sqlQuery = "SELECT blab_name FROM users WHERE username = '" + blabberUsername + "'";
-			Statement sqlStatement = connect.createStatement();
-			logger.info(sqlQuery);
-			ResultSet result = sqlStatement.executeQuery(sqlQuery);
+sqlQuery = "SELECT blab_name FROM users WHERE username = ?";
+PreparedStatement sqlStatement = connect.prepareStatement(sqlQuery);
+sqlStatement.setString(1, blabberUsername);
+logger.info(sqlQuery);
+ResultSet result = sqlStatement.executeQuery();
 			result.next();
 			
 			/* START BAD CODE */

github-actions · 2026-01-08T20:20:43Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/java/com/veracode/verademo/utils/UserFactory.java

Lines 39 to 49 in 9ac1141

    
           InputStream decodedstream = Base64.getDecoder().wrap(stream); 
        
           ObjectInputStream in; 
        
           try { 
        
           	/* START BAD CODE */ 
        
           	in = new ObjectInputStream(decodedstream); 
        
           	User user = (User) in.readObject(); 
        
           	in.close(); 
        
           	/* END BAD CODE */ 
        
           	return user;

Caution

CWE: 502 Deserialization of Untrusted Data
Severity: 3
The serialized-object data stream used in the call to java.io.ObjectInput.readObject() appears to have been constructed with untrusted data. Attacker manipulation of this stream has the ability to cause the creation of objects of arbitrary Serializable types. Paired with a weakness in another class's constructor, this could result in a denial of service, code execution, or data corruption vulnerability. readObject() was called on the in object, which contains tainted data. The tainted data originated from an earlier call to javax.servlet.http.HttpServletRequest.getCookies. Avoid passing untrusted data; if the data is untrusted, consider switching to a safer serialization scheme such as JSON. References: CWE

--- src/main/java/com/veracode/verademo/utils/UserFactory.java
+++ src/main/java/com/veracode/verademo/utils/UserFactory.java
@@ -15,11 +15,15 @@
 
 import org.apache.log4j.LogManager;
 import org.apache.log4j.Logger;
+import java.io.ObjectInputFilter;
 
 public class UserFactory {
 	private static final String COOKIE_NAME = "user";
 
 	private static final Logger logger = LogManager.getLogger("VeraDemo:UserFactory");
+private static ObjectInputFilter getObjectInputFilter(){
+        return ObjectInputFilter.Config.createFilter("safe.example.Class;safe.example.package.and.subpackages.**;!*");
+    }
 
 	public static User createFromRequest(HttpServletRequest req)
 	{
@@ -41,6 +45,7 @@
 		try {
 			/* START BAD CODE */
 			in = new ObjectInputStream(decodedstream);
+in.setObjectInputFilter(getObjectInputFilter());
 			User user = (User) in.readObject();
 			in.close();
 			/* END BAD CODE */

github-actions · 2026-01-08T20:20:55Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/java/com/veracode/verademo/controller/UserController.java

Lines 168 to 178 in 9ac1141

    
           // Did we find exactly 1 user that matched? 
        
           if (result.first()) { 
        
           	logger.info("User Found."); 
        
           	// Remember the username as a courtesy. 
        
           	response.addCookie(new Cookie("username", username)); 
        
           	// If the user wants us to auto-login, store the user details as a cookie. 
        
           	if (remember != null) { 
        
           		User currentUser = new User(result.getString("username"), result.getString("password_hint"), 
        
           				result.getTimestamp("created_at"), result.getTimestamp("last_login"),

Caution

CWE: 113 Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting')
Severity: 3
This call to javax.servlet.http.HttpServletResponse.addCookie() contains an HTTP response splitting flaw. Writing untrusted input into an HTTP header allows an attacker to manipulate the HTTP response rendered by the browser, to inject additional headers or an entire response body into the response stream. Injecting headers can be used to trick various security mechanisms in browsers into allowing XSS style attacks. Injecting entire response bodies can not only cause XSS attacks to succeed but may even poison the cache of any intermediary proxies between the clients and the application server. The first argument to addCookie() contains tainted data from the variables (new Cookie(...)). The tainted data originated from an earlier call to AnnotationVirtualController.vc_annotation_entry. Escape, encode, or remove carriage return and line feed characters from untrusted data before inclusion in HTTP response headers. Whenever possible, use a security library such as ESAPI that provides safe versions of addHeader(), etc. that will automatically remove unexpected carriage returns and line feeds and can be configured to use HTML entity encoding for non-alphanumeric data. Alternatively, some of the XSS escaping functions from the OWASP Java Encoder project will also sanitize CRLF sequences. Only create a custom blocklist when absolutely necessary. Always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP Supported Cleansers

--- src/main/java/com/veracode/verademo/controller/UserController.java
+++ src/main/java/com/veracode/verademo/controller/UserController.java
@@ -50,6 +50,7 @@
 import com.veracode.verademo.utils.Constants;
 import com.veracode.verademo.utils.User;
 import com.veracode.verademo.utils.UserFactory;
+import java.net.URLEncoder;
 
 /**
  * @author johnadmin
@@ -170,7 +171,7 @@
 			if (result.first()) {
 				logger.info("User Found.");
 				// Remember the username as a courtesy.
-				response.addCookie(new Cookie("username", username));
+				response.addCookie(new Cookie("username", URLEncoder.encode(username, Charset.defaultCharset())));
 
 				// If the user wants us to auto-login, store the user details as a cookie.
 				if (remember != null) {

github-actions · 2026-01-08T20:21:06Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/java/com/veracode/verademo/controller/UserController.java

Lines 244 to 254 in 9ac1141

    
           Class.forName("com.mysql.jdbc.Driver"); 
        
           Connection connect = DriverManager.getConnection(Constants.create().getJdbcConnectionString()); 
        
           String sql = "SELECT password_hint FROM users WHERE username = '" + username + "'"; 
        
           logger.info(sql); 
        
           Statement statement = connect.createStatement(); 
        
           ResultSet result = statement.executeQuery(sql); 
        
           if (result.first()) { 
        
           	String password= result.getString("password_hint"); 
        
           	String formatString = "Username '" + username + "' has password: %.2s%s";

Caution

CWE: 117 Improper Output Neutralization for Logs
Severity: 3
This call to org.apache.log4j.Category.info() could result in a log forging attack. Writing untrusted data into a log file allows an attacker to forge log entries or inject malicious content into log files. Corrupted log files can be used to cover an attacker's tracks or as a delivery mechanism for an attack on a log viewing or processing utility. For example, if a web administrator uses a browser-based utility to review logs, a cross-site scripting attack might be possible. The first argument to info() contains tainted data from the variable sql. The tainted data originated from an earlier call to AnnotationVirtualController.vc_annotation_entry. Avoid directly embedding user input in log files when possible. Sanitize untrusted data used to construct log entries by using a safe logging mechanism such as the OWASP ESAPI Logger, which will automatically remove unexpected carriage returns and line feeds and can be configured to use HTML entity encoding for non-alphanumeric data. Alternatively, some of the XSS escaping functions from the OWASP Java Encoder project will also sanitize CRLF sequences. Only create a custom blocklist when absolutely necessary. Always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP Supported Cleansers

--- src/main/java/com/veracode/verademo/controller/UserController.java
+++ src/main/java/com/veracode/verademo/controller/UserController.java
@@ -50,6 +50,7 @@
 import com.veracode.verademo.utils.Constants;
 import com.veracode.verademo.utils.User;
 import com.veracode.verademo.utils.UserFactory;
+import org.apache.commons.text.StringEscapeUtils;
 
 /**
  * @author johnadmin
@@ -246,7 +247,7 @@
 			Connection connect = DriverManager.getConnection(Constants.create().getJdbcConnectionString());
 
 			String sql = "SELECT password_hint FROM users WHERE username = '" + username + "'";
-			logger.info(sql);
+			logger.info(StringEscapeUtils.escapeJava(sql));
 			Statement statement = connect.createStatement();
 			ResultSet result = statement.executeQuery(sql);
 			if (result.first()) {

github-actions · 2026-01-08T20:21:29Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/java/com/veracode/verademo/controller/UserController.java

Lines 251 to 261 in 9ac1141

    
           ResultSet result = statement.executeQuery(sql); 
        
           if (result.first()) { 
        
           	String password= result.getString("password_hint"); 
        
           	String formatString = "Username '" + username + "' has password: %.2s%s"; 
        
           	logger.info(formatString); 
        
           	return String.format( 
        
           			formatString, 
        
           			password, 
        
           			String.format("%0" + (password.length() - 2) + "d", 0).replace("0", "*") 
        
           	); 
        
           }

Caution

CWE: 80 Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
Severity: 3
This call to showPasswordHint() contains a cross-site scripting (XSS) flaw. The application populates the HTTP response with untrusted input, allowing an attacker to embed malicious content, such as Javascript code, which will be executed in the context of the victim's browser. XSS vulnerabilities are commonly exploited to steal or manipulate cookies, modify presentation of content, and compromise confidential information, with new attack vectors being discovered on a regular basis. The tainted data originated from earlier calls to AnnotationVirtualController.vc_annotation_entry, and java.sql.Statement.executeQuery. Use contextual escaping on all untrusted data before using it to construct any portion of an HTTP response. The escaping method should be chosen based on the specific use case of the untrusted data, otherwise it may not protect fully against the attack. For example, if the data is being written to the body of an HTML page, use HTML entity escaping; if the data is being written to an attribute, use attribute escaping; etc. Both the OWASP Java Encoder library and the Microsoft AntiXSS library provide contextual escaping methods. For more details on contextual escaping, see https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md. In addition, as a best practice, always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP Supported Cleansers

undefined

github-actions · 2026-01-08T20:21:41Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/java/com/veracode/verademo/controller/UserController.java

Lines 380 to 390 in 9ac1141

    
           	query.append("'" + blabName + "'"); 
        
           	query.append(");"); 
        
           	sqlStatement = connect.createStatement(); 
        
           	sqlStatement.execute(query.toString()); 
        
           	logger.info(query.toString()); 
        
           	/* END BAD CODE */ 
        
           	emailUser(username); 
        
           } 
        
           catch (SQLException | ClassNotFoundException ex) {

Caution

CWE: 117 Improper Output Neutralization for Logs
Severity: 3
This call to org.apache.log4j.Category.info() could result in a log forging attack. Writing untrusted data into a log file allows an attacker to forge log entries or inject malicious content into log files. Corrupted log files can be used to cover an attacker's tracks or as a delivery mechanism for an attack on a log viewing or processing utility. For example, if a web administrator uses a browser-based utility to review logs, a cross-site scripting attack might be possible. The first argument to info() contains tainted data from the variable query. The tainted data originated from earlier calls to AnnotationVirtualController.vc_annotation_entry, and java.sql.Statement.executeQuery. Avoid directly embedding user input in log files when possible. Sanitize untrusted data used to construct log entries by using a safe logging mechanism such as the OWASP ESAPI Logger, which will automatically remove unexpected carriage returns and line feeds and can be configured to use HTML entity encoding for non-alphanumeric data. Alternatively, some of the XSS escaping functions from the OWASP Java Encoder project will also sanitize CRLF sequences. Only create a custom blocklist when absolutely necessary. Always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP Supported Cleansers

--- src/main/java/com/veracode/verademo/controller/UserController.java
+++ src/main/java/com/veracode/verademo/controller/UserController.java
@@ -50,6 +50,7 @@
 import com.veracode.verademo.utils.Constants;
 import com.veracode.verademo.utils.User;
 import com.veracode.verademo.utils.UserFactory;
+import org.apache.commons.lang3.StringUtils;
 
 /**
  * @author johnadmin
@@ -382,7 +383,7 @@
 
 			sqlStatement = connect.createStatement();
 			sqlStatement.execute(query.toString());
-			logger.info(query.toString());
+logger.info(StringUtils.normalizeSpace(query.toString()));
 			/* END BAD CODE */
 
 			emailUser(username);

github-actions · 2026-01-08T20:21:53Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/java/com/veracode/verademo/controller/UserController.java

Lines 488 to 498 in 9ac1141

    
           ArrayList<String> events = new ArrayList<String>(); 
        
           /* START BAD CODE */ 
        
           String sqlMyEvents = "select event from users_history where blabber=\"" + username 
        
           		+ "\" ORDER BY eventid DESC; "; 
        
           logger.info(sqlMyEvents); 
        
           Statement sqlStatement = connect.createStatement(); 
        
           ResultSet userHistoryResult = sqlStatement.executeQuery(sqlMyEvents); 
        
           /* END BAD CODE */ 
        
           while (userHistoryResult.next()) {

Caution

CWE: 117 Improper Output Neutralization for Logs
Severity: 3
This call to org.apache.log4j.Category.info() could result in a log forging attack. Writing untrusted data into a log file allows an attacker to forge log entries or inject malicious content into log files. Corrupted log files can be used to cover an attacker's tracks or as a delivery mechanism for an attack on a log viewing or processing utility. For example, if a web administrator uses a browser-based utility to review logs, a cross-site scripting attack might be possible. The first argument to info() contains tainted data from the variable sqlMyEvents. The tainted data originated from earlier calls to AnnotationVirtualController.vc_annotation_entry, and java.sql.Statement.executeQuery. Avoid directly embedding user input in log files when possible. Sanitize untrusted data used to construct log entries by using a safe logging mechanism such as the OWASP ESAPI Logger, which will automatically remove unexpected carriage returns and line feeds and can be configured to use HTML entity encoding for non-alphanumeric data. Alternatively, some of the XSS escaping functions from the OWASP Java Encoder project will also sanitize CRLF sequences. Only create a custom blocklist when absolutely necessary. Always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP Supported Cleansers

--- src/main/java/com/veracode/verademo/controller/UserController.java
+++ src/main/java/com/veracode/verademo/controller/UserController.java
@@ -50,6 +50,7 @@
 import com.veracode.verademo.utils.Constants;
 import com.veracode.verademo.utils.User;
 import com.veracode.verademo.utils.UserFactory;
+import org.apache.commons.lang3.StringUtils;
 
 /**
  * @author johnadmin
@@ -490,7 +491,7 @@
 			/* START BAD CODE */
 			String sqlMyEvents = "select event from users_history where blabber=\"" + username
 					+ "\" ORDER BY eventid DESC; ";
-			logger.info(sqlMyEvents);
+			logger.info(StringUtils.normalizeSpace(sqlMyEvents));
 			Statement sqlStatement = connect.createStatement();
 			ResultSet userHistoryResult = sqlStatement.executeQuery(sqlMyEvents);
 			/* END BAD CODE */

github-actions · 2026-01-08T20:22:04Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/java/com/veracode/verademo/controller/UserController.java

Lines 626 to 636 in 9ac1141

    
           // Update all session and cookie logic 
        
           request.getSession().setAttribute("username", username); 
        
           for (Cookie cookie : request.getCookies()) { 
        
           	if (cookie.getName().equals("username")) { 
        
           		cookie.setValue(username); 
        
           		response.addCookie(cookie); 
        
           	} 
        
           } 
        
           // Update remember me functionality 
        
           User currentUser = UserFactory.createFromRequest(request);

Caution

CWE: 113 Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting')
Severity: 3
This call to javax.servlet.http.HttpServletResponse.addCookie() contains an HTTP response splitting flaw. Writing untrusted input into an HTTP header allows an attacker to manipulate the HTTP response rendered by the browser, to inject additional headers or an entire response body into the response stream. Injecting headers can be used to trick various security mechanisms in browsers into allowing XSS style attacks. Injecting entire response bodies can not only cause XSS attacks to succeed but may even poison the cache of any intermediary proxies between the clients and the application server. The first argument to addCookie() contains tainted data from the variable cookie. The tainted data originated from earlier calls to javax.servlet.http.HttpServletRequest.getCookies, and AnnotationVirtualController.vc_annotation_entry. Escape, encode, or remove carriage return and line feed characters from untrusted data before inclusion in HTTP response headers. Whenever possible, use a security library such as ESAPI that provides safe versions of addHeader(), etc. that will automatically remove unexpected carriage returns and line feeds and can be configured to use HTML entity encoding for non-alphanumeric data. Alternatively, some of the XSS escaping functions from the OWASP Java Encoder project will also sanitize CRLF sequences. Only create a custom blocklist when absolutely necessary. Always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP Supported Cleansers

--- src/main/java/com/veracode/verademo/controller/UserController.java
+++ src/main/java/com/veracode/verademo/controller/UserController.java
@@ -50,6 +50,7 @@
 import com.veracode.verademo.utils.Constants;
 import com.veracode.verademo.utils.User;
 import com.veracode.verademo.utils.UserFactory;
+import java.net.URLEncoder;
 
 /**
  * @author johnadmin
@@ -628,6 +629,7 @@
 			for (Cookie cookie : request.getCookies()) {
 				if (cookie.getName().equals("username")) {
 					cookie.setValue(username);
+cookie.setValue(URLEncoder.encode(username, "UTF-8"));
 					response.addCookie(cookie);
 				}
 			}

github-actions · 2026-01-08T20:22:16Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/java/com/veracode/verademo/controller/UserController.java

Lines 706 to 716 in 9ac1141

    
           	mimeType = "application/octet-stream"; 
        
           } 
        
           logger.info("MIME type: " + mimeType); 
        
           // Set content attributes for the response 
        
           response.setContentType(mimeType); 
        
           response.setContentLength((int) downloadFile.length()); 
        
           response.setHeader("Content-Disposition", "attachment; filename=" + imageName); 
        
           // get output stream of the response 
        
           outStream = response.getOutputStream();

Caution

CWE: 113 Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting')
Severity: 3
This call to javax.servlet.ServletResponse.setContentType() contains an HTTP response splitting flaw. Writing untrusted input into an HTTP header allows an attacker to manipulate the HTTP response rendered by the browser, to inject additional headers or an entire response body into the response stream. Injecting headers can be used to trick various security mechanisms in browsers into allowing XSS style attacks. Injecting entire response bodies can not only cause XSS attacks to succeed but may even poison the cache of any intermediary proxies between the clients and the application server. Escape, encode, or remove carriage return and line feed characters from untrusted data before inclusion in HTTP response headers. Whenever possible, use a security library such as ESAPI that provides safe versions of addHeader(), etc. that will automatically remove unexpected carriage returns and line feeds and can be configured to use HTML entity encoding for non-alphanumeric data. Alternatively, some of the XSS escaping functions from the OWASP Java Encoder project will also sanitize CRLF sequences. Only create a custom blocklist when absolutely necessary. Always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP Supported Cleansers

--- src/main/java/com/veracode/verademo/controller/UserController.java
+++ src/main/java/com/veracode/verademo/controller/UserController.java
@@ -50,6 +50,7 @@
 import com.veracode.verademo.utils.Constants;
 import com.veracode.verademo.utils.User;
 import com.veracode.verademo.utils.UserFactory;
+import java.net.URLEncoder;
 
 /**
  * @author johnadmin
@@ -708,7 +709,7 @@
 			logger.info("MIME type: " + mimeType);
 
 			// Set content attributes for the response
-			response.setContentType(mimeType);
+			response.setContentType(URLEncoder.encode(mimeType, Charset.defaultCharset()));
 			response.setContentLength((int) downloadFile.length());
 			response.setHeader("Content-Disposition", "attachment; filename=" + imageName);

github-actions · 2026-01-08T20:22:28Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/java/com/veracode/verademo/controller/UserController.java

Lines 798 to 808 in 9ac1141

    
           			catch (SQLException e) { 
        
           				logger.error(e); 
        
           			} 
        
           		} 
        
           		logger.info("Username: " + username + " already exists. Try again."); 
        
           		return true; 
        
           	} 
        
           	/** 
        
           	 * Change the user's username. Since the username is the DB key, we have a lot to do

Caution

CWE: 117 Improper Output Neutralization for Logs
Severity: 3
This call to org.apache.log4j.Category.info() could result in a log forging attack. Writing untrusted data into a log file allows an attacker to forge log entries or inject malicious content into log files. Corrupted log files can be used to cover an attacker's tracks or as a delivery mechanism for an attack on a log viewing or processing utility. For example, if a web administrator uses a browser-based utility to review logs, a cross-site scripting attack might be possible. The first argument to info() contains tainted data. The tainted data originated from an earlier call to AnnotationVirtualController.vc_annotation_entry. Avoid directly embedding user input in log files when possible. Sanitize untrusted data used to construct log entries by using a safe logging mechanism such as the OWASP ESAPI Logger, which will automatically remove unexpected carriage returns and line feeds and can be configured to use HTML entity encoding for non-alphanumeric data. Alternatively, some of the XSS escaping functions from the OWASP Java Encoder project will also sanitize CRLF sequences. Only create a custom blocklist when absolutely necessary. Always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP Supported Cleansers

--- src/main/java/com/veracode/verademo/controller/UserController.java
+++ src/main/java/com/veracode/verademo/controller/UserController.java
@@ -50,6 +50,7 @@
 import com.veracode.verademo.utils.Constants;
 import com.veracode.verademo.utils.User;
 import com.veracode.verademo.utils.UserFactory;
+import org.apache.commons.lang3.StringUtils;
 
 /**
  * @author johnadmin
@@ -800,7 +801,7 @@
 			}
 		}
 
-		logger.info("Username: " + username + " already exists. Try again.");
+		logger.info("Username: " + StringUtils.normalizeSpace(username) + " already exists. Try again.");
 		return true;
 	}

github-actions · 2026-01-08T20:22:40Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/java/com/veracode/verademo/controller/ResetController.java

Lines 104 to 114 in 9ac1141

    
           // Add the users 
        
           logger.info("Preparing the Stetement for adding users"); 
        
           usersStatement = connect.prepareStatement( 
        
           		"INSERT INTO users (username, password, password_hint, created_at, last_login, real_name, blab_name) values (?, ?, ?, ?, ?, ?, ?);"); 
        
           for (int i = 0; i < users.length; i++) { 
        
           	logger.info("Adding user " + users[i].getUserName()); 
        
           	usersStatement.setString(1, users[i].getUserName()); 
        
           	usersStatement.setString(2, users[i].getPassword()); 
        
           	usersStatement.setString(3, users[i].getPasswordHint()); 
        
           	usersStatement.setTimestamp(4, users[i].getDateCreated()); 
        
           	usersStatement.setTimestamp(5, users[i].getLastLogin());

Caution

CWE: 117 Improper Output Neutralization for Logs
Severity: 3
This call to org.apache.log4j.Category.info() could result in a log forging attack. Writing untrusted data into a log file allows an attacker to forge log entries or inject malicious content into log files. Corrupted log files can be used to cover an attacker's tracks or as a delivery mechanism for an attack on a log viewing or processing utility. For example, if a web administrator uses a browser-based utility to review logs, a cross-site scripting attack might be possible. The first argument to info() contains tainted data. The tainted data originated from earlier calls to java.sql.Statement.executeQuery, and AnnotationVirtualController.vc_annotation_entry. Avoid directly embedding user input in log files when possible. Sanitize untrusted data used to construct log entries by using a safe logging mechanism such as the OWASP ESAPI Logger, which will automatically remove unexpected carriage returns and line feeds and can be configured to use HTML entity encoding for non-alphanumeric data. Alternatively, some of the XSS escaping functions from the OWASP Java Encoder project will also sanitize CRLF sequences. Only create a custom blocklist when absolutely necessary. Always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP Supported Cleansers

--- src/main/java/com/veracode/verademo/controller/ResetController.java
+++ src/main/java/com/veracode/verademo/controller/ResetController.java
@@ -26,6 +26,7 @@
 import java.io.File;
 import java.io.FileReader;
 import java.io.IOException;
+import java.net.URLEncoder;
 
 @Controller
 @Scope("request")
@@ -106,7 +107,7 @@
 			usersStatement = connect.prepareStatement(
 					"INSERT INTO users (username, password, password_hint, created_at, last_login, real_name, blab_name) values (?, ?, ?, ?, ?, ?, ?);");
 			for (int i = 0; i < users.length; i++) {
-				logger.info("Adding user " + users[i].getUserName());
+				logger.info("Adding user " + URLEncoder.encode(users[i].getUserName()));
 				usersStatement.setString(1, users[i].getUserName());
 				usersStatement.setString(2, users[i].getPassword());
 				usersStatement.setString(3, users[i].getPasswordHint());

github-actions · 2026-01-08T20:22:52Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/java/com/veracode/verademo/controller/ResetController.java

Lines 127 to 137 in 9ac1141

    
           for (int j = 1; j < users.length; j++) { 
        
           	if (rand.nextBoolean() && i != j) { 
        
           		String blabber = users[i].getUserName(); 
        
           		String listener = users[j].getUserName(); 
        
           		logger.info("Adding " + listener + " as a listener of " + blabber); 
        
           		listenersStatement.setString(1, blabber); 
        
           		listenersStatement.setString(2, listener); 
        
           		listenersStatement.executeUpdate();

Caution

CWE: 117 Improper Output Neutralization for Logs
Severity: 3
This call to org.apache.log4j.Category.info() could result in a log forging attack. Writing untrusted data into a log file allows an attacker to forge log entries or inject malicious content into log files. Corrupted log files can be used to cover an attacker's tracks or as a delivery mechanism for an attack on a log viewing or processing utility. For example, if a web administrator uses a browser-based utility to review logs, a cross-site scripting attack might be possible. The first argument to info() contains tainted data. The tainted data originated from earlier calls to java.sql.Statement.executeQuery, and AnnotationVirtualController.vc_annotation_entry. Avoid directly embedding user input in log files when possible. Sanitize untrusted data used to construct log entries by using a safe logging mechanism such as the OWASP ESAPI Logger, which will automatically remove unexpected carriage returns and line feeds and can be configured to use HTML entity encoding for non-alphanumeric data. Alternatively, some of the XSS escaping functions from the OWASP Java Encoder project will also sanitize CRLF sequences. Only create a custom blocklist when absolutely necessary. Always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP Supported Cleansers

--- src/main/java/com/veracode/verademo/controller/ResetController.java
+++ src/main/java/com/veracode/verademo/controller/ResetController.java
@@ -26,6 +26,7 @@
 import java.io.File;
 import java.io.FileReader;
 import java.io.IOException;
+import org.apache.commons.lang3.StringUtils;
 
 @Controller
 @Scope("request")
@@ -129,7 +130,7 @@
 						String blabber = users[i].getUserName();
 						String listener = users[j].getUserName();
 
-						logger.info("Adding " + listener + " as a listener of " + blabber);
+logger.info("Adding " + StringUtils.normalizeSpace(listener) + " as a listener of " + blabber);
 
 						listenersStatement.setString(1, blabber);
 						listenersStatement.setString(2, listener);

github-actions · 2026-01-08T20:23:03Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/java/com/veracode/verademo/controller/ResetController.java

Lines 151 to 161 in 9ac1141

    
           for (String blabContent : blabsContent) { 
        
           	// Get the array offset for a random user, except admin who's offset 0. 
        
           	int randomUserOffset = rand.nextInt(users.length - 2) + 1; 
        
           	// get the number or seconds until some time in the last 30 days. 
        
           	long vary = rand.nextInt(30 * 24 * 3600); 
        
           	String username = users[randomUserOffset].getUserName(); 
        
           	logger.info("Adding a blab for " + username); 
        
           	blabsStatement.setString(1, username);

Caution

CWE: 331 Insufficient Entropy
Severity: 3
Standard random number generators do not provide a sufficient amount of entropy when used for security purposes. Attackers can brute force the output of pseudorandom number generators such as rand(). If this random number is used where security is a concern, such as generating a session key or session identifier, use a trusted cryptographic random number generator instead. These can be found on the Windows platform in the CryptoAPI or in an open source library such as OpenSSL. In Java, use the SecureRandom object to ensure sufficient entropy. References: CWE

undefined

github-actions · 2026-01-08T20:23:15Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/java/com/veracode/verademo/controller/ResetController.java

Lines 174 to 184 in 9ac1141

    
           logger.info("Preparing the Statement for adding comments"); 
        
           commentsStatement = connect.prepareStatement( 
        
           		"INSERT INTO comments (blabid, blabber, content, timestamp) values (?, ?, ?, ?);"); 
        
           for (int i = 1; i <= blabsContent.length; i++) { 
        
           	// Add a random number of comment 
        
           	int count = rand.nextInt(6); // (between 0 and 6) 
        
           	for (int j = 0; j < count; j++) { 
        
           		// Get the array offset for a random user, except admin who's offset 0. 
        
           		int randomUserOffset = rand.nextInt(users.length - 2) + 1; 
        
           		String username = users[randomUserOffset].getUserName();

Caution

CWE: 331 Insufficient Entropy
Severity: 3
Standard random number generators do not provide a sufficient amount of entropy when used for security purposes. Attackers can brute force the output of pseudorandom number generators such as rand(). If this random number is used where security is a concern, such as generating a session key or session identifier, use a trusted cryptographic random number generator instead. These can be found on the Windows platform in the CryptoAPI or in an open source library such as OpenSSL. In Java, use the SecureRandom object to ensure sufficient entropy. References: CWE

undefined

github-actions · 2026-01-08T20:23:27Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/java/com/veracode/verademo/controller/ResetController.java

Lines 182 to 192 in 9ac1141

    
           // Get the array offset for a random user, except admin who's offset 0. 
        
           int randomUserOffset = rand.nextInt(users.length - 2) + 1; 
        
           String username = users[randomUserOffset].getUserName(); 
        
           // Pick a random comment to add 
        
           int commentNum = rand.nextInt(commentsContent.length); 
        
           String comment = commentsContent[commentNum]; 
        
           // get the number or seconds until some time in the last 30 days. 
        
           long vary = rand.nextInt(30 * 24 * 3600);

Caution

CWE: 331 Insufficient Entropy
Severity: 3
Standard random number generators do not provide a sufficient amount of entropy when used for security purposes. Attackers can brute force the output of pseudorandom number generators such as rand(). If this random number is used where security is a concern, such as generating a session key or session identifier, use a trusted cryptographic random number generator instead. These can be found on the Windows platform in the CryptoAPI or in an open source library such as OpenSSL. In Java, use the SecureRandom object to ensure sufficient entropy. References: CWE

undefined

github-actions · 2026-01-08T20:23:38Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/java/com/veracode/verademo/controller/ResetController.java

Lines 188 to 198 in 9ac1141

    
           String comment = commentsContent[commentNum]; 
        
           // get the number or seconds until some time in the last 30 days. 
        
           long vary = rand.nextInt(30 * 24 * 3600); 
        
           logger.info("Adding a comment from " + username + " on blab ID " + String.valueOf(i)); 
        
           logger.info("Adding another comment from " + username + " on blab ID " + String.valueOf(i)); 
        
           commentsStatement.setInt(1, i); 
        
           commentsStatement.setString(2, username); 
        
           commentsStatement.setString(3, comment); 
        
           commentsStatement.setTimestamp(4, new Timestamp(now.getTime() - (vary * 1000)));

Caution

CWE: 117 Improper Output Neutralization for Logs
Severity: 3
This call to org.apache.log4j.Category.info() could result in a log forging attack. Writing untrusted data into a log file allows an attacker to forge log entries or inject malicious content into log files. Corrupted log files can be used to cover an attacker's tracks or as a delivery mechanism for an attack on a log viewing or processing utility. For example, if a web administrator uses a browser-based utility to review logs, a cross-site scripting attack might be possible. The first argument to info() contains tainted data. The tainted data originated from earlier calls to java.sql.Statement.executeQuery, and AnnotationVirtualController.vc_annotation_entry. Avoid directly embedding user input in log files when possible. Sanitize untrusted data used to construct log entries by using a safe logging mechanism such as the OWASP ESAPI Logger, which will automatically remove unexpected carriage returns and line feeds and can be configured to use HTML entity encoding for non-alphanumeric data. Alternatively, some of the XSS escaping functions from the OWASP Java Encoder project will also sanitize CRLF sequences. Only create a custom blocklist when absolutely necessary. Always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP Supported Cleansers

--- src/main/java/com/veracode/verademo/controller/ResetController.java
+++ src/main/java/com/veracode/verademo/controller/ResetController.java
@@ -26,6 +26,7 @@
 import java.io.File;
 import java.io.FileReader;
 import java.io.IOException;
+import org.apache.commons.text.StringEscapeUtils;
 
 @Controller
 @Scope("request")
@@ -190,7 +191,7 @@
 					// get the number or seconds until some time in the last 30 days.
 					long vary = rand.nextInt(30 * 24 * 3600);
 
-					logger.info("Adding a comment from " + username + " on blab ID " + String.valueOf(i));
+					logger.info("Adding a comment from " + username + " on blab ID " + String.valueOf(StringEscapeUtils.escapeJava(String.valueOf(i))));
 					logger.info("Adding another comment from " + username + " on blab ID " + String.valueOf(i));
 					commentsStatement.setInt(1, i);
 					commentsStatement.setString(2, username);

github-actions · 2026-01-08T20:23:50Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/java/com/veracode/verademo/controller/BlabController.java

Lines 199 to 209 in 9ac1141

    
           	} 
        
           	catch (SQLException | ClassNotFoundException ex) { 
        
           		logger.error(ex); 
        
           	} 
        
           	return ret.toString(); 
        
           } 
        
           @RequestMapping(value = "/feed", method = RequestMethod.POST) 
        
           public String processFeed( 
        
           		@RequestParam(value = "blab", required = true) String blab,

Caution

CWE: 80 Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
Severity: 3
This call to getMoreFeed() contains a cross-site scripting (XSS) flaw. The application populates the HTTP response with untrusted input, allowing an attacker to embed malicious content, such as Javascript code, which will be executed in the context of the victim's browser. XSS vulnerabilities are commonly exploited to steal or manipulate cookies, modify presentation of content, and compromise confidential information, with new attack vectors being discovered on a regular basis. The tainted data originated from an earlier call to java.sql.PreparedStatement.executeQuery. Use contextual escaping on all untrusted data before using it to construct any portion of an HTTP response. The escaping method should be chosen based on the specific use case of the untrusted data, otherwise it may not protect fully against the attack. For example, if the data is being written to the body of an HTML page, use HTML entity escaping; if the data is being written to an attribute, use attribute escaping; etc. Both the OWASP Java Encoder library and the Microsoft AntiXSS library provide contextual escaping methods. For more details on contextual escaping, see https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md. In addition, as a best practice, always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP Supported Cleansers

--- src/main/java/com/veracode/verademo/controller/BlabController.java
+++ src/main/java/com/veracode/verademo/controller/BlabController.java
@@ -27,6 +27,7 @@
 import com.veracode.verademo.model.Blabber;
 import com.veracode.verademo.model.Comment;
 import com.veracode.verademo.utils.Constants;
+import org.owasp.encoder.Encode;
 
 @Controller
 @Scope("request")
@@ -201,7 +202,7 @@
 			logger.error(ex);
 		}
 
-		return ret.toString();
+		return Encode.forHtml(ret).toString();
 	}
 
 	@RequestMapping(value = "/feed", method = RequestMethod.POST)

github-actions · 2026-01-08T20:24:02Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/java/com/veracode/verademo/controller/BlabController.java

Lines 553 to 563 in 9ac1141

    
           if (command == null || command.isEmpty()) { 
        
           	logger.info("Empty command provided..."); 
        
           	return nextView = "redirect:login?target=blabbers"; 
        
           } 
        
           logger.info("blabberUsername = " + blabberUsername); 
        
           logger.info("command = " + command); 
        
           Connection connect = null; 
        
           PreparedStatement action = null;

Caution

CWE: 117 Improper Output Neutralization for Logs
Severity: 3
This call to org.apache.log4j.Category.info() could result in a log forging attack. Writing untrusted data into a log file allows an attacker to forge log entries or inject malicious content into log files. Corrupted log files can be used to cover an attacker's tracks or as a delivery mechanism for an attack on a log viewing or processing utility. For example, if a web administrator uses a browser-based utility to review logs, a cross-site scripting attack might be possible. The first argument to info() contains tainted data. The tainted data originated from an earlier call to AnnotationVirtualController.vc_annotation_entry. Avoid directly embedding user input in log files when possible. Sanitize untrusted data used to construct log entries by using a safe logging mechanism such as the OWASP ESAPI Logger, which will automatically remove unexpected carriage returns and line feeds and can be configured to use HTML entity encoding for non-alphanumeric data. Alternatively, some of the XSS escaping functions from the OWASP Java Encoder project will also sanitize CRLF sequences. Only create a custom blocklist when absolutely necessary. Always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP Supported Cleansers

--- src/main/java/com/veracode/verademo/controller/BlabController.java
+++ src/main/java/com/veracode/verademo/controller/BlabController.java
@@ -27,6 +27,7 @@
 import com.veracode.verademo.model.Blabber;
 import com.veracode.verademo.model.Comment;
 import com.veracode.verademo.utils.Constants;
+import org.owasp.encoder.Encode;
 
 @Controller
 @Scope("request")
@@ -555,7 +556,7 @@
 			return nextView = "redirect:login?target=blabbers";
 		}
 
-		logger.info("blabberUsername = " + blabberUsername);
+logger.info("blabberUsername = " + Encode.forJava(blabberUsername));
 		logger.info("command = " + command);
 
 		Connection connect = null;

github-actions · 2026-01-08T20:24:13Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/java/com/veracode/verademo/commands/RemoveAccountCommand.java

Lines 41 to 51 in 9ac1141

    
           result.next(); 
        
           /* START BAD CODE ------*/ 
        
           String event = "Removed account for blabber " + result.getString(1); 
        
           sqlQuery = "INSERT INTO users_history (blabber, event) VALUES ('" + blabberUsername + "', '" + event + "')"; 
        
           logger.info(sqlQuery); 
        
           sqlStatement.execute(sqlQuery); 
        
           sqlQuery = "DELETE FROM users WHERE username = '" + blabberUsername + "'"; 
        
           logger.info(sqlQuery); 
        
           sqlStatement.execute(sqlQuery);

Caution

CWE: 117 Improper Output Neutralization for Logs
Severity: 3
This call to org.apache.log4j.Category.info() could result in a log forging attack. Writing untrusted data into a log file allows an attacker to forge log entries or inject malicious content into log files. Corrupted log files can be used to cover an attacker's tracks or as a delivery mechanism for an attack on a log viewing or processing utility. For example, if a web administrator uses a browser-based utility to review logs, a cross-site scripting attack might be possible. The first argument to info() contains tainted data from the variable sqlQuery. The tainted data originated from earlier calls to AnnotationVirtualController.vc_annotation_entry, and java.sql.Statement.executeQuery. Avoid directly embedding user input in log files when possible. Sanitize untrusted data used to construct log entries by using a safe logging mechanism such as the OWASP ESAPI Logger, which will automatically remove unexpected carriage returns and line feeds and can be configured to use HTML entity encoding for non-alphanumeric data. Alternatively, some of the XSS escaping functions from the OWASP Java Encoder project will also sanitize CRLF sequences. Only create a custom blocklist when absolutely necessary. Always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP Supported Cleansers

--- src/main/java/com/veracode/verademo/commands/RemoveAccountCommand.java
+++ src/main/java/com/veracode/verademo/commands/RemoveAccountCommand.java
@@ -8,6 +8,7 @@
 
 import org.apache.log4j.LogManager;
 import org.apache.log4j.Logger;
+import org.apache.commons.text.StringEscapeUtils;
 
 public class RemoveAccountCommand implements BlabberCommand {
 	private static final Logger logger = LogManager.getLogger("VeraDemo:RemoveAccountCommand");
@@ -43,7 +44,7 @@
 			/* START BAD CODE ------*/
 			String event = "Removed account for blabber " + result.getString(1);
 			sqlQuery = "INSERT INTO users_history (blabber, event) VALUES ('" + blabberUsername + "', '" + event + "')";
-			logger.info(sqlQuery);
+			logger.info(StringEscapeUtils.escapeJava(sqlQuery));
 			sqlStatement.execute(sqlQuery);
 			
 			sqlQuery = "DELETE FROM users WHERE username = '" + blabberUsername + "'";

github-actions · 2026-01-08T20:24:25Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/java/com/veracode/verademo/commands/ListenCommand.java

Lines 34 to 44 in 9ac1141

    
           action.setString(2, username); 
        
           action.execute(); 
        
           sqlQuery = "SELECT blab_name FROM users WHERE username = '" + blabberUsername + "'"; 
        
           Statement sqlStatement = connect.createStatement(); 
        
           logger.info(sqlQuery); 
        
           ResultSet result = sqlStatement.executeQuery(sqlQuery); 
        
           result.next(); 
        
           /* START BAD CODE -----*/ 
        
           String event = username + " started listening to " + blabberUsername + "(" + result.getString(1) + ")";

Caution

CWE: 117 Improper Output Neutralization for Logs
Severity: 3
This call to org.apache.log4j.Category.info() could result in a log forging attack. Writing untrusted data into a log file allows an attacker to forge log entries or inject malicious content into log files. Corrupted log files can be used to cover an attacker's tracks or as a delivery mechanism for an attack on a log viewing or processing utility. For example, if a web administrator uses a browser-based utility to review logs, a cross-site scripting attack might be possible. The first argument to info() contains tainted data from the variable sqlQuery. The tainted data originated from an earlier call to AnnotationVirtualController.vc_annotation_entry. Avoid directly embedding user input in log files when possible. Sanitize untrusted data used to construct log entries by using a safe logging mechanism such as the OWASP ESAPI Logger, which will automatically remove unexpected carriage returns and line feeds and can be configured to use HTML entity encoding for non-alphanumeric data. Alternatively, some of the XSS escaping functions from the OWASP Java Encoder project will also sanitize CRLF sequences. Only create a custom blocklist when absolutely necessary. Always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP Supported Cleansers

--- src/main/java/com/veracode/verademo/commands/ListenCommand.java
+++ src/main/java/com/veracode/verademo/commands/ListenCommand.java
@@ -8,6 +8,7 @@
 
 import org.apache.log4j.LogManager;
 import org.apache.log4j.Logger;
+import org.apache.commons.lang3.StringUtils;
 
 public class ListenCommand implements BlabberCommand {
 	private static final Logger logger = LogManager.getLogger("VeraDemo:ListenCommand");
@@ -36,7 +37,7 @@
 
 			sqlQuery = "SELECT blab_name FROM users WHERE username = '" + blabberUsername + "'";
 			Statement sqlStatement = connect.createStatement();
-			logger.info(sqlQuery);
+			logger.info(StringUtils.normalizeSpace(sqlQuery));
 			ResultSet result = sqlStatement.executeQuery(sqlQuery);
 			result.next();

github-actions · 2026-01-08T20:24:37Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/java/com/veracode/verademo/commands/IgnoreCommand.java

Lines 34 to 44 in 9ac1141

    
           action.setString(2, username); 
        
           action.execute(); 
        
           sqlQuery = "SELECT blab_name FROM users WHERE username = '" + blabberUsername + "'"; 
        
           Statement sqlStatement = connect.createStatement(); 
        
           logger.info(sqlQuery); 
        
           ResultSet result = sqlStatement.executeQuery(sqlQuery); 
        
           result.next(); 
        
           /* START BAD CODE */ 
        
           String event = username + " is now ignoring " + blabberUsername + "(" + result.getString(1) + ")";

Caution

CWE: 117 Improper Output Neutralization for Logs
Severity: 3
This call to org.apache.log4j.Category.info() could result in a log forging attack. Writing untrusted data into a log file allows an attacker to forge log entries or inject malicious content into log files. Corrupted log files can be used to cover an attacker's tracks or as a delivery mechanism for an attack on a log viewing or processing utility. For example, if a web administrator uses a browser-based utility to review logs, a cross-site scripting attack might be possible. The first argument to info() contains tainted data from the variable sqlQuery. The tainted data originated from an earlier call to AnnotationVirtualController.vc_annotation_entry. Avoid directly embedding user input in log files when possible. Sanitize untrusted data used to construct log entries by using a safe logging mechanism such as the OWASP ESAPI Logger, which will automatically remove unexpected carriage returns and line feeds and can be configured to use HTML entity encoding for non-alphanumeric data. Alternatively, some of the XSS escaping functions from the OWASP Java Encoder project will also sanitize CRLF sequences. Only create a custom blocklist when absolutely necessary. Always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP Supported Cleansers

--- src/main/java/com/veracode/verademo/commands/IgnoreCommand.java
+++ src/main/java/com/veracode/verademo/commands/IgnoreCommand.java
@@ -8,6 +8,7 @@
 
 import org.apache.log4j.LogManager;
 import org.apache.log4j.Logger;
+import org.apache.commons.lang3.StringUtils;
 
 public class IgnoreCommand implements BlabberCommand {	
 	private static final Logger logger = LogManager.getLogger("VeraDemo:IgnoreCommand");
@@ -36,7 +37,7 @@
 						
 			sqlQuery = "SELECT blab_name FROM users WHERE username = '" + blabberUsername + "'";
 			Statement sqlStatement = connect.createStatement();
-			logger.info(sqlQuery);
+			logger.info(StringUtils.normalizeSpace(sqlQuery));
 			ResultSet result = sqlStatement.executeQuery(sqlQuery);
 			result.next();

github-actions · 2026-01-08T20:24:49Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/java/com/veracode/verademo/controller/UserController.java

Lines 944 to 954 in 9ac1141

    
           		/* END BAD CODE */ 
        
           		message.setText(t.getMessage() + "<br>" + properties.getProperty("test") + displayErrorForWeb(t)); 
        
           		logger.info("Sending email to admin"); 
        
           		Transport.send(message); 
        
           	} 
        
           	catch (MessagingException mex) { 
        
           		mex.printStackTrace(); 
        
           	} 
        
           }

Caution

CWE: 209 Information Exposure Through an Error Message
Severity: 2
The application calls the javax.mail.Transport.send() function, which may expose information about the application logic or other details such as the names and versions of the application container and associated components. This information can be useful in executing other attacks and can also enable the attacker to target known vulnerabilities in application components. The first argument to send() contains data from an error message (possibly containing untrusted data) from the variable message. The data from an error message (possibly containing untrusted data) originated from earlier calls to java.lang.Throwable.getMessage, java.lang.NullPointerException.getMessage, and java.lang.Throwable.printStackTrace. Ensure that error codes or other messages returned to end users are not overly verbose. Sanitize all messages of any sensitive information that is not absolutely necessary. References: CWE

--- src/main/java/com/veracode/verademo/controller/UserController.java
+++ src/main/java/com/veracode/verademo/controller/UserController.java
@@ -946,7 +946,8 @@
 			message.setText(t.getMessage() + "<br>" + properties.getProperty("test") + displayErrorForWeb(t));
 
 			logger.info("Sending email to admin");
-			Transport.send(message);
+logger.severe("An exception occurred while sending email.");
+    Transport.send(message);
 		}
 		catch (MessagingException mex) {
 			mex.printStackTrace();

github-actions · 2026-01-08T20:25:00Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/java/com/veracode/verademo/controller/BlabController.java

Lines 481 to 491 in 9ac1141

    
           // Get the Database Connection 
        
           Class.forName("com.mysql.jdbc.Driver"); 
        
           connect = DriverManager.getConnection(Constants.create().getJdbcConnectionString()); 
        
           // Find the Blabbers 
        
           logger.info(blabbersSql); 
        
           blabberQuery = connect.prepareStatement(blabbersSql); 
        
           blabberQuery.setString(1, username); 
        
           blabberQuery.setString(2, username); 
        
           ResultSet blabbersResults = blabberQuery.executeQuery(); 
        
           /* END BAD CODE */

Caution

CWE: 117 Improper Output Neutralization for Logs
Severity: 3
This call to org.apache.log4j.Category.info() could result in a log forging attack. Writing untrusted data into a log file allows an attacker to forge log entries or inject malicious content into log files. Corrupted log files can be used to cover an attacker's tracks or as a delivery mechanism for an attack on a log viewing or processing utility. For example, if a web administrator uses a browser-based utility to review logs, a cross-site scripting attack might be possible. The first argument to info() contains tainted data from the variable blabbersSql. The tainted data originated from an earlier call to AnnotationVirtualController.vc_annotation_entry. Avoid directly embedding user input in log files when possible. Sanitize untrusted data used to construct log entries by using a safe logging mechanism such as the OWASP ESAPI Logger, which will automatically remove unexpected carriage returns and line feeds and can be configured to use HTML entity encoding for non-alphanumeric data. Alternatively, some of the XSS escaping functions from the OWASP Java Encoder project will also sanitize CRLF sequences. Only create a custom blocklist when absolutely necessary. Always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP Supported Cleansers

--- src/main/java/com/veracode/verademo/controller/BlabController.java
+++ src/main/java/com/veracode/verademo/controller/BlabController.java
@@ -27,6 +27,7 @@
 import com.veracode.verademo.model.Blabber;
 import com.veracode.verademo.model.Comment;
 import com.veracode.verademo.utils.Constants;
+import org.apache.commons.lang3.StringUtils;
 
 @Controller
 @Scope("request")
@@ -483,7 +484,7 @@
 			connect = DriverManager.getConnection(Constants.create().getJdbcConnectionString());
 
 			// Find the Blabbers
-			logger.info(blabbersSql);
+logger.info(StringUtils.normalizeSpace(blabbersSql));
 			blabberQuery = connect.prepareStatement(blabbersSql);
 			blabberQuery.setString(1, username);
 			blabberQuery.setString(2, username);

github-actions · 2026-01-08T20:25:12Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/webapp/WEB-INF/views/tools.jsp

Lines 63 to 73 in 9ac1141

    
           		<label for="host">Host:</label> <input type="text" name="host" 
        
           			<%if (request.getParameter("host") != null) {%> 
        
           			value="<%=request.getParameter("host")%>" <%}%> /> <input 
        
           			type="submit" value="Check" /> 
        
           	</form> 
        
           	<pre>${ping}</pre> 
        
           </div> 
        
           <div> 
        
           	<h5>Show a UNIX fortune from one of the 2 supported dictionaries.</h5> 
        
           	<form method="post"> 
        
           		<select name="fortunefile">

Caution

CWE: 80 Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
Severity: 3
This call to java.io.Writer.write() contains a cross-site scripting (XSS) flaw. The application populates the HTTP response with untrusted input, allowing an attacker to embed malicious content, such as Javascript code, which will be executed in the context of the victim's browser. XSS vulnerabilities are commonly exploited to steal or manipulate cookies, modify presentation of content, and compromise confidential information, with new attack vectors being discovered on a regular basis. The first argument to write() contains tainted data from the variable ping. The tainted data originated from an earlier call to java.lang.Process.getInputStream. The tainted data is directed into an output stream returned by javax.servlet.jsp.JspWriter. Use contextual escaping on all untrusted data before using it to construct any portion of an HTTP response. The escaping method should be chosen based on the specific use case of the untrusted data, otherwise it may not protect fully against the attack. For example, if the data is being written to the body of an HTML page, use HTML entity escaping; if the data is being written to an attribute, use attribute escaping; etc. Both the OWASP Java Encoder library and the Microsoft AntiXSS library provide contextual escaping methods. For more details on contextual escaping, see https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md. In addition, as a best practice, always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP Supported Cleansers

undefined

github-actions · 2026-01-08T20:25:24Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/webapp/WEB-INF/views/register.jsp

Lines 55 to 65 in 9ac1141

    
           		<% 
        
           			String error = (String) request.getAttribute("error"); 
        
           			if (null != error) { 
        
           		%> 
        
           		<div class="alert alert-danger" role="alert"> 
        
           			<%=error%> 
        
           		</div> 
        
           		<% 
        
           			} 
        
           		%>

Caution

CWE: 80 Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
Severity: 3
This call to javax.servlet.jsp.JspWriter.print() contains a cross-site scripting (XSS) flaw. The application populates the HTTP response with untrusted input, allowing an attacker to embed malicious content, such as Javascript code, which will be executed in the context of the victim's browser. XSS vulnerabilities are commonly exploited to steal or manipulate cookies, modify presentation of content, and compromise confidential information, with new attack vectors being discovered on a regular basis. The first argument to print() contains tainted data from the variable error. The tainted data originated from earlier calls to AnnotationVirtualController.vc_annotation_entry, java.lang.Throwable.getMessage, and java.lang.Throwable.printStackTrace. The tainted data is directed into an output stream returned by javax.servlet.jsp.JspWriter. Use contextual escaping on all untrusted data before using it to construct any portion of an HTTP response. The escaping method should be chosen based on the specific use case of the untrusted data, otherwise it may not protect fully against the attack. For example, if the data is being written to the body of an HTML page, use HTML entity escaping; if the data is being written to an attribute, use attribute escaping; etc. Both the OWASP Java Encoder library and the Microsoft AntiXSS library provide contextual escaping methods. For more details on contextual escaping, see https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md. In addition, as a best practice, always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP Supported Cleansers

undefined

github-actions · 2026-01-08T20:25:35Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/webapp/WEB-INF/views/register-finish.jsp

Lines 55 to 65 in 9ac1141

    
           		<% 
        
           			String error = (String) request.getAttribute("error"); 
        
           			if (null != error) { 
        
           		%> 
        
           		<div class="alert alert-danger" role="alert"> 
        
           			<%=error%> 
        
           		</div> 
        
           		<% 
        
           			} 
        
           		%>

Caution

CWE: 80 Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
Severity: 3
This call to javax.servlet.jsp.JspWriter.print() contains a cross-site scripting (XSS) flaw. The application populates the HTTP response with untrusted input, allowing an attacker to embed malicious content, such as Javascript code, which will be executed in the context of the victim's browser. XSS vulnerabilities are commonly exploited to steal or manipulate cookies, modify presentation of content, and compromise confidential information, with new attack vectors being discovered on a regular basis. The first argument to print() contains tainted data from the variable error. The tainted data originated from earlier calls to AnnotationVirtualController.vc_annotation_entry, java.lang.Throwable.getMessage, and java.lang.Throwable.printStackTrace. The tainted data is directed into an output stream returned by javax.servlet.jsp.JspWriter. Use contextual escaping on all untrusted data before using it to construct any portion of an HTTP response. The escaping method should be chosen based on the specific use case of the untrusted data, otherwise it may not protect fully against the attack. For example, if the data is being written to the body of an HTML page, use HTML entity escaping; if the data is being written to an attribute, use attribute escaping; etc. Both the OWASP Java Encoder library and the Microsoft AntiXSS library provide contextual escaping methods. For more details on contextual escaping, see https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md. In addition, as a best practice, always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP Supported Cleansers

undefined

github-actions · 2026-01-08T20:25:47Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/webapp/WEB-INF/views/profile.jsp

Lines 58 to 68 in 9ac1141

    
           		<% 
        
           			String error = (String) request.getAttribute("error"); 
        
           			if (null != error) { 
        
           		%> 
        
           		<div class="alert alert-danger" role="alert"> 
        
           			<%=error%> 
        
           		</div> 
        
           		<% 
        
           			} 
        
           		%>

Caution

CWE: 80 Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
Severity: 3
This call to javax.servlet.jsp.JspWriter.print() contains a cross-site scripting (XSS) flaw. The application populates the HTTP response with untrusted input, allowing an attacker to embed malicious content, such as Javascript code, which will be executed in the context of the victim's browser. XSS vulnerabilities are commonly exploited to steal or manipulate cookies, modify presentation of content, and compromise confidential information, with new attack vectors being discovered on a regular basis. The first argument to print() contains tainted data from the variable error. The tainted data originated from earlier calls to AnnotationVirtualController.vc_annotation_entry, java.lang.Throwable.getMessage, and java.lang.Throwable.printStackTrace. The tainted data is directed into an output stream returned by javax.servlet.jsp.JspWriter. Use contextual escaping on all untrusted data before using it to construct any portion of an HTTP response. The escaping method should be chosen based on the specific use case of the untrusted data, otherwise it may not protect fully against the attack. For example, if the data is being written to the body of an HTML page, use HTML entity escaping; if the data is being written to an attribute, use attribute escaping; etc. Both the OWASP Java Encoder library and the Microsoft AntiXSS library provide contextual escaping methods. For more details on contextual escaping, see https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md. In addition, as a best practice, always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP Supported Cleansers

undefined

github-actions · 2026-01-08T20:25:58Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/webapp/WEB-INF/views/profile.jsp

Lines 97 to 107 in 9ac1141

    
           <tr> 
        
           	<td>Real Name</td> 
        
           	<td> 
        
           		<div class="form-group"> 
        
           			<input type="text" class="form-control" name="realName" 
        
           				value="<%=request.getAttribute("realName")%>" /> 
        
           		</div> 
        
           	</td> 
        
           </tr> 
        
           <tr> 
        
           	<td>Blab Name</td>

Caution

CWE: 80 Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
Severity: 3
This call to javax.servlet.jsp.JspWriter.print() contains a cross-site scripting (XSS) flaw. The application populates the HTTP response with untrusted input, allowing an attacker to embed malicious content, such as Javascript code, which will be executed in the context of the victim's browser. XSS vulnerabilities are commonly exploited to steal or manipulate cookies, modify presentation of content, and compromise confidential information, with new attack vectors being discovered on a regular basis. The first argument to print() contains tainted data from the variable realName. The tainted data originated from an earlier call to java.sql.PreparedStatement.executeQuery. The tainted data is directed into an output stream returned by javax.servlet.jsp.JspWriter. Use contextual escaping on all untrusted data before using it to construct any portion of an HTTP response. The escaping method should be chosen based on the specific use case of the untrusted data, otherwise it may not protect fully against the attack. For example, if the data is being written to the body of an HTML page, use HTML entity escaping; if the data is being written to an attribute, use attribute escaping; etc. Both the OWASP Java Encoder library and the Microsoft AntiXSS library provide contextual escaping methods. For more details on contextual escaping, see https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md. In addition, as a best practice, always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP Supported Cleansers

undefined

github-actions · 2026-01-08T20:26:10Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/webapp/WEB-INF/views/profile.jsp

Lines 115 to 125 in 9ac1141

    
           <tr> 
        
           	<td>Username</td> 
        
           	<td> 
        
           		<div class="form-group"> 
        
           			<input type="text" class="form-control" name="username" 
        
           				value="<%=request.getAttribute("username")%>" /> 
        
           		</div> 
        
           	</td> 
        
           </tr> 
        
           <tr> 
        
           	<td colspan="2">

Caution

CWE: 80 Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
Severity: 3
This call to javax.servlet.jsp.JspWriter.print() contains a cross-site scripting (XSS) flaw. The application populates the HTTP response with untrusted input, allowing an attacker to embed malicious content, such as Javascript code, which will be executed in the context of the victim's browser. XSS vulnerabilities are commonly exploited to steal or manipulate cookies, modify presentation of content, and compromise confidential information, with new attack vectors being discovered on a regular basis. The first argument to print() contains tainted data from the variable username. The tainted data originated from earlier calls to AnnotationVirtualController.vc_annotation_entry, and java.sql.PreparedStatement.executeQuery. The tainted data is directed into an output stream returned by javax.servlet.jsp.JspWriter. Use contextual escaping on all untrusted data before using it to construct any portion of an HTTP response. The escaping method should be chosen based on the specific use case of the untrusted data, otherwise it may not protect fully against the attack. For example, if the data is being written to the body of an HTML page, use HTML entity escaping; if the data is being written to an attribute, use attribute escaping; etc. Both the OWASP Java Encoder library and the Microsoft AntiXSS library provide contextual escaping methods. For more details on contextual escaping, see https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md. In addition, as a best practice, always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP Supported Cleansers

undefined

github-actions · 2026-01-08T20:26:21Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/webapp/WEB-INF/views/profile.jsp

Lines 159 to 169 in 9ac1141

    
           	<div class="clear"> 
        
           		<div class="commenterImage"> 
        
           			<img src="resources/images/<%= heckler.getUsername() %>.png" /> 
        
           		</div> 
        
           		<div class="commentText"> 
        
           			<p><%= heckler.getBlabName() %></p> 
        
           			<span class="date sub-text">member since <%= heckler.getCreatedDateString() %></span> 
        
           			<br/> 
        
           		</div> 
        
           	</div> 
        
           </li>

Caution

CWE: 80 Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
Severity: 3
This call to javax.servlet.jsp.JspWriter.print() contains a cross-site scripting (XSS) flaw. The application populates the HTTP response with untrusted input, allowing an attacker to embed malicious content, such as Javascript code, which will be executed in the context of the victim's browser. XSS vulnerabilities are commonly exploited to steal or manipulate cookies, modify presentation of content, and compromise confidential information, with new attack vectors being discovered on a regular basis. The first argument to print() contains tainted data from the variable heckler.getBlabName(). The tainted data originated from an earlier call to java.sql.PreparedStatement.executeQuery. The tainted data is directed into an output stream returned by javax.servlet.jsp.JspWriter. Use contextual escaping on all untrusted data before using it to construct any portion of an HTTP response. The escaping method should be chosen based on the specific use case of the untrusted data, otherwise it may not protect fully against the attack. For example, if the data is being written to the body of an HTML page, use HTML entity escaping; if the data is being written to an attribute, use attribute escaping; etc. Both the OWASP Java Encoder library and the Microsoft AntiXSS library provide contextual escaping methods. For more details on contextual escaping, see https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md. In addition, as a best practice, always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP Supported Cleansers

--- src/main/webapp/WEB-INF/views/profile.jsp
+++ src/main/webapp/WEB-INF/views/profile.jsp
@@ -1,3 +1,4 @@
+import org.owasp.esapi.ESAPI;
 <%@ page language="java" contentType="text/html; charset=US-ASCII"
 	pageEncoding="US-ASCII"%>
 <%@ page import="java.util.*"%>
@@ -161,7 +162,7 @@
 										<img src="resources/images/<%= heckler.getUsername() %>.png" />
 									</div>
 									<div class="commentText">
-										<p><%= heckler.getBlabName() %></p>
+										<p><%= heckler.getBlabName() %></p><p><%= ESAPI.encoder().encodeForHTMLAttribute(heckler.getBlabName()) %></p>										<p><%= heckler.getBlabName() %></p>
 										<span class="date sub-text">member since <%= heckler.getCreatedDateString() %></span>
 										<br/>
 									</div>

github-actions · 2026-01-08T20:26:33Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/webapp/WEB-INF/views/login.jsp

Lines 53 to 63 in 9ac1141

    
           		<% 
        
           			String error = (String) request.getAttribute("error"); 
        
           			if (null != error) { 
        
           		%> 
        
           		<div class="alert alert-danger" role="alert"> 
        
           			<%=error%> 
        
           		</div> 
        
           		<% 
        
           			} 
        
           		%>

Caution

CWE: 80 Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
Severity: 3
This call to javax.servlet.jsp.JspWriter.print() contains a cross-site scripting (XSS) flaw. The application populates the HTTP response with untrusted input, allowing an attacker to embed malicious content, such as Javascript code, which will be executed in the context of the victim's browser. XSS vulnerabilities are commonly exploited to steal or manipulate cookies, modify presentation of content, and compromise confidential information, with new attack vectors being discovered on a regular basis. The first argument to print() contains tainted data from the variable error. The tainted data originated from earlier calls to AnnotationVirtualController.vc_annotation_entry, java.lang.Throwable.getMessage, and java.lang.Throwable.printStackTrace. The tainted data is directed into an output stream returned by javax.servlet.jsp.JspWriter. Use contextual escaping on all untrusted data before using it to construct any portion of an HTTP response. The escaping method should be chosen based on the specific use case of the untrusted data, otherwise it may not protect fully against the attack. For example, if the data is being written to the body of an HTML page, use HTML entity escaping; if the data is being written to an attribute, use attribute escaping; etc. Both the OWASP Java Encoder library and the Microsoft AntiXSS library provide contextual escaping methods. For more details on contextual escaping, see https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md. In addition, as a best practice, always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP Supported Cleansers

undefined

github-actions · 2026-01-08T20:26:44Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/webapp/WEB-INF/views/login.jsp

Lines 79 to 89 in 9ac1141

    
           <tbody> 
        
           	<tr> 
        
           		<td>Username</td> 
        
           		<td><div class="form-group"> 
        
           				<input type="text" class="form-control" name="user" 
        
           					value="<%=(String) request.getAttribute("username")%>"> 
        
           			</div><a href="javascript:hint()">Hint</a></td> 
        
           	</tr> 
        
           	<tr> 
        
           		<td>Password</td> 
        
           		<td><div class="form-group">

Caution

CWE: 80 Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
Severity: 3
This call to javax.servlet.jsp.JspWriter.print() contains a cross-site scripting (XSS) flaw. The application populates the HTTP response with untrusted input, allowing an attacker to embed malicious content, such as Javascript code, which will be executed in the context of the victim's browser. XSS vulnerabilities are commonly exploited to steal or manipulate cookies, modify presentation of content, and compromise confidential information, with new attack vectors being discovered on a regular basis. The first argument to print() contains tainted data from the variable username. The tainted data originated from earlier calls to AnnotationVirtualController.vc_annotation_entry, and java.sql.PreparedStatement.executeQuery. The tainted data is directed into an output stream returned by javax.servlet.jsp.JspWriter. Use contextual escaping on all untrusted data before using it to construct any portion of an HTTP response. The escaping method should be chosen based on the specific use case of the untrusted data, otherwise it may not protect fully against the attack. For example, if the data is being written to the body of an HTML page, use HTML entity escaping; if the data is being written to an attribute, use attribute escaping; etc. Both the OWASP Java Encoder library and the Microsoft AntiXSS library provide contextual escaping methods. For more details on contextual escaping, see https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md. In addition, as a best practice, always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP Supported Cleansers

undefined

github-actions · 2026-01-08T20:26:56Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/webapp/WEB-INF/views/feed.jsp

Lines 65 to 75 in 9ac1141

    
           			String error = (String) request.getAttribute("error"); 
        
           			if (null != error) { 
        
           		%> 
        
           		<div class="alert alert-danger" role="alert"> 
        
           			<%=error%> 
        
           		</div> 
        
           		<% 
        
           			} 
        
           		%>

Caution

CWE: 80 Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
Severity: 3
This call to javax.servlet.jsp.JspWriter.print() contains a cross-site scripting (XSS) flaw. The application populates the HTTP response with untrusted input, allowing an attacker to embed malicious content, such as Javascript code, which will be executed in the context of the victim's browser. XSS vulnerabilities are commonly exploited to steal or manipulate cookies, modify presentation of content, and compromise confidential information, with new attack vectors being discovered on a regular basis. The first argument to print() contains tainted data from the variable error. The tainted data originated from earlier calls to AnnotationVirtualController.vc_annotation_entry, java.lang.Throwable.getMessage, and java.lang.Throwable.printStackTrace. The tainted data is directed into an output stream returned by javax.servlet.jsp.JspWriter. Use contextual escaping on all untrusted data before using it to construct any portion of an HTTP response. The escaping method should be chosen based on the specific use case of the untrusted data, otherwise it may not protect fully against the attack. For example, if the data is being written to the body of an HTML page, use HTML entity escaping; if the data is being written to an attribute, use attribute escaping; etc. Both the OWASP Java Encoder library and the Microsoft AntiXSS library provide contextual escaping methods. For more details on contextual escaping, see https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md. In addition, as a best practice, always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP Supported Cleansers

undefined

github-actions · 2026-01-08T20:27:07Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/webapp/WEB-INF/views/feed.jsp

Lines 92 to 102 in 9ac1141

    
           <div> 
        
           	<div class="commenterImage"> 
        
           		<img src="resources/images/<%= post.getAuthor().getUsername() %>.png" /> 
        
           	</div> 
        
           	<div class="commentText"> 
        
           		<p class=""><%= post.getContent() %></p> 
        
           		<span class="date sub-text"> 
        
           			by <%= post.getAuthor().getBlabName() %> on <%= post.getPostDateString() %> 
        
           		</span> 
        
           		<br/> 
        
           		<span class="date sub-text">

Caution

CWE: 80 Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
Severity: 3
This call to javax.servlet.jsp.JspWriter.print() contains a cross-site scripting (XSS) flaw. The application populates the HTTP response with untrusted input, allowing an attacker to embed malicious content, such as Javascript code, which will be executed in the context of the victim's browser. XSS vulnerabilities are commonly exploited to steal or manipulate cookies, modify presentation of content, and compromise confidential information, with new attack vectors being discovered on a regular basis. The first argument to print() contains tainted data from the variable post.getContent(). The tainted data originated from an earlier call to java.sql.PreparedStatement.executeQuery. The tainted data is directed into an output stream returned by javax.servlet.jsp.JspWriter. Use contextual escaping on all untrusted data before using it to construct any portion of an HTTP response. The escaping method should be chosen based on the specific use case of the untrusted data, otherwise it may not protect fully against the attack. For example, if the data is being written to the body of an HTML page, use HTML entity escaping; if the data is being written to an attribute, use attribute escaping; etc. Both the OWASP Java Encoder library and the Microsoft AntiXSS library provide contextual escaping methods. For more details on contextual escaping, see https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md. In addition, as a best practice, always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP Supported Cleansers

--- src/main/webapp/WEB-INF/views/feed.jsp
+++ src/main/webapp/WEB-INF/views/feed.jsp
@@ -1,3 +1,4 @@
+import org.owasp.esapi.ESAPI;
 <%@ page language="java" contentType="text/html; charset=US-ASCII"
 	pageEncoding="US-ASCII"%>
 <%@ page import="com.veracode.verademo.model.*"%>
@@ -94,7 +95,7 @@
 										<img src="resources/images/<%= post.getAuthor().getUsername() %>.png" />
 									</div>
 									<div class="commentText">
-										<p class=""><%= post.getContent() %></p>
+										<p class=""><%= post.getContent() %></p><p class=""><%= ESAPI.encoder().encodeForHTMLAttribute(post.getContent()) %></p>										<p class=""><%= post.getContent() %></p>
 										<span class="date sub-text">
 											by <%= post.getAuthor().getBlabName() %> on <%= post.getPostDateString() %>
 										</span>

github-actions · 2026-01-08T20:27:19Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/webapp/WEB-INF/views/feed.jsp

Lines 137 to 147 in 9ac1141

    
           								for (Blab post : myBlabs) { 
        
           							%> 
        
           							<li> 
        
           								<div class="commentText"> 
        
           									<p class=""><%= post.getContent() %></p> 
        
           									<span class="date sub-text">by you on <%= post.getPostDateString() %></span><br/> 
        
           									<span class="date sub-text"> 
        
           										<a href="blab?blabid=<%= post.getId() %>"><%= post.getCommentCount() %> Comments</a> 
        
           									</span> 
        
           								</div>

Caution

CWE: 80 Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
Severity: 3
This call to javax.servlet.jsp.JspWriter.print() contains a cross-site scripting (XSS) flaw. The application populates the HTTP response with untrusted input, allowing an attacker to embed malicious content, such as Javascript code, which will be executed in the context of the victim's browser. XSS vulnerabilities are commonly exploited to steal or manipulate cookies, modify presentation of content, and compromise confidential information, with new attack vectors being discovered on a regular basis. The first argument to print() contains tainted data from the variable post.getContent(). The tainted data originated from an earlier call to java.sql.PreparedStatement.executeQuery. The tainted data is directed into an output stream returned by javax.servlet.jsp.JspWriter. Use contextual escaping on all untrusted data before using it to construct any portion of an HTTP response. The escaping method should be chosen based on the specific use case of the untrusted data, otherwise it may not protect fully against the attack. For example, if the data is being written to the body of an HTML page, use HTML entity escaping; if the data is being written to an attribute, use attribute escaping; etc. Both the OWASP Java Encoder library and the Microsoft AntiXSS library provide contextual escaping methods. For more details on contextual escaping, see https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md. In addition, as a best practice, always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP Supported Cleansers

undefined

github-actions · 2026-01-08T20:27:30Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/webapp/WEB-INF/views/blabbers.jsp

Lines 96 to 106 in 9ac1141

    
           									for (Blabber blabber : blabbers) { 
        
           								%> 
        
           								<tr> 
        
           									<td class="commenterImage"> 
        
           										<img src="resources/images/<%= blabber.getUsername() %>.png" /> 
        
           									</td> 
        
           									<td class="commenterName"> 
        
           										<%= blabber.getBlabName() %> 
        
           									</td> 
        
           									<td class="commenterJoinDate">

Caution

CWE: 80 Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
Severity: 3
This call to javax.servlet.jsp.JspWriter.print() contains a cross-site scripting (XSS) flaw. The application populates the HTTP response with untrusted input, allowing an attacker to embed malicious content, such as Javascript code, which will be executed in the context of the victim's browser. XSS vulnerabilities are commonly exploited to steal or manipulate cookies, modify presentation of content, and compromise confidential information, with new attack vectors being discovered on a regular basis. The first argument to print() contains tainted data from the variable blabber.getUsername(). The tainted data originated from an earlier call to java.sql.PreparedStatement.executeQuery. The tainted data is directed into an output stream returned by javax.servlet.jsp.JspWriter. Use contextual escaping on all untrusted data before using it to construct any portion of an HTTP response. The escaping method should be chosen based on the specific use case of the untrusted data, otherwise it may not protect fully against the attack. For example, if the data is being written to the body of an HTML page, use HTML entity escaping; if the data is being written to an attribute, use attribute escaping; etc. Both the OWASP Java Encoder library and the Microsoft AntiXSS library provide contextual escaping methods. For more details on contextual escaping, see https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md. In addition, as a best practice, always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP Supported Cleansers

undefined

github-actions · 2026-01-08T20:27:41Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/webapp/WEB-INF/views/blab.jsp

Lines 52 to 62 in 9ac1141

    
           </div> 
        
           <div class="container theme-showcase" role="main"> 
        
           	<div class="page-header"> 
        
           		<h4><%= request.getAttribute("blab_name") %> says...</h4> 
        
           	</div> 
        
           	<div> 
        
           		<blockquote> 
        
           			<h3><%= request.getAttribute("content") %></h3> 
        
           		</blockquote>

Caution

CWE: 80 Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
Severity: 3
This call to javax.servlet.jsp.JspWriter.print() contains a cross-site scripting (XSS) flaw. The application populates the HTTP response with untrusted input, allowing an attacker to embed malicious content, such as Javascript code, which will be executed in the context of the victim's browser. XSS vulnerabilities are commonly exploited to steal or manipulate cookies, modify presentation of content, and compromise confidential information, with new attack vectors being discovered on a regular basis. The first argument to print() contains tainted data from the variable blab_name. The tainted data originated from an earlier call to java.sql.PreparedStatement.executeQuery. The tainted data is directed into an output stream returned by javax.servlet.jsp.JspWriter. Use contextual escaping on all untrusted data before using it to construct any portion of an HTTP response. The escaping method should be chosen based on the specific use case of the untrusted data, otherwise it may not protect fully against the attack. For example, if the data is being written to the body of an HTML page, use HTML entity escaping; if the data is being written to an attribute, use attribute escaping; etc. Both the OWASP Java Encoder library and the Microsoft AntiXSS library provide contextual escaping methods. For more details on contextual escaping, see https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md. In addition, as a best practice, always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP Supported Cleansers

undefined

github-actions · 2026-01-08T20:27:53Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/webapp/WEB-INF/views/blab.jsp

Lines 64 to 74 in 9ac1141

    
           		<% 
        
           			String error = (String) request.getAttribute("error"); 
        
           			if (error != null) { 
        
           		%> 
        
           		<div class="alert alert-danger" role="alert"> 
        
           			<%= error %> 
        
           		</div> 
        
           		<% 
        
           			} 
        
           		%>

Caution

CWE: 80 Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
Severity: 3
This call to javax.servlet.jsp.JspWriter.print() contains a cross-site scripting (XSS) flaw. The application populates the HTTP response with untrusted input, allowing an attacker to embed malicious content, such as Javascript code, which will be executed in the context of the victim's browser. XSS vulnerabilities are commonly exploited to steal or manipulate cookies, modify presentation of content, and compromise confidential information, with new attack vectors being discovered on a regular basis. The first argument to print() contains tainted data from the variable error. The tainted data originated from earlier calls to AnnotationVirtualController.vc_annotation_entry, java.lang.Throwable.getMessage, and java.lang.Throwable.printStackTrace. The tainted data is directed into an output stream returned by javax.servlet.jsp.JspWriter. Use contextual escaping on all untrusted data before using it to construct any portion of an HTTP response. The escaping method should be chosen based on the specific use case of the untrusted data, otherwise it may not protect fully against the attack. For example, if the data is being written to the body of an HTML page, use HTML entity escaping; if the data is being written to an attribute, use attribute escaping; etc. Both the OWASP Java Encoder library and the Microsoft AntiXSS library provide contextual escaping methods. For more details on contextual escaping, see https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md. In addition, as a best practice, always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP Supported Cleansers

undefined

github-actions · 2026-01-08T20:28:04Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/webapp/WEB-INF/views/blab.jsp

Lines 104 to 114 in 9ac1141

    
           	<div class="commenterImage"> 
        
           		<img src="resources/images/<%= comment.getAuthor().getUsername() %>.png" /> 
        
           	</div> 
        
           	<div class="blockquote"> 
        
           		<p class=""> 
        
           			"<%= comment.getContent() %>" 
        
           		</p> 
        
           		<span class="date sub-text">by <%= comment.getAuthor().getBlabName() %> 
        
           			on <%= comment.getTimestampString() %></span><br> 
        
           	</div> 
        
           </div>

Caution

CWE: 80 Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
Severity: 3
This call to javax.servlet.jsp.JspWriter.print() contains a cross-site scripting (XSS) flaw. The application populates the HTTP response with untrusted input, allowing an attacker to embed malicious content, such as Javascript code, which will be executed in the context of the victim's browser. XSS vulnerabilities are commonly exploited to steal or manipulate cookies, modify presentation of content, and compromise confidential information, with new attack vectors being discovered on a regular basis. The first argument to print() contains tainted data from the variable comment.getContent(). The tainted data originated from an earlier call to java.sql.PreparedStatement.executeQuery. The tainted data is directed into an output stream returned by javax.servlet.jsp.JspWriter. Use contextual escaping on all untrusted data before using it to construct any portion of an HTTP response. The escaping method should be chosen based on the specific use case of the untrusted data, otherwise it may not protect fully against the attack. For example, if the data is being written to the body of an HTML page, use HTML entity escaping; if the data is being written to an attribute, use attribute escaping; etc. Both the OWASP Java Encoder library and the Microsoft AntiXSS library provide contextual escaping methods. For more details on contextual escaping, see https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md. In addition, as a best practice, always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP Supported Cleansers

--- src/main/webapp/WEB-INF/views/blab.jsp
+++ src/main/webapp/WEB-INF/views/blab.jsp
@@ -1,3 +1,4 @@
+import org.springframework.web.util.HtmlUtils;
 <%@ page language="java" contentType="text/html; charset=US-ASCII"
 	pageEncoding="US-ASCII"%>
 <%@ page import="com.veracode.verademo.model.*"%>
@@ -106,7 +107,7 @@
 									</div>
 									<div class="blockquote">
 										<p class="">
-											"<%= comment.getContent() %>"
+											"<%= comment.getContent() %>"<%= HtmlUtils.htmlEscape(comment.getContent()) %>											"<%= comment.getContent() %>"
 										</p>
 										<span class="date sub-text">by <%= comment.getAuthor().getBlabName() %>
 											on <%= comment.getTimestampString() %></span><br>

github-actions · 2026-01-08T20:28:16Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/webapp/WEB-INF/views/register-finish.jsp

Lines 55 to 65 in 9ac1141

    
           		<% 
        
           			String error = (String) request.getAttribute("error"); 
        
           			if (null != error) { 
        
           		%> 
        
           		<div class="alert alert-danger" role="alert"> 
        
           			<%=error%> 
        
           		</div> 
        
           		<% 
        
           			} 
        
           		%>

Caution

CWE: 209 Information Exposure Through an Error Message
Severity: 2
The application calls the javax.servlet.jsp.JspWriter.print() function, which may expose information about the application logic or other details such as the names and versions of the application container and associated components. This information can be useful in executing other attacks and can also enable the attacker to target known vulnerabilities in application components. The first argument to print() contains data from an error message (possibly containing untrusted data) from the variable error. The data from an error message (possibly containing untrusted data) originated from earlier calls to AnnotationVirtualController.vc_annotation_entry, java.lang.Throwable.getMessage, and java.lang.Throwable.printStackTrace. The data from an error message (possibly containing untrusted data) is directed into an output stream returned by javax.servlet.jsp.JspWriter. Ensure that error codes or other messages returned to end users are not overly verbose. Sanitize all messages of any sensitive information that is not absolutely necessary. References: CWE

undefined

github-actions · 2026-01-08T20:28:27Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/webapp/WEB-INF/views/login.jsp

Lines 53 to 63 in 9ac1141

    
           		<% 
        
           			String error = (String) request.getAttribute("error"); 
        
           			if (null != error) { 
        
           		%> 
        
           		<div class="alert alert-danger" role="alert"> 
        
           			<%=error%> 
        
           		</div> 
        
           		<% 
        
           			} 
        
           		%>

Caution

CWE: 209 Information Exposure Through an Error Message
Severity: 2
The application calls the javax.servlet.jsp.JspWriter.print() function, which may expose information about the application logic or other details such as the names and versions of the application container and associated components. This information can be useful in executing other attacks and can also enable the attacker to target known vulnerabilities in application components. The first argument to print() contains data from an error message (possibly containing untrusted data) from the variable error. The data from an error message (possibly containing untrusted data) originated from earlier calls to AnnotationVirtualController.vc_annotation_entry, java.lang.Throwable.getMessage, and java.lang.Throwable.printStackTrace. The data from an error message (possibly containing untrusted data) is directed into an output stream returned by javax.servlet.jsp.JspWriter. Ensure that error codes or other messages returned to end users are not overly verbose. Sanitize all messages of any sensitive information that is not absolutely necessary. References: CWE

undefined

github-actions · 2026-01-08T20:28:38Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/webapp/WEB-INF/views/blabbers.jsp

Lines 61 to 71 in 9ac1141

    
           		<% 
        
           			String error = (String) request.getAttribute("error"); 
        
           			if (null != error) { 
        
           		%> 
        
           		<div class="alert alert-danger" role="alert"> 
        
           			<%=error%> 
        
           		</div> 
        
           		<% 
        
           			} 
        
           		%>

Caution

CWE: 209 Information Exposure Through an Error Message
Severity: 2
The application calls the javax.servlet.jsp.JspWriter.print() function, which may expose information about the application logic or other details such as the names and versions of the application container and associated components. This information can be useful in executing other attacks and can also enable the attacker to target known vulnerabilities in application components. The first argument to print() contains data from an error message (possibly containing untrusted data) from the variable error. The data from an error message (possibly containing untrusted data) originated from earlier calls to AnnotationVirtualController.vc_annotation_entry, java.lang.Throwable.getMessage, and java.lang.Throwable.printStackTrace. The data from an error message (possibly containing untrusted data) is directed into an output stream returned by javax.servlet.jsp.JspWriter. Ensure that error codes or other messages returned to end users are not overly verbose. Sanitize all messages of any sensitive information that is not absolutely necessary. References: CWE

undefined

github-actions · 2026-01-08T20:28:50Z

Caution

Breaking Flaw identified in code!

verademo-java-web/src/main/webapp/WEB-INF/views/profile.jsp

Lines 199 to 209 in 9ac1141

    
           							%> 
        
           							<li> 
        
           								<p class=""><%=events.get(i)%></p> 
        
           							</li> 
        
           							<% 
        
           									} 
        
           								} 
        
           								else { 
        
           							%> 
        
           							<li> 
        
           								<p class="">You haven't done anything yet!</p>

Caution

CWE: 80 Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
Severity: 3
This call to getMoreFeed() contains a cross-site scripting (XSS) flaw. The application populates the HTTP response with untrusted input, allowing an attacker to embed malicious content, such as Javascript code, which will be executed in the context of the victim's browser. XSS vulnerabilities are commonly exploited to steal or manipulate cookies, modify presentation of content, and compromise confidential information, with new attack vectors being discovered on a regular basis. The tainted data originated from an earlier call to java.sql.PreparedStatement.executeQuery. Use contextual escaping on all untrusted data before using it to construct any portion of an HTTP response. The escaping method should be chosen based on the specific use case of the untrusted data, otherwise it may not protect fully against the attack. For example, if the data is being written to the body of an HTML page, use HTML entity escaping; if the data is being written to an attribute, use attribute escaping; etc. Both the OWASP Java Encoder library and the Microsoft AntiXSS library provide contextual escaping methods. For more details on contextual escaping, see https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md. In addition, as a best practice, always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. References: CWE OWASP Supported Cleansers

--- src/main/webapp/WEB-INF/views/profile.jsp
+++ src/main/webapp/WEB-INF/views/profile.jsp
@@ -1,3 +1,4 @@
+import org.owasp.esapi.ESAPI;
 <%@ page language="java" contentType="text/html; charset=US-ASCII"
 	pageEncoding="US-ASCII"%>
 <%@ page import="java.util.*"%>
@@ -245,7 +246,7 @@
 							$.each(data.values, function(key, val) {
 								$('input[name="' + key + '"]').val(val);
 								if (key === "username") {
-									$('#profileImage').attr('src', 'resources/images/' + val + '.png');
+									$('#profileImage').attr('src', 'resources/images/' + val + '.png');$('#profileImage').attr('src', 'resources/images/' + ESAPI.encoder().encodeForHTMLAttribute(val) + '.png')									$('#profileImage').attr('src', 'resources/images/' + val + '.png');
 								}
 							});
 						}

github-actions · 2026-01-08T20:29:01Z

Caution

Breaking Flaw identified in code!

https://github.com/harlockus/verademo-java-web/blob/9ac1141af46027ef3a028136af8c95a996356bed/src/main/webapp/WEB-INF/views/feed.jsp#L225-L235

Caution

CWE: 73 External Control of File Name or Path
Severity: 3
This call to processLogin() contains a path manipulation flaw. The argument to the function is a filename constructed using untrusted input. If an attacker is allowed to specify all or part of the filename, it may be possible to gain unauthorized access to files on the server, including those outside the webroot, that would be normally be inaccessible to end users. The level of exposure depends on the effectiveness of input validation routines, if any. The tainted data originated from an earlier call to AnnotationVirtualController.vc_annotation_entry. Validate all untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. When using blocklists, be sure that the sanitizing routine performs a sufficient number of iterations to remove all instances of disallowed characters. References: CWE OWASP

undefined

chore: create holder PR for Veracode Fix single advisor

950e8bc

harlockus closed this Jan 8, 2026

harlockus reopened this Jan 8, 2026

harlockus closed this Jan 15, 2026

Conversation

github-actions Bot commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026