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

Most C programmers, even beginners, would claim that arrays are easy, except those abundant off-by-one errors and they are right. Arrays are easy indeed. However, here are a few points to consider when writing a program that needs a rather large array (By the way, the thought for this article came into mind while helping a colleague to resolve an error a couple of days ago). When creating a large array (e.g. something like int a[1000][1000], which BTW takes up around 3.8 MB on most machines), you might not have any issue at all or might see either a compile time error or worse, runtime errors.
Why do these errors happen? Depending on your machine’s limitations you are most probably consuming the total available stack (if you used a local variable) or data memory. Depending on your compiler, these might be flagged at compile time or surface when you try to run your program. Or it might be that your compiler isn’t able to work with large arrays. What you can do to alleviate these:

• The first and best way is to minimize your array size (This makes for an amazing example here from the bookd “Programming Peals”: http://www.cs.bell-labs.com/cm/cs/pearls/cto.html )
• Use “huge” memory model.
• Use a global variable (or a static variable if you are particular about its visibility to the rest of the program). The stack is generally quite limited as compared to the data memory available to a program. So, a variable with static storage would ensure that you use memory from the data segment.
• Don’t declare it as an array at all and instead use a pointer and dynamically allocate the memory required for it. You might have to use special allocation calls instead of normal malloc/calloc to get this working though (e.g. using farmalloc)
• Create a section in assembly with the “Area” directive (or whatever it is for your particular assembler) and reserve space for your array there and refer to that array as an extern variable.

The first approach is something that you should always look for. But if you can’t mimize your need any further, choose one out of the rest two. But few things to be kept in mind here that these options can still fail, e.g., when you don’t have enough RAM/heap memory remaining at runtime (of course, you would have planned for a graceful exit though in such case instead of the random crash that would have occured otherwise). But still these could be useful to you in case you don’t have any real RAM limitations but just that your compiler isn’t able to work with large objects.

© Safer Code | Large Arrays In C

Related posts

• int main() vs void main() (22)

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

Even an expert programmer cannot claim of writing bug free code. Bugs are here to stay during a software development life cycle. But what every programmer needs to do is to test his code before the code goes into the main repository. So, programmers have different techniques to do this. Running Test cases, getting code reviewed, code walk through, running manual tests, ad-hoc tests are various things performed by people and Bang!!! code goes into the repository. Let’s consider the following psuedo-code:

char* someString = (char*) malloc(100);
if(someString != NULL){
    // do something
}else{
    // handle error condition
}

Now, If you try to test the above code using the above mentioned testing techniques, you can never be sure that you have covered 100% code in developer testing. The code definitely seems to be fine handling the error condition if the memory allocation fails. But have you actually tested the error condition handling? Generally, all the automated test cases or running the code will make the memory allocation successful and the error condition will never get executed. Even the code reviewers will pass the code without any objection as the code is handling memory allocation failure. But you haven’t made sure that error handling is safe or not. The Bug might be in error handling scenario.

So, One of the best way to “de-Bug” or test your code is always to step through your code. Think that you were stepping through your code using a debugger. Now, put a breakpoint at malloc and set someString to NULL right after memory allocation is done. This will enable your error condition code to be executed and you can claim 100% coverage of testing your code before checking it in the repository.

The next word of advise is that not only error conditions, one should check all the possible execution paths in the code. Consider the following example:

int someInt = 30;
char someChar = 'c';
if( someInt= 32 && someChar=='c'){
    // do something
}else{
    // handle error condition
}

If you notice, I have made a mistake in the code by typing ‘=’ in place of ‘==’ in the first part of ‘if’ statement. So, even if you run test cases or use debugger, the code will easily execute ‘if’ statement in one shot and will evaulate to true as first and second condition will always evaluate to ‘TRUE’. and hence, leaving a hole in the code. The error condition will never occur in this case. This can only be caught if while using a debugger, put a breakpoint inside ‘if’ statement, and then verify both the conditions on either side of ‘&&’ operator. This will lead you to find the anomaly in the code and hence, you’ll be able to kill a potential showstopper bug instantly.

In a nutshell, I wish to emphasize on a point is that debuggers are not meant only to be used when the defects are raised in defect trackign systems, they should be used during developmental testing of the code. I agree that this consumes a hell lot of extra time in development but isn’t it beneficial to be safe in the beginning rather than wasting time on these small issues after the software is released and have already translated into bigger crash bugs.

© Safer Code | “De-Bugging” Code before Check-in

Related posts

• And So It Begins… (0)
• Improper Variable Initialization (0)
• Predicting the rand() and using Cryptographic Random Numbers (7)
• int main() vs void main() (22)
• All Input is Evil (3)

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

Every programmer, no matter how great he is, makes mistakes sometime or the other while coding. Although every compiler tries its best to put across every possible error during compilation,many mistakes skip the wrath of compiler. Some are seemingly very innocent and very tough to be caught even during code review, sometimes even get through the cycle of testing. The real face of these mistakes show up always on the customer side by crashing the system.

Consider the following example:

int multiply(int m, int n)
{
	int result = 0;
	result = m * n;	
	return 	result;
}
 
void func()
{
	int m = 32767;
	int n = 32767;
	int result = 0;
	result = multiply( m, n );
}

In this example, if you notice, the result always overrun the maximum value of an integer (int being of 16 bits). Now, for any compiler, this code seems to be perfect. But if you lint this code, the lint tool will definitely raise a warning about this potential bug. This bug if overlooked, can cause havoc in any system in crucial scenarios.

Similarly, there are many more example like these which can be caught while linting the code. Quite a few significant but obvious problems like buffer overrun, array index out of bounds, uninitialized variables causing junk in junk out can be caught using any of the good lint tools. This process of linting makes the code safe, secure and strong enough to withstand any kind of malicious input injections or buffer overrun attacks. Ofcourse, the complex scenarios can get skipped by some of the tools but still, it definitely is a better steo to catch the bug early. Quite a few tools are available in the market but i’ll recommend a tools can PC-Lint(Windows)/FlexLint(Linux). This tool is pretty good as it catches almost every obvious flaw which gets skipped by the developers or code reviewers eyes. It follows the guidelines given in MISRA (Motor Industry Software Reliability Assocation)standard and strictly adhers to that.

These linting tools generally have their properietary algorithms but in general, they all follow the same approach of static analysis of source code. Following are examples of some of the problems which these tools are capable of finding during the lint process.

Linting your code during development is very important as it can make your code much safer. It definitely does add to the build time and it might take few extra seconds to get the final object file, but isn’t it worth the hassle if you are saved from deadly bugs?

© Safer Code | Lint your code: Find probable mistakes much before testing

Related posts

• Validating Untrusted Integer Inputs (6)
• Validating Untrusted String Inputs (1)
• Unsafe Functions In C And Their Safer Replacements: Strings Part II (8)
• Unsafe Functions In C And Their Safer Replacements: Strings Part I (7)
• int main() vs void main() (22)

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

Everyone must have used rand() sometime or the other while writing C code. The problem with rand() in most of the platforms is that it is easy to predict the output. Being based on unsigned int, it is just a simple function using a seed which is always the last randomly generated some number. This seed is not very tough to guess for an advanced hacker. once this seed is guessed,, any password or information based on random number generation can be easilt cracked and maligned.

following code is abridged code of rand() function implementation referenced from the book The C programming Language written by Brian Kernighan and Dennis Ritchie

unsigned long int next = 1;
int rand(void)
{
    next = next * 1103515245 + 12345;
    return (unsigned int)(next / 65536) % 32768;
}

This type of function is generally called linear congruential function. As you can notice yourself, that these type of linear congruential functions are very much predictable and are not recommended for security sensitive applications. If you look at the above given code, it is obvious that if the underlying environment does not change, then the random number generation can easily be guessed as it will generate same random number on running the application again and again.

Any type of good random number generator should adhere to three basic properties:

1. Generate evenly distributed numbers
2. The generated number should be unpredictable
3. It should use a long cycle of range of numbers

Linear congruential functions just suffice the first property but fail miserably in the other two, thus, making themselves unusable for secure random number generation.In the early era of internet, people have used the rand() function, and hackers have exploited it at leisure.

To Solve this problem, most of the platforms support Cryptographic Random Numbers these days. For example, CryptGenRandom is provided by almost all the Windows platforms. These type of Cryptographic Random numbers are completely random as the seed used in them is also unknown to the programmer. It is completely random because it uses the system properties(system entropy) to generate the seed, which is then hashed used a hashing algorithm like SHA-1/MD4/MD5 etc. This implementation is completely platform dependent. For example: quite a few parameters used by Windows platforms are like

1. Current Process ID
2. Current Thread ID
3. GetLocalTime()
4. CPU counters
5. Allocated Process Memmory at initial time
6. Page Fault count
7. etc etc etc….

Due to these large number of parameters and then, applying the hashing algorithms, the seed becomes almost random and unpredictable, thus, making it next to impossible to be decrypted.

Crypt Random Numbers and algorithms are part of FIPS (Federal Information Processing Standard) standard. The above mentioned function is a part of FIPS 186-2 standard.

Talking about Cryptographic Random numbers is a fairly vast topic and I would like to continue in my next post.

© Safer Code | Predicting the rand() and using Cryptographic Random Numbers

Related posts

• And So It Begins… (0)
• All Input is Evil (3)
• Using Enum Pattern in Java < 1.5 (1)
• Improper Variable Initialization (0)
• “De-Bugging” Code before Check-in (0)

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

Except for few good C programmers, others generally tend to ignore variable initialization or I should rather say “proper variable initialization”. Generally seen, the variable declaration itself is not done with a good thinking. Improper local variable initialization might not be good for the working of the program but improper global variable initialization might get your software or system hacked.

The uninitialized variable or a wrongly initialized variable might lead a program to change its normal course of flow from the intended one. For example: If a variable “index” is being used for array navigation and is left uninitialized, it might contain a garbage value which can lead to array index out of bounds error. or if the variable “index” is initialized wrongly to –1, it might lead to serious flaw in code flow. Even if an integer value is being initialized to ‘0’, it might lead to a security check bypass because for some programs, even a ‘0’ is considered a valid value.

Lets take an example of a code piece.

 int isMachineRunning = GetMachineStatus();
 int state = GetUserState(isMachineRunning);
 int userid = 0;
 if (state) {
	userid = ExtractUserID(state);
 }
/* do stuff */
if (uid == 0) {
	DoAdminThings();
}

Now, in the above example, userId is initialized to ‘0′. and adminUserID is also equal to ‘0′. Consider that the GetUserState() function somehow failed to get the state of user then, the If condition check might fail resulting in failure to obtain a valid user id. This, In turn, will still lead to admin access as we have wrongly initialized the userid variable to ‘0′ which is equal to admin user id. Let’s consider another example:

char str[20];
strcat(str, "hello world");
printf("%s", str);

This might seem innocent enough, but str was not initialized, so it contains random memory. As a result, str[0] might not contain the null terminator, so the copy might start at an offset other than 0. The consequences can vary, depending on the underlying memory. If a null terminator is found before str[8], then some bytes of random garbage will be printed before the “hello world” string. The memory might contain sensitive information from previous uses, such as a password stored in a buffer. In this example, it might not be a big deal, but consider what could happen if large amounts of memory are printed out before the null terminator is found. If a null terminator isn’t found before str[8], then a buffer overflow could occur, since strcat will first look for the null terminator, then copy 12 bytes starting with that location. Alternately, a buffer over-read might occur if a null terminator isn’t found before the end of the memory segment is reached, leading to a segmentation fault and crash. I hope that the above mentioned examples are goos enough to emphasize on the correct initialization of variables and yes, that each and every needs to be initialized.

The four mandatory steps to follow for correct variable declaration is :

1. Explicitly initialize all variable or data stores with the correct and expected values either at the first usage or during declaration as a must rule.
2. Properly do input validation to make sure that the variable usage in the first statement itself is initialized to expected value.
3. Avoid race conditions during initialization routine.
4. Definitely run some static analysis tool on your code to make sure that it raises all sorts of warnings or errors to warn you before you publish your code.

Once you follow the above mentioned checklist, I am sure that you’ll face least of problems or issues with variable initializations.

© Safer Code | Improper Variable Initialization

Related posts

• And So It Begins… (0)
• “De-Bugging” Code before Check-in (0)
• Validating Untrusted Integer Inputs (6)
• Predicting the rand() and using Cryptographic Random Numbers (7)
• Validating Untrusted String Inputs (1)

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.
1) Either we have “public static final” constants declared.

