mokkang / github-verademo

Verademo Github Integration

ℹ️ Notice

This project is intentionally vulnerable! Itfftt contains known vulnerabilities and security errors in its code and is meant as an example project for software security scanning tools such as Veracode. Please do not report vulnerabilities in this project; the odds are they’re there on purpose :) .

About

Blab-a-Gag is a fairly simple forum type application which allows:

• Users can post a one-liner joke.
• Users can follow the jokes of other users or not (listen or ignore).
• Users can comment on other users messages (heckle).

URLs

• /feed shows the jokes/heckles that are relevant to the current user.
• /blabbers shows a list of all other users and allows the current user to listen or ignore.
• /profile allows the current user to modify their profile.
• /login allows you to log in to your account
• /register allows you to create a new user account
• /tools shows a tools page that shows a fortune or lets you ping a host.

Run

If you don't already have Docker this is a prerequisite.

docker run --rm -it -p 127.0.0.1:8080:8080 antfie/verademo

Navigate to: http://127.0.0.1:8080.

Exploitation Demos

See the docs folder.

Technologies Used

• Spring boot
• MariaDB

Development

To build the container run this:

docker pull mariadb:10.6.2
docker build --no-cache -t verademo .

To run the container for local development run this:

docker run --rm -it -p 127.0.0.1:8080:8080 --entrypoint bash -v "$(pwd)/app:/app" verademo

You will then need to manually run the two commands within /entrypoint.sh. The first starts the DB in the background whereas the second compiles and runs the application. Typically a container shouldn't have multiple services but this was done for convenience.

github-verademo's Issues

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') ('SQL Injection') [VID:137]

Filename: IgnoreCommand.java

Line: 40

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

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

Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') ('Command or Argument Injection') [VID:19]

Filename: ToolsController.java

Line: 53

CWE: 78 (Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') ('Command or Argument Injection'))

This call to java.lang.Runtime.exec() contains a command injection flaw. The argument to the function is constructed using untrusted input. If an attacker is allowed to specify all or part of the command, it may be possible to execute commands on the server with the privileges of the executing process. The level of exposure depends on the effectiveness of input validation routines, if any. The first argument to exec() contains tainted data from the variables (new String[...]). 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. Most APIs that execute system commands also have a "safe" version of the method that takes an array of strings as input rather than a single string, which protects against some forms of command injection. References: CWE OWASP

Improper Neutralization of Invalid Characters in Identifiers in Web Pages ('Cross-Site Scripting (XSS)') [VID:8]

Filename: server.js

Line: 133

CWE: 86 (Improper Neutralization of Invalid Characters in Identifiers in Web Pages ('Cross-Site Scripting (XSS)'))

When the 'autoescape' property is set to false in a call to swig.setDefaults(), a significant line of defense against cross-site scripting attacks is disabled. Where unfiltered output is required, use individual instances of the safe filter and regularly review their use to ensure mitigation against XSS attacks is in place. References: CWE

Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) ('Cross-Site Scripting (XSS)') [VID:13]

Filename: profile.html

Line: 66

CWE: 80 (Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) ('Cross-Site Scripting (XSS)'))

This call to __vc_output_text() 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. 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

Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) ('Cross-Site Scripting (XSS)') [VID:6]

Filename: allocations.html

Line: 35

CWE: 80 (Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) ('Cross-Site Scripting (XSS)'))

This call to __vc_output_text() 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. 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

Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) ('Cross-Site Scripting (XSS)') [VID:7]

Filename: allocations.html

Line: 42

CWE: 80 (Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) ('Cross-Site Scripting (XSS)'))

This call to __vc_output_text() 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. 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

Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) ('Cross-Site Scripting (XSS)') [VID:2]

Filename: allocations.html

Line: 39

CWE: 80 (Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) ('Cross-Site Scripting (XSS)'))

This call to __vc_output_text() 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. 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

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') ('SQL Injection') [VID:158]

Filename: ListenCommand.java

Line: 40

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

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

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') ('SQL Injection') [VID:190]

Filename: UserController.java

Line: 310

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

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

Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) ('Cross-Site Scripting (XSS)') [VID:27]

Filename: allocations.html

Line: 15

CWE: 80 (Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) ('Cross-Site Scripting (XSS)'))

This call to __vc_output_text() 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. 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

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') ('SQL Injection') [VID:60]

Filename: UserController.java

Line: 479

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

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

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') ('SQL Injection') [VID:68]

Filename: ListenCommand.java

Line: 47

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

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

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') ('SQL Injection') [VID:81]

Filename: BlabController.java

Line: 467

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

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

Use of Hard-coded Password ('Credentials Management') [VID:20]

Filename: db-reset.js

