Jim Manico -- The Extremely Unabridged History of SQLi and XSS

0:00Chris RomeoLadies and gentlemen, you are in for a treat this week on season 4, episode 19 of the Application Security Podcast. What you're about to hear is an interview I did with Jim Manico out at AppSecUSA. This is Jim's, I think, 4th time appearing on the show here, and we went on a bit of a journey through the history of cross-site scripting and SQL injection. And I can tell you this, if anything, you will be entertained. and you will learn something about AppSec. So we hope you enjoy. The Application Security Podcast. Here we go. Hey folks, welcome to this episode of the AppSec Podcast. We are coming to you from the AppSec USA conference in San Jose, California. It's pretty exciting that AppSec has come here right into Silicon Valley, and I'm joined by somebody who has been with us on the show a number of times before, Jim Manico. And so Jim, thank you for being here once again to share your OWASP wisdom with us.

1:25Jim ManicoHow are you doing today, Chris? How's it going?

1:26Chris RomeoI can't complain. And even if I did, nobody would listen.

1:29Jim ManicoWell, I hear that. And Chris, thank you for having me on the show. Complaints or not, I'm glad to be here.

1:33Chris RomeoYeah, it's definitely always great to have you here. And so the question that I want us to be able to ponder actually came to us from Twitter from somebody who's a follower of the podcast. And the question that he asked I thought was pretty interesting. How has AppSec changed over the years? And so it certainly got me thinking about, I've been involved in security for about 22 or 23 years at this point, but only AppSec for maybe the last 10. So I don't even know that I go back far enough in security to really even talk about it, but I know you've been around this for a long time. And so kind of what's your perspective there on AppSec over the years?

2:14Jim ManicoSo this is a question from my friend, John McCoy, right? This is Mr. McCoy asking this. So John's asking about the history of like, security over the years. And what do I do? I do AppSec. You know, I'm a software engineer turned into a security person, I guess. I like to still think I'm a software engineer. My latest code, I'm very proud of this. I want to learn Python, so I wrote a Caesar cipher cracker in Python. It's like 10 lines of code. I'm very proud of that first program. I gave it to a friend of mine for their birthday. So anyways, Chris, I have an idea. Let's go on a journey together, shall we? Let's go on an AppSec journey through time, time, time, time.

2:50Chris RomeoLet's go.

2:50Jim ManicoLet's go. Let's Let's talk about SQL injection over time, right? Okay, Chris, go with me now to 1997 where enterprise programmers using Java 1.0.1 on Netscape Navigator 3, and we had in the field, we have salesmen who are selling stuff in like countries where there's no dial-up, they have sat phones like 3600 baud. So what we did was in the client, we built thick client Java applications that would run as an applet through Netscape 3. that would then, as you're building, as you're making queries in the UI, like you're picking dropdown menus, you're typing stuff in, the client would build the SQL statement in the Java app and send it through a network connection through Netscape over the internet to the backend server that would then run the query. Now, that's not really SQL injection. That's more like I'm giving you a direct insert, update, delete prompt directly to the database for everyone, including So that, that's where we used to be when it came to SQL injection. Are you with me now?

3:51Chris RomeoYep, I'm with you.

3:51Jim ManicoWe would just give people like ports to the effing database with full permissions.

3:55Yeah.

3:56Jim ManicoThen we started building SQL. We did CGI, really first generation real web stuff around the same era where we'd build SQL like in, in a backend, in some kind of backend web application on a CGI or early technologies. And we would just take variables and shove them into SQL, maybe do some validation for functionality, But we weren't even thinking about SQL injection even for a decade until like 2007, '08, '09, '10. Even today, some people don't think about it. So back then, 2000s, now we're beginning like first-generation services and stuff, and we're still sending data into like object-relational mapping errors at the early— at that time, or just building SQL. And we would get SQL injection protection by luck. And it's not something we were thinking about development-wise. Then it's like, as 2000 rolls on, OWASP starts getting a little rise, and we start talking about security for the first time. A lot of people are talking about validation now. So this is now like over a decade ago. Even though there is parameterized APIs in Perl about it this era, it's not something that I don't think a lot of literature was talking about. There's a lot of talk—