public class UsingConstants {  
    public static final int CONST_1 = 1234 ;
    public static final int CONST_2 = 1 ;
    public static final int CONST_3 = 1 ;
    private int value ;
    private UsingConstants(int param) {
       value = param ;
    }
 }

2) Implement the enum pattern.

public class UsingEnumPattern {
    public static final UsingEnumPattern CONST_1 = new UsingEnumPattern(1234) ;
    public static final UsingEnumPattern CONST_2 = new UsingEnumPattern(1) ;
    public static final UsingEnumPattern CONST_3 = new UsingEnumPattern(1) ;
    private int value ;
    private UsingEnumPattern(int param) {
       value = param ;
    }
    public static int getValue()
    {
       return value;
    }
}

To evaluate the performance and understand the details of these two different implementations, have a look at the user code given below:

public class UserCode {  
    public void initializeSomethingUsingConstants(int param) {
       int i = param;
    }
    public void initializeSomethingUsingEnumPattern(UsingEnumPattern param) {
        UsingEnumPattern i = UsingEnumPattern.CONST_1;
        int i = UsingEnumPattern.getValue();
    }
    public void callMethods(){  
        initializeSomethingUsingConstants(1111); // I can pass any integer here
        initializeSomethingUsingEnumPattern(UsingEnumPattern.CONST_1) // only defined enums can be passed.
    }
}

