- [Instructor] When an application makes data available,
especially sensitive data like financial information,
data security is an important concern.
The JSON data in app provides in response to a request
can be formatted in many ways.
For instance, you can provide data
that parses into an object,
but your data can also be in the form of a JSON array
or even a function in the case of JSON-P.
Because some forms of JSON data
can be evaluated as JavaScript by a client,
you need to be aware of any security holes opened
by different formats
and take steps to mitigate them where necessary.
Browsers enforce what are known as same-origin policies.
One of these policies allows a script
to access data from another script
only if both scripts share the same origin.
The origin includes scheme like HTTP or HTTPS,
hostname and port number.
So this effectively limits a script from accessing data
that comes from another server.
Now in some cases, I want to permit data sharing,
and there are a number of schemes in use
that let us do this.
At the same time,
I have to recognize any unintentional backdoors
and be sure to lock them up.
Same-origin policies apply to code in a script.
However, an HTML document can load scripts from any origin.
Some attackers have taken advantage of this
by running malicious code
that adds a new script element to an HTML document.
This is known as a cross-site script injection attack,
sometimes abbreviated XSSI.
By hijacking what the browser does after parsing data,
malicious code can intercept data
and send it to an attacker.
Fortunately, there's an easy way to defend against this.
Although a malicious script can add a new script element,
it can't control what happens next.
When the client downloads the script file,
it immediately executes it,
so many web services add JavaScript code
that generates an error
to the start of the JSON data they send.
When the data is requested by another script,
which can only happen in a script from the same origin,
the script can parse the data
and strip out the JavaScript code before using the data,
but when the data is downloaded directly
using an injected script element
and the data is immediately executed,
the malformed code at the start generates an error
and the data is never parsed.
One statement that causes an error,
and that is commonly used for this purpose is while one.
The statement creates a while loop
that executes as long as the value one evaluates to true
because one is equivalent to true in JavaScript,
and because the statement includes no end condition,
the statement creates an infinite loop.
If the loop is allowed to run,
it causes the client to stop responding.
Alternatively, the client may have built in logic
that recognizes the loop
and ends execution of the injected script.
Either way, it closes off the possibility
that the data object can be parsed
and then intercepted by a malicious script.
To deliver JSON that's prefixed like this,
you have to configure your web service on the backend,
but assuming that's already done,
let's look at what it takes for your code to parse
and then use this data.
In the script.js file for this video,
the protected data variable on line one
contains data like you might receive from a web service,
and this data is prefixed with the while one statement.
If I open products.html and I go live,
and then I open up my console,
I can see that there's an error
and that the contents of my webpage aren't actually loading.
And this is the behavior I want from my raw data,
but I don't want to be parsing the data in this form,
instead, because I know that my data contains
this extra while statement at the start,
I can write code to edit that out
and work with just the data itself.
So I just need to create a function
that removes the while statement from the start of the data
and then parses the remaining data.
So further down here on line six,
I'm going to add a function called clean data.
I need to start by making that a const.
And then the value is going to take a parameter,
which is raw data
and it's going to return
the result of taking that raw data parameter
and using the slice method
to remove the first nine characters.
And those first nine characters are the while statement.
So this clean data function is taking my data,
removing that while statement,
and then returning the rest of it, which is just the data.
Then down here on line nine,
I need to update my existing JSON.parse statement
to use that clean data function.
So instead of simply parsing protected data,
which has the while statement in it,
I want to first call clean data
and I want to pass it protected data.
And the result here is that the protected data
is going to run through the clean data function
and the result of that is going to get parsed.
And that will be just my data.
And I'll save that and I'll go back to my browser.
And now I can see, first off, immediately,
that the products have loaded on my page,
so the data is in use on my webpage.
I can also see that my console.log statements,
first, I'm getting that entire JSON string logged,
and then next, I'm getting just the data logged,
which is the array containing all the information
without the while statement at the beginning.
You can ignore this other error statement down here.
That's irrelevant for our purposes,
just has to do with an icon that the browser is looking for.
So again, because I'm operating from the same origin
as the data source, I'm able to run code to modify it,
and I can get the data out
without being hampered by the error generating statement,
and this should help prevent some malicious uses.