5:06Chris RomeoWait, there was parameterized APIs in Perl?

5:08Jim ManicoOh yeah.

5:10Chris RomeoOh heck yeah. Or SQL.

5:11Jim ManicoOh yeah, there are SQL parameterized APIs. See, databases needed to support this. I'm not— I don't have a— this is a question I didn't prep for. I'm just going with it, folks. I'm just going with it. But I'm not sure if like the C interfaces into the databases, which a lot of the drivers depend on in some way— I don't even know if that's true— but I don't know if like the parameterized APIs were available, or if they are, their performance hits when they first came out because First, it would— first, the database connection would send the parameterized API— parameterized query with the placeholders, and then it would send the variables in a second pass. Only till later on did the protocols allow you to do both together. This is what— this is the result of doing a parameterized query, sending the query with the placeholder and the variables in a separate pass.

5:57Okay.

5:58Jim ManicoAnd so only until, like, you know, less than 10 years ago did the cry of parameterized queries are now not a performance problem and they're going to really stop injection, did that really show up? So that's recently. That's like maybe in the last— I would say as far as 5 years ago, some use of parameterized queries in older versions of Oracle, to my memory, Oracle 7, 8 type stuff, older versions, parameterized queries would sometimes hurt you horrifically when it comes to performance. I remember that as far as like 8, 9 years ago. That was a problem. And I think more recent versions of databases have addressed this more. So now today we have parameterized queries that combine the placeholder query and the parameters in one basic request to the database. And databases know how to do proper query plan creation of parameterized queries. So you're not getting whacked painfully from a performance point of view as you move from dynamic SQL to a parameterized query. That's kind of where we are today. Let's go back to the beginning, right? We're talking about a Java applet that as you're using the UI, it assembled the SQL statement in the applet and then sent it to the server. That's where we started and we're ending up with optimization at all ends on how to run parameterized queries in most situations. So how long—

7:20Chris RomeoI kind of have this OWASP joke and it kind of always gets a laugh every time. So you can feel free to steal this. You probably use the same one. We have the OWASP Top 10, but yet we have not yet been able to solve the OWASP Top 1 in injection.

7:35Jim ManicoInjection.

7:35Chris RomeoAnd it's, it's, it's just what it is. Like, it's been around, like you just said, I mean, it's been going on for 20 years at this point, and we're still— we put all this focus, and we certainly need to look at everything else in the Top 10, but it's still kind of funny that if we stopped, could we, could we eliminate injection? What would it take to eliminate injection? Across our industry?

7:56Jim ManicoNot gonna happen.

7:58Chris RomeoNever?

7:59Jim ManicoIt requires programmers to primarily do parameterized queries, different kind— is the main defense. You know, have different kinds of input validation, different kinds of data sanitization and detection and logging of these kind of attacks coming in. But the problem is you can have valid data that's valid, some, you know, valid for the use of your application that's still dangerous to injection. So at the end of the day, developers have to write code a certain way. And it'll become, I think it becomes less and less of a problem. There's a lot of other constructs to make SQL injection difficult, like some meta query languages, like for example LINQ for SQL and .NET.

8:39Yeah.

8:39Jim ManicoWill auto-parameterize. You have like object-relational mapping engines that you build your queries through function calls, not through a query language, but through like, like using different object-oriented patterns to tack on WHERE clause criteria.

8:54Chris RomeoLike in Ruby, there's .where and .find and those things. Yeah, exactly.

8:58Jim Manico.where, .find, .union, whatever, that auto-parameterizes as they assemble the query and auto-defend in other ways. So, there's a lot of constructs and knowledge out there to avoid SQL injection. Absolutely. If people want to do it, I think it's one of the easier defenses to add in retroactively after you've made the mistake to go back and fix it. It's not always easy, Chris, but it's doable.