Now, We’ll deduce the following two things from this example:

a) The first example, UsingConstants, has defnitely got faster execution time as it has got only few bytecode instructions to execute.

    0:   aload_0
    1:   invokespecial   #16; //Method java/lang/Object."<init>":()V
    4:   aload_0
    5:   iload_1
    6:   putfield        #19; //Field value:I
       9:   return

where as the second example, UsingEnumPattern has about 16 instructions to execute. 16 to create statics and 6 for initialization.

    static {};
      0:   new     #1; //class com/nds/epg/network/IPConfigErrorCodeA
      3:   dup
      4:   sipush  1234
      7:   invokespecial   #14; //Method "<init>":(I)V
      10:  putstatic       #18; //Field CONST_1:LUsingEnumPattern;
      13:  new     #1; //class UsingEnumPattern
      16:  dup
      17:  iconst_1
      18:  invokespecial   #14; //Method "<init>":(I)V
      21:  putstatic       #20; //Field CONST_2:LUsingEnumPattern;
      24:  new     #1; //class UsingEnumPattern
      27:  dup
      28:  iconst_1
      29:  invokespecial   #14; //Method "<init>":(I)V
      32:  putstatic       #22; //Field CONST_3:LUsingEnumPattern;
      35:  return
 
      0:   aload_0
      1:   invokespecial   #26; //Method java/lang/Object."<init>":()V
      4:   aload_0
      5:   iload_1
      6:   putfield        #28; //Field value:I
      9:   return

