Category Archives: Programming

Programming In Javascript

Posted by Daniel on July 29, 2010 None comments

Javascript is an interesting language. Its partly a functional programming language and part object oriented. It uses a C style syntax but borrows its naming conventions from Java (mostly). Personally I find Javascript language to be one of the most interesting languages that I have played with. The complaints I hear most often regarding Javascript are that it is very hard to learn and that there are many subtle differences between the interpreters.

Difficult to learn

This used to be mostly true. Javascript was a poorly documented language, often only documented in tutorial form by w3schools, or technically documented as ECMAScript. The absolute wealth of tutorials and blog posts made the good information few and far between. Largely when looking for information on how to perform a particular function you had to download some sample code and figure out how it was done based on that.

More recently though Javascript has caught the wave that is trying to standardize the web and this has somewhat improved the situation. Browser manufacturers are documenting their Javascript implementations and largely converging on a common standard. Additionally many helper libraries have been introduced to make the task of working on Javascript even easier. Once Javascript may have been difficult to learn, but as of late this is no longer true.

Javascript Documentation:

Subtle differences in interpretation

This is is one of the biggest problems you still see in Javascript today. You will often find developers writing functions to simply deal with the differences between browsers, there are even entire libraries dedicate to to abstracting away the differences. If I had a dollar for every implementation of a function to get a XMLHttpRequest object across browsers, I wouldn’t need my job.

Unfortunately it is still however very important to know the differences between implementations of Javascript if you plan on writing anything that will run on more than one browser. These difference may be in the features available in the language, in the Document Object Model or in the way the browser handles CSS. Thankfully many people work on documenting the difference and abstracting around them in libraries.

Javascript Implementations Differences:

Javascript Libraries:

Random Thought: If only Facebook didn’t get in the way of Javascript all the time…

Cross-Domain AJAX

Posted by Daniel on May 5, 2010 1 comments

When making an xmlhttprequest from a website the browser will restrict you to the site from which the script came. This is a security precaution. If sites were able to tell the browser to make requests from other domains then they would be able to DDOS a site with a users browser. There are legitimate reasons to make requests to other sites though.

Many sites offer web services, xml data and json encoded data. These can provide almost anything from the weather, to search results, to advanced APIs. To use these services from your site using javascript you’ll have to employ one of the methods below.

Signing Javascript

Firefox allows you to sign your Javascript and place it in a jar file. This will give your code more privileges, You can also request these permissions explicitly without having your code signed, but having a dialog box appear for every AJAX request could get very tiring for the user. Another problem with this approach is that it isn’t documented very well and its Firefox specific. The first link in the references section deals with this method.

Access-Control Headers

This is the w3 approved method of allowing a client from another domain to access your web service. It is a server side method and requires no changes on the client to implement. This is both and advantage and a disadvantage. If you have control over the server then this method is simple, otherwise (for sites such as Yahoo API or other public services) you will not be able to implement this. It should also be noted that this was implemented in Firefox 3.5 so it can’t be used with earlier versions, or other browsers.

To use this method you tell your service to output extra headers that tell the browser whether access was allowed or denied.

Flash Enabled xmlhttprequest

This method involves using an invisible flash player to perform the actual request then handing the result back to the Javascript for processing. Flash still performs permission checking by looking for a /crossdomain.xml file in the root directory of the domain the request is being made to. There are several libraries that implement this approach and a few even implement in a way which is compatible with xmlhttprequest. One downside is this Flash is required, though recently Flash is required for several major sites and most browsers will have it installed.

Add Sites To Trusted Zone

Internet Explorer allows and denies cross-domain based xmlhttprequests based on the security setting. This approach is likely not going to be used on the Internet as it requires user interaction and is Internet Explorer specific. On a corporate Intranet this is slightly less difficult but not by much.

Apache mod_proxy

With this method you use the same server you shared the page from to proxy the requests automatically to the server with the data you’re fetching. For this to work your version of Apache has to be compiled with proxy support or you need to have the mod_proxy dso loaded. This method increases the latency of requests as they must first go via your server. It should also be noted that this cannot be implemented in .htaccess file and must be done in the main configuration.

Manual Proxy