9:22Chris RomeoSo, you know, but you don't think we're going to see that in our lifetime?

9:23Jim ManicoGo away?

9:24Chris RomeoGo away completely.

9:26Jim ManicoIn our lifetime? What's that? Who knows how long we're going to live? 20 years?

9:31Chris RomeoLet's say 20 years from now.

9:32Jim ManicoDo we get to the point where—

9:33Chris Romeo20 years?

9:34Jim ManicoWill injection still be a problem in 20 years? That's a rough one. How about let's go 10 years? Absolutely. 10 years, injection will still be on our plate, I think. 20 years, maybe not. Maybe aliens will come down and give us some like special, you know, alien static analysis that we can add to the compiler at just at compile time to always eliminate SQL injection. I don't know. I don't know, Chris.

9:58Chris RomeoNo, it's, it's, yeah, I mean, 20 years seems, it seems like we should, but we've been at it for 20 years now though, right?

10:03Jim ManicoYeah, but there's more seriousness about it now.

10:06Chris RomeoTrue.

10:06Jim ManicoThere wasn't a big push 20 years ago to behave here, only in special groups. And even 10 years ago, it was still we were still building an industry from scratch. Not from scratch. Let me rephrase that before I upset anyone. 10 years ago, it was still an oddity, AppSec, right? It wasn't mainstream. Today, I think AppSec is a lot more mainstream.

10:25Chris RomeoYeah, that's true. That's true.

10:27Jim ManicoPeople that I would never expect to want AppSec services or training or scanning or pen testing or whatever, everyone's getting involved now. Yeah, that's true.

10:35Chris RomeoThat was fun chasing SQL injection down the rabbit hole here.

10:38Jim ManicoRight on it.

10:39Chris RomeoLet's chase another one down the rabbit hole just for the fun of it. Well, how about cross-site scripting? What's the, you know, what's the history as far as what you can remember about cross-site scripting?

10:47Jim ManicoOh, back in my day, back in the, in the late '90s when we started building web apps.

10:51Chris RomeoLike we should be in rocking chairs, like, you know, on the front porch going back and remember back in my day.

10:55Jim ManicoWe were using like raw template languages, like pre-JSP stuff to just add data and database query data and markup in a servlet. So we're basically like in a raw way, just like outputting database query data and user data directly to SQL statements that directly would dump to a UI in a servlet. It's like real low-level construct, a lot of very little fancy framework wrapped around it. And XSS was just a given, I guess, right? It's not something we think about, any kind of the content injection, that was a given early on. It was trivial. I'm not even sure if people even— I'd love to Google around or search around when content injection was first talked about, when Amit Sethi first talked about DOM-based XSS when the first XSS literature came out, but we didn't even defend against it early on.

11:48Yeah.

11:48Jim ManicoAs the first template languages came out, like Java Standard Taglib, some of the basic ways I can add content to a web page, they would escape some of the variables. I'm not sure if they were doing it for XSS. It was just that standard markup, you know, you want everything to render, so certain characters you, you convert to their HTML entity equivalents, and early Early frameworks would give some escaping on some components that are added to a certain— some templates. Now I could easily add script and raw request data at this era and still have XSS-like vulnerabilities, but at least there was the beginning of these frameworks that handled it.

12:28Chris RomeoYep.

12:28Jim ManicoAnd then like later on, we're now looking at— oh, I would love to look up when a SAPI came out. When, when did Asapi came out? Let's say Asapi came out like, like 10 years ago. So '97, that's like 20 years ago-ish.

12:43Chris RomeoIt's gotta be at least, I mean, I was, we were recommending it when I worked at Cisco 10 years ago.

