Katy Anton -- OWASP Top 10 #4 XXE

0:00Chris RomeoHey folks, this is season 3, episode 6 of the Application Security Podcast. On this episode, we're joined by Katie Anton, who talks to us about XXE, or the new number 4 on the OWASP Top 10 2017. We break down what XXE is, what are the impacts of this vulnerability class. We talk about how to prevent it and how you can use some different tools to find it, as well as some recommendations for how we can deal with this going into the future. We hope you enjoy. The Application Security Podcast. Here we go. Hey folks, welcome to season 3, episode 6, XML External Entities, or XXE. Today we are joined by Katie Anton, and this is Katie's second visit to the Application Security Podcast. Her first visit was in season 2, episode 17, where she joined us to talk about the future of the OWASP proactive controls. And so, Today, she's here to talk about XXE. So we're going to skip our normal security origin story, and we're going to jump right in and ask Katie, hey Katie, what are you working on right now? What projects are you working on? And I know you're a huge contributor in the OWASP universe. So what types of things are you working on right now?

1:42Katy AntonHi, Chris and Robert, and thank you very much for inviting me. So we are working to the final release of the OWASP Top 10. Proactive Controllers project. We are close to it. And also, as I am an OWASP Bristol chapter leader, I am going to be involved into the OWASP AppSecU conference, where my drive would be to actually have as many possible female speakers on the conference. That would be my personal goal. Yeah.

2:20Chris RomeoSo to all our female listeners out there, I think it'd be great to look for some different topics and things that you could submit to AppSecEU. I can tell you as somebody who's been to AppSecEU in the past, actually when it was in Romeo, and it's a great conference and it's just a, especially if you're somebody in the United States, it's a completely different group of people. This group of people at AppSecEU are not making it to AppSec USA or any of the other primary US conferences for the most part. And so I got a chance to meet a whole lot of new people that I never would have met if I had stayed away. So definitely check that out. So Katie, Proactive Controls and AppSecEU, that sounds like a pretty big amount of things that you're working on right now. Anything else that you're kind of looking at or working on?

3:09Katy AntonNo, that is for the time being.

3:12Chris RomeoOkay. You're always keeping up with the OWASP universe, and that's why we invited you here today to talk about this new thing, XXE. And so why don't we start out, Katie, just by telling us what is XXE, what is the significance of it, and what do people need to know?

3:33Katy AntonYeah, so XXE, or XML External Entities, is an interesting one. And the interest is that at the beginning, it was a little bit confusing even among the security professionals as being an injection issue. In fact, in the Release Candidate 1 of the OWASP Top 10 2017, this vulnerability or the CWE-611, Improper Restriction of XML External Entity Reference, was listed under A1 injection. And for this, I think it's good to go back of this, a simple definition of what an injection is. And injection occurs when an application accepts user-supplied data concatenated with some kind of syntax that is then sent to another parser. For example, in the case of SQL injection, the user-supplied input is combined with the SQL command that is sent to the SQL parser, and the parser interprets that input as part of the SQL command. The same for example cross-site scripting. The input is combined when creating the HTML document and when it's sent to the HTML parser, then it's executed as part of an HTML and the tags are being executed and that's when script is triggered, script execution is triggered. However, the XXE is about submitting a perfectly legal XML document that uses Document Type Definitions, or DTD, which among other features enables the definition of XML entities and can refer to external entities. So the vulnerability in this case comes when parsing this syntactically correct XML document through a weakly configured XML parser. And this is what allows to read or overwrite resources you shouldn't do in the first place, like for example accessing files or accessing backend services. So in this case, there is no injection. You are submitting a perfectly legal document, but based on how the XML parser is configured, this is when the A vulnerability can be exploited.

6:07Chris RomeoSo is it primarily— so it's really not— so it sounds like you're saying it's really not an injection attack because— but the XML itself that we're going to submit in an XXE attack, it's going to have some type of— so I guess there's not really a vulnerability there because I've seen some XXE attacks or samples where it'll reference a file, for example, like file /etc/passwd. And so that's that. So you're saying that's actually a legitimate use of XML? It's not violating the actual way XML is supposed to work?

