-: XML vulnerabilities.
In this lesson, we're going to talk about XML,
which is the extensible markup language.
This is used by web applications for authentication
and authorizations and for other types
of data exchange and uploading.
Now, here you might hear some people
talk about this as XML vulnerabilities,
XML exploitation, or even XML injection.
Now, technically, XML injection isn't really accurate.
It's more of an XML parsing vulnerability
that people are exploiting.
But on the exam, you may see it called
any of those three things.
Now, when we talk about XML data,
the XML data itself has to be submitted
from you to the server or from one server to another.
And so, when you're dealing with XML data,
you want to make sure that it's submitted
with encryption or input validation.
If you submit XML data without encryption
or without input validation,
it's going to be vulnerable to spoofing,
request forgery, and injection of arbitrary code.
So, we want to make sure we prevent that.
Again, input validation is here to help,
and so is encryption.
Now, when you look at XML, it looks something like this.
This is a basic XML that I set up
just to show you the example of it.
You'll notice the first line here.
It has XML listed right in there.
What version of XML and what type of encoding we're using.
The second line, this is what we're defining.
We're defining a question in this case.
And then we have a couple of different fields
inside this question type.
For instance, I have the ID.
In this case, I'm identifying it as CYSA-002-0001.
It's the first question in the second version
of the CySA+ exam.
Then I have a title.
Is this an XML vulnerability?
And then I have a choice.
Yes, and a second choice, no.
You can define these with any kind of terms you want.
This is just how I define the structure for my question.
Because maybe I have a quiz app
and it's going to read this information
and display it to the screen
so you can get different questions
while you're practicing for your CySA+ exam.
And then you'll see they all,
just like HTML, have the slash at the end of them,
closing out those brackets and closing out the XML.
If you see something like this,
I want you to recognize it as XML code.
Now, the next thing we're going to talk about
is some of the exploits that we can have with XML.
Now, the first one we're going to talk about
is an XML bomb or a billion laughs attack.
Now, this is where they take XML
and they use this encoding to encode those entities
that I just showed you and expand them to exponential sizes,
consuming memory on the host and potentially crashing it.
So, what does this sound like to you?
Well, it sounds like a bomb or a denial-of-service attack.
If I can go forward and I can start consuming
all these resources on your web server
by uploading some kind of bad XML file,
I can take you down.
And that's what we're trying to do with an XML bomb.
Now, the next one we're going to talk about is an XML
external entity or XXE.
Now, this is an attack that embeds a request
for a local resource.
Hmm, this sounds kind of like a file inclusion, doesn't it?
Well, let's take a look at what this looks like.
Well, if we have something like XML,
it's going to look like this.
And we're going to have xml,
the version, and the encoding type.
Then we have the document type.
We're defining this as foo,
which is just code or speak for some junk variable.
Then, we have the element foo any,
we have the entity xxe system,
and then we have that file,
file:///etc/shadow, and then we end this out
with some kind of data type in XML,
in this case, we're calling it foo
instead of question, or title, or ID.
So, what really are we looking for in here
that's really looking bad?
Well, that etc shadow file, right?
By looking at that file:///etc/shadow,
that tells me they're trying to do a file inclusion.
And because we're doing it through XML,
this is known as an XML external entity
or XXE type of attack.
Now, to prevent XML vulnerabilities from being exploited,
what do you think you want to do?
You want to use proper input validation, that's right.
Input validation, input validation, input validation.
We keep talking about it, but it's really that important.
Are we sensing a theme here?
If we validate the input from a user,
whether it's a URL being inputted,
a file being inputted,
a field being entered on a website,
we can prevent a lot of these security issues.
So always remember, input validation,
anytime the user is giving you something
and that'll help prevent a lot of these different attacks.
Now, for the exam,
if you see something with XML written in it,
and it is clearly XML, guess what?
It's going to be an XML vulnerability that's being exploited.
They might call this XML vulnerability.
They might call it XML exploitation.
They might call it XML injection.
Whatever they're talking about,
it's still an XML vulnerability that's being exploited here.
Now, if you see anything that looks like the code
in the format that I showed you in this lesson, guess what?
It's probably XML.
Now, the only tricky part with this
is that XML code can often look a lot like HTML code,
or it might look like JavaScript.
The big difference is that when you're dealing with HTML
or JavaScript, there are defined keywords
for each of those bracketed entries.
With XML, you can make those say anything you want,
depending on how you're configuring your XML.
So, just take a second to read the code and identify,
does this look like HTML?
Are they using something like font
or image or href, that's HTML.
If they're using something like question,
or ID, or type, or element, or entity, that's XML.
And so, this will help you figure out
which one they're referring to,
so you can get the right answer.