---
title: "Bill Sempf  -- Insecure Deserialization"
url: https://appsecpodcast.com/bill-sempf-insecure-deserialization/
date: 2018-02-02
duration_seconds: 2046
guests: ["Bill Sempf"]
topics: ["OWASP Top 10", "Vulnerabilities and Exploits"]
audio: https://www.buzzsprout.com/1730684/episodes/8122698-bill-sempf-insecure-deserialization.mp3
transcript: true
---

# Bill Sempf  -- Insecure Deserialization

*February 2, 2018 · 34 min*

with [Bill Sempf](https://appsecpodcast.com/guests/bill-sempf/)

on [OWASP Top 10](https://appsecpodcast.com/topics/owasp-top-10/), [Vulnerabilities and Exploits](https://appsecpodcast.com/topics/vulnerabilities/)

[Audio](https://www.buzzsprout.com/1730684/episodes/8122698-bill-sempf-insecure-deserialization.mp3)

## Show notes

What happens when data arriving at an application is allowed to recreate objects and trigger unexpected behavior? Bill Sempf joins Chris and Robert to unpack insecure deserialization, a new category in the 2017 OWASP Top 10. He explains serialization through familiar programming examples and describes the research questions that drew him into the topic. The conversation follows attacks across language ecosystems, discusses the possible impact of accepting untrusted serialized objects, and considers ways to reduce exposure. Bill also shares how an assessor might recognize serialized data, investigate application behavior, and use an intercepting proxy during testing. Alongside his work in the .NET security community, this archive conversation captures practitioners working through a difficult vulnerability class and debating the limits of their tools and assumptions.

The Application Security Podcast is brought to you by [Security Journey](https://www.securityjourney.com/).

About Security Journey  
Security Journey provides application security education for developers and everyone in the software development lifecycle.  
→ [Learn more about Security Journey](https://www.securityjourney.com/)

Connect with Bill Sempf:  
→ [Bill Sempf’s developer profile](https://stackoverflow.com/users/467274/bill-sempf)

Mentioned in this episode:  
→ [OWASP Top 10 project repository](https://github.com/OWASP/Top10)  
→ [ZAP](https://www.zaproxy.org/)  
→ [Burp Suite](https://portswigger.net/burp)

Chapters:  
00:00 Insecure deserialization with Bill Sempf  
01:14 Bill’s security origin story  
06:54 Filling gaps in .NET security guidance  
08:05 Why deserialization entered the 2017 Top 10  
10:48 Researching examples across platforms  
12:22 Serialization and deserialization explained  
15:54 The impact of malicious serialized objects  
17:35 Reducing deserialization risk  
23:09 ViewState and framework considerations  
24:37 Debating .NET and language-specific behavior  
27:29 Recognizing serialized data during an assessment  
28:53 Investigating with intercepting proxies  
30:31 What testing tools can find

## Transcript

*5,315 words · assemblyai*

**0:00 Chris Romeo:** Hey folks, on this episode of the Application Security Podcast, Robert and I speak with Bill Sempf on the topic of insecure deserialization. We really break down this new item, A8, on the OWASP Top 10 and provide you with a lot of context and a lot of deep technical ideas and concepts about how do you find vulnerabilities and specifically things with .NET. Hope you enjoy. The Application Security Podcast.

**0:34 Bill Sempf:** Here we go.

**0:36 Robert Hurlbut:** Hello friends, and welcome to another episode of the AppSec Podcast. This is our episode 3 of season 3, and Chris and I are here today with Bill Sempf, who is joining us. Welcome, Bill.

**1:12 Bill Sempf:** Hey, thank you a lot for having me on.

**1:14 Robert Hurlbut:** So when we have somebody on, usually what we do is we start out with asking their security origin story. So could you tell us that?

**1:24 Bill Sempf:** Certainly. So, I'm old. I've been coding for so long that one of my first significant projects for pay anyway was helping to translate the library system at Ohio State University from GopherScript to web back in '93. So, I've been at this for a very, very long time.

**1:48 Robert Hurlbut:** In '90—

**1:51 Bill Sempf:** I think it was, an application that I had written was taken over via a SQL injection vulnerability that I had written. And I got a page on a Saturday afternoon from the server saying the hard drive was full and went over to the hosting. This is back in the day when little hosting companies still existed, right? This is pre-cloud and all that. I went over to the guy's place that was hosting for me. We logged into the terminal and it was completely full of junk. That had been uploaded by spammers. And we couldn't— so they installed an FTP server on it and the whole deal. We couldn't figure out how it happened. Well, after a long time of basically doing forensics, which I didn't know anything about at the time at all, I figured out that they had exploited a SQL injection vulnerability on this application that I'd written. And it just fascinated me because I didn't even realize that application security was a thing. I thought, like many developers, many people do, I thought that, you know, there's Blinky light boxes that fix that problem, right? And the deeper I went, the more I was just amazed by how much there was. And keep in mind, this was effectively pre-OASP. I think OASP might have been— might have actually technically started, but certainly didn't have any traction back then. So I was doing a lot of this research completely on my own at the time. I didn't know anybody who knew anything about application security or anything. And I was, you know, following along on the DEF CON forums and stuff like that to try to get some idea of what other flaws there were that applications were leaving open. And it just went from there. So I ended up from then on pretty much always being the You know, that security guy on the dev team with air quotes. You can't see me, but I'm doing the air quotes. And that's eventually one day, it just led to me moving into the vulnerability analysis space. A little help from Jim Manico and his friends. I got, you know, sometimes you get a little burned out on, you get on a coding project, burns you out a little bit. You're like, all right, I gotta go do something else for a little while, some architecture or something. Well, I said I got hooked up with a company out of California that needed some testing done. I was like, well, I know how to do this. And now here I am. It's been, what, 7 years now? And I'm pretty much full-time vulnerability analysis.

**4:17 Robert Hurlbut:** Okay. So yeah, I think we have some similar backgrounds in terms of longtime development, lots of different platforms and things like that. But, you know, finding security and And understanding about application security. Yeah, same similar thing. I thought, oh, you know, some of that stuff is already taken care of, but, you know, realizing, no, you need to think about this stuff and certainly, you know, moved into that direction.

**4:42 Chris Romeo:** So certainly, Robert, makes us— listening to Bill's story here about kind of where you've come from and how you got into this, it certainly makes me realize how lucky we are now with all the resources that OWASP has available for for us to use. Just, Bill, hearing your story about, you know, you're trying to figure out SQL injection and understand it, and I'm thinking through the lens like, but wait, he can't just open the OWASP Top 10 and read the SQL injection section.

**5:09 Bill Sempf:** Funny story, my first vulnerability analysis was in 2002 against a pre-WSF, so an AS/IMIX web service that was being used as single sign-on. My main tool was, and Robert, you'll like this at least, was FxCop. I wrote a bunch of tools for FxCop to find SQL concatenation and other things. It's the first, not the first, I'm sure, but my first static code analysis toolset. I remember for that report, I turned in, oh, what, like a 3-inch binder. It was something like 390 pages of evidence.

**5:50 Robert Hurlbut:** Oh, fun.

**5:53 Bill Sempf:** Because I didn't know what a vulnerability— nobody really knew what a vulnerability analysis would look like. But of course, I've now honed my toolset and my reporting a little bit, so it's a little bit less overwhelming. But it was very hard in the beginning to get the information you needed, and there wasn't a common place to go and disseminate information, and nobody had the voice. And honestly, back then, the few places that did, they weren't terribly trustworthy. I mean, people would say things that were wrong all the time, and there wasn't any common voice of the crowd to help adjust the story to more accuracy, which we fortunately now largely have. Of course, there's still problems here and there, but largely we've solved that problem, so it's a good thing.

**6:42 Robert Hurlbut:** Yeah, we have definitely come a long ways, which is great. And if I remember correctly, you were also helping with one of the projects with OWASP, or a few of the projects, and one in particular I think was the .NET project, if I remember correctly.

**6:54 Bill Sempf:** That's right. I'm supposedly the wrangler for the .NET project. I need to go shake some trees right now, but our goal of the .NET project is to fill in all the gaps that are left from Microsoft's admittedly very good security documentation. A couple of the ones that I pick on are like the cross-site request forgery handling inside of .NET. MVC handles it, it's built in, but you have to turn it on and There's very few pieces of documentation on how to do that or even recommendations to do that. We have some articles about that and making that easier. If you do have to store your own passwords, PBKDF2 is a great hashing— it's not really a hashing algorithm, but a great system to do that with, to handle your passwords. It's built into the .NET Framework, it's just called something different. So we have an article about that. That's the general goal, is just very actionable guidance and code samples to help you write more secure .NET code, which is already very secure. But, you know, hey, let's make it better, right?

**8:05 Robert Hurlbut:** Right, absolutely. Okay. Well, I want to take a little bit of a shift into the OWASP Top 10. We covered that quite a bit last year, and we haven't actually dived into a few of the things in the new 2017, especially any technical changes. There's one in particular that you've been looking at recently. Is that right?

**8:25 Bill Sempf:** That's right. So I have a— as I'm sure everybody who does training, I have a presentation on, hey, what's changed in the OWASP Top 10, you know? And there's some significant wording changes in the description of the individual pieces, but there's 3 new items and one One item that's been modified. One of the items that was added based on community input was insecure deserialization, which I thought was very interesting reading it when it came out. I was very glad to see the revised top 10, which I'm sure your listeners all know the story behind that if you talked about it last year. I'm glad they made the changes they made. I was always very concerned with the amount of static analysis data that went into the top 10 creation. But I was very curious to see the deserialization piece in there because to me, that just meant the Java bug that was out there in all the WebLogic and JBoss and WebSphere and all those things that was really specific and frankly, for a very long time, relatively hard to exploit, though somebody did write, of course, in 2015, a very good exploit for it that made anyone who's in a Java shop at all stand up and look very quickly, right? And of course, you know, 2016 was declared the year of holy cow.

**10:06 Robert Hurlbut:** I think it was the Java deserialization apocalypse or something like that.

**10:10 Bill Sempf:** Yes, there we go. That's the phrase, yes. And it was, And I know for several of my clients, I mean, my only recommendation to them was to write it out of the code. I mean, there just wasn't any good way to fix it. And it was a big deal, but it was one bug. And I thought, that's unusual. The OWASP Top 10 is about categories of bugs, right? Injection, you know, the big sweeping things. One of the other things is insufficient logging. That's not a bug, that's an idea.

**10:47 Robert Hurlbut:** It is.

**10:48 Bill Sempf:** I thought, well, why did they do that? Well, the first time I got to give my OWASP Top 10 talk was for our local .NET developers group last month. I thought, oh, I'm going to write some .NET samples for this. I thought, hey, I'm going to figure out what you can do in .NET with deserialization. I knew that there was going to be some things. I reached out to Barry Dorrans, who's one of the advisors for the .NET Security Project, and he's the security god for ASP.NET MVC.

**11:28 Robert Hurlbut:** Right.

**11:29 Bill Sempf:** I said, hey, you have any samples for this? He goes, I don't. I don't think you can find anything. You know what? He was right. I tried to basically replicate the Java bug, not exactly, but with me controlling both sides. I purposefully wrote insecure code and then tried to do binary object deserialization and cause anything, even just a bad error on a website, and I was completely incapable of doing any of it. I went and researched what other people had come up with. Every example out there that I found has been squashed by the .NET Framework. I was very pleased by— I mean, I was bummed because I like to show examples, but I was pleased by how secure it was. But what I learned doing all this is there's way more to deserialization flaws than just object deserialization.

**12:22 Chris Romeo:** Hey, Bill, maybe we can take a step back here just for some of our listeners are going to be you know, maybe newer developers, newer to the security world. And maybe can you give us a definition when we're talking about insecure deserialization? Maybe start with deserialization and then add the insecure part on top.

**12:40 Bill Sempf:** So I'm going to ask both of you for help then, because I'm not certain I can do a good job of describing exactly how it works. This is one of the reasons why I took this on as a research project is because I felt rather weak in it. But basically, if you have a— you instantiate an object in your code, and you need to move it over a network in such a way that you need to turn into a string so that you can move it and store it someplace in a cookie or move it as part of a web service call. These frameworks all provide serialization and deserialization APIs that allow you to do that. Basically takes the binary gobbledygook and turns it into more or less ASCII. I mean, there's other bits to it so that you can move them from place to place. Well, yeah. Would you say that's a pretty reasonable description?

**13:35 Robert Hurlbut:** Yeah, definitely. And exactly what you just said, you can't send the binary object. It doesn't make sense, but you can turn it into something that will, that you can put into some kind of a stream or something like that and send it over, as you said, over the network. And then on the other side, when you receive that, Then you reconstruct it into an object, you know, by— so serialize and deserialize it in order to put it back into the binary object so you can then use it in the code on the other side.

**14:04 Bill Sempf:** Exactly. And in the pre-web service era, we had all kinds of tricky ways to move binary bits around, like the old Microsoft people remember DCOM. There's an open source one called CORBA. If I remember correctly. Oh, yeah, right. It would move binaries from place to place. But we kind of figured out over time that serialization is a good way to solve this problem. Well, anytime you have a rendering engine of any kind, the possibility to inject your own instructions into the input as an attacker exists. So that's what happens For instance, when we make a JavaScript renderer processor fail in a browser with cross-site scripting, right?

**14:52 Robert Hurlbut:** Right.

**14:53 Bill Sempf:** We are injecting our own code. We have caused the processing engine in the browser to render, process our code as an attacker instead of the developer's code, or maybe in addition to the developer's code. More or less, that's what insecure deserialization is. It's a way to force the deserialization engine, so the receiving side, to process instructions that the attacker has put in instead of instructions that the developer has put in.

**15:30 Robert Hurlbut:** Right. And so essentially, what then happens is you can potentially make it become a remote code execution processor for you. So you can do things as if you were on that server. You can call out to other services and other kinds of things as if you were creating a shell or something to that server. You can instead use this object to do that for you.

**15:54 Bill Sempf:** Right. So it can be an extreme— I mean, the Java bug that we started by talking about, it was an extremely serious attack. An attacker could find a serialized object, deserialize it using the JVM, inject your own instructions, re-serialize it, and just let it continue on its merry way. And then the backend processor would do whatever instructions I sent it instead of what the developer intended. Some of those, depending upon your development patterns, that could be disastrous. I could, like Robert said, completely take over the server doing that. That's basically the reason that it's in here is because it's very like injection, it's very serious. SQL injection isn't as common anymore because we're all using data frameworks to do our data work instead of writing our stored procedures by hand. But it's still an extremely serious vulnerability, which is why it's still A1. And it is still out there, it's just not quite as common as it used to be. And the same thing is true of this. It's not as— something like 8% of the total collection of findings that they analyzed to make the top 10 were deserialization findings, which isn't a lot, but it's still plenty. And considering the end result is I get to own your server, yeah, that's a big deal.

**17:35 Robert Hurlbut:** And what are some things to do to protect against it, prevent it, protect against it?

**17:42 Bill Sempf:** So that's a really interesting question, and I'm going to double back for just a minute to a little bit more, a little bit, one other piece of my analysis is all the other weird deserialization pieces that I ran into. For instance, If you're, for instance, an Apache MyFaces developer, or if you've written ASP.NET Web Forms apps, not MVC, but Web Forms, and dealt with the ViewState, that ViewState is really just an encoded block that is a data format specific to whatever platform it is, and it can just be literally deserialized. It's really just encoded. But effectively, you can deserialize it, edit it, and then send it back in. If you're saving important data in that ViewState, there's a potential for it to be used for vulnerabilities. Another great example is super cookies. People will take a block of JSON or some other data structure that's specific to the language you're working in, an array or a list or whatever, serialize it, and save it in a cookie and then retrieve it on POST in order to figure out who sent it because we have to do some kind of— basically using it as a session variable. To the user, it just looks like a bunch of junk. But to the trained eye, you can recognize it as potentially serialized. It's not object serialization, mind you, it's just data serialization, but it still is all you're doing is hiding it. It's almost like bad encryption. That still falls under A8, which I found really interesting. Honestly, I find that bug constantly doing vulnerability analysis. Robert, you asked what to do to fix it. For object serialization, I mean, honestly, so one of my— one of the clients I do a lot of testing for falls under PCI. So they have some special standards. But when this bug came out, we did a bunch of additional testing based on it and discovered that there was a fair amount of vulnerable applications. And there were times when literally the only thing I could recommend is just don't do that. Yeah. I mean, you can attempt to filter incoming requests based on the— especially for the Java bug, there's a pretty well-known signature to the bug, what it looks like after it's serialized. It always looks the same at the beginning. I don't remember this, but there's a series of bytes that it's always the same. It's like RT00 or something, something, something, something. you can add that to your web application firewall and just filter those posts or those requests in general. But man, all that means is that they have to find a different way to write the request. I think that in general, object serialization, it's a really difficult thing to do input validation on. If you've got no choice, then input validation is your only— I mean, you've got to make sure that what you're getting is exactly what you expect. If you can use, for instance, only use primitive data types so that you can cast them once they come back.

**21:32 Robert Hurlbut:** Right.

**21:33 Bill Sempf:** That's the thing. Make sure you're doing really good logging. I mean, it's a tough problem. It's even worse on the data deserialization side because, man, we've got so much old code out there that's dependent on the developers encoding a dataset in .NET and tossing it in a cookie or tossing it in a a hidden input. It's just, I don't know, it's something that people are going to have to look at and it's going to take a while to fix. So I don't have the— I mean, the input validation is the answer, but that's a lot of input validation. So it's not like one of those bugs that's going to be prevalent for something like a huge big splash right this minute. But I think it's going to be the gift that keeps on giving for a long time once the attackers figure out, hey, We can glean secrets from this and chain attacks together. And the only thing we can do is that input validation and really good logging.

**22:42 Robert Hurlbut:** Yeah. In the OWASP Top 10, I noticed a couple other suggestions they mentioned is, well, like you said, the validation, but using digital signatures. So signing the actual objects that basically if somebody tampers with it, changes it, you'll be able to determine that, which I think is good. And then of course strict types and so on.

**23:09 Bill Sempf:** And I want to throw out there too, in .NET 4.6 and up, they finally sorted out the whole encryption of ViewState. So for years, a decade almost, encryption of ViewState was very difficult because you couldn't farm your website. You couldn't have more than one, easily have more than one server running. It was very, very difficult to— it was possible, very difficult to manage the servers if you had more than one frontend web server. But they solved that problem in IIS. So now, not only by default is the view state encrypted, you have to, even if you put in the whatever enableViewStateMac equals false or something, whatever the code was in to put it in there, if it's still somewhere in your web.config or in your main object, body object, it still will encrypt the ViewState. It'll ignore that particular parameter and encrypt the ViewState, which I found very interesting. In fact, I had to roll back my sample code to 4.0 in order to show people what it looked like to be able to take over a ViewState. because of that change. So, if you're up to date, which I realize is hard to do, but if you're up to date, the ViewState has gone from a dangerous place to put your data to a safe place to put your data.

**24:31 Chris Romeo:** Yeah. So, Bill, I wanna kind of poke at something here.

**24:36 Bill Sempf:** Sure.

**24:37 Chris Romeo:** So, before we started, I kind of drew us back into the basics of it, but I'm gonna stoke the fire here a little bit because I think what I heard you say is that Insecure deserialization is very difficult to actually pull off in .NET. And so, I mean, I think that could potentially incite a holy war, but I hope not. But so, I mean, is that kind of what you're saying there? Are you saying that it's not possible or that it's really hard or that— No, no, no.

**25:07 Bill Sempf:** It was beyond my skill as an exploit writer, which I am not, by the way. I'm not a malware developer. That is not my area of expertise. But I wanted to write an example where I control both sides of binary deserialization causing something significant to happen on the server side and even stealing other people's code. I was unable to do it even with older versions of .NET. Now, I only rolled back to 4. I probably could have gone back to 3.5 or 2 or something and found something different, but I was I was unable to get it to work. Now, if you know some secrets, then this is the time. Drop them.

**25:48 Chris Romeo:** No, I don't. I got almost zero secrets, but, yeah, I was just curious. Okay. So, that makes sense. So, Java has certainly been where we've seen the publicity of insecure deserialization, but it sounds like the same type of problems will exist in any object-oriented language It's providing you the opportunity to package up an object and ship it over to some other service somewhere else across the network.

**26:16 Bill Sempf:** Oh, absolutely. In fact, unless I'm mistaken, and I'm sure somebody will fact-check me on this, in even the current version of Python, there are a number— all the most popular deserialization utilities have vulnerabilities in them, like all of them. There's 4 or 5 because when I reached out to my network to say, hey, I want to show some examples, can somebody help me? Everybody replied and said, oh, do this Python one, everybody can do that. That's great. This is a .NET group, I don't want to do Python examples. PHP is famous for it. Python has issues, I didn't even know that. I haven't played with Rails, but Rails does a lot of serialization, deserialization, so I'm figuring that There's possibilities there. This isn't just a Java thing. It's just that Java got the bad rap on this one. They had the big bug. And it wasn't even, if I remember correctly, well, if I understood correctly, it wasn't even the individual frameworks. It was a problem actually in the JVM and the way they'd implemented it, and that required a patch at that level.

**27:21 Chris Romeo:** Yeah.

**27:22 Bill Sempf:** And it fixed everything. So, yeah, I'm not ripping on Java by any stretch of the imagination. They just got the bad rap this time.

**27:28 Chris Romeo:** Yeah.

**27:29 Robert Hurlbut:** Right.

**27:29 Chris Romeo:** So, when you're actually looking for this type of problem as somebody who's doing vulnerability analysis, what is one thing that I could look for? Like, if I'm profiling the application, what's going to be a tell for me that it's doing— that there could be a problem with deserialization? How am I going to see this?

**27:50 Bill Sempf:** Yeah. See, it's not— In my opinion, it's not terribly obvious. But if you go in and you're looking at those big Base64-encoded strings that are just a mess, you know, and it's just a bunch of letters and numbers and nothing, you're thinking, all right, so let's try to decode these a couple different ways. So I've got some scripts to do a lot of different decodings just to see what I get. And then There are certain patterns, certain ASCII patterns when objects are serialized, certain ASCII patterns that fall into the first couple of characters that you can find. If you already know your platform, which is usually fairly obvious because you can look at the extension on the file name or you can look at the code that's coming, the HTML is coming back to you and figure out, all right, is this Is this, you know, Java Server Pages, one of those frameworks? Is this .NET? Is this Rails?

**28:53 Robert Hurlbut:** Is it—

**28:53 Bill Sempf:** what is it? Where's this coming from? You can use that information and the information of those decoded strings and maybe get an idea of what— where some serialized strings would be. And then the only thing you can really do is try and deserialize them, which there are some tools. For instance, if you're using ZAP or Burp Suite, as an intercepting proxy. There are some tools for both of those that will assist you with deserialization, and you can look at the objects. Data serialization is way easier because generally it's just encoded. It's ASCII Base64 or something of that nature. In fact, there's a— in Burp Suite at least, and this might be true of Zap too, there's a ViewState tab that shows up if you're looking at an ASP.NET Web Forms site. And you can just click on the tab and look at the view state as long— well, as long as it's not 4.6 and up. So that's a little bit easier. But the object one is— I mean, I think it's relatively advanced find. And one of the reasons why the Java thing became such a big deal is because it was so— it was— they found a tell. They found that one string that was super easy to search for in cookies or hidden strings or whatever, or in web service calls. And so you can say, oh, this has this ASCII string, so we can just throw it at this prebuilt tool and it will do the attack for us. So they made it a script kiddie project. And that's how— that's why the Java thing became such a big splash.

**30:31 Robert Hurlbut:** One more thing I was going to ask is about— because we're talking about how difficult this may be to find or even to try to duplicate, but what do you think about tools? I know that the OWASP Top 10, usually the SaaS tools, they try to implement a lot of these into their tools and that's how they sell it. I was at AppSec Cali this past week. I know Andrew spoke on the OWASP Top 10 and he mentioned that, you know, out of all the new Top 10, if they say they're doing all the Top 10, Number 10, logging. There's no way they're going to have that in their tool.

**31:06 Bill Sempf:** No, it's very difficult to find that, yeah.

**31:08 Robert Hurlbut:** Right.

**31:09 Bill Sempf:** Unless you find the log files, which does happen occasionally.

**31:11 Robert Hurlbut:** Sure, sure. But, you know, in terms of A8, you know, and finding that, that should be interesting to see that be a part of SAS tools. Interesting to see how they try to think about how they could implement that or put that in place.

**31:25 Bill Sempf:** Yeah, I'm not sure. I guess it's possible. Like I said, I've got some decoding scripts, I've got some lists of those little string things at the beginning, what a .NET serialized object looks like, what a Java serialized object looks like. You could build that into a static analysis tool and that would be possible, but certainly it will not be an easy attack. It won't be an easy vulnerability to discover automatically.

**31:58 Robert Hurlbut:** Right.

**31:59 Bill Sempf:** And it's, in my opinion, it's very difficult to find manually as well, especially on the object side. Data side is a little easier. But once again, on the data side, it requires that human insight. It's not something that automated testing is going to do a good job of finding. It may figure out that this string is just, you know, Base64 encoded twice and And it's got some data, but whether or not the data is important, only a human will know that.

**32:25 Chris Romeo:** Very cool.

**32:27 Robert Hurlbut:** Well, yeah, definitely. I think, you know, again, just making sure developers know about this, understand about the implications, I think is also very, very key as well. Yeah.

**32:38 Chris Romeo:** And Bill, I got to tell you this. It's honesty time for me. You basically— I never understood what CORBA was. Oh, I can admit that. You know what? I don't know everything. I don't know, you know, I've been doing this for 20 years and there's still a lot of things I don't know. Until I—

**32:54 Bill Sempf:** you just wrote my entire bio right there. Every single day.

**32:59 Chris Romeo:** Until I saw it. I never— I heard of CORBA many times in the past and I never really understood it was basically doing what serialization and deserialization is doing. So thank you for that. And thank you for your time on this. This is great. This is This is— I know it's helped me a lot to understand deserialization better, and we definitely thank you for being here with us.

**33:17 Bill Sempf:** Hey, I'm glad I could share. It was a fun research project, and I'm glad I can get a little bit of— I mean, I don't have a ton on it, but what I've got, I'm glad to be able to get it out there.

**33:27 Robert Hurlbut:** I appreciate it. Thank you, Bill.

**33:29 Bill Sempf:** Thank you. 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.

---

Source: https://appsecpodcast.com/bill-sempf-insecure-deserialization/