12:48Jim ManicoLet, let's say 10 years ago. Let's say 10-ish years ago, like 10+ years ago when the first like encode, like escaping libraries came out historically, like the predecessor to Asapi, there's like a real basic encoding project at OWASP. They had an encoding library for a lot of different languages, real primitive. But it still worked. And I would— that probably goes back like 13 years, I think, 12 years even. So the first knowledge that escaping is the way to stop XSS, those original libraries come out. And then as we go like 5 years ago, that's when like Spring and Struts and lots of other frameworks, they begin to push out, you know, it might be more than 5 years, I could be wrong. They begin to push out more mature XSS defense integrated into libraries. Around this time, we see some of the first example of attempts to really build auto-escaping templates as well that handle this. Like, I know Jeff Eichenausky had like an auto-escaping template like 5 years ago, and Go Templates has their auto-escaping template. And I'm thinking that's when like the original like Angulars or JavaScript frameworks that do some escaping start to come out.

13:51Yeah.

13:51Jim ManicoAnd now today, we have relatively mature ability to do escaping, We have knowledge of when escaping is not going to work, and we have a lot of HTML sanitizers like DOMPurify to help sanitize untrusted HTML. We see frameworks that do auto-escaping as the norm these days. We see that even Angular has built-in escaping and HTML sanitization. We're pretty aware that if we put a URI URL into an href, that a JavaScript link is an attack vector that can bypass some of these frameworks.

14:26Chris RomeoYeah.

14:27Jim ManicoSo that's where we are. And then we have content security policy that, that is fairly mature at this point. Like we look at the work at, at Spegniolo and Weichelbaum from Google, who now show us ways to add, you know, fairly dynamic, easy-to-configure policies to drop CSP into a website. So, and we have subresource integrity to limit attacks through third-party libraries. And so now we have, we have a pretty, pretty good idea of how to stop this thing in the modern era. And again, let's go back to the beginning. I'm building servlets with like, where I'm just taking requests and raw SQL data and I'm merging it with string building into other, into primitive pre-4.0 HTML and HTML 3.0 or something. I don't even know if that's, I got that right, but old version of markup and just sending it right to the, right to the browser.

15:17Chris RomeoWow.

15:17Yep.

15:17Jim ManicoWithout even thinking about validating.

15:20Chris RomeoIt was hard enough just to get it, just to get the HTML put out.

15:23Jim ManicoExactly.

15:24Chris RomeoMuch less to worry about an attack that you're, that you're including.

15:26Jim ManicoExactly. And then today we have all these multitude of technology, CSP, auto-escaping, HTML sanitizers, all getting fairly mature at this point if you really want to stop XSS. There you go, Chris. Both of those were like off the cuff of my brain. I did not prepare for either of those journeys down time. I probably got timing wrong, but we did a little like— we took a little poetic license.

15:53Chris RomeoPoetic license.

15:54Jim ManicoThat's okay. That's okay.

15:55Chris RomeoThat's the beautiful thing.

15:56Jim ManicoBased in fact.

15:57Chris RomeoOur intent was good. We weren't, uh, we weren't messing with the dates to make our story sound better. We were just trying to remember. After the break, Jim dives back in to answer whether cross-site scripting can be gone in the next 10 years. The Application Security Podcast operates with support from Security Journey. A Security Belt program provides the 3 pillars of successful AppSec training: learning, application, and experience. Visit us on the web at www.securityjourney.com to learn how you can teach and empower your developers using a new kind of security training. So Jim, do you really think cross-site scripting can be gone in the next 10 years?

16:42Jim ManicoYes, I think it'll be— I'll at least go this far. I think it'll be way less of a problem 10 years from now because all the technologies are in place. I see like in the near future where something like DOM Purify— this is a JavaScript HTML sanitizer— in 10 years it will be part of the browser. It'll be a built-in utility. You want to sanitize markup? Bang, it's in native JavaScript. Like you want all the frameworks 10 years— because JavaScript programmers, they're never gonna be happy with these frameworks. They'll write a whole bunch of new ones next year, the year after, the year after. And the frameworks that start coming out in 2028 they'll have a lot of these defenses built in.