and as per user code, constant evaluation will bve faster as it will using the ’sipush’ instruction as compared to ‘getstatic’ instruction in case of enum pattern.

   /*
   public void initializeSomethingUsingConstants();
      0:   sipush  1234
      3:   istore_1
      4:   return
 
   public void initializeSomethingUsingEnumPattern();
      0:   getstatic       #18; //Field UsingEnumPattern.CONST_1:LUsingEnumPattern;
      3:   astore_1
      4:   return
*/

So, to summarize, if you are very much worried just about performance then definitely, using constants makes it a perfect sense.

b) Now, lets look at the problem of using constants. get a bit paranoid and think that people are just waiting to break your code. it is easily possible as while using constants, any integer value can be passed to the user method instead of the constant values, which is enough to break your code. Now, to protect this, you’ll have to write conditions for every possible value the program expects and handles the correct error conditions for every incorrect value. Now, won’t this increase your code size resulting in a lot of execution overhead.

Whereas, if you use second example, incorrect values cannot be passed at all and your code will be safe from attackers. and you need not write any extra guard conditions resulting in keeping your code size to minimum.

Alright!! By now, most of you would be thinking that how this post relate to bytecode reverse engineering but then, I just needed a starting point to explain a problem before getting into injecting malicious content in your bytecode to break what you consider secure.

