The Executive Guide to Third-Party Cyber Risk

Learn about how you, as an executive, can manage your organization's third-party risk.

Download Now

The Open Web Application Security Project (OWASP) is a well-established organization dedicated to improving web application security through the creation of tools, documentation, and information—that latter of which includes a yearly top 10 of web application vulnerabilities. The following is a compilation of the most recent critical vulnerabilities to surface on its lists, as well as information on how to remediate each of them.

Top OWASP Vulnerabilities

1. SQL Injection

Description: SQL injection vulnerabilities occur when data enters an application from an untrusted source and is used to dynamically construct a SQL query. SQL Injection may result in data loss or corruption, lack of accountability, or denial of access. Injection can sometimes lead to complete host takeover.

Fix / Recommendation: Proper server-side input validation must be used for filtering out hazardous characters from user input. Additionally, making use of prepared statements / parameterized stored procedures can ensure that input is processed as text.

Sample Code Snippet (Input Validation):

String input = request.getParameter ("SeqNo");
String characterPattern = "[0-9a-zA-Z]";
If (! input. matches (characterPattern))
{
out.println (“Invalid Input”);
}

2. Cross Site (XSS) Scripting

Description: In these cases, invalid user-controlled data is processed within the application—leading to the execution of malicious scripts. XSS vulnerabilities can allow attackers to capture user information and/or inject HTML code into the vulnerable web application.

Fix / Recommendation: Proper server-side input validation and output encoding should be employed on both the client and server side to prevent the execution of scripts. Hazardous characters should be filtered out from user input [e.g.: | , & , ; , $ , % , @ , ' , " , \' , \" , <> , () , + , CR (Carriage return, ASCII 0x0d) , LF (Line feed, ASCII 0x0a),(comma sign) , \ ].

Sample Code Snippet (Encoding Technique):

<input type="text" maxlength="30" name="ecsChangePwdForm" size="40" readonly="true"  value='<%=ESAPI.encoder().encodeForHTML(request.getParameter("userName"))%>'/>

3. Information Leakage

Description: The web application may reveal system data or debugging information by raising exceptions or generating error messages. Leakage of system data or debugging information through an output stream or logging function can allow attackers to gain knowledge about the application and craft specialized attacks on the it.

Fix / Recommendation:

  • Ensure that error codes and other messages visible by end users do not contain sensitive information.
  • Sanitize all messages, removing any unnecessary sensitive information.   
  • Ensure that debugging, error messages, and exceptions are not visible.

Sample Code Snippet:

catch (Exception e)
{
if(log.isDebugEnabled()) log.debug (context, EVENTS.ADHOC,
"Caught InvalidGSMException Exception -- "
+ e.toString() );
}

4. Frame Injection

Description: Improper validation of input parameters could lead to attackers injecting frames to compromise confidential user information. Frame injection is a common method employed in phishing attacks

Fix / Recommendation: Use a whitelist of acceptable inputs that strictly conforms to secure specifications

Sample Code Snippet:

String input = request.getParameter ("input");
String character Pattern = "[./a-zA-Z0-9?"="&]";
If (! input. matches (character Pattern))
{
out.println (“Invalid Input”);
}

5. URL Redirection

Description: While it's common for web applications to redirect or forward users to other websites/pages, attackers commonly exploit vulnerable applications without proper redirect validation in place. This can lead to malicious redirection to an untrusted page.

Fix / Recommendation: Use a whitelist of acceptable inputs that strictly conform to specifications and for approved URLs or domains used for redirection.

Sample Code Snippet:

String input = request.getParameter ("input");
String character Pattern = "[./a-zA-Z0-9?"="&]";
If (! input. matches (character Pattern))
{
out.println (“Invalid Input”);
}

6. Missing Session Timeout

Description: Attackers may gain unauthorized access to web applications if inactivity timeouts are not configured correctly.

Fix / Recommendation: Ensure that timeout functionality is properly configured and working.

Sample Code Snippet:

<webapp>
     <session-config>
     <session-timeout>15</session-timeout>
</session-config>
</webapp>

7. Sensitive Information Passed as Clear Text in GET URL

Description: Web applications using GET requests to pass information via the query string are doing so in clear-text. This makes any sensitive information passed with GET visible in browser history and server logs.

Fix / Recommendation: Using POST instead of GET ensures that confidential information is not visible in the query string parameters.

8. Session ID Cookies Not Marked Secure

Description: If session ID cookies for a web application are marked as secure, the browser will not transmit them over an unencrypted HTTP request. Not marking them as such allows cookies to be accessible and viewable in by attackers in clear text.

Fix / Recommendation: Make sure that sensitive cookies are set with the "secure" attribute to ensure they are always transmitted over HTTPS.

Sample Code Snippet:

Cookie cookie = new Cookie("myCookieName");
cookie.secure(true);

9. Cross Frame Scripting (XFS)

Description: XFS exploits are used in conjunction with XSS to direct browsers to a web page controlled by attackers. In these cases, the malicious page loads a third-party page in an HTML frame. Scripts on the attacker's page are then able to steal data from the third-party page, unbeknownst to the user.

Fix / Recommendation:  Proper validation should be used to filter out any malicious input that can be injected into a frame and executed on the user's browser, within the context of the main page frame.

Sample Code Snippet:

if (top == self) }
   document.documentElement.style.display = 'block';
}
else {
top.location = self.location;
}

10. Sensitive Information Displayed as Clear Text on Screen

Description: Sensitive information (e.g., passwords, credit card information) should not be displayed as clear text on the screen. In addition to shoulder surfing attacks, sensitive data stored as clear text often finds its away into client-side caches—which can be easily stolen if discovered.

Fix / Recommendation: Sensitive information should be masked so that it is not visible to users

