Tainted Object Propagation
Subscribe To Our Feed | Follow Us On Twitter | Get Updates on Email
Basically, Tainted Object Propagation is the term defined for using incorrect or invalid inputs to get more than required information from the system and in some cases, taking control of the system. Although this technique is much widely used to misuse web applications and database oriented applications, but this holds true for any API publisher who exposes his API’s to third party application writers.
Again, just like previous post, Let’s start with an example.
Consider that a web page or an application takes an input “userName” and the application executes the following query to find that particular user.
HttpServletRequest request = ...; String userName = request.getParameter("name"); Connection con = ... String query = "SELECT * FROM Users " + " WHERE name = ’" + userName + "’"; con.execute(query);
Now, this is the usual code written by programmers to get the particular from the database. Now, if an attacker gets the control of the userName field, he can set it to ‘OR 1=1; This query allows the user to circumvent user name check and returns all the users from the database. In this case, the input variable “userName” is considered as Tainted Object.
Lets take another example,
<input type="hidden" name="total_price" value="25.00">
A web form contains hidden fields to pass some information to the server which is not visible to the user. Now, HTTP pages are stateless. Unlike regular fields, hidden fields cannot be modified directly by typing values into an HTML form. However, since the hidden field is part of the page source, saving the HTML page, editing the hidden field value, and reloading the page will cause the Web application to receive the newly updated value of the hidden field.
Following is the classification of various attacks:
- Parameter tampering: pass specially crafted malicious values in fields of HTML forms.
- URL manipulation: use specially crafted parameters to be submitted to the Web application as part of the URL.
- Hidden field manipulation: set hidden fields of HTML forms in Web pages to malicious values.
- HTTP header tampering: manipulate parts of HTTP requests sent to the application.
- Cookie poisoning: place malicious data in cookies, small files sent to Web-based applications.
- SQL injection: pass input containing SQL commands to a database server for execution.
- Cross-site scripting: exploit applications that output unchecked input verbatim to trick the user into executing malicious scripts.
- HTTP response splitting: exploit applications that output input verbatim to perform Web page defacements or Web cache poisoning attacks.
- Path traversal: exploit unchecked user input to control which files are accessed on the server.
- Command injection: exploit user input to execute shell commands.
Now, I’ll describe how to “UnTaint” your objects.
In order to track tainted inputs, we must specify following three things:
To track the taintedness of strings, we associated a taint flag with every string. This taint flag is set when a string is returned by a source method. We propagate this taint flag to strings that are derived from tainted strings through operations such as concatenation, case conversion etc.
To “Untaint”, we need to have mechanism in place which will subject every input for taint verification and then, untaint it. For example: a tainted string that is passed through a regular expression match, or been tested for the presence of a particular character is not tainted anymore. Note that, here we need to trust the programmer to have performed a meaningful check that accounts for all cases that might be exploitable in an attack. It is entirely possible that the programmer wrote a faulty input validation routine that lets through user-input strings with malicious content in them. 
If we find any tainted object using these algorithms, then two things can be done. Either raise a TaintException or Abandon that particular taint session. The weakest option is to let tainted data be used as an argument to a sink, but make a full log of the arguments, the sink, and the path the tainted data took from source to sink. This seems insecure, but is useful when auditing, doing penetration testing, debugging, or if used in a honeypot.
The best way to find most of the taint problems and the code vulnerablity is use of static analyzer tools. These tools identify the possibility of any input field being maliciously utilized and raise a warning to fix that error. The algorithms by which most of these static analyzer tools work use the above mentioned methodology. Some of the java static analyzer tools work on the bytecode level to prevent bytecode contamination also.
But even after this, you may find some taint issues coming your way. In this case, no one can defeat the strictest of code reviews. More strict the code review and reviewer, less the code is prone to attackers.
There is a lot of information available on the net about Taint object problem. I have used the resources available on the net itself to make myself aware of the gory details and if you are interested, search details on the net . By going through the details, even you should be able to build you own static analyzer tool.
© Safer Code | Tainted Object Propagation
|
Liked this post? Get FREE Updates Subscribe to RSS feed 
|
Related posts
Tags: Database, database input, Java, Queries, Security, SQL Injection, Taint, Tainted Object
[...] of java code and protect the java code from tainted objects. We’ve already talked about Tainted Object Propagation in my previous post in context with databases. now, it is in context with application code. I’ll [...]
Not that I’m totally impressed, but this is more than I expected when I found a link on SU telling that the info is awesome. Thanks.
That’s an interesting article. I just wondered if you could tell me where to find more info on this topic ?
@stomach fat
This is a very popular topic in security discussions in reference to SQL injections.. Just google for “Tainted Object Propagation”