In my next post, i’ll evaluate these bytecodes more and then, later on, we’ll talk about contaminating bytecodes to make the code malfunction. All my posts will consider the aspect of code performance vs. code safety amd I am not sure whether these thoughts of mine will make any sense but I do need a place to vent out.

© Safer Code | Using Enum Pattern in Java < 1.5

Related posts

• And So It Begins… (0)
• All Input is Evil (3)
• Validating Untrusted Integer Inputs (6)
• Predicting the rand() and using Cryptographic Random Numbers (7)
• Tainted Object Propagation (5)

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:

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

Related posts

• Using Enum Pattern in Java < 1.5 (1)
• And So It Begins… (0)
• Validating Untrusted Integer Inputs (6)
• Predicting the rand() and using Cryptographic Random Numbers (7)
• int main() vs void main() (22)

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

Related posts

• Unsafe Functions In C And Their Safer Replacements: Strings Part I (7)
• Validating Untrusted String Inputs (1)
• Validating Untrusted Integer Inputs (6)
• Lint your code: Find probable mistakes much before testing (3)
• Improper Variable Initialization (0)

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

In my previous posts, I have been emphasizing on validating Integer and String inputs by putting various checks in place. But now, I’ll suggest you to consider any type of input to your application or software as “Evil”. Consider the following two rules for any input data:

1. All input is evil until proven otherwise.
2. Data must be validated as it crosses the boundary between untrusted and trusted environments.

Till now, I explained how to validate Integer and String data, but today, I’ll explain what is to be validated in the input data. First things first, Look for valid data and reject everything else. You should deny all access until you are sure that the input in the request is valid. You should look for valid data and not look for invalid data for two reasons:

1. There might be more than one valid way to represent the data.
   • For example: a word “Rose” can be represented in many ways like “ROSE”, “rose”, “R%6fse”, “RoSE” et cetera. All the mentioned words are the variations of single word “Rose” and they are valid variations. But, This can definitely be a problem for an application.
2. You might miss an invalid data pattern.

Consider the following code:

bool IsBadExtn(char *szFileName)
{
	/* some code */
	if(szFileName)
	{
		size_t cFileName = strlen(szFileName);
		if(cFileName >= 3)
		{
			char* szBadExtn[] = {".exe",".com",".bat",".cmd"}; /** Line 9 **/
 
			/* code to check validate the input "szFileName" against these file extensions which are not allowed */
		}
	}
}

Now, The above mentioned code is not good enough as It does not catches all the vulnerabilities. This program is trying to block all those types of file extensions which might be harmful for the system if executed. But, The validation done is not good enough as even “.pl”, “.js”, “.vbs”, “.wsh” etc can also be harmful. So, To protect your system, allow only file those types which are expected. For example: Line 9 can be replaced by

char* szGoodExtn[] = {".gif",".bmp",".png",".txt"};

This is a positive aspect of data validation. This is needed as we don’t know what are various possibilities that a program can be exploited with. So, we block all access other than the expected input.

