When we were writing our interpreter,
we saw that JavaScript let's us modify
global variables from within a function.
Does this have security implications for our browser?
Oh yes, there are very tragic--very problematic security implications
of the ability to overwrite or even read from
a variable that you're not expecting.
Especially when you have a program written in JavaScript
or something like PHP, another language
commonly used to write web applications,
that's outward facing--where adversaries
can keep poking you until you fall over.
One of the historically most common ways this came up--
and I'll use PHP as an example.
In PHP--was known as registering or register global variables.
Early on, PHP was commonly used
to write code that would respond to web forms.
Now if you're not familiar with web forms,
just think about registering for an account online
or maybe buying some food or buying a book.
You often have to fill in things like this is my name,
this is my address, this is my credit card number,
here's how much I'm paying, here's how much I'm tipping.
You write all of those things in text,
and then some computer program on the other side is going to do calculations on them.
For example, maybe it's going to
add in sales tax, or calculate how much shipping is going to be,
or figure out when to send you some email later
based on the time and your zip code and the particular shipping company--
any sort of business logic in the middle.
In order to do that, though, it needs to know
what your zip code was when you entered it in the form field
or how much money you said you were paying.
So we need to get that information.
In order to make it very simple for early PHP programmers,
if you wrote your web page and said
name here--this is the name field--
zip code here--this is the zip code field--
it might automatically make global variables
in the middle of your PHP program
called Name and Zip Code.
Then you could just read out of them
and get whatever the user had posted in the form.
This was super convenient, but also super deadly.
It is phenomenally easy to take over a web page
or otherwise maliciously attack a web page
or a web application that uses this sort of register global variables behavior.
One easy way to think about this is,
the values of these variable aren't set by the programmer, and they may not be validated.
You can't trust people on the web
to always put in an exact integer for their zip code.
You can't trust them not to make up
fake form fields that weren't really there
that contain things like am I cleared
or password credentials or how much money should I give this user
or what's the sale or whatnot.
In essence, any bit of business logic that you had in your program,
they could fake up new values for it.
You thought you were giving a 10% sale,
suddenly you are giving a 110% sale--worst case sort of scenario.
So this register global variables approach
turned out to be a really poor design decision
in early versions of PHP.
These days, it's more or less off by default,
but still it's what a lot of people think of
when they think of global variables that we don't necessarily
have control over where reading or writing them.
But so is some adversary.
Now this can definitely lead to security problems.
Now these days, even if register global variables
isn't a PHP feature, PHP programmers will still find
fun ways to make the web insecure.
Functions like Explode, which are very similar to things like
String.Split in Python, are often used to assign to local variables,
trusting the user or trusting the person on the other side
of some sort of web interface to be well behaved.
One of the big problems with computer security
is that often the adversary is not well behaved.
We have to pay attention and validate these sorts of strings.
So this issue that you saw in class,
relating to when can I change global variables,
when are they in scope, am I going to get the value that I expect or make a new one.
Now this can have unfortunate security implications.
So it's worth understanding exactly how it works.