17:21Chris RomeoYou would hope that they would carry the best practices of built-in defenses forward versus hopefully they don't start from scratch for some of these new frameworks and we lose some of that traction. Because I wonder, I wonder, do we have— do we have the traction in the people that are— but I guess you think about like, I mean, who's behind— is it Facebook's the one that's behind React, right?

17:42Jim ManicoAbsolutely.

17:42Chris RomeoSo, so you would think if Facebook comes out with another— if they do something beyond React or some new technology idea they come up with, I would think that they're gonna have the security built in.

17:52Jim ManicoReact is at version like 0.17 or 0.16 or something. I want React 2.0 to have all these problems fixed cuz they're really fixable. Anytime I drop data into a, an anchor tag href link, I want it to automatically validate it's not JavaScript. The, the code for that's already out there in the wild to have a module that does link sanitization to avoid JavaScript links. I want anytime I'm doing, I'm using like Glamorous or some of the React stylers that anytime I put untrusted data or any data into a CSS dynamic block, it automatically CSS escapes or doesn't let me do that. I want anytime in React where I'm dropping props or types in to createElement that it's not gonna— it's gonna do some kind of additional escaping or DOM purifying so I can't get XSS in that area. I'm just saying these little nooks and crannies that we can use to pop React, they can be fixed.

18:43Chris RomeoYeah.

18:43Jim ManicoAnd I'd like to see a version of React someday that does that so I can do the promise of React and just use it and I get most security dialed in. A lot of React programmers think that. And by the way, if you're a React developer who thinks you can just use React and you're all set, this is flat out wrong.

18:59Yeah.

18:59Jim ManicoIt doesn't work that way. There's a lot of little nooks and crannies of things you have to do yourself manually that is unfortunate in React.

19:08Yeah.

19:08Jim ManicoBut there'll be a future time By 2028, Chris, where that's done.

19:13Chris RomeoWe're gonna— what AppSec USA will that be? We'll probably be in— I don't know, who knows— we'll be in, I don't know, Fort Lauderdale, Florida for AppSec USA.

19:22Jim ManicoOr I'll meet you at LastCon 20.

19:23Chris RomeoThere you go.

19:24Jim ManicoI know this year is LastCon 10 or coming, so LastCon 20, we'll talk about it. React 3.0 or 3.8 or whatever that has all the XSS defenses dialed in.

19:34Chris RomeoMakes me wonder though, like How long are web apps— what's the lifespan of a web app these days? Because like, if you think— if we're talking history now, you think about some of those COBOL programs. Remember that whole year 2000 thing where when people were creating the software in the '70s, they're like, oh, this software will be long gone by the time we get to year 2000 and we could potentially have a date problem. What happened? That software was still hanging around in 2000. Of course, we all panicked and nothing happened, but it could have. It could have been. So Does 20 years from now— how many of the web apps we have today still exist in 20 years, or does DevOps allow us to say that those things are all going to be gone and new versions will be put out?

20:13Jim ManicoThere are still mainframes that were built in the early '70s that are serving up data that do mapping to basic web applications, like from the '70s and original '90s. So you never know, is all I can say, how long— what kind of shelf life these web apps have. Who knows? I don't know. I see a lot of crusty stuff in big corps, especially big corps with a long lifecycle. It's like, so you never know, but there is long lifecycle potential in these apps. Absolutely.

20:47Yeah.

20:47Chris RomeoI mean, you think if they, you know, hopefully within 20 years, all those large companies have found DevOps and are implementing it so that some of those things are starting to go away. Let's just pick another hot-button potential soapbox type of issue and say, what's the role of technology in protecting against these things of cross-site scripting and SQL injection? Could the tools that we have today, the IAST tools or the RASP tools, could that be part of the answer for how these things are actually eradicated?

