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.