Sample Code Snippet:

<asp:TextBox ID="txtSSN" TabIndex="6" runat="server" Width="206px" MaxLength="11" TextMode="Password"></asp:TextBox>

11. Sensitive Information Cached

Description: Browsers typically store a copy of requested items in their caches: web pages, images, and more. This creates a security gap for applications that store, process, and display sensitive data, since attackers gaining access to the user's browser cache have access to any information contained therein.

Fix / Recommendation: HTTP Cache-Control headers should be used such as Cache-Control: no-cache, no-store Pragma: no-cache.

Sample Code Snippet:

<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate" />
<meta http-equiv="Pragma" content="no-cache" />
<meta http-equiv="Expires" content="0" />

12. Inadequate Encryption Strength

Description: Applications using less than 1024 bit key sizes for encryption can be exploited via brute force attacks

Fix / Recommendation: Use a higher version bit key size, 2048 bits or larger.

13. CRLF (Carriage Return and Line Feed) Injection

Description: CRLF exploits occur when malicious content is inserted into the browser's HTTP response headers after an unsuspecting user clicks on a malicious link. Hackers will typically inject malicious code into the user's browser through the web application/server, making casual detection difficult.

Fix / Recommendation: URL-encode all strings before transmission. Ensure that shell metacharacters and command terminators (e.g., ; CR or LF) are filtered from user data before they are transmitted.

Sample Code Snippet:

String author = request.getParameter(AUTHOR_PARAM);
Cookie cookie = new Cookie("author", ESAPI.encoder().encodeForURL(author));
cookie.setMaxAge(cookieExpiration);
response.addCookie(cookie);

14. Trust Boundary Violation

Description: Web applications often mistakenly mix trusted and untrusted data in the same data structures, leading to incidents where unvalidated/unfiltered data is trusted/used.

Fix / Recommendation: Proper input validation and output encoding should be used on data before moving it into trusted boundaries.

Sample Code Snippet:

String sessionPolicyId = request.getParameter("id");
if(sessionPolicyId.matches("[0-9a-zA-Z_]+") {
session.setAttribute("sessionPolicyId",sessionPolicyId);
}

15. Directory Traversal

Description: By accepting user inputs that control or influence file paths/names used in file system operations, vulnerable web applications could enable attackers to access or modify otherwise protected system resources.

Fix / Recommendation: A whitelist of acceptable data inputs that strictly conforms to specifications can prevent directory traversal exploits.

Sample Code Snippet:

String input = request.getParameter("fileName");
if (ESAPI.validator().isValidFileName(String context, String input, boolean allowNull))
{
File file = new File(input);
}

16. Session Fixation

Description: In these cases, vulnerable web applications authenticate users without first destroying existing sessions associated with said users. This allows attackers to access users' accounts by hijacking their active sessions.

Fix / Recommendation: Destroy any existing session identifiers prior to authorizing a new user session.

Sample Code Snippet:

session.invalidate();
session=request.getSession(true);

17. Use of a Risky Cryptographic Algorithm

Description: Web applications using non-standard algorithms are weakly encrypted, allowing hackers to gain access relatively easily using brute force methods.

Fix / Recommendation: When storing or transmitting sensitive data, use strong, up-to-date cryptographic algorithms to encrypt that data before sending/storing.

Sample Code Snippet: 

MessageDigest md = MessageDigest.getInstance("SHA-256");
FileInputStream fis = new FileInputStream("c:\\loging.log");
byte[] dataBytes = new byte[1024];
int nread = 0;
while ((nread = fis.read(dataBytes)) != -1) {
  md.update(dataBytes, 0, nread);
};
byte[] mdbytes = md.digest();

18. Credentials Management

Description: Storing passwords in plain text can easily result in system compromises— especially if configuration/source files are in question.

Fix / Recommendation: Avoid storing passwords in easily accessible locations. Use cryptographic hashes as an alternative to plain-text.

19. SQL Injection Hibernate

Description: Hibernate is a popular ORM framework for Java—as such, it provides several methods that permit execution of native SQL queries. Attackers commonly exploit Hibernate to execute malicious, dynamically-created SQL statements.

Fix / Recommendation: Proper server-side input validation can serve as a basic defense to filter out hazardous characters. Prepared statements/parameterized stored procedures can be used to render data as text prior to processing or storage.

Sample Code Snippet: 

Query hqlQuery = session.createQuery("select product from Orders as orders where orders.id =?");
List results = hqlQuery.setString(0, "123-ADB-567-QTWYTFDL").list();

20. Improper Resource Shutdown or Release

Description: Improper resource shutdown occurs when a web application fails to release a system resource before it is made available for reuse. A denial of service attack (Dos) can be then launched by depleting the server's resource pool.

Fix / Recommendation: Any created or allocated resources must be properly released after use. 

Sample Code Snippet: 

try {
Connection con = DriverManager.getConnection(some_connection_string);
}
catch ( Exception e ) {
log( e );
}
finally {
if( stmt != null )
     stmt.close();
     con.close()   }

In short, the 20 items listed above are the most commonly encountered web application vulnerabilities, per OWASP. While many of these can be remediated through safer coding practices, some may require the identifying of relevant vendor-specific patches. This ultimately depends on what specific technologies, frameworks, and packages are being used in your web application.

Need an easier way to discover vulnerabilities in your web application? Powered by policy-driven testing, UpGuard can automatically scan and monitor your web application for misconfigurations and security gaps.

Infographic

Top 20 OWASP Vulnerabilities And How To Fix Them Infographic

 

Top 20 OWASP Vulnerabilities And How To Fix Them Infographic

Ready to see
UpGuard in action?

Ready to save time and streamline your trust management process?