If you don’t have control over your servers configuration then you can mimic the above method by writing a script that forwards the variables required and forwards back the data. This approach can even be more preferable than the above method as it allows you to preprocess the variables and cache the data if required.

References

http://www.mozilla.org/projects/security/components/signed-scripts.html

http://dev.w3.org/2006/waf/access-control/

http://developer.yahoo.com/javascript/howto-proxy.html

https://developer.mozilla.org/En/HTTP_Access_Control

http://ejohn.org/blog/cross-site-xmlhttprequest/

http://ajaxpatterns.org/XMLHttpRequest_Call

http://ajaxpatterns.org/Flash-enabled_XHR

Random Thought: Can you use AJAX to make web applications cleaner?

Writing a Daemon in C

Posted by Daniel on January 1, 2010 1 comments

What is a Daemon?

A daemon is a program that runs in the background. A daemon will usually be started at system startup and end at system shutdown. The exceptions to this rule are programs like the Bluetooth SDP daemon, which is activated when a new Bluetooth HCI is found,, and ends when it is removed. Daemons run transparently and do not normally interact with the user directly.

Daemons start as ordinary processes but they eventually ‘fork and die’ to start running in the background. Some daemons do only the ‘fork and die’ step but ignore other important steps. Here is a list of what a daemon should do:

  1. Fork to create a child, and exit the parent process.
  2. Change the umask so that we aren’t relying on the one set in the parent.
  3. Open logs to write to in the case of an error.
  4. Create a new session id and detach from the current session.
  5. Change the working directory to somewhere that won’t get unmounted.
  6. Close STDIN, STDOUT and STDERR.

These steps ensure that our association with the calling environment is destroyed and our daemon is now free to run as a completely separate process.

Lastly before writing the daemon you should make sure the code is written securely and in a way that fails gracefully. If your daemon crashes it will not be able to prompt the user about what action to take. The user may not even notice until it is too late.

Forking a child process

In Unix fork() is the only system call with two return values. When you call fork a child process is created which is a near copy of its parent (some things will be different in the child eg. process id). The fork command then returns a 0 in the child and the childs process id in the parent, on failure a -1 is sent to the parent. Generally a program will then check whether it is the child or parent by these return values (just like in movies when a cloned character will check to see if he has a belly button and hence is the original). Here is a snippet of code to do this:
[code lang="c"]
pid_t pid;

/* Clone ourselves to make a child */
pid = fork();

/* If the pid is less than zero,
something went wrong when forking */
if (pid < 0) {
exit(EXIT_FAILURE);
}

/* If the pid we got back was greater
than zero, then the clone was
successful and we are the parent. */
if (pid > 0) {
exit(EXIT_SUCCESS);
}

/* If execution reaches this point we are the child */
[/code]

Changing the umask

Because we are a clone of our parent we’ve inherited its umask. This means the child doesn’t know what permissions files will end up with when it tries to create them. We do this by simply calling umask like this:
[code lang="c"]
/* Set the umask to zero */
umask(0);
[/code]

Open logs to write to

This part can be done in several different ways. You could open text files, log to a database or use syslog. The method I’m going to demonstrate here is to log using syslog. Syslog sends your log messages to a system wide logger, where they can be configured to be written to a file, send to a network server or filtered away entirely.
[code lang="c"]
/* Open a connection to the syslog server */
openlog(argv[0],LOG_NOWAIT|LOG_PID,LOG_USER);

/* Sends a message to the syslog daemon */
syslog(LOG_NOTICE, "Successfully started daemon\n");

/* this is optional and only needs to be done when your daemon exits */
closelog();
[/code]

Create a new session id

Each process on a Unix system is a member of a process group (or session). The id of each group is the process id of its owner. When we forked from our parent earlier we will have inherited its process group, and our process group leader will still be its parent process. We want to create our own process group and become our own process leader otherwise we will look like an orphan. We can do this easily as follows:
[code lang="c"]
pid_t sid;

/* Try to create our own process group */
sid = setsid();
if (sid < 0) {
syslog(LOG_ERR, "Could not create process group\n");
exit(EXIT_FAILURE);
}
[/code]

Changing the working directory