In a nutshell, There is no hard and fast rule whether to do a negative validation or a positive validation. It’s purely up to you depending on the application requirements. But, If you take care of the above mentioned rules, There are very rare chances of  tainted data entering into your system.

© Safer Code | All Input is Evil

Related posts

• Validating Untrusted Integer Inputs (6)
• Using Enum Pattern in Java < 1.5 (1)
• And So It Begins… (0)
• Predicting the rand() and using Cryptographic Random Numbers (7)
• int main() vs void main() (22)

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

Alright!! In my last post about untrusted inputs, we talked about validating the data of the “integer” input parameters, checking the out parameters et cetera.This time, we’ll talk about other types of inputs. If you have written a program to take in multiple lines of strings as an input from the user, you need to make sure that the input is not tainted. It is clean and as per your expectations. For example: If your program requires an answer for a question which can be subjective, then you need to provide a string buffer good enough to get a complete answer but not large enough to crash your system or make it run out of memory. Or you need to protect your system from getting any malicious scripts being inserted.Strings are a very risky area for inputs as there is pre-defined rule for this type of validation. So, following are the points to ponder to make your code safe and secure.

1. Firstly, do use regular expressions to validate the string input. For example, ^[A-Za-z0-9]+$ specifies that the string must be at least one character long and that it can only include upper-case letters, lower-case letters, and the digits 0 through 9 (in any order). You can use regular expressions to limit which characters are allowed and to be more specific (for example, you can often limit even further what the first character can be).If you use regular expressions, be sure to indicate that you want to match the beginning (usually symbolized by ^) and end (usually symbolized by $) of the data in your match. If you forget to include ^ or $, an attacker could include legal text inside their attack to bypass your check.
2. Now, if your program needs more variety of input and the above point doesn’t fulfil the requirements then you need to make a bit more complicated regular expressions. If the data is a filename (or will be used to create one), be very restrictive. Ideally, don’t let users choose filenames, and if that won’t work, limit the characters to small patterns such as ^[A-Za-z0-9][A-Za-z0-9._\-]*$. You should consider omitting from the legal patterns characters like “/”, control characters (especially newline), and a leading “.”Similarly, you need to take care for email strings, locale specific strings. UTF-8 encoding characters et cetera. In most of the programs, complex regular expressions are good enough to validate a string. But in certain cases, a malicious input containing some script code can spoil the fun.
3. If your program faces HTML tags or script related instructions in the input, the input should be rejected immidiately or your program might get infected with self executing malicious code. This technique is generally used in Cross Site scripting attack. (XSS attack). These problems are especially a problem for Web applications. Now, you need to again take care not to validate any input which looks like an HTML tag. The easiest way is to use above mentioned regular expressions which won’t allow the entry of ‘<’ or ‘>’ character. But if you must support some of the HTML tags like <a href=> etc, please validate them exclusively by filtering the whole string using a regex like ^(http|ftp|https)://[-A-Za-z0-9._/]+$. A pattern that allows some more complex patterns is: ^(http|ftp|https)://[-A-Za-z0-9._]+(\/([A-Za-z0-9\-\_\.\!\~\*\'\(\)\%\?]+))*/?$
4. For more complex strings, like reading a data file, regular expressions, again, prove useful but the ideal way is to break the file into multiple chunks rather than reading it in one complete string.

To Keep your String input kept in well defined range or buffer, make sure that your program terminates it with a NULL character. This will ensure that even if a large buffer is inserted using the input, the sting will get truncated as soon as the buffer gets full and it will be protected from buffer overflow.

© Safer Code | Validating Untrusted String Inputs

Related posts

• Unsafe Functions In C And Their Safer Replacements: Strings Part I (7)
• Validating Untrusted Integer Inputs (6)
• Unsafe Functions In C And Their Safer Replacements: Strings Part II (8)
• Lint your code: Find probable mistakes much before testing (3)
• Improper Variable Initialization (0)