Coder Social home page Coder Social logo

veracode-async's People

Contributors

lerer avatar

Watchers

avatar avatar

veracode-async's Issues

Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)

Description:

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.

  • Veracode issue ID: 189
  • Severity: Medium
  • Location: /WEB-INF/views/login.jsp:86
  • Issue found on build: 11171357
  • Issue first found at: Tue, 05 Jan 2021 04:12:30 GMT
  • Scanner: Veracode Static Application Security Testing

Identifiers:

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

Description:

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.

  • Veracode issue ID: 161
  • Severity: High
  • Location: com/veracode/verademo/commands/ListenCommand.java:40
  • Issue found on build: 11171357
  • Issue first found at: Tue, 05 Jan 2021 04:12:30 GMT
  • Scanner: Veracode Static Application Security Testing

Identifiers:

Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)

Description:

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 target. The tainted data originated from an earlier call to AnnotationVirtualController.vc_annotation_entry. 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.

  • Veracode issue ID: 190
  • Severity: Medium
  • Location: /WEB-INF/views/login.jsp:79
  • Issue found on build: 11171357
  • Issue first found at: Tue, 05 Jan 2021 04:12:30 GMT
  • Scanner: Veracode Static Application Security Testing

Identifiers:

Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)

Description:

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 fortunes. 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.

  • Veracode issue ID: 160
  • Severity: Medium
  • Location: /WEB-INF/views/tools.jsp:78
  • Issue found on build: 11171357
  • Issue first found at: Tue, 05 Jan 2021 04:12:30 GMT
  • Scanner: Veracode Static Application Security Testing

Identifiers:

Improper Output Neutralization for Logs

Description:

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.

Identifiers:

Insufficient Entropy

Description:

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.

Identifiers:

Improper Output Neutralization for Logs

Description:

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.

Identifiers:

Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)

Description:

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.

  • Veracode issue ID: 156
  • Severity: Medium
  • Location: /WEB-INF/views/profile.jsp:63
  • Issue found on build: 11171357
  • Issue first found at: Tue, 05 Jan 2021 04:12:30 GMT
  • Scanner: Veracode Static Application Security Testing

Identifiers:

Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)

Description:

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 blabName. 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.

  • Veracode issue ID: 173
  • Severity: Medium
  • Location: /WEB-INF/views/profile.jsp:111
  • Issue found on build: 11171357
  • Issue first found at: Tue, 05 Jan 2021 04:12:30 GMT
  • Scanner: Veracode Static Application Security Testing

Identifiers:

J2EE Bad Practices: Direct Management of Connections

Description:

This call to getConnection() fails to use the J2EE container's resource management facilities as required by the J2EE standard.

Request the connection from the container rather than attempting to access it directly.

Identifiers:

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

Description:

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 myInfo object, which contains tainted data. 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.

Identifiers:

J2EE Bad Practices: Direct Management of Connections

Description:

This call to getConnection() fails to use the J2EE container's resource management facilities as required by the J2EE standard.

Request the connection from the container rather than attempting to access it directly.

  • Veracode issue ID: 157
  • Severity: Low
  • Location: com/veracode/verademo/controller/ResetController.java:267
  • Issue found on build: 11171357
  • Issue first found at: Tue, 05 Jan 2021 04:12:30 GMT
  • Scanner: Veracode Static Application Security Testing

Identifiers:

J2EE Bad Practices: Direct Management of Connections

Description:

This call to getConnection() fails to use the J2EE container's resource management facilities as required by the J2EE standard.

Request the connection from the container rather than attempting to access it directly.

Identifiers:

Improper Output Neutralization for Logs

Description:

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.

Identifiers:

J2EE Bad Practices: Direct Management of Connections

Description:

This call to getConnection() fails to use the J2EE container's resource management facilities as required by the J2EE standard.

Request the connection from the container rather than attempting to access it directly.

Identifiers:

Improper Output Neutralization for Logs

Description:

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 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.

Identifiers:

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

Description:

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 query. 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.

Identifiers:

Generation of Error Message Containing Sensitive Information

Description:

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.NullPointerException.getMessage, java.lang.Throwable.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.

Identifiers:

Sensitive Cookie in HTTPS Session Without 'Secure' Attribute

Description:

This call to javax.servlet.http.HttpServletResponse.addCookie() adds a cookie to the HTTP response that does not have the Secure attribute set. Failing to set this attribute allows the browser to send the cookie unencrypted over an HTTP session.

