Dynamic function names in JavaScript

Creating a function with a custom name is not something you can do easily out of the box in ECMAScript. Thankfully, ECMAScript comes with a custom function constructor.

First, the basic code, which will give most of you want you want:

The above will create an anonymous function, which when called creates the named function (using the name variable). This functionality is a good substitute for when you can’t use eval() but you need a function with a custom name. Eval is generally useless in ES5 strict mode for a number of good reasons, so its best avoided.

However, an issue with the code above is that we had to write the main code into a string. This sucks because it makes it difficult to debug (i.e., we can’t easily set break points), so we want to avoid that as much as possible. The solution is to make the main function external, pass it as an argument to the Function constructor to call it.

Another advantage here is that we can set private variables inside our custom function, which can then be mixed with public arguments. Check this out!:

You can basically the start doing cool things from there, like:

The above is mega useful for dynamically implementing custom DOM-like interfaces… like shims. Enjoy! 🙂

Secure Programming and the evil
element

For something to do, I took a secure programming course a few days ago. The course covered all the basic stuff: buffer overflows in c, cross-site scripting, injections, denial of service attacks, SSL, signatures and digital certificates.

One of the examples for cross-site scripting was a user having the ability to input HTML elements into a comment box on a blog. The example demonstrated how a site could be defaced and even susceptible to people injecting <script> elements (nothing new here). However, when the instructor showed how the issue could be overcome, he thought he would be nice and leave the ability for users to use <br> elements. I thought, “Bonza! Maybe I can hack with the <br> element” and promptly wrote the following code:

<br onmouseover=“alert(’hello’)”>

Much to my surprise, the above code works in IE6 and IE7. Firstly, according to the HTML 4 spec the br element should only use the core attributes, and not the events. So there’s another bug in Microsoft’s IE6 and 7’s implementation of HTML4. The above code, however, does not work in FireFox2 or in Opera9:  no events are applied.

According to Hixie, it should be possible to style the br. However, the CSS 1 spec says the following (my emphasis):

The current CSS1 properties and values cannot describe the behavior of the ‘BR’ element. In HTML, the ‘BR’ element specifies a line break between words. In effect, the element is replaced by a line break. Future versions of CSS may handle added and replaced content, but CSS1-based formatters must treat ‘BR’ specially.

I tried applying a style attribute to the br element but nothing happened in all browsers.

Javascript security experiments

I’ve been reading an old article (2004) on JavaScript security and decided to try out some of the security issues outlined to see how the new generation of browsers were dealing simple security issues. In particular, I wanted to see how each mayor browser handled recursion and running loops that just use up memory.

Recursion experiment

I ran the following experiment on Vista and MacOs 10.4 in Opera 9.1 and Firefox 2.0.0.1, and in IE7 to see how many recursive loops it would allow me to do before it (a) crashed, or (b) ran out of memory space allocated for that web page:

var count= 0 ; 
function tag(){
document.write(count++ + " " );
you_are_it();
} 
function you_are_it()  { tag(); }
tag();

Results

Opera
PC: 1668 (throws no exception)
Mac: 1672 (throws no exception)
IE7
1275 (if not caught by a try block it displays an unfriendly pop up saying out of memory on line: 5)
Firefox 2.0.0.1
Mac and PC: 499 Throws exception: “InternalError: too much recursion”

try it (javaScript will be executed in your browser’s address bar)

Recursion conclusion

I’m not sure if IE is actually running out of memory (maybe it’s recursion stack is overflowing). Seems to me that it has just been restricted to allow 2551 recursive calls. Firefox seems to be limited to a 1000 recursive calls. Unlike the other two browsers, Opera locks up for a bit, then comes back. If you vary the size of the string that is written by document.write it also behaves somewhat erratically, letting you do 3335 recursive calls.
Memory tests

I ran the following code on the same browsers with upsetting results. IE locked up windows Vista and it took me about 5-10 minutes to be able to force IE to quit. Firefox quickly jumped from using 130Mb to about 560Mb and then threw an out of memory exception. However, when I hit refresh to do the experiment again it locked up Vista and again took me about 5-10 to close Firefox. I ran the experiment again, but this time I had the task manager open ready for kill the processes. Same thing happened again. Opera, on the other hand threw an Object too big exception straight away. Its memory footprint did not go up at all.

Code

var adiosAmigo = "Sayanora, sucker.";
while (true)
adiosAmigo += adiosAmigo;

Conclusion

IE7 does not deal with memory hog issues very well. Firefox tries to, but alas it is not a graceful as Opera.