Safer Code – Secure Coding In C \ C++ And More..

Subscribe To Our Feed | Follow Us On Twitter | Get Updates on Email

Alright!!! Let’s get started. This is one of many subjects which always overwhelms me. Why so? Ofcourse, the reasons can not be explained here but then, the reason should be the least of your worries.

Okay, if you know enough about this, then please post your knowledge tips as comments because your comments might help towards my unexplained reasons.

You may find similar information on other websites but then, it’s a wild world and I am not intending to infringe any copyrights.

Now to begin with, let’s first understand how to evaluate the performance 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 explain this with an example of enum pattern.

We can have enums in Java in two ways. Continue for detailed reading

© Safer Code | Using Enum Pattern in Java < 1.5

Liked this post? Get FREE Updates Subscribe to RSS feed Or Enter Your E-mail ID below

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.

Continue Reading

© Safer Code | Tainted Object Propagation

Liked this post? Get FREE Updates Subscribe to RSS feed Or Enter Your E-mail ID below

Subscribe To Our Feed | Follow Us On Twitter | Get Updates on Email

Last time, we advised you to use ditch the unsafe functions like strcpy and strcat, and use their safer replacements (strlcpy, strlcat) instead. However, there is a small problem with this that you might discover that your compiler (especially gcc) does not have these functions in their implementation of the c library (libc). Why is this so? Read this thread about the original patch that was submitted to add these functions to libc. Essentially, it was rejected on the basis that these functions hide problems instead of solving them and would actually lead to hard to detect bugs that creep in because of unsolicited truncation caused by these functions. A sample implementation of strlcpy looks like this:

#include <sys/types.h>
#include <string.h>
 
/*
 * Copy src to string dst of size siz.  At most siz-1 characters
 * will be copied.  Always NUL terminates (unless siz == 0).
 * Returns strlen(src); if retval >= siz, truncation occurred.
 */
size_t
strlcpy(char *dst, const char *src, size_t siz)
{
	char *d = dst;
	const char *s = src;
	size_t n = siz;
 
	/* Copy as many bytes as will fit */
	if (n != 0) {
		while (--n != 0) {
			if ((*d++ = *s++) == '\0')
				break;
		}
	}
 
	/* Not enough room in dst, add NUL and traverse rest of src */
	if (n == 0) {
		if (siz != 0)
			*d = '\0';		/* NUL-terminate dst */
		while (*s++)
			;
	}
 
	return(s - src - 1);	/* count does not include NUL */
}

Now, there are supporters for both the sides. Solaris and BSD accepted these functions while GNU/Linux refuses to do so till date. The stand that I’d like to take here is that this is at least a step towards the right direction because a truncation bug is much better than an attacker taking over the control of your network just by pushing out a long string onto the stack. However, we could indeed augment the implementation above to communicate back to the caller somehow that truncation occurred. Whichever side you choose, be aware that these problems are very real and don’t just keep on using the older unsafe versions (Even in words of Ulrich Drepper, the opposer of strlcpy: “ The users of these functions[strcpy, strcat] should be severly punished”).

© Safer Code | Unsafe Functions In C And Their Safer Replacements: Strings Part II

Liked this post? Get FREE Updates Subscribe to RSS feed Or Enter Your E-mail ID below