Set the Secure attribute for all cookies used by HTTPS sessions.

Identifiers:

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

Description:

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.

Identifiers:

Improper Output Neutralization for Logs

Description:

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.

Identifiers:

External Control of File Name or Path

Description:

This call to java.io.File.!operator_javanewinit() 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 first argument to !operator_javanewinit() contains tainted data from the variable path. 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.

Identifiers:

Generation of Error Message Containing Sensitive Information

Description:

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.

  • Veracode issue ID: 183
  • Severity: Low
  • Location: /WEB-INF/views/login.jsp:60
  • Issue found on build: 11171357
  • Issue first found at: Tue, 05 Jan 2021 04:12:30 GMT
  • Scanner: Veracode Static Application Security Testing

Identifiers:

Use of Hard-coded Password

Description:

This variable assignment uses a hard-coded password that may compromise system security in a way that cannot be easily remedied. The use of a hard-coded password significantly increases the possibility that the account being protected will be compromised. Moreover, the password cannot be changed without patching the software. If a hard-coded password is compromised in a commercial product, all deployed instances may be vulnerable to attack. In some cases, this finding may indicate a reference to a password (e.g. the name of a key in a properties file) rather than an actual password. JDBC_PASSWORD initializer

Store passwords out-of-band from the application code. Follow best practices for protecting credentials stored in locations such as configuration or properties files. An HSM may be appropriate for particularly sensitive credentials.

  • Veracode issue ID: 194
  • Severity: Medium
  • Location: com/veracode/verademo/utils/Constants.java:1
  • Issue found on build: 11171357
  • Issue first found at: Tue, 05 Jan 2021 04:12:30 GMT
  • Scanner: Veracode Static Application Security Testing

Identifiers:

Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)

Description:

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 content. 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.

  • Veracode issue ID: 158
  • Severity: Medium
  • Location: /WEB-INF/views/blab.jsp:61
  • Issue found on build: 11171357
  • Issue first found at: Tue, 05 Jan 2021 04:12:30 GMT
  • Scanner: Veracode Static Application Security Testing

Identifiers:

J2EE Bad Practices: Direct Management of Connections

Description:

This call to getConnection() fails to use the J2EE container's resource management facilities as required by the J2EE standard.

Request the connection from the container rather than attempting to access it directly.

Identifiers:

Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)

Description:

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.

  • Veracode issue ID: 191
  • Severity: Medium
  • Location: /WEB-INF/views/tools.jsp:68
  • Issue found on build: 11171357
  • Issue first found at: Tue, 05 Jan 2021 04:12:30 GMT
  • Scanner: Veracode Static Application Security Testing

Identifiers:

Improper Output Neutralization for Logs

Description:

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.

  • Veracode issue ID: 164
  • Severity: Medium
  • Location: com/veracode/verademo/controller/UserController.java:249
  • Issue found on build: 11171357
  • Issue first found at: Tue, 05 Jan 2021 04:12:30 GMT
  • Scanner: Veracode Static Application Security Testing

Identifiers:

Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)

Description:

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.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.

  • Veracode issue ID: 171
  • Severity: Medium
  • Location: /WEB-INF/views/blabbers.jsp:105
  • Issue found on build: 11171357
  • Issue first found at: Tue, 05 Jan 2021 04:12:30 GMT
  • Scanner: Veracode Static Application Security Testing

Identifiers:

Improper Output Neutralization for Logs

Description:

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.

Identifiers:

Improper Output Neutralization for Logs

Description:

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.

Identifiers:

Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)

Description:

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.

  • Veracode issue ID: 199
  • Severity: Medium
  • Location: /WEB-INF/views/blab.jsp:109
  • Issue found on build: 11171357
  • Issue first found at: Tue, 05 Jan 2021 04:12:30 GMT
  • Scanner: Veracode Static Application Security Testing

Identifiers:

URL Redirection to Untrusted Site ('Open Redirect')

Description:

This call to showLogin() contains a URL redirection to untrusted site flaw. Writing untrusted input into a URL value could cause the web application to redirect the request to the specified URL, leading to phishing attempts to steal user credentials.

Always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. The tainted data originated from an earlier call to AnnotationVirtualController.vc_annotation_entry.

Identifiers:

Improper Output Neutralization for Logs

Description:

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.

Identifiers:

Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)

Description:

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 an earlier call to AnnotationVirtualController.vc_annotation_entry.

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.

Identifiers:

Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)