21:20Jim ManicoNo, I'm not going to go there. I don't think testing tools are what's going to help solve these problems. I think I'm going to switch the question and the answer. The question is, how can we build frameworks that developers use day in and day out that don't have these problems? Like, again, I want a framework that you're not allowed to write SQL to. You can only write SQL, like LINQ to SQL or something similar that auto-parameterizes. And seeing that the ability to write flexible enterprise queries, including things like ORDER BY clauses and all the complicated stuff, that's all auto-parameterizable or automatically protected. So developers don't have to think about it. Developer just writes SQL and they rock and they're protected from injection. And I think those kinds of frameworks for data access, they exist. Absolutely they do. Where it's not possible to compile code that's injectable to SQL injection, I think that's possible. And I think the framework should handle that. Not SAST, not DAST, not IAST or RASP, but the framework and the LangSec can handle that. Absolutely.

22:25Chris RomeoYeah.

22:25Jim ManicoThat same thing goes for XML. There's no reason why I can't have a version of React. We could fork it today. Chris, hook me up with a little funding. Give me about $10 mil. I need, I need, I need to make sure I'm taken care of.

22:37Chris RomeoLet me check my bank account.

22:38Jim ManicoA little $10 mil and I will give you— I'll fork React with like 2 other developers and we'll give you a version of React that you cannot XSS. Absolutely, that can be done. It's hard work, requires sophistication. It requires a savage bloody knife to features that people love and depend on. Bloody. That's why I'm saying 2.0. It's gonna be a whole new version of React. Yeah, but we could fork it and fix this up. Pardon my language, but I'm getting a little emotional. So XSS, so these things are not possible. Yeah, and I think we'll see that in the future. That's why I'm hopeful 10 years from now there'll be framework choices that make XSS nearly impossible.

23:13Chris RomeoAbsolutely. Makes me wonder then, what does the tool market look like in 10 or 20 years?

23:18Jim ManicoGoing away.

23:19Chris RomeoYou think it's going away?

23:19Jim ManicoYeah, it'll be integrated into languages. It'll be integrated into frameworks. It'll be integrated Like rather than having a standalone SaaS tool, the Java low-level Java C for Java 38 will have a full static analysis engine built into it at compile time. I just think that the tools will fade into GitHub, will fade into the raw compilers, will fade into the framework. Like I was part of the Breakman team, you know, it's a gem that does Ruby on Rails static analysis. I don't think a standalone gem is the right answer. future. I think a gem that's integrated into the framework of Ruby on Rails that prevents certain code from running, or— that sounds like Rust. I hurt myself there. Well, let's take a step back. Let me try again. Like, the Ruby compiler would run Breakman-like tools in a, hopefully, a 10-year more sophisticated way that does these checks as part of the language itself, not as a standalone thing. That's what I would hope for.

24:15Chris RomeoNo, and I think that's That's certainly almost a perfect state for when we think about applications and the way they're deployed right now. I don't know if we're going to get there.

24:26Jim ManicoI agree.

24:26Chris RomeoBecause I don't know that— take Ruby, for example, with Ruby on Rails. I don't know if the folks that are behind that are going to see the true value. If you and I were behind it, we'd be like, oh, this is our top feature, is to build those types of protections into the language. The folks that are— I don't think that we've got a lot of security people that are leading those types of projects right now. And maybe 10 years from now, maybe things will change, but—

24:52Jim ManicoWell, think of it this way, having like a generic static analysis engine for all languages is just not very high fidelity. That kind of technology doesn't— that kind of technology I don't think works in the modern era. So you almost need a language-specific static analysis engine that's really written for that particular language almost individually. And even that's not good enough because just because you're able to do static analysis on a certain language doesn't mean you can do it in a framework. Like show me JavaScript static analysis that can really do static analysis on React, right? So now I need like a static analysis engine that's React-aware with all those special rules. So the, the level of specif— you have to get so specific to the language. What's that? Help, help me with that word. I wanna get that word. Specif—

25:37Chris RomeoI can't say it either.

25:38Jim ManicoSpecificity?

25:39Chris RomeoThere we go.

25:39Jim ManicoWe got it. Did I get that right? We got it. Wow. That was a little too much for me.

25:42Chris RomeoI hope it was my, it was my little push that helped you over the edge there.