At the moment we have the working directory we inherited from our parent. This working directory could be a network mount, a removable drive or somewhere the administrator may want to unmount at some point. To unmount any of these the system will have to kill any processes still using them, which would be unfortunate for our daemon. For this reason we set our working directory to the root directory, which we are sure will always exist and can’t be unmounted.
[code lang="c"]
/* Change the current working directory */
if ((chdir("/")) < 0) {
syslog(LOG_ERR, "Could not change working directory to /\n");
exit(EXIT_FAILURE);
}
[/code]

Closing the standard file descriptors

A daemon doesn’t interact with the user directly it has no use for STDIN, STDOUT and STDERR and we really have no idea where these are connected or where anything we write to them will end up. As these file descriptors are not required and effectively useless we should close them to save some system resources and prevent any related security problems. We close these descriptors like this:
[code lang="c"]
/* Close the standard file descriptors */
close(STDIN_FILENO);
close(STDOUT_FILENO);
close(STDERR_FILENO);
[/code]

Writing the payload

Now you have a C program that is capable of becoming a daemon, but its a pretty useless daemon if it exits immediately. Payload code is really up to you to design. I’ll offer you a few tips on designing your payload.

  • Put your payload in a loop. Generally in a daemon you want to perform the same action over and over again until you’re killed. If you have to cleanup (such as closing syslog) when the daemon is about to be killed you should add an exit clause that will be activated by a SIGTERM signal handler.
  • Make your code as fast an efficient as possible. This is something you should do with any program, but with daemons it is important that you do not hamper the performance of the rest of the system. This is especially true if you’re going to be running this daemon on desktop systems.
  • Be aware that your code may be preempted very often. As your daemon is going to be running for the amount of time the system is up, it is likely that its execution will be preempted.
  • Be paranoid about security. Daemons are common attack vectors and can be used to gain privileged access to a system. You should consider dropping any privileges that you don’t require.

Conclusion

So if we take all the code I’ve mentioned in this post and put it all together you have a simple daemon. You can download the source from the link here: daemon.c.
If your daemon is only going to be run on Linux and not on a System V style system such as Solaris you can use the daemon function to do a lot of this work for you.

References

Linux Daemon Writing HOWTO in C
Linux Daemon writing in C++

Random Thought: It appears the devil uses a Unix based OS, probably OSX.

Paramaterized Java Classes

Posted by Daniel on October 3, 2009 3 comments

One of the biggest features of Java 1.5 was generics. In particular all the collection classes had been extended to use parametrized classes. Normally the collection classes accepted and returned Objects which is the class all other Java classes descend from. Unfortunately this meant that you had to cast everything you got back out of a collection to what you expected it to be. and until you did you would only be able to call methods that were provided by Object. You also had to be ready to catch an exception in case the class could not be cast because it was the wrong object.

Generics and parametrized classes allow Java programmers to place a type on a class and have that type inherited by its methods. For example you can now declare an ArrayList class with a type String. This alters the ArrayList class so that its add method now only accepts objects of type String, the get method now also returns objects of type String. This makes everything type safe which means you don’t have to cast anything and your code won’t compile if you try to put something in the ArrayList that doesn’t match its class.

Java uses parametrized classes to build its collections and you’ll want to use them too if you’re making your own collection class. For example if you were implementing a stack, a queue or a multi-priority FIFO queue are good cases for parametrized classes. Be careful though of the lure parametrized classes can have. They are not a replacement for polymorphism and shouldn’t be used when polymorphism would make more sense. For example if your multi-priority queue gets the priority out of the object itself then you’d need an interface that provides a method to get the priority. Then your class will only be able to accept items that implement that interface, which makes sense in this case as we need to priority to be able to store it.

A parametrized class is really simple to use. Here is an example implementation of a stack collection backed by an ArrayList:
[code lang="java"]import java.util.ArrayList;
import java.util.Collection;