6:45Katy AntonYes, it's just the configuration of the XML parser, because the next thing that you can do in order to stop this vulnerability being exploited is to configure the XML parser to not parse those external entities. And this is the primary remediation. But in the case of this vulnerability, the configuration must be done in the software. And depending on the language you use, then you'll have different syntaxes for this type of vulnerability.

7:21Chris RomeoSo is this a software— is this an age problem, meaning that it's only— are only older XML parsers and processors vulnerable to this, or is a Is a version of an XML parser that was released in the last month, is it still going to have this problem because it's a fundamental issue?

7:43Katy AntonI think it's an awareness problem, first of all. So, in the case of Java, you need to write a piece of code to actually forbid parsing external entities. In the case of .NET though, especially in the latest frameworks, what they've done there, they actually have by default this parsing is disabled. So, starting with frameworks like 4.6, by default this is not possible anymore. So, you need to actually go into the configuration and change it to parse external entities, but by default you would not be able to do this one. In the Java, you actually need to do it. So, by default, it is enabled and you have to actually put in the code the few lines of code in order to disable this one. And when it comes to actually what are those specific lines of code, the best source out there, resource for the languages available, is the OWASP XXE Prevention Cheat Sheet. So it's absolutely fantastic, that document, because it actually goes to the level of language, in the case of .NET, the versions of frameworks, and very, very low-level guidance on what you need to do for this type of vulnerability.

9:04Robert HurlbutSo I'm thinking about when you're talking about how an application or service or something like that is waiting for an XML input and then processing it. I'm thinking about, like, for example, web services, which deal with a lot of XML SOAP messages and so forth. I notice in the top 10 it suggests or recommends SOAP 1.2 and higher, but even there where you're doing that every day, you're processing XML messages every day, even there you need to think about which version you're using to address this issue.

9:38Katy AntonYes, definitely, definitely. That will need to be taken into account, yes.

9:46Chris RomeoSo what are the bad things that can happen then as a result of an XXE attack? Is there other specific things that we should be scared about if we have an XXE vulnerability? Like I know with SQL injection, it's always clear, everybody always understands like SQL injection means somebody could ultimately with the proper SQL commands through your application download all your data. What's the big scare? With XXE?

10:15Katy AntonIt can access files that it shouldn't access. Like, for example, on a Linux machine, it's the /etc/passwd, just an example. But I think probably the most, how to say, scary one is allowing command execution. So for whatever reason, if you access or access services that you can trigger command execution, then that can be probably a more devastating consequence.

10:42Chris RomeoAnd then what about, I've also heard that denial of service, there's denial of service conditions that can stem from the XXE-style attack. What types of things could go wrong in the denial of service realm?

10:56Katy AntonSo, in that Billion Laughs attack, yes, where you actually can create an XML document where you have external entities that call other external entities and it goes on loop. Ah, so it's a loop. Yeah, so that would be, how to say, a well-known type of attack.

11:20Chris RomeoSo in the Billion Laughs attack then, it goes into a loop and it just, every time it loops through, it uses additional resources on the localhost. until it just runs out of resources?

11:36Katy AntonYes. Okay.

11:38Chris RomeoYeah, that certainly sounds scary. So, how do we find these things then? What are the— are there particular tools and techniques we can use? Do we have to find them using manual code reviews? Or what do you recommend for people, Katie?

11:55Katy AntonWell, probably the best one is SAST tools because it can be detected in the source code. Whenever you load an XML, which would be calling a load XML function depending on your language, then that's when you can look into how that parser is configured. So probably the best one is SASTooth because they will be more efficient in terms of coverage and time.

12:24Chris RomeoAnd is that just because the XML processing is just so clear? Because, you know, you always hear about SAST and false positives, and that's always the big concern. Is the, is the searching for XXE vulnerabilities, does that have a low false positive rate or a high false positive rate?