Description:

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.

  • Veracode issue ID: 200
  • Severity: Medium
  • Location: /WEB-INF/views/profile.jsp:102
  • Issue found on build: 11171357
  • Issue first found at: Tue, 05 Jan 2021 04:12:30 GMT
  • Scanner: Veracode Static Application Security Testing

Identifiers:

Deserialization of Untrusted Data

Description:

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 to ObjectInputStream; if the data is untrusted, consider switching to a safer serialization scheme such as JSON.

  • Veracode issue ID: 184
  • Severity: Medium
  • Location: com/veracode/verademo/utils/UserFactory.java:44
  • Issue found on build: 11171357
  • Issue first found at: Tue, 05 Jan 2021 04:12:30 GMT
  • Scanner: Veracode Static Application Security Testing

Identifiers:

Insufficient Entropy

Description:

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.

Identifiers:

Use of a Broken or Risky Cryptographic Algorithm

Description:

This function uses the MD5() function, which uses a hash algorithm that is considered weak. In recent years, researchers have demonstrated ways to breach many uses of previously-thought-safe hash functions such as MD5.

Consider using a stronger algorithm in order to prevent attackers from being able to manipulate hash results. If this algorithm is being used to hash passwords, then consider using a strong computationally-hard algorithm such as PBKDF2 or bcrypt instead of a plain hashing algorithm.

Identifiers:

Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)

Description:

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 events.get(). The tainted data originated from an earlier call to java.sql.Statement.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.

  • Veracode issue ID: 193
  • Severity: Medium
  • Location: /WEB-INF/views/profile.jsp:201
  • Issue found on build: 11171357
  • Issue first found at: Tue, 05 Jan 2021 04:12:30 GMT
  • Scanner: Veracode Static Application Security Testing

Identifiers:

Use of Hard-coded Password

Description:

This variable assignment uses a hard-coded password that may compromise system security in a way that cannot be easily remedied. The use of a hard-coded password significantly increases the possibility that the account being protected will be compromised. Moreover, the password cannot be changed without patching the software. If a hard-coded password is compromised in a commercial product, all deployed instances may be vulnerable to attack. In some cases, this finding may indicate a reference to a password (e.g. the name of a key in a properties file) rather than an actual password. hardcodepasswdset

Store passwords out-of-band from the application code. Follow best practices for protecting credentials stored in locations such as configuration or properties files. An HSM may be appropriate for particularly sensitive credentials.

  • Veracode issue ID: 185
  • Severity: Medium
  • Location: com/veracode/verademo/utils/Constants.java:13
  • Issue found on build: 11171357
  • Issue first found at: Tue, 05 Jan 2021 04:12:30 GMT
  • Scanner: Veracode Static Application Security Testing

Identifiers:

J2EE Bad Practices: Direct Management of Connections

Description:

This call to getConnection() fails to use the J2EE container's resource management facilities as required by the J2EE standard.

Request the connection from the container rather than attempting to access it directly.

Identifiers:

J2EE Bad Practices: Direct Management of Connections

Description:

This call to getConnection() fails to use the J2EE container's resource management facilities as required by the J2EE standard.

Request the connection from the container rather than attempting to access it directly.

Identifiers:

Improper Output Neutralization for Logs

Description:

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.

Identifiers:

J2EE Bad Practices: Direct Management of Connections

Description:

This call to getConnection() fails to use the J2EE container's resource management facilities as required by the J2EE standard.

Request the connection from the container rather than attempting to access it directly.

Identifiers:

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

Description:

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.

  • Veracode issue ID: 159
  • Severity: High
  • Location: com/veracode/verademo/controller/UserController.java:494
  • Issue found on build: 11171357
  • Issue first found at: Tue, 05 Jan 2021 04:12:30 GMT
  • Scanner: Veracode Static Application Security Testing

Identifiers:

Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)

Description:

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.

  • Veracode issue ID: 170
  • Severity: Medium
  • Location: /WEB-INF/views/feed.jsp:142
  • Issue found on build: 11171357
  • Issue first found at: Tue, 05 Jan 2021 04:12:30 GMT
  • Scanner: Veracode Static Application Security Testing

Identifiers:

Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)

Description:

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.

  • Veracode issue ID: 201
  • Severity: Medium
  • Location: /WEB-INF/views/profile.jsp:120
  • Issue found on build: 11171357
  • Issue first found at: Tue, 05 Jan 2021 04:12:30 GMT
  • Scanner: Veracode Static Application Security Testing

Identifiers:

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.