Line: 18

CWE: 259 (Use of Hard-coded Password ('Credentials Management'))

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. set 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. References: CWE

Authorization Bypass Through User-Controlled Key ('Authorization Issues') [VID:11]

Filename: contributions-dao.js

Line: 28

CWE: 639 (Authorization Bypass Through User-Controlled Key ('Authorization Issues'))

The property named update contains untrusted data, and (due to its name) may contain internal authorization data. Ensure that nothing in this application relies on this value to be a trusted indicator of security privilege or identity. References: CWE

Improper Output Neutralization for Logs ('CRLF Injection') [VID:36]

Filename: UserController.java

Line: 228

CWE: 117 (Improper Output Neutralization for Logs ('CRLF Injection'))

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

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') ('SQL Injection') [VID:122]

Filename: RemoveAccountCommand.java

Line: 53

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

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

Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) ('Cross-Site Scripting (XSS)') [VID:9]

Filename: benefits.html

Line: 51

CWE: 80 (Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) ('Cross-Site Scripting (XSS)'))

This call to __vc_output_text() 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. 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

Use of Hard-coded Password ('Credentials Management') [VID:22]

Filename: db-reset.js

Line: 27

CWE: 259 (Use of Hard-coded Password ('Credentials Management'))

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. set 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. References: CWE

Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) ('Cross-Site Scripting (XSS)') [VID:14]

Filename: profile.html

Line: 57

CWE: 80 (Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) ('Cross-Site Scripting (XSS)'))

This call to __vc_output_text() 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. 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

Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) ('Cross-Site Scripting (XSS)') [VID:4]

Filename: profile.html

Line: 53

CWE: 80 (Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) ('Cross-Site Scripting (XSS)'))

This call to __vc_output_text() 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. 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

Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection') ('Code Injection') [VID:29]

Filename: contributions.js

Line: 34

CWE: 95 (Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection') ('Code Injection'))

This call to eval() contains untrusted input or potentially untrusted data. If this input could be modified by an attacker, arbitrary JS code could be executed. Validate all untrusted and untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. In general, avoid executing code derived from untrusted input. References: CWE

Authorization Bypass Through User-Controlled Key ('Authorization Issues') [VID:5]

Filename: contributions-dao.js

Line: 57

CWE: 639 (Authorization Bypass Through User-Controlled Key ('Authorization Issues'))

The property named findOne contains untrusted data, and (due to its name) may contain internal authorization data. Ensure that nothing in this application relies on this value to be a trusted indicator of security privilege or identity. References: CWE

Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) ('Cross-Site Scripting (XSS)') [VID:17]

Filename: benefits.html

Line: 52

CWE: 80 (Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) ('Cross-Site Scripting (XSS)'))

This call to __vc_output_text() 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. 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

Use of Hard-coded Credentials ('Credentials Management') [VID:23]

Filename: db-reset.js

Line: 23

CWE: 798 (Use of Hard-coded Credentials ('Credentials Management'))

The application contains hard-coded information that may contain credentials to an external service. The use of hard-coded credentials significantly increases the possibility that the account being protected will be compromised. set Store credentials out-of-band from the application code. Follow best practices for protecting credentials stored in locations such as configuration or properties files. References: CWE

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') ('SQL Injection') [VID:31]

Filename: UserController.java

Line: 490

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

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. References: CWE OWASP

Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection') ('Code Injection') [VID:26]

Filename: contributions.js

Line: 33

CWE: 95 (Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection') ('Code Injection'))

This call to eval() contains untrusted input or potentially untrusted data. If this input could be modified by an attacker, arbitrary JS code could be executed. Validate all untrusted and untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. In general, avoid executing code derived from untrusted input. References: CWE

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') ('SQL Injection') [VID:39]

Filename: IgnoreCommand.java

Line: 47

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

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

Improper Output Neutralization for Logs ('CRLF Injection') [VID:33]

Filename: session.js

Line: 62

CWE: 117 (Improper Output Neutralization for Logs ('CRLF Injection'))

This call to console.log() 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. 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

Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) ('Cross-Site Scripting (XSS)') [VID:10]

Filename: benefits.html

Line: 57

CWE: 80 (Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) ('Cross-Site Scripting (XSS)'))

This call to __vc_output_text() 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. 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

Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection') ('Code Injection') [VID:28]

Filename: contributions.js

Line: 32

CWE: 95 (Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection') ('Code Injection'))

This call to eval() contains untrusted input or potentially untrusted data. If this input could be modified by an attacker, arbitrary JS code could be executed. Validate all untrusted and untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible. In general, avoid executing code derived from untrusted input. References: CWE

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') ('SQL Injection') [VID:160]

Filename: RemoveAccountCommand.java

Line: 42

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

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

Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) ('Cross-Site Scripting (XSS)') [VID:3]

