com.ibm.security.appscan.altoromutual.servlet.SubscribeServlet:50 new StringBuilder().append(email)
com.ibm.security.appscan.altoromutual.servlet.SubscribeServlet:50 new StringBuilder().append(email).append(" has been accepted.")
com.ibm.security.appscan.altoromutual.servlet.SubscribeServlet:50 new StringBuilder().append(email).append(" has been accepted.").toString()
com.ibm.security.appscan.altoromutual.servlet.SubscribeServlet:50 request.setAttribute("message_subscribe",new StringBuilder().append(email).append(" has been accepted.").toString())
Not all "business" method implementations of public API in Apache Commons Codec 1.x are thread safe, which might disclose the wrong data or allow an attacker to change non-private fields.Updated 2018-10-07 - an additional review by WhiteSource research team could not indicate on a clear security vulnerability.
Base64 encode() method is no longer thread-safe in Apache Commons Codec before version 1.7, which might disclose the wrong data or allow an attacker to change non-private fields.
XML external entity (XXE) vulnerability in the SqlXmlUtil code in Apache Derby before 10.12.1.1, when a Java Security Manager is not in place, allows context-dependent attackers to read arbitrary files or cause a denial of service (resource consumption) via vectors involving XmlVTI and the XML datatype.
In Apache Derby 10.3.1.4 to 10.14.1.0, a specially-crafted network packet can be used to request the Derby Network Server to boot a database whose location and contents are under the user's control. If the Derby Network Server is not running with a Java Security Manager policy file, the attack is successful. If the server is using a policy file, the policy file must permit the database location to be read for the attack to work. The default Derby Network Server policy file distributed with the affected releases includes a permissive policy as the default Network Server policy, which allows the attack to work.
com.ibm.security.appscan.altoromutual.util.DBUtil:306 new StringBuilder().append(startDate)
com.ibm.security.appscan.altoromutual.util.DBUtil:306 new StringBuilder().append(startDate).append(" 00:00:00' AND '")
com.ibm.security.appscan.altoromutual.util.DBUtil:306 new StringBuilder().append(startDate).append(" 00:00:00' AND '").append(endDate)
com.ibm.security.appscan.altoromutual.util.DBUtil:306 new StringBuilder().append(startDate).append(" 00:00:00' AND '").append(endDate).append(" 23:59:59'")
com.ibm.security.appscan.altoromutual.util.DBUtil:306 dateString =new StringBuilder().append(startDate).append(" 00:00:00' AND '").append(endDate).append(" 23:59:59'").toString()
com.ibm.security.appscan.altoromutual.util.DBUtil:313 new StringBuilder().append(dateString)
com.ibm.security.appscan.altoromutual.util.DBUtil:313 new StringBuilder().append(dateString).append(") ")
com.ibm.security.appscan.altoromutual.util.DBUtil:313 new StringBuilder().append(dateString).append(") ").toString()
com.ibm.security.appscan.altoromutual.util.DBUtil:396 new StringBuilder().append(username).append("','").append(password).append("', '").append(firstname).append("', '").append(lastname)
com.ibm.security.appscan.altoromutual.util.DBUtil:396 new StringBuilder().append(username).append("','").append(password).append("', '").append(firstname).append("', '").append(lastname).append("','user')")
com.ibm.security.appscan.altoromutual.util.DBUtil:396 new StringBuilder().append(username).append("','").append(password).append("', '").append(firstname).append("', '").append(lastname).append("','user')").toString()
com.ibm.security.appscan.altoromutual.util.DBUtil:396 new StringBuilder().append(username).append("','").append(password)
com.ibm.security.appscan.altoromutual.util.DBUtil:396 new StringBuilder().append(username).append("','").append(password).append("', '")
com.ibm.security.appscan.altoromutual.util.DBUtil:396 new StringBuilder().append(username).append("','").append(password).append("', '").append(firstname)
com.ibm.security.appscan.altoromutual.util.DBUtil:396 new StringBuilder().append(username).append("','").append(password).append("', '").append(firstname).append("', '")
com.ibm.security.appscan.altoromutual.util.DBUtil:396 new StringBuilder().append(username).append("','").append(password).append("', '").append(firstname).append("', '").append(lastname)
com.ibm.security.appscan.altoromutual.util.DBUtil:396 new StringBuilder().append(username).append("','").append(password).append("', '").append(firstname).append("', '").append(lastname).append("','user')")
com.ibm.security.appscan.altoromutual.util.DBUtil:396 new StringBuilder().append(username).append("','").append(password).append("', '").append(firstname).append("', '").append(lastname).append("','user')").toString()
com.ibm.security.appscan.altoromutual.util.DBUtil:396 new StringBuilder().append(username).append("','").append(password).append("', '").append(firstname)
com.ibm.security.appscan.altoromutual.util.DBUtil:396 new StringBuilder().append(username).append("','").append(password).append("', '").append(firstname).append("', '")
com.ibm.security.appscan.altoromutual.util.DBUtil:396 new StringBuilder().append(username).append("','").append(password).append("', '").append(firstname).append("', '").append(lastname)
com.ibm.security.appscan.altoromutual.util.DBUtil:396 new StringBuilder().append(username).append("','").append(password).append("', '").append(firstname).append("', '").append(lastname).append("','user')")
com.ibm.security.appscan.altoromutual.util.DBUtil:396 new StringBuilder().append(username).append("','").append(password).append("', '").append(firstname).append("', '").append(lastname).append("','user')").toString()
com.ibm.security.appscan.altoromutual.util.DBUtil:396 new StringBuilder().append(username)
com.ibm.security.appscan.altoromutual.util.DBUtil:396 new StringBuilder().append(username).append("','")
com.ibm.security.appscan.altoromutual.util.DBUtil:396 new StringBuilder().append(username).append("','").append(password)
com.ibm.security.appscan.altoromutual.util.DBUtil:396 new StringBuilder().append(username).append("','").append(password).append("', '")
com.ibm.security.appscan.altoromutual.util.DBUtil:396 new StringBuilder().append(username).append("','").append(password).append("', '").append(firstname)
com.ibm.security.appscan.altoromutual.util.DBUtil:396 new StringBuilder().append(username).append("','").append(password).append("', '").append(firstname).append("', '")
com.ibm.security.appscan.altoromutual.util.DBUtil:396 new StringBuilder().append(username).append("','").append(password).append("', '").append(firstname).append("', '").append(lastname)
com.ibm.security.appscan.altoromutual.util.DBUtil:396 new StringBuilder().append(username).append("','").append(password).append("', '").append(firstname).append("', '").append(lastname).append("','user')")
com.ibm.security.appscan.altoromutual.util.DBUtil:396 new StringBuilder().append(username).append("','").append(password).append("', '").append(firstname).append("', '").append(lastname).append("','user')").toString()
com.ibm.security.appscan.altoromutual.util.DBUtil:408 new StringBuilder().append(password)
com.ibm.security.appscan.altoromutual.util.DBUtil:408 new StringBuilder().append(password).append("' WHERE USER_ID = '")
com.ibm.security.appscan.altoromutual.util.DBUtil:408 new StringBuilder().append(password).append("' WHERE USER_ID = '").append(username)
com.ibm.security.appscan.altoromutual.util.DBUtil:408 new StringBuilder().append(password).append("' WHERE USER_ID = '").append(username).append("'")
com.ibm.security.appscan.altoromutual.util.DBUtil:408 new StringBuilder().append(password).append("' WHERE USER_ID = '").append(username).append("'").toString()
com.ibm.security.appscan.altoromutual.util.DBUtil:408 statement.execute(new StringBuilder().append(password).append("' WHERE USER_ID = '").append(username).append("'").toString())
com.ibm.security.appscan.altoromutual.util.DBUtil:408 new StringBuilder().append(password).append("' WHERE USER_ID = '").append(username)
com.ibm.security.appscan.altoromutual.util.DBUtil:408 new StringBuilder().append(password).append("' WHERE USER_ID = '").append(username).append("'")
com.ibm.security.appscan.altoromutual.util.DBUtil:408 new StringBuilder().append(password).append("' WHERE USER_ID = '").append(username).append("'").toString()
com.ibm.security.appscan.altoromutual.util.DBUtil:408 statement.execute(new StringBuilder().append(password).append("' WHERE USER_ID = '").append(username).append("'").toString())
H
Common Fix Point: SQL Injection: com.ibm.security.appscan.altoromutual.util.DBUtil.isValidUser(j...
com.ibm.security.appscan.altoromutual.util.DBUtil:133 new StringBuilder().append(user).append("' AND PASSWORD='").append(password)
com.ibm.security.appscan.altoromutual.util.DBUtil:133 new StringBuilder().append(user).append("' AND PASSWORD='").append(password).append("'")
com.ibm.security.appscan.altoromutual.util.DBUtil:133 new StringBuilder().append(user).append("' AND PASSWORD='").append(password).append("'").toString()
com.ibm.security.appscan.altoromutual.util.DBUtil:133 resultSet = statement.executeQuery(new StringBuilder().append(user).append("' AND PASSWORD='").append(password).append("'").toString())
com.ibm.security.appscan.altoromutual.util.DBUtil:133 new StringBuilder().append(user)
com.ibm.security.appscan.altoromutual.util.DBUtil:133 new StringBuilder().append(user).append("' AND PASSWORD='")
com.ibm.security.appscan.altoromutual.util.DBUtil:133 new StringBuilder().append(user).append("' AND PASSWORD='").append(password)
com.ibm.security.appscan.altoromutual.util.DBUtil:133 new StringBuilder().append(user).append("' AND PASSWORD='").append(password).append("'")
com.ibm.security.appscan.altoromutual.util.DBUtil:133 new StringBuilder().append(user).append("' AND PASSWORD='").append(password).append("'").toString()
com.ibm.security.appscan.altoromutual.util.DBUtil:133 resultSet = statement.executeQuery(new StringBuilder().append(user).append("' AND PASSWORD='").append(password).append("'").toString())
H
Common Fix Point:Cross-Site Scripting: java.lang.StringBuilder.toString():java.lang.String
Cross-site scripting (XSS) vulnerabilities arise when an attacker sends malicious code to the victim's browser, mostly using JavaScript. A vulnerable web application might embed untrusted data in the output, without filtering or encoding it. In this way, an attacker can inject a malicious script to the application, and the script will be returned in the response. This will then run on the victim's browser. In particular, sanitization of hazardous characters was not performed correctly on user input or untrusted data.
Risk
XSS attacks can expose the user's session cookie, allowing the attacker to hijack the user's session and gain access to the user's account, which could lead to impersonation of users.
An attacker could modify and view the users' records and perform transactions as those users. The attacker may be able to perform privileged operations on behalf of the user, or gain access to any sensitive data belonging to the user. This would be especially dangerous if the user has administrator permissions.
The attacker could even run a malicious script on the victim's browser which would redirect the user to other pages or sites, modify content presentation, or even make it possible to run malicious software or a crypto miner.
Exploit example
The following example shows a script that returns a parameter value in the response.
The parameter value is sent to the script using a GET request, and then returned in the response embedded in the HTML.
GET /index.aspx?name=JSmith HTTP/1.1
HTTP/1.1 200 OK Server: SomeServer Date: Sun, 01 Jan 2002 00:31:19 GMT Content-Type: text/html Accept-Ranges: bytes Content-Length: 27
<HTML> Hello JSmith </HTML>
An attacker might leverage the attack like this. In this case, the JavaScript code will be executed by the browser.
GET /index.aspx?name=>"'><script>alert('XSS')</script> HTTP/1.1
HTTP/1.1 200 OK Server: SomeServer Date: Sun, 01 Jan 2002 00:31:19 GMT Content-Type: text/html Accept-Ranges: bytes Content-Length: 83
Fully encode all dynamic data from an untrusted source that is inserted into the webpage, to ensure it is treated as literal text and not as a script that could be executed or markup that could be rendered.
Consider the context in which your data will be used, and contextually encode the data as close as possible to the actual output: e.g. HTML encoding for HTML content; HTML Attribute encoding for data output to attribute values; JavaScript encoding for dynamically generated JavaScript. For example, when HTML encoding non-alphanumeric characters into HTML entities, `<` and `>` would become `<` and `>`.
As an extra defensive measure, validate all external input on the server, regardless of source. Carefully check each input parameter against a rigorous positive specification (allowlist) defining data type; size; range; format; and acceptable values. Regular expressions or framework controls may be useful in some cases, though this is not a replacement for output encoding.
Output encoding and data validation must be done on all untrusted data, wherever it comes from: e.g. form fields, URL parameters, web service arguments, cookies, any data from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files and filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.
For every web page that is returned by the server, explicitly set the `Content-Type` HTTP response header. This header value should define a specific character encoding (charset), such as `ISO-8859-1` or `UTF-8`. When an encoding is not specified, the web browser may choose a different encoding by guessing which encoding is actually being used by the web page, which would allow a potential attacker to bypass XSS protections.
Additionally, set the `httpOnly` flag on the session cookie, to prevent any XSS exploits from stealing a user's cookie.
Prefer using a framework or standard library that prevents this vulnerability by automatically encoding all dynamic output based on context, or at least that provides constructs that make it easier to avoid.
For every web page that is returned by the server, explicitly set the `Content-Security-Policy` HTTP response header, In order to make it significantly more difficult for the attacker to actually exploit the XSS attack.
The application uses a method that sends data to an external system and that external system is capable of executing code embedded in the data it receives. If the sent data contains malicious scripts, this can lead to malicious scripting attacks and unexpected behavior on the external system. Therefore, it is important to encode the output data appropriately to prevent it from subsequently being interpreted as script code. Although not a common practice, sometimes it may be necessary to encode received data to prevent malicious scripts from getting into the application in the first place. Typical vulnerable external systems include scripting-enabled clients such as web browsers and database servers. Thus, this finding is primarily applicable to web applications. If content created from unvalidated user input generates dynamic web pages or is stored in data sources, an attacker can introduce malicious scripts, such as JavaScript, into data that other users may later view in a web browser. When viewed, these scripts will be interpreted by the browser and run with the viewing user's security context for communicating with the originating web site. Thus, the attacker's code runs with the same privileges granted to legitimate code sent by the web site. For example, in a message board application, an attacker can put the following malicious script onto the message board:
This is my message <script>alert(document.cookie)</script>
When viewed by another user, the victim's browser interprets the code between the <script> tags, resulting in a cross-site scripting attack. In this case, the victim's session cookie appears to the victim in a popup window. In a real attack scenario, a malicious script can send the cookie to the attacker's web site, and then use it for a session hijacking attack. Non web-based applications can also stage malicious scripting attacks. For example, any application that generates log messages could attack system or security administrators through web-based log viewers. Also, an application that generates email alert messages can attack web-based or other JavaScript-enabled mail clients.
Fix recommendation
To defend against this kind of attack, the application should encode certain special characters that may be meaningful to other systems, especially for data that will be sent to other systems. For example, it may be useful to apply HTML entity encoding to all data that will be sent to an HTML browser, which may include web pages and log files. HTML entity encoding translates all non-alphanumeric characters into a special character sequence that HTML enabled viewers will not interpret. For example, < and > become < and > respectively. Likewise, if the contents of a free text field are to be stored in a database, one alternative to filtering out special SQL characters (like ' or -) is simply base64 encoding the text before sending it to the database.
Encoded with HTML entity encoding, the above message will become:
This is my message <script>alert(document.cookie)</script>bad
When viewed by a browser, the whole message will be interpreted as pure text.
The web application redirects users to an external site based on untrusted data. In particular, the submitted request was found to include a URL as a parameter. The web application uses this value to redirect the user's browser to the specified URL. An attacker can modify this URL value to an arbitrary address. The attacker would then cause the victim to submit the altered request, thus being redirected to a site of the attacker's choosing.
Risk
This vulnerability can allow an attacker to take advantage of the trust the user holds for the application, causing them to trust an arbitrary site under control of the attacker as well. This would often be leveraged through the use of phishing techniques.
Phishing is a social engineering technique where an attacker masquerades as a legitimate entity with which the victim might do business in order to prompt the user to reveal some confidential information (frequently authentication credentials) that can later be used by an attacker. Phishing is essentially a form of information gathering or "fishing" for information.
An attacker may successfully launch a phishing scam and steal user credentials or other sensitive information such as credit card number, social security number, and more.
It can also be possible to redirect the user to install malware that could infect the user's computer.
Exploit example
The following example shows a URL redirection to untrusted site.
The redir parameter is used to redirect the user to a different page automatically.
GET /MyPage.php?redir=/AnotherPage.php HTTP/1.1
An attacker might trick the GET parameter used to redirect the user to an external site
GET /MyPage.php?redir=https://www.malware.com HTTP/1.1
Fix recommendation
Avoid redirecting requests based on untrusted data if possible.
If relying on user input cannot be avoided, the URL should first be validated before redirection. Data that a user can modify must be treated as untrusted data.
A unique token, linked to the current user session, should be sent along with the redirect field value. This unique token should then be verified by the server before the actual redirect takes place. This ensures that attackers would have a harder time using the redirect field to propagate their malicious activities, since they cannot guess the user's session token.
Sanitize input by comparing to a predefined list of trusted URLs, based on an allow-list.
Force all redirects to first go through a page notifying users that they are about to leave your site, with the destination clearly displayed, and have them click a link to confirm.
A vulnerable version of third party software component is installed in the tested application.
Risk
A vulnerable third party software component may introduce all manner of vulnerabilities into the application
Fix recommendation
Upgrade to the latest version of the third party software component. We highly recommend contacting the vendor of this product to see if a patch or fix has recently been made available.
Cross-site scripting (XSS) vulnerabilities arise when an attacker sends malicious code to the victim's browser, mostly using JavaScript. A vulnerable web application might embed untrusted data in the output, without filtering or encoding it. In this way, an attacker can inject a malicious script to the application, and the script will be returned in the response. This will then run on the victim's browser. In particular, sanitization of hazardous characters was not performed correctly on user input or untrusted data. In reflected attacks, an attacker tricks an end user into sending request containing malicious code to a vulnerable Web server, which then reflects the attack back to the end user's browser. The server receives the malicious data directly from the HTTP request and reflects it back in the HTTP response. The most common method of sending malicious content is adding it as a parameter in a URL that is posted publicly or e-mailed directly to the victim. URLs that contain the malicious script constitute the core of many phishing schemes, whereby the convinced victim visits a URL that refers to a vulnerable site. The site then reflects the malicious content back to the victim, and then the content is executed by the victim's browser.
Risk
XSS attacks can expose the user's session cookie, allowing the attacker to hijack the user's session and gain access to the user's account, which could lead to impersonation of users.
An attacker could modify and view the users' records and perform transactions as those users. The attacker may be able to perform privileged operations on behalf of the user, or gain access to any sensitive data belonging to the user. This would be especially dangerous if the user has administrator permissions.
The attacker could even run a malicious script on the victim's browser which would redirect the user to other pages or sites, modify content presentation, or even make it possible to run malicious software or a crypto miner.
Exploit example
The following example shows a script that returns a parameter value in the response.
The parameter value is sent to the script using a GET request, and then returned in the response embedded in the HTML.
GET /index.aspx?name=JSmith HTTP/1.1
HTTP/1.1 200 OK Server: SomeServer Date: Sun, 01 Jan 2002 00:31:19 GMT Content-Type: text/html Accept-Ranges: bytes Content-Length: 27
<HTML> Hello JSmith </HTML>
An attacker might leverage the attack like this. In this case, the JavaScript code will be executed by the browser.
GET /index.aspx?name=>"'><script>alert('XSS')</script> HTTP/1.1
HTTP/1.1 200 OK Server: SomeServer Date: Sun, 01 Jan 2002 00:31:19 GMT Content-Type: text/html Accept-Ranges: bytes Content-Length: 83
Fully encode all dynamic data from an untrusted source that is inserted into the webpage, to ensure it is treated as literal text and not as a script that could be executed or markup that could be rendered.
Consider the context in which your data will be used, and contextually encode the data as close as possible to the actual output: e.g. HTML encoding for HTML content; HTML Attribute encoding for data output to attribute values; JavaScript encoding for dynamically generated JavaScript. For example, when HTML encoding non-alphanumeric characters into HTML entities, `<` and `>` would become `<` and `>`.
As an extra defensive measure, validate all external input on the server, regardless of source. Carefully check each input parameter against a rigorous positive specification (allowlist) defining data type; size; range; format; and acceptable values. Regular expressions or framework controls may be useful in some cases, though this is not a replacement for output encoding.
Output encoding and data validation must be done on all untrusted data, wherever it comes from: e.g. form fields, URL parameters, web service arguments, cookies, any data from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files and filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.
For every web page that is returned by the server, explicitly set the `Content-Type` HTTP response header. This header value should define a specific character encoding (charset), such as `ISO-8859-1` or `UTF-8`. When an encoding is not specified, the web browser may choose a different encoding by guessing which encoding is actually being used by the web page, which would allow a potential attacker to bypass XSS protections.
Additionally, set the `httpOnly` flag on the session cookie, to prevent any XSS exploits from stealing a user's cookie.
Prefer using a framework or standard library that prevents this vulnerability by automatically encoding all dynamic output based on context, or at least that provides constructs that make it easier to avoid.
For every web page that is returned by the server, explicitly set the `Content-Security-Policy` HTTP response header, In order to make it significantly more difficult for the attacker to actually exploit the XSS attack.
Sanitization of hazardous characters was not performed correctly on user input. Dynamically generating queries that include unvalidated user input can lead to SQL injection attacks. An attacker can insert SQL commands or modifiers in the user input that can cause the query to behave in an unsafe manner. Without sufficient validation and encapsulation of user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data. This can be used to alter query logic to bypass security checks, or to insert additional statements that modify the back-end database, possibly including execution of system commands. SQL payloads can enter the system through any untrusted data, including user input, data previously stored in the database, files, 3rd party APIs, and more.
Risk
Potential consequences include the loss of:
Confidentiality - Since SQL databases generally hold sensitive data, loss of confidentiality is a frequent problem with SQL injection vulnerabilities.
Authentication - If poor SQL commands are used to check user names and passwords, it may be possible to connect to a system as another user with no previous knowledge of the password.
Authorization - If authorization information is held in a SQL database, it may be possible to change this information through the successful exploitation of a SQL injection vulnerability.
Integrity - Just as it may be possible to read sensitive information, it is also possible to make changes or even delete this information with a SQL injection attack.
Fix recommendation
Use stored procedures with parameters to prevent injection of SQL commands in data, or at least parameterized database calls that do not allow the injection of code. Do not include any dynamic SQL execution in the stored procedures.
An even better solution is to use an ORM (object-relational mapping) framework such as Hibernate or EntityFramework, if you have one available on your platform.
Ensure that all user input is validated and filtered on the server side, not just to disallow bad characters such as a single quote ( ' ) and double quotes ("), but rather to only allow safe characters. Narrowly define the set of safe characters based on the expected value of the parameter in the request.
Use escaping functions on all user input.
Configure the application identity for the least database privileges that are required to accomplish the necessary tasks. Harden the database server to disable any unneeded functionality, such as shell commands.
Input validation is necessary to ensure the integrity of the dynamic data of the application. Validation is useful to protect against cross-site scripting, SQL and command injection, and corrupt application data fields. Even if there are no directly vulnerable uses of a piece of data inside one application, data that is being passed to other applications should be validated to ensure that those applications are not given bad data. Validation, especially for size and metacharacters that might cause string expansion, is even more important when dealing with fixed size, overflowable buffers. You should validate input from untrusted sources before using it. The untrusted data sources can be HTTP requests or other network traffic, file systems, databases, and any external systems that provide data to the application. In the case of HTTP requests, validate all parts of the request, including headers, form fields, cookies, and URL components that transfer information from the browser to the server side application. Attackers use unvalidated parameters to target the application's security mechanisms such as authentication and authorization or business logic, and as the primary vector for exercising many other kinds of error, including buffer overflows. If the unvalidated parameters are stored in log files, used in dynamically generated database queries or shell commands, and/or stored in database tables, attackers may also target the server operating system, a database, back-end processing systems, or even log viewing tools. For example, if the application looks up products from the database using an unvalidated productID from HTTP request. This productID can be manipulated using readily available tools to submit SQL injection attacks to the backend database.
final String productID = request.getParameter( "productID" ); final String sql = "Select * from Product Where productID = '" + productID + "'"; final Statement statement = connection.createStatement(); final boolean rsReturned = statement.execute(sql);
char productID[28]; fscanf(fd, "%28s", productID); char sql[71] = "Select * from Product Where productID = '"; strncat(sql, productID, 28); strncat(sql, "'", 1); SQLPrepare(handle, sql, 71); SQLRETURN ret = SQLExecute(handle);
Note that using dynamically generated SQL queries is another bad practice. Refer to vulnerability type SQL Injection for more detail.
// This class would simply associate parameter names with a data type, plus bounds for // numeric data or a regular expression for text. Validator validator = Validator.getInstance( this.getServletContext ); Boolean valid = false; try { validator.validate( request ); valid = true; } catch ( ValidationException e ) { request.getSession().invalidate(); out.println("Invalid HTTP request"); out.close(); } if ( valid ) { final String productId = request.getParameter( "productID" ); final String sql = "Select * from Product where productID= ?"); final PreparedStatement ps = con.prepareStatement(sql); ps.setString(1,productID); ps.execute(); }
In this instance, a regular expression constrained input to a known set of characters, through a whitelist (rejecting inputs containing anything not in that set), and of a known and limited length. Using a whitelist instead of a blacklist is important, because it can be difficult to anticipate which characters (especially when Unicode is involved) may cause problems, while it is normally easy to determine which characters are legal in a given input field.
Fix recommendation
The primary recommendation is to validate each input value against a detailed specification of the expectation for that value. This specification should detail characteristics like the character set allowed, length, whether to allow null, minimum value, maximum value, enumerated values, or a specific regular expression. For example, make sure all email fields have the same format. Also, limit name fields and other text fields to an appropriate character set, no special characters, and with expected minimum and maximum sizes. A input pattern violation can be evidence of an attack and should be logged and responded to appropriately.
There are several possible approaches to input validation in an application. The recommendation is to implement the features in a single component that is invoked in a central location. If this is not possible, then enforce a strong policy for the use of a common set of input validation functions.
M
Authentication.Entity
Cause
Authentication.Entity refers to cases in which an application insecurely performs authentication. For example, if username and password information are stored in the source code in clear text, an attacker who gains access to the source code will learn the credentials needed to compromise the database.
Fix recommendation
Never store passwords in clear text. If the password must be remembered in memory for a short time to perform authentication null out the value as soon as possible to mitigate reading memory blocks to determine the password. In some languages String objects are kept alive throughout the run of the program. In those instances prefer using a char[] array instead of a String ibject and set every byte to '0' after the password is used for login.
H
Insecure Use of Document.Location
API:Insecure Use of Document.Location
Cause
Content being assigned to the `document.location` variable could be carrying tainted data. Since this data can be further used within the HyperText Markup Language (HTML) of a page, take steps to validate it. The Document Object Model (DOM) as defined by the World Wide Web Consortium (W3C) supports setting the location of the document, assuming it is well formed. Content passed into `document.location` should not be exposed to the user in a way that allows for alteration of that content. Exposing such content to the user can lead to a variety of Cross Site Scripting and HTML Injection attacks.
In the cases where `document.location` carries input originating from an external location, further validation on the input is recommended.
Validation of such content when it is exposed to the user should be performed in the same manner as server-side input validation. Input validation should not be solely performed by client-side JavaScript components exposed to the user. Validation implemented in this manner can be bypassed by means of manipulating the browser and/or the submitted request. Use Server-Side validation or a combination of Client-Side and Server-Side validation.
Furthermore, any unnecessary content should not be attached to `document.location`.
<script language="javascript">… var inLocation = <%request.getEncodedParameter("location")%>; document.location = inLocation;…</script>bad
Content being passed into the `document.write()` or the `document.writeln()` method could be carrying tainted data. Since this data is further used to display the HyperText Markup Language (HTML) inside a page, take steps to validate it. The Document Object Model (DOM) as defined by the World Wide Web Consortium (W3C) provides two methods for controlling output being written to the document: `document.write()` and `document.writeln()`. Content inputted to `document.write()` or the `document.writeln()` method should not be trusted without further validation. Using such content without validation can lead to a variety of Cross Site Scripting and HTML Injection attacks.
<script language="javascript"> … var inText = <%request.getParameter("text_type")%>; document.write("The text inputted is: " + inText); … </script>
Fix recommendation
In the cases where these methods carry input originating from an external location, further validation on the input is recommended.
Validation of such content when it is exposed to the user should be performed in the same manner as server-side input validation. Input validation should not be solely performed by client-side JavaScript components exposed to the user. Validation implemented in this manner can be bypassed by means of manipulating the browser and/or the submitted request. Use Server-Side validation or a combination of Client-Side and Server-Side validation.
Furthermore, any unnecessary content should not be passed to these methods.
<script language="javascript">… var inText = <%request.getEncodedParameter("text_type")%>; document.write("The text inputted is: " + inText);…</script>bad
A relatively new form of attack called Side Jacking allows an attacker to steal unencrypted information, which is then cloned and used to access a protected system. For a more in depth look at this type of attack see the References section below for links to relevant information. The Side Jacking attack is typically used to steal cookies that are then cloned and replayed to the target website allowing the attacker to log in as the victim. Even if the web site uses HTTPS as its protocol, an attacker can still force the session cookie to be sent in an unencrypted (HTTP) connection. To mitigate this attack the session cookie is sent with the `secure` attribute. This attribute forces the cookie to only be sent to the client when there is a secure connection (HTTPS). The problem is that a typical web page downloads various resources such as JavaScript (.js) files and Cascading StyleSheets (.css) files from the web site. These files are typically send via unsecured connections (HTTP) for performance reasons.
An attacker can take advantage of this by sniffing the network for these files, intercept them and then inject code in them or rewrite them in order to steal the session cookie. The injected JavaScript is then executed by the victim and the cookie that was sent over the secure connection can then be stolen. For more details on how this is accomplished see the blog entry "Surf Jacking Secure Cookies" in the References section below.
Fix recommendation
Add the `HTTPOnly` flag on the cookie. This will prevent client-side script from accessing the cookie. Note that not all browsers support the `HTTPOnly` flag.
Additionally, any resources accessed through script tags could be accessed only through a secure connection (HTTPS). This will prevent an attacker from intercepting a resource such as a JavaScript file and inject code into it.
Content being passed into the `InnerHTML()` or `OuterHTML()` methods should be checked for tainted data. Since this data is further used to insert text, HyperText Markup Language (HTML), and/or script inside of a page, steps should be taken towards validating this data. Content inputted to the `InnerHTML()` or `OuterHTML()` methods should not be trusted without further validation. Using such content without validation can lead to a variety of Cross Site Scripting and HTML Injection attacks.
<script language="javascript"> ... var par = <%request.getParameter("param1")%>; document.getElementById('div1').innerHtml = par; ... </script>
Fix recommendation
It is recommended that all `InnerHTML()` or `OuterHTML()` methods be replaced with `InnerText()` or `OuterText()` methods. These methods simply write the data as plain text to the browser without rendering HTML or script.
If the `InnerHTML()` or `OuterHTML()` methods are necessary, further validation on the input is recommended.
Validation of such content when it is exposed to the user should be performed in the same manner as server-side input validation. Input validation should not be solely performed by client-side JavaScript components exposed to the user. Validation implemented in this manner can be bypassed by means of manipulating the browser and/or the submitted request. Use Server-Side validation or a combination of Client-Side and Server-Side validation.
Furthermore, any unnecessary content should not be passed to these methods.
<script language="javascript">... var par = <%request.getEncodedParameter("param1")%>; document.getElementById('div1').innerText = par;...</script>bad
Additionally, you can add JavaScript that performs whitelist validation on the input data:
<script language="javascript">... var par = document.URL; if (inText.match(/^[a-zA-Z0-9]$/)) // Only allow alpha-numeric data { document.getElementById('div1').innerText = par; }...</script>bad
Content being passed into the `setAttribute()` or `setAttributeNS()` methods should be checked for containing tainted data. Since this data is used to add or modify attributes of elements inside the HyperText Markup Language (HTML) of a page, steps should be taken towards validating it. Content inputted to these methods should not be trusted without further validation. Using such content without validation can lead to a variety of Cross Site Scripting and HTML Injection attacks.
<script language="javascript"> ... var par = <%request.getParameter("param1")%>; var anchor1 = document.getElementById("anchor1"); anchor1.setAttribute("href", par); ... </script>
Fix recommendation
In the cases where this method carries input originating from an external location, further validation on the input is recommended.
Validation of such content when it is exposed to the user should be performed in the same manner as server-side input validation. Input validation should not be solely performed by client-side JavaScript components exposed to the user. Validation implemented in this manner can be bypassed by means of manipulating the browser and/or the submitted request. Use Server-Side validation or a combination of Client-Side and Server-Side validation.
Furthermore, any unnecessary content should not be passed to this method.
<script language="javascript">... var par = <%request.getEncodedParameter("param1")%>; var anchor1 = document.getElementById("anchor1"); anchor1.setAttribute("href", SanitizeURL(par));...</script>bad
Authentication.Entity refers to cases in which an application insecurely performs authentication. For example, if username and password information are stored in the source code in clear text, an attacker who gains access to the source code will learn the credentials needed to compromise the database.
Fix recommendation
Never store passwords in clear text. If the password must be remembered in memory for a short time to perform authentication null out the value as soon as possible to mitigate reading memory blocks to determine the password. In some languages String objects are kept alive throughout the run of the program. In those instances prefer using a char[] array instead of a String ibject and set every byte to '0' after the password is used for login.