25:45Jim ManicoStatic analysis needs to at least get specific as the language and the rule system needs to get specific to the framework. And the only hope of having really good static analysis in everyone's hands is if it does become, does become more part of the language. Like in Java, you couldn't touch the compiler in terms of getting hooks into it. Now there's direct hooks into it. Now there's direct ways to flag certain constructs in Java for taint tracking at the language level itself. You don't have full Java static analysis at javac right now, but any compiler built into the language, but the features that allow deeper hooks into it are beginning to emerge in the last couple of versions of these languages.

26:26Chris RomeoSo what's the business case though? I mean, I know you spend a lot of time with Java and you're, you're, you know, you speak at a lot of Java conferences and and are involved in that Java security. What's the business case for making that investment though? I mean, is there a business case for whoever— I don't even know. I mean, I know Oracle owns Java ultimately, but for whoever the primary business owner of Java, what's the reasoning behind them making those— adding those type of hooks into the language itself?

26:53Jim ManicoJava is an enterprise language. I'm not sure why they support those features, but these are features that Well, you know what? It's the JEP process. So there, it's not like one corp just builds Java. There's the Java enhancement process. So the squeaky wheel gets the grease. Different teams make proposals. I know, like, the type annotations was from Werner Dietl, was one of the members of that team. They're academics who proposed a tainted flag to do taint tracking in Java. It got accepted and they rolled it, they backported in different versions of Java. That's just from the community process of people who want to get stuff done. Somebody wanted deeper compiler hooks to— so static analysis would be easier to hook into Java. Rock on, that got through. Squeaky wheel gets the grease. I'm not— that might be a simplistic explanation, but I'm just trying to note that in certain languages I see hooks into security testing at lower levels. That gives me hope. And you're trying to push out 20 years, dude, right?

27:49Chris RomeoYeah.

27:50Jim ManicoIn 20 years, I want to have like 6-foot-long hair in like a white robe on a mountainside somewhere with like a lot of paint in my face because I've been busy painting the countryside on an oil painting. Yeah, you know, way in the mountains somewhere. Again, robes, long hair, the whole, the whole thing, right?

28:07Chris RomeoSo not, uh, not teaching.

28:09Jim ManicoNot thinking about advance. Like, if you like call me, like now all of a sudden I'm like envisioning me again in the robes, long hair, oil painting on the mountainside somewhere, and you just showed up like, like with the hiking stick, like, I have some questions about static analysis for you, and then I like beat you to death with my painting and you ruined my zen. Now I just have to hide your body now. So let's— wow, okay. I think, I think that— I think we've, we've exhausted this podcast. I think we've, I think we've come to the end.

28:36Chris RomeoWe're making a— we're making a good— that was a good fun little journey through the history of SQL injection, cross-site scripting. And then, then we looked out into the future. Probably a lot of analysts and people are going to listen to this and be like, you know, we need to, you need to short our static analysis vendors or something.

28:52Jim ManicoI don't know about that, but I don't know that we're that prolific. But certainly the unabridged, the unabridged history, very, very unabridged, extremely unabridged history of SQL injection XSS defense.

29:03Chris RomeoThat's what we'll call it. That'll be the name of this podcast. Extremely, extremely abridged version of this. But now I thank you for taking the time to kind of walk us through your vision of history and also look a little bit in the future. I think that's fun just to think a little bit about what could happen. And certainly we hope that these problems will be fixed at the framework level. It's one of those things where it'd be nice if we were out of a job in 20 years, but I don't think we're— I think there'll be other problems to solve. Even if we're out of the cross-site scripting and SQL injection business, there'll be something else.

29:35Jim ManicoYeah.

29:36Chris Romeothat'll require people in white robes with long hair and oil painting skills to do. So, Jim, thanks for being here with us today and have a great rest of the conference.

29:45Jim ManicoThanks for having me, Chris. Have a great day yourself.

29:47Thanks 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 Carton. You can find us on Twitter @AppSecPodcast or on the web at www.appsecpodcast.org.