Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request from patched fixes 20 issues.
Fix: Prevent SQL injection in storeFeedback method
Replaced the use of a Statement with a PreparedStatement to prevent SQL injection vulnerabilities. The original code constructed SQL queries by concatenating user-provided input directly into the query string. This approach is vulnerable to SQL injection attacks. The updated code utilizes a PreparedStatement, which allows placeholders for user input. These placeholders are then populated with the actual values in a safe manner, effectively preventing SQL injection attempts.Fix SQL injection vulnerability in changePassword method
Replaced the vulnerable Statement with PreparedStatement to prevent SQL injection. The query now uses parameter binding to safely incorporate user-provided values.Fix: Prevent SQL injection in addUser method
The addUser method was using a formatted string to build the SQL query, which is vulnerable to SQL injection. This commit fixes the vulnerability by using a PreparedStatement instead of a Statement. The PreparedStatement allows us to safely insert parameters into the query without risking SQL injection.Fix: Prevent SQL injection in addSpecialUser method
The original code was using string concatenation to build the SQL query, which is vulnerable to SQL injection. The fix uses a prepared statement with parameterized values to prevent SQL injection vulnerabilities.Fix SQL injection vulnerability in addAccount method
Replaced the vulnerable Statement with PreparedStatement to prevent SQL injection. The values for username and acctType are now passed as parameters to the prepared statement.Fix: SQL injection vulnerability
The original code was vulnerable to SQL injection attacks because it concatenated user input directly into a SQL query string. This commit fixes the vulnerability by using a prepared statement with a parameterized query. This ensures that user input is properly escaped and prevents attackers from injecting malicious SQL code.Fix: Prevent SQL injection vulnerability
The original code was vulnerable to SQL injection as it was concatenating user-provided input directly into the SQL query. This commit replaces the vulnerable code with a prepared statement, which effectively prevents SQL injection attacks.Fix: SQL Injection Vulnerability in transferFunds method
The originaltransferFunds
method was using string concatenation to build SQL queries, making it vulnerable to SQL injection attacks. This commit refactors the method to use prepared statements with parameterized queries, effectively mitigating the vulnerability.Fix SQL injection vulnerability
Replaced the vulnerable Statement with PreparedStatement to prevent SQL injection.Fix: Prevent SQL injection vulnerability
Replaced the vulnerable statement.executeQuery() call with a prepared statement (java.sql.PreparedStatement) to prevent SQL injection.Fix: Set HttpOnly and Secure flags on session cookie
Set the HttpOnly and Secure flags on the session cookie to prevent client-side script access and ensure the cookie is only sent over HTTPS. This mitigates the risk of XSS attacks.Fix: Prevent potential ReDoS vulnerability in item replacement
Replaced the dynamically generated RegExp with a hardcoded regular expression to prevent potential ReDoS vulnerabilities. The original code constructed a RegExp object using a string template literal, which could potentially allow an attacker to provide malicious input that leads to catastrophic backtracking and denial of service. The fix uses a static regex that is not influenced by user input, eliminating this vulnerability.Update link to use HTTPS
Changed the URL from HTTP to HTTPS.Fix: Mitigate XSS vulnerability by encoding user-provided content before writing to the response
Added encoding of user-provided content usingescapeHtml4
fromorg.apache.commons.text.StringEscapeUtils
to prevent potential XSS vulnerabilities before writing the content to the response.Sanitize user input before setting session attribute
Added sanitization of the 'step' parameter using StringEscapeUtils.escapeHtml4() from Apache Commons Lang library to prevent potential XSS vulnerabilities before setting it as a session attribute. This ensures that any HTML special characters in the input are escaped, preventing their interpretation as markup by the browser.Update link to use HTTPS
Changed the URL for the CERT website from HTTP to HTTPS.Fix: Use SecureRandom for generating random strings
Replaced the use ofjava.util.Random
withjava.security.SecureRandom
for generating random strings in themakeRandomString
method. This change enhances the security of the generated strings, making them suitable for sensitive operations.Use HTTPS for Adobe Reader download link
Changed the URL for the Adobe Reader download link from HTTP to HTTPS.Fix: Sanitize user input in AdminServlet
Added sanitization for user inputs in the AdminServlet to prevent potential injection vulnerabilities. It now leverages the ESAPI library'sESAPI.encoder().canonicalize()
method to sanitize all user-provided parameters before using them.Fix: Set cookie flags for security
Set HttpOnly and Secure flags on the account cookie to enhance security.