12:43Katy AntonI would expect to have a low false positive rate apart from the case of certain frameworks where the configuration would be separate at the framework level. And that's when something that the scanner, an automated tool, would not find it easy. But For the majority of languages out there or frameworks, it shouldn't involve bringing a high number of false positives. Okay.

13:14Chris RomeoSo I'm looking at the OWASP Top 10 2017, the page for A4 here, and I'm looking at a couple of different things they recommend for how to prevent. So obviously they talk about developer training, which is always going to be crucial for any of the items in the Top 10. And the first one they list specifically is use less complex data formats such as JSON. How does JSON help me? So JSON isn't— there is no type of vulnerability in this class that would impact JSON as well?

13:47Katy AntonThere would be less type of vulnerability. So when it comes to the XML, we have to actually ensure the correct format. which we need to ensure also in the XML, but we don't have any other things that we need to look. While in the case of XML, we also need to actually check the XML configuration. So, from a security point of view, if you have a choice, then JSON is the preferred format.

14:17Chris RomeoWhy is that? Why do we want— why would somebody want to use JSON over XML? What are the security benefits of JSON?

14:28Katy AntonSo, it would be the configuration, which is required for the XML parser. And generally parsing an XML is a little bit more difficult.

14:40Robert HurlbutSo, it sounds like it comes out to complexity, right? So, with the XML, the XML parsers, the DTD, and trying to make sure that you have a good format for XML and so on. All those kinds of things can be very complex, and you do a lot of complex things with XML, whereas JSON, as I understand it, can be a lot more simpler. You yourself can determine what's inside the JSON without executing it necessarily, whereas the XML parsers themselves typically execute— and that's part of what the problem is here— can potentially execute things that it finds in the XML while doing the parsing. And so that seems to be the difference between the two.

15:21Chris RomeoSo JSON doesn't have any— I can't actually execute commands and stuff from within a JSON request?

15:28Katy AntonNot if it is correctly parsed. So in the case of LCML, you also have other vulnerabilities like, for example, XPath injection depending on how it is. So it's a little bit more complex document like Robert said. So you can lead into vulnerabilities of XPath injection, XML injection if the schema is not valid. So these would be a few that I can think of.

15:52Chris RomeoOkay. And they— the top 10 also lists, of course, input validation, which is good advice for anything. Anything anybody's building should always have proper whitelisting and server-side input validation. In this case, you could be trying to check some of the XML things. I almost come to the thought of when we're talking about prevention here, should we just tell people to not use XML anymore? Like, why do we even need XML anymore? Because XML seems like it's old and JSON seems to be so much better and more robust. Why isn't XML just going to go away on its own?

16:35Katy AntonProbably this would be a little bit a matter of time. Currently, there are SOAP services where you have this format, although a service should present alternative formats as well. The benefit of using JSON is that more and more frameworks, in particular client-side frameworks like Angular, are already designed for JSON. Probably in time we can see, and with this introduction of the XXE into top 10, we can see a move towards less XML and more JSON. But as it is at the moment, which is the first year since this vulnerability has been added to the top 10, it's just a matter to see of how many are out there and how people think of actually moving towards JSON.

17:32Chris RomeoSo XML is still used then in a lot of different use cases across the board.

17:37Katy AntonYes, there are still cases for them, yes.

17:40Robert HurlbutBlogs, for example, a lot of blogs, WordPress and so forth, still send XML for blog posts, and so therefore, yeah, it's still going to be there for a while, unfortunately.

17:52Chris RomeoYeah, I guess with like a lot of things in the top 10, it would be— we could make the problem go away easily if we could just squash an entire segment of technology like XML and just say you can't use it anymore. But in the real world, that's not gonna be possible because even if, say, WordPress got rid of it today, there's still gonna be legacy deployments, legacy applications, and things are gonna exist for 10, 20 years in the future. So I guess unfortunately, XXE is not going away anytime soon is what I'm hearing. Yeah.