/**
* This class acts as a stack. Items can be 'pushed' which adds them to the top
* of the stack. items can also be 'popped' which removes and returns the top
* item on the stack and removes it. This means only the most recently added
* item is available at the current time. To get to older items you need to
* first remove the others.
*
* Note: Java already has a stack object that should probably be used in
* preference to this one. This is only an example implementation.
*
* @author Daniel Hall <daniel@danielhall.me>
*
* @param <T> The type of items that can be stored in the Stack.
*/
public class Stack<T> {
/* Uses the same type as this class to store the items */
private ArrayList<T> array = new ArrayList<T>();

/**
* Creates a Stack containing items already in a collection. The collection
* must have the same parameterized type as this class to ensure that we get
* the right objects.
* @param c The Collection to initialize with
*/
public Stack(Collection<T> c) {
array.addAll(c);
}

/**
* Creates an empty Stack object
*/
public Stack() {

}

/**
* Adds an item to the top of the stack.
* @param item The item which will be added to the top of the stack.
*/
public void push(T item) {
array.add(item);
}

/**
* Removes the first item from the stack
* @return The item that was on the top of the stack.
*/
public T pop() {
/* This gets the size so we don't have to do it twice. */
int count = array.size();

/* If the stack is empty return null, note that the Java implementation
* of stack throws an Exception instead.
*/
if (count == 0) {
return null;
}

/* Remove the last added object (which will have index count - 1) */
return array.remove(count - 1);
}
}[/code]
Random thought: John Lions wrote a book about the Unix source code, in the seventies, which because it also included some code, was blocked from being published until 1996.

Cryptographically Secure Random Numbers in Java

Posted by Daniel on September 30, 2009 None comments

The Random Class

Most people wanting to generate random numbers in Java do something similar to the following:
[code lang="java"]public static void main(String[] args) {
Random generator = new Random();
int randomnumber = generator.nextInt(5) + 1;
System.out.println("Dice rolled: " + randomnumber);
}[/code]
This is perfectly fine for a simple dice rolling application where there isn’t going to be much effort put into cracking it. For example in this application the only real reason you would bother cracking it would be to show off a neat party trick to your geeky friends. No doubt though the effort wouldn’t be worth it.

Java states that the Random class and its subclasses must produce predictable results when seeded with the same data. This however is not why this is insecure, and it is useful when testing. The reason that this class is predictable though is the way in which it is seeded. The Random class, in the absence of a seed in its constructor it will seed its random number generator with the current time in milliseconds. This means that if somebody knows the time that the Random object was seeded and has several consecutive bytes of output then they can reasonably predict the next numbers. Once somebody has discovered the seed for the generator all number produced from it can be seen as compromised.

The SecureRandom Class

The SecureRandom class is different, it again uses algorithms that when seeded will produce predictable results, but the algorithm is much more complex. It uses a digest algorithm such as SHA-1 on the seed and a counter to generate random data. SHA-1 is much more costly than the simple algorithm used in the Random class and as such it is much harder to brute force.

Its true strength however lies in the method in which it is seeded. The SecureRandom class is seeded using true random data gathered by the operating system. This is data gathered by the OS from sources of true randomisation, such as mouse movements, network packet arrival times, IO statistics and interrupts. On Linux the data is gathered from /dev/random and on Windows via the CryptGenRandom() call in Windows.

When using SecureRandom though you should be aware of a few things:

  • The more random numbers some can get a hold of the more likely they can figure out the seed. You should either throw away the SecureRandom object every now and then or reseed it. Keeping in mind the next point though.
  • The seeding the generator takes entropy out of the system, if it cannot get any entropy it will block until the system has some. This means if you’re reseeding the generator too often your program will hang along with anything else on the system requiring entropy.
  • Don’t seed the SecureRandom class yourself, unless you are 100% absolutely sure you are seeding it with purely random data, or you are testing and need repeatable results. Whatever you do, don’t let your testing code leak into a production system.

How to decide

Generally when you’re coding you don’t need secure random numbers. For example if you’re writing a number guessing game, or a quiz generating program then high quality random numbers aren’t required. It should be noted though that if money is involved people will often go to greater lengths and a more secure generator will be required, such as in a slot machine.

Again generally if what you are generating is a security token of some sort then you will need a secure generator. For example a session id, a one time password or an encryption key. The exception here is a salt for a password, salts can be generated using predictable entropy sources, even a simple time stamp would work here (especially if your also storing the time stamp to measure password expiry).

Random Thought: For those of you who don’t know Bruce Schneier is the Chuck Norris of cryptography.