Filename: benefits.html

Line: 56

CWE: 80 (Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) ('Cross-Site Scripting (XSS)'))

This call to __vc_output_raw() 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. 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

Use of Hard-coded Credentials ('Credentials Management') [VID:25]

Filename: db-reset.js

Line: 15

CWE: 798 (Use of Hard-coded Credentials ('Credentials Management'))

The application contains hard-coded information that may contain credentials to an external service. The use of hard-coded credentials significantly increases the possibility that the account being protected will be compromised. set Store credentials out-of-band from the application code. Follow best practices for protecting credentials stored in locations such as configuration or properties files. References: CWE

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') ('SQL Injection') [VID:136]

Filename: UserController.java

Line: 249

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

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

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') ('SQL Injection') [VID:62]

Filename: UserController.java

Line: 165

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

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

Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') ('Command or Argument Injection') [VID:34]

Filename: ToolsController.java

Line: 83

CWE: 78 (Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') ('Command or Argument Injection'))

This call to java.lang.Runtime.exec() contains a command injection flaw. The argument to the function is constructed using untrusted input. If an attacker is allowed to specify all or part of the command, it may be possible to execute commands on the server with the privileges of the executing process. The level of exposure depends on the effectiveness of input validation routines, if any. The first argument to exec() contains tainted data from the variables (new String[...]). 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. Most APIs that execute system commands also have a "safe" version of the method that takes an array of strings as input rather than a single string, which protects against some forms of command injection. References: CWE OWASP

Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) ('Cross-Site Scripting (XSS)') [VID:1]

Filename: benefits.html

Line: 50

CWE: 80 (Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) ('Cross-Site Scripting (XSS)'))

This call to __vc_output_raw() 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. 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

Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) ('Cross-Site Scripting (XSS)') [VID:16]

Filename: login.html

Line: 110

CWE: 80 (Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) ('Cross-Site Scripting (XSS)'))

This call to __vc_output_text() 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. 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

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') ('SQL Injection') [VID:89]

Filename: RemoveAccountCommand.java

Line: 49

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

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

Use of Hard-coded Password ('Credentials Management') [VID:12]

Filename: db-reset.js

Line: 35

CWE: 259 (Use of Hard-coded Password ('Credentials Management'))

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. set 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. References: CWE

Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) ('Cross-Site Scripting (XSS)') [VID:18]

Filename: allocations.html

Line: 45

CWE: 80 (Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) ('Cross-Site Scripting (XSS)'))

This call to __vc_output_text() 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. 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

URL Redirection to Untrusted Site ('Open Redirect') ('Insufficient Input Validation') [VID:37]

Filename: research.js

Line: 16

CWE: 601 (URL Redirection to Untrusted Site ('Open Redirect') ('Insufficient Input Validation'))

This call to http.get() 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. References: CWE OWASP

Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) ('Cross-Site Scripting (XSS)') [VID:15]

Filename: profile.html

Line: 78

CWE: 80 (Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) ('Cross-Site Scripting (XSS)'))

This call to __vc_output_text() 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. 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

Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) ('Cross-Site Scripting (XSS)') [VID:38]

Filename: profile.html

Line: 41

CWE: 80 (Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) ('Cross-Site Scripting (XSS)'))

This call to __vc_output_text() 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. 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

Authorization Bypass Through User-Controlled Key ('Authorization Issues') [VID:30]

Filename: allocations-dao.js

Line: 29

CWE: 639 (Authorization Bypass Through User-Controlled Key ('Authorization Issues'))

The property named update contains untrusted data, and (due to its name) may contain internal authorization data. Ensure that nothing in this application relies on this value to be a trusted indicator of security privilege or identity. References: CWE

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') ('SQL Injection') [VID:115]

Filename: UserController.java

Line: 374

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

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. References: CWE OWASP

Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) ('Cross-Site Scripting (XSS)') [VID:24]

Filename: allocations.html

Line: 35

CWE: 80 (Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) ('Cross-Site Scripting (XSS)'))

This call to __vc_output_text() 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. 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

Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) ('Cross-Site Scripting (XSS)') [VID:21]

Filename: profile.html

Line: 45

CWE: 80 (Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) ('Cross-Site Scripting (XSS)'))

This call to __vc_output_text() 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. 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

URL Redirection to Untrusted Site ('Open Redirect') ('Insufficient Input Validation') [VID:35]

Filename: index.js

Line: 74

CWE: 601 (URL Redirection to Untrusted Site ('Open Redirect') ('Insufficient Input Validation'))

This call to express.Response.redirect() 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. References: CWE OWASP