18:27Katy AntonYeah, I think it would be interesting to see how the trend over the years will be around this one. So according to the OWASP Top 10 team, there has been a trend slightly increasing on this vulnerability, on the, in particular, the CWE-611. So I think it would be interesting to see now after this one has been published and more and more people learn about it, how do they think it's going to look in a year or a few years' time?

18:57Chris RomeoSo, Katie, if you were gonna— so how would you approach, say, like a development team, if you're working with a development team, how would you approach preparing them to deal with this particular issue of XXE?

19:12Katy AntonSo from my experience, first of all, there is not awareness. So the majority of development teams that I have interacted, they have not heard of XXE before, before this document was launched. So the first one was to actually explain what this vulnerability is all about. The next one was if they are aware that their application actually needs external entities, which in majority of cases it does not, or they were not aware. So just investigating what their XML functionality was for. And that's when we would work towards hardening the XML parser. And in some cases, depending on the nature of the application or the coverage, so I had a case where a team was using, it was an R project, and they had in one part JSON, in another one only one occurrence of XML. So, in that case, because of the nature of that project, my suggestion was to bring it slowly towards JSON, just because it would make sense to actually consolidate towards JSON slowly for the future.

20:27Chris RomeoSo, that's your recommendation then for everybody is to try and consolidate towards JSON in the future, try to eliminate your your need for XML in your applications. Is that how you would recommend for people?

20:44Katy AntonDepends on the application. If it's a big one that uses already massively XML, I would not ask them to rewrite it. The first thing is to actually harden the parser. But if there is something that they either has a low occurrence of XML files processed, then, and there is another way to achieve the same thing, then yes. That would be the next approach.

21:07Chris RomeoSo when you say harden the parser from an XML perspective, what does that actually mean?

21:12Katy AntonTo configure in the software to not process external entities. So to actually, in the case that, let's say, so most of the time the software accepts this XML from outside. So if somebody submits an XML that contains these document type definition tags, then the parser should not parse in particular those. Okay.

21:41Chris RomeoAnd so that's— so there's basically a twofold recommendation approach that I'm taking away here that I think our listeners that are dealing with XXE and trying to understand it, the harden the parser is really your first step. And then the second step is to, from an application design perspective over time, look for ways to move away from XML. and move more into using JSON that doesn't have this ability for somebody to submit a document that has some type of command that's going to execute. So is that kind of— is that a good summary of kind of what you would recommend for folks?

22:17Katy AntonYes, but however, as we always know, the security is not that simple. So also when it comes to JSON, the other thing that I usually say is to use to manipulate JSON objects to use a well-known library that hasn't any known vulnerabilities. Because if the library that they are using has vulnerabilities, then we can get into deserialization issues. So it's also important when they use that one to use a well-known library and never ever to actually manually create Yeah, I think that's good advice as well.

23:02Chris RomeoIf you have a framework, use the framework, because the framework's been battle-tested, it's been code-reviewed, it's been through lots of different challenges. Whereas, if you try to write your own parser for anything, you always seem to be getting in trouble if you're ever writing your own parser to do kind of any type of parsing.

23:21Katy AntonRight. Yes.

23:22Chris RomeoAll right, Katie, well, thank you for taking the time today to explain XXE and, and helping us to continue in our series of understanding the new items that exist in the OWASP Top 10 2017 edition. So we thank you very much for your time and look forward to seeing you at a conference here soon.

23:42Katy AntonThank you very much. Thanks for your time as well, both Chris and Robert. Thanks for listening to the Application Security Podcast. If you enjoy the podcast, please do us a favor and visit the iTunes Store and give us a 5-star rating. Our intro music is 8-Bit Kung Fu by Born and TJ, and the outro is Southern Delight by Stefan Cartenberg. You can find us on Twitter @appsecpodcast or on the web at www.appsecpodcast.org.