Hey, welcome back. In our previous lesson,
we left off with a challenge for you to
try to exploit a REST framework.
In this lesson, I will show you
how I would approach such a thing.
I will also address the misconception
that if we're sending
our data through a JSON or some rest API,
we're safe from this type of attack.
I will show you an example of
a blind XXE or XML injection.
Where you, as the attacker,
don't have the visual feedback to
see if your attack is succeeding.
I will demonstrate how to
patch this kind of vulnerability,
and how to protect against XML injections.
I will also address strategies to
mitigate XXE attacks in a complex situation.
After this lesson, you'll be able to
craft the way to infer the success of an attack.
Patching XML injection vulnerabilities,
better draw similarities between
types of injection attacks.
Then, at the end of
the lesson I'll pause and give
you a chance to give it a try.
Let's do it. So hopefully you get
a chance to exploit it using the REST framework.
I'm going to submit another test just to get
a new burp up top.
I'm just going to send this post to
the repeater right away. So this was our tests.
The misleading thing here is,
just because this is application JSON,
or not, the framework is going to protect
us because it's only going to accept JSON objects.
Meaning, just like when we're playing
before with our various data types.
When this XML is converted to JSON like this,
it loses any of those entity references.
So the misconception here is
that if we're sending our data through JSON,
we're safe from this type of attack,
because a framework is protecting us.
Well. That's not necessarily true,
because as within our proxy
we can change the data type to XML.
If the framework isn't
configured properly to protect against this,
this would absolutely be let through.
In fact, the same payload that we used the first time,
can replace our new payload,
entirely with no modifications.
If we hit Go,
you'll get a true lesson completed because you have
successfully listed all of the files,
in the file system at the root.
So if I refresh again,
you'll notice that it's the same files that we had,
and it's all the way down to the user root.
Just like last time,
we can modify our payload to open up a file
under Users, Joubin, Desktop, example.txt.
Now, in the last video we
showed how an attacker could gain this information.
But since we already have that information,
I'm just going to paste it in for us, and hit Go.
Whoops. If I refresh,
you'll see the secret content
that no one should be able to read.
So that's an example of how this all
could be misused and misplaced.
Module 7, feel free to use it and play with it.
This is about doing blind XXE.
Meaning if you have
no view into the feedback that comes out.
Currently, our comments are being displayed right here.
But what if the XML that you posted wasn't being parsed,
and the data wasn't being returned to
some common or blog.
What if it was something that you
couldn't see the effects of.
From there, you could use pinging
or other facility that are built into
the OS to get some information about it,
referencing files from different locations.
So feel free to give that one a try.
But we're going to start
patching this and how we can go
about protecting against XXE.
So what are some of the mitigations?
So in reality, to protect against this,
it's pretty easy to start
but as your use case gets more complex,
it gets a little bit harder to defend against it.
So the first thing is we need to make sure that we
validate the input that we're
receiving from an untrusted client.
As we've been able to demonstrate using a proxy,
all clients can modify data.
So it doesn't matter that our web page designed to,
for instance, only send JSON objects.
Our users could modify that in
a proxy and become attackers and attack us.
In the Java world,
we can ask our XML factory to not support DTDs,
and not support custom entities that are like that.
But, sometimes it's hard to not follow through with.
I can give you an example of this.
A realistic example of this.
There are sometimes use cases where you define
a Java class or a Java object using XML or JSON.
You want to convert that JSON into
a Plain Old Java Object.
That's what POJO stands for.
Just a regular Java object that we're familiar seeing.
So here's a test class that
in JSON I'm defining age to be 23.
You could also equally do in an XML.
The name to be that some blog and some message.
If we simply hit Submit on this,
you actually get a POJO
a Plain Old Java Object
from just those few lines that define a class.
The name, the age, the blog parameter fields
are pre-filled in,
and setters and getters are
created based on the object types.
So this is a realistic use case
and why sometimes you may have to allow
for special modifiers and DTDs in your XML object.
So sometimes you may not be able
to completely block that.
But you may be able
to block supporting external entities.
So limiting the user only to
the internal ones will allow for that.
So lastly, we want to make sure that we're
accepting the content types that we truly want to accept.
So in the last example,
we allowed our User to pass us
an application/XML object or
data without us validating it.
We were simply relying on the framework to do it for us.
But if the framework isn't configured properly,
it won't have a chance.
So give it a shot and see if you can
find the code that has to do with this and patch it.
I'll direct you to near where the code is.
So if we go under XXE,
under source, under main, under Java,
and under the plugins,
there's several files that you need
to examine to find
the specific file that you need to patch this.
Go ahead and read through the files
and see where these factories exists,
and how they're configured.
Feel free to put in print statements to see if
a particular AD common function
is really the one you're looking for.
Recompile and rerun,
and go and patch it for your next lab.
Make sure to take screenshots as per the guidelines.
We'